100% found this document useful (2 votes)

2K views264 pages

ISA Implementation For SIS

Q: How does the configuration workbench assist in managing application software for automation systems?

The configuration workbench aids in managing application software by providing tools for program development, such as facilities for printing program listings and cross-referencing inputs with outputs. It encourages using small, manageable modules and restricts data access to defined modules. This setup ensures operations on variables are of the expected type and sub-ranges are defined, enhancing software clarity and manageability .

Q: What processes are involved in application software validation, and why are they important?

Application software validation involves verifying that all software requirements are tested and met, conducting tests in the final-use environment, and ensuring individual module testing. These processes are crucial to ensure the software meets the specified safety and operational standards before deployment, mitigating the risks of software failure .

Q: In what ways do ANSI/ISA-84.00.01-2004-1 requirements for Safety Instrumented Systems (SIS) differ from ANSI/ISA-84.01-1996?

ANSI/ISA-84.00.01-2004-1 introduces a more comprehensive SIS lifecycle, addressing activities not covered by ANSI/ISA-84.01-1996 and including new technology-driven requirements . It is aligned with IEC 61508, adopting normative references and including specific software requirements, whereas ANSI/ISA-84.01-1996 offers mainly informative guidance . ANSI/ISA-84.00.01-2004-1 recognizes SIL 4 as the maximum level of performance for Safety Instrumented Functions, up from SIL 3 in the previous standard . It also introduces "Safety Instrumented Function" (SIF) as a distinct term, differentiating it from "SIS," which was less defined in the 1996 version . Furthermore, ANSI/ISA-84.00.01-2004-1 includes specific requirements for functional safety assessments during the SIS lifecycle and requires more formal verification and auditing processes, unlike its predecessor .

Q: How do safety lifecycle requirements in ANSI/ISA-84.00.01-2004-1 enhance the effectiveness of safety instrumented systems compared to previously existing standards?

ANSI/ISA-84.00.01-2004-1 enhances the effectiveness of Safety Instrumented Systems (SIS) by establishing a more comprehensive safety lifecycle that emphasizes risk management and continuous improvement. Unlike ANSI/ISA-84.01-1996, the updated standard incorporates new concepts such as Safety Instrumented Functions (SIF), which provide clearer allocations of safety responsibilities and integration with Hazard and Risk Analysis (H&RA). It also syncs with international standards like IEC 61511, promoting global compatibility . Additionally, the newer standard mandates periodic auditing, competency requirements, and specific guidelines for functional safety assessments to ensure ongoing reliability and risk reduction . These enhancements, including detailed guidance for technology assessment and expanded application software requirements, address previous limitations and adapt to technological advances ."}

Q: Evaluate the challenges associated with device selection for Safety Instrumented Functions with respect to IEC 61508 compliance and field experience.

Challenges in selecting devices for Safety Instrumented Functions (SIF) with respect to IEC 61508 compliance and field experience include the absence of standard methodologies for IEC 61508 certification and compliance assessment, requiring users to perform detailed reviews of certification claims and to rely on both compliance reports and actual operating experience before device selection . Many manufacturers claim devices to be "suitable" or "qualified" for certain Safety Integrity Levels (SILs), but these terms lack a consensus definition and often require detailed assessments to establish the SIL claim limit . Furthermore, IEC 61508 assessments may not cover systematic failures associated with application software design or process interfaces, emphasizing the importance of combining compliance information with field history to understand potential performance . Field experience or "prior use" is a crucial element, especially when IEC 61508-compliant devices are not available; collecting and evaluating operational data to justify device selection can be challenging—particularly for complex devices with limited variability programming .

Q: What is the significance of PFDavg in evaluating the performance of Safety Instrumented Functions, and how is it calculated?

PFDavg (Probability of Failure on Demand average) is a key measure in evaluating the performance of Safety Instrumented Functions (SIFs) as it indicates the likelihood that a safety system will fail to perform its intended function upon demand. It is crucial for determining Safety Integrity Level (SIL) classifications, where a lower PFDavg corresponds to higher SIL, representing better safety performance . The PFDavg is calculated using failure rates of individual components within the SIF, taking into account factors like random and systematic failures, diagnostics, and mechanical integrity activities . Maintaining an effective mechanical integrity program helps ensure that the PFDavg remains consistent with the required SIL .

Q: Can you analyze the impact of shared hardware and software in achieving target hazard rates in safety instrumented systems?

Shared hardware and software in safety instrumented systems (SIS) must be designed and managed with care to meet target hazard rates. Physical separation between protection layers is recommended to prevent common-cause failures, which can compromise safety. Using shared components requires rigorous evaluation to address potential common-mode, common-cause, and dependent failures across the system's lifecycle, ensuring required risk reduction levels are maintained. Software errors should be predicted and mitigated with stringent validation processes, especially as systematic errors are challenging to detect and control. Ensuring the separation of control and safety functions through hardware and software configuration is essential to maintain system integrity. Moreover, management of change procedures must be robust to prevent inadvertent modifications that could impact safety functions in SIS. These measures collectively ensure that integrated systems can reliably meet safety performance criteria while managing shared components efficiently.

Q: How does testing frequency relate to the operational mode of a Safety Instrumented Function (SIF) and its reliability in critical processes?

Testing frequency directly impacts the reliability of a Safety Instrumented Function (SIF) in critical processes by influencing the probability of failure on demand (PFD). More frequent testing generally leads to earlier detection of failures and better reliability, reducing the PFD and enhancing the system's capability to perform its intended safety function . Additionally, ANSI/ISA-84.00.01 emphasizes the importance of a structured mechanical integrity program and regular testing to maintain the specified Safety Integrity Level (SIL) and ensure long-term operation and reliability of the Safety Instrumented System (SIS). Thus, the operational mode and designated SIL of a SIF dictate its testing frequency, balancing reliability with operational considerations ."}

ISA Implementation for SIS Safety

Uploaded by

Mauro MLR

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (2 votes)

2K views264 pages

ISA Implementation For SIS

ISA Implementation for SIS Safety

Uploaded by

Mauro MLR

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

TECHNICAL REPORT

ISA-TR84.00.04-2011
Part 1
Guidelines for the Implementation of ANSI/ISA-84.00.01-2004
(IEC 61511 Mod)

Approved 14 October 2011

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Part 1 - Guideline for the Implementation of ANSI/ISA-84.00.01-2004 (IEC 61511)

ISBN: 978-1-937560-24-9

Copyright © 2011 by the International Society of Automation (ISA). All rights reserved. Not for resale.
Printed in the United States of America. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted in any form or by any means (electronic mechanical, photocopying,
recording, or otherwise), without the prior written permission of the Publisher.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

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

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Preface

This preface, as well as all footnotes and annexes, is included for information purposes and is not part of
ISA-TR84.00.04.

This document has been prepared as part of the service of the International Society of Automation (ISA)
toward a goal of uniformity in the field of instrumentation. To be of real value, this document should not be
static but should be subject to periodic review. Toward this end, the Society welcomes all comments and
criticisms and asks that they be addressed to the Secretary, Standards and Practices Board; ISA; 67
Alexander Drive; P. O. Box 12277; Research Triangle Park, NC 27709; Telephone (919) 549-8411; Fax
(919) 549-8288; E-mail: standards@isa.org.

It is the policy of ISA to encourage and welcome the participation of all concerned individuals and
interests in the development of ISA standards, recommended practices, and technical reports.
Participation in the ISA 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.

CAUTION — ISA DOES NOT TAKE ANY POSITION WITH RESPECT TO THE EXISTENCE OR
VALIDITY OF ANY PATENT RIGHTS ASSERTED IN CONNECTION WITH THIS DOCUMENT, AND
ISA DISCLAIMS LIABILITY FOR THE INFRINGEMENT OF ANY PATENT RESULTING FROM THE
USE OF THIS DOCUMENT. USERS ARE ADVISED THAT DETERMINATION OF THE VALIDITY OF
ANY PATENT RIGHTS, AND THE RISK OF INFRINGEMENT OF SUCH RIGHTS, IS ENTIRELY THEIR
OWN RESPONSIBILITY.

PURSUANT TO ISA’S PATENT POLICY, ONE OR MORE PATENT HOLDERS OR PATENT

APPLICANTS MAY HAVE DISCLOSED PATENTS THAT COULD BE INFRINGED BY USE OF THIS
DOCUMENT AND EXECUTED A LETTER OF ASSURANCE COMMITTING TO THE GRANTING OF A
LICENSE ON A WORLDWIDE, NON-DISCRIMINATORY BASIS, WITH A FAIR AND REASONABLE
ROYALTY RATE AND FAIR AND REASONABLE TERMS AND CONDITIONS. FOR MORE
INFORMATION ON SUCH DISCLOSURES AND LETTERS OF ASSURANCE, CONTACT ISA OR
VISIT WWW.ISA.ORG/STANDARDSPATENTS.

OTHER PATENTS OR PATENT CLAIMS MAY EXIST FOR WHICH A DISCLOSURE OR LETTER OF
ASSURANCE HAS NOT BEEN RECEIVED. ISA IS NOT RESPONSIBLE FOR IDENTIFYING PATENTS
OR PATENT APPLICATIONS FOR WHICH A LICENSE MAY BE REQUIRED, FOR CONDUCTING
INQUIRIES INTO THE LEGAL VALIDITY OR SCOPE OF PATENTS, OR DETERMINING WHETHER
ANY LICENSING TERMS OR CONDITIONS PROVIDED IN CONNECTION WITH SUBMISSION OF A
LETTER OF ASSURANCE, IF ANY, OR IN ANY LICENSING AGREEMENTS ARE REASONABLE OR
NON-DISCRIMINATORY.

ISA REQUESTS THAT ANYONE REVIEWING THIS DOCUMENT WHO IS AWARE OF ANY PATENTS
THAT MAY IMPACT IMPLEMENTATION OF THE DOCUMENT NOTIFY THE ISA STANDARDS AND
PRACTICES DEPARTMENT OF THE PATENT AND ITS OWNER.

ADDITIONALLY, THE USE OF THIS DOCUMENT MAY INVOLVE HAZARDOUS MATERIALS,

OPERATIONS OR EQUIPMENT. THE DOCUMENT CANNOT ANTICIPATE ALL POSSIBLE
APPLICATIONS OR ADDRESS ALL POSSIBLE SAFETY ISSUES ASSOCIATED WITH USE IN
HAZARDOUS CONDITIONS. THE USER OF THIS DOCUMENT MUST EXERCISE SOUND
PROFESSIONAL JUDGMENT CONCERNING ITS USE AND APPLICABILITY UNDER THE USER’S
PARTICULAR CIRCUMSTANCES. THE USER MUST ALSO CONSIDER THE APPLICABILITY OF
ANY GOVERNMENTAL REGULATORY LIMITATIONS AND ESTABLISHED SAFETY AND HEALTH
PRACTICES BEFORE IMPLEMENTING THIS DOCUMENT.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

THE USER OF THIS DOCUMENT SHOULD BE AWARE THAT THIS DOCUMENT MAY BE IMPACTED
BY ELECTRONIC SECURITY ISSUES. THE COMMITTEE HAS NOT YET ADDRESSED THE
POTENTIAL ISSUES IN THIS VERSION.

The following served as members of ISA84 in developing this technical report:

NAME COMPANY
W. Johnson, Chair DuPont Sustainable Solutions
V. Maggioli, Co-Managing Director Feltronics Corp
D. Zetterberg, Co-Managing Director Chevron Energy Technology Company
A. Summers, TR Working Group Leader SIS-TECH Solutions LP
R. Adamski RA Safety Consulting LLC
T. Ando Yokogawa Electric Co
R. Avali Westinghouse Electric Corp
L. Beckman Safeplex Systems Inc
J. Campbell ConocoPhillips
I. Chen Aramco
R. Chittilapilly Oil & Natural Gas Corp
M. Coppler Ametek Inc
M. Corbo ExxonMobil
P. Early Langdon Coffman Services
C. Fialkowski Siemens Inc
K. Gandhi KBR
I. Gibson Consultant
J. Gilman JFG Technology Transfer LLC
W. Goble Exida
P. Gruhn ICS Triplex

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
B. Hampshire BP
J. Harris UOP A Honeywell Company
J. Jamison EnCana Corporation Ltd
R. Johnson Dow Process Automation
K. Klein Celanese Corp
T. Layer Emerson Process Management
E. Marszal Kenexis Consulting Corp
N. McLeod ARKEMA
M. Mollicone SYM Consultoria
G. Ramachandran Systems Research Intl Inc
R. Roberts Suncor Energy Inc
M. Scott AE Solutions
D. Sniezek Lockheed Martin Federal Services
C. Sossman CLS Tech-Reg Consultants
R. Strube Strube Industries
L. Suttinger Savannah River Nuclear Solutions
T. Walczak Conversions Inc
M. Weber System Safety Inc
A. Woltman Shell Global Solutions
P. Wright BHP Engineering & Construction Inc

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

This technical report was approved for revision by the ISA Standards and Practices Board
on 14 October 2011.

NAME COMPANY
D. Dunn, Vice President Aramco Services Co.
E. Cosman, Vice President-Elect The Dow Chemical Co.
D. Bartusiak ExxonMobil Research & Engineering
P. Brett Honeywell Inc.
J. Campbell ConocoPhillips
M. Coppler Ametek Inc.
B. Dumortier Schneider Electric
J. Federlein Federlein & Assoc. Inc.
J. Gilsinn NIST/MEL
E. Icayan ACES Inc.
J. Jamison EnCana Corporation Ltd.
K. Lindner Endress+Hauser Process Solutions AG
V. Maggioli Feltronics Corp.
T. McAvinew Jacobs Engineering
R. Reimer Rockwell Automation
S. Russell Valero Energy Corp.
N. Sands DuPont
H. Sasajima Yamatake Corp.
T. Schnaare Rosemount Inc.
J. Tatera Tatera & Associates Inc.
I. Verhappen Industrial Automation Networks Inc.
W. Weidman Consultant
J. Weiss Applied Control Solutions LLC
M. Wilkins Yokogawa IA Global Marketing (USMK)
D. Zetterberg Chevron Energy Technology Company

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Foreword

ANSI/ISA-84.00.01-2004 gives requirements for the specification, design, installation, operation and
maintenance of SIS, so that it can be confidently entrusted to place and/or maintain the process in a safe
state. These requirements are presented in the standard, using the safety lifecycle shown in ANSI/ISA-
84.00.01-2004-1, Figure 8, and described in ANSI/ISA-84.00.01-2004-1 Table 2.

The ISA84 committee has developed a series of complimentary technical reports to provide guidance, as
well as practical examples of implementation, on various topics and applications. Three of these technical
reports, ISA-TR84.00.02, ISA-TR84.00.03 and ISA-TR84.00.04, provide informative guidance related to
specific phases of the Safety Instrumented System (SIS) lifecycle. Figure 8 and Table 2 have been
adapted for this foreword as shown in ISA-TR84.00.04 Figure 1 and Table 1, respectively. A brief
overview of each technical report is given below, including the report’s relationship to the lifecycle
requirements and the intended scope of each report’s guidance.

ISA-TR84.00.02—Safety Integrity Level (SIL) Verification of Safety Instrumented Functions—

Lifecycle phase 4 requires verification that the intended or installed SIS meets its specified SIL. To
support the calculation of the average probability of failure on demand as required by ANSI/ISA-84.00.01
Clause 11.9, ISA-TR84.00.02 provides guidance on the following: a) assessing random and systematic
failures, failure modes and failure rates; b) understanding the impact of diagnostics and mechanical
integrity (MI) activities on the SIL and reliability; c) identifying sources of common cause, common mode
and systematic failures; and d) using quantitative methodologies to verify the SIL and spurious trip rate.
The approaches outlined in this document are performance-based; consequently, the reader is cautioned
to understand that the examples provided do not represent prescriptive architectural configurations or MI
requirements for any given SIL. Once an SIS is designed and installed, the ability to maintain the
specified SIL requires the implementation of a structured MI program as described in ISA-TR84.00.03

ISA-TR84.00.03—Mechanical Integrity of Safety Instrumented Systems (SIS)—Lifecycle phases 5

and 6 involve the installation and testing of the SIS, the validation that the SIS meets the safety
requirements specification, and the assurance that functional safety is maintained during long-term
operation and maintenance. An important aspect of achieving and maintaining the SIS integrity and its
specified SIL is the implementation of an MI program that provides quality assurance of the installed SIS
performance. This technical report is an informative document providing guidance on establishing an
effective MI program that demonstrates, through traceable and auditable documentation, that the SIS and
its equipment are maintained in the “as good as new” condition. The technical report addresses the
identification of personnel roles and responsibilities when establishing an MI plan, important
considerations in establishing an effective MI program, and detailed examples to illustrate user work
processes used to support various activities of the MI program. Data and information collected as part of
the MI program can be used to validate the SIL Verification calculations, as discussed in ISA-TR84.00.02
and the selection, and continued use of devices, as discussed in ISA-TR84.00.04 Annex L.

ISA-TR84.00.04-Guidelines for the Implementation of ANSI/ISA-84.00.01—Lifecycle phases 2, 4, 9

and 10 address the management of functional safety, allocation of safety functions to protection layers,
SIS design and engineering, and SIS verification. This technical report is divided into two parts. Part 1
provides an overview of the SIS lifecycle with references to annexes containing more detailed guidance
on various subjects. Part 2 provides an end-user example of how to implement ANSI/ISA-84.00.01. This
report covers many aspects of the safety lifecycle, including such topics as: "grandfathering" existing SIS
(Clause 3 and Annex A); operator initiated functions (Annex B), separation of the Basic Process Control
System (BPCS) and SIS (Annex F), field device and logic solver selection (Annex L), manual shutdown
considerations (Annex P), and design/installation considerations (e.g., wiring, power, relationship to
BPCS, common mode impacts, fault tolerance, etc. – Annex N). ISA-TR84.00.02 expands Annex G,
which only provides a brief introduction to the topic of failure calculations. ISA-TR84.00.04 does not
address the MI program, which is discussed in ISA-TR84.00.03.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Manage- Safety Hazard & Risk Analysis Verifica-

ment of Lifecycle Clause 8 tion
Function Structure 1
al Safety and
and Planning Allocation of Safety
Function Functions to
al Safety Protection Layers
Assess- 2 Clause 9
ment and
Auditing
Safety Requirements

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Specification for the
Safety Instrumented
System
3 Clauses 10 & 12

Design and Engineering of Design and Development

Safety Instrumented of Other
System Means of Risk Reduction
4 Clauses 11 & 12 Clause 9

Installation, Commissioning
and Validation
Clause 14 &15
5

Operation and Maintenance

6 Clause 16

Modification
7 Clause 17
Clauses 7,
Clause 5 Clause 6.2 12.4 &
Decommissioning 12.7
10 11 8 Clause 18 9
Legend:

No guidance is provided in this technical report

Guidance is provided in this technical report

Figure 1 – SIS Safety Lifecycle (modified ANSI/ISA-84.00.01-1 Figure 8)

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Table 1 - SIS safety life-cycle overview (modified ANSI/ISA-84.00.01-1 Table 2)

Safety lifecycle phase or Objectives ANSI/ISA-84.00.01 ISA-84

activity Requirements Technical Report
Figure Title Clause Reference
1 box
number

1 Hazard and risk To determine the 8 None

analysis hazards and hazardous
events of the process
and associated
equipment, the sequence
of events leading to the
hazardous event, the
process risks associated
with the hazardous
event, the requirements
for risk reduction, and
the safety functions
required to achieve the
necessary risk reduction.
2 Allocation of safety Allocation of safety 9 ISA-TR84.00.04 Annexes
functions to functions to protection B, F, and J
protection layers layers and for each
safety instrumented
function, the associated
safety integrity level.
3 SIS safety To specify the 10 No specific guidance on
requirements requirements for each documenting the SRS. An
specification (SRS) SIS, in terms of the example is shown in ISA-
required safety TR84.00.04 Part 2. All
instrumented functions three technical reports
and their associated (ISA-TR84.00.02, 03, and
safety integrity, in order 04) provide fundamental
to achieve the required considerations for SRS
functional safety. development.
4 SIS design & To design the SIS to 11 & 12.4 ISA-TR84.00.04 Annexes
engineering meet the requirements F, G, I, K, L, M, N, O, P,
for safety instrumented and Q
functions and safety ISA-TR84.00.02
integrity.
5 SIS installation To integrate and test the 12.3, 14, 15 ISA-TR84.00.03
commissioning & SIS.
validation To validate that the SIS
meets, in all respects,
the requirements for
safety in terms of the
required Safety
Instrumented Functions
and the required safety
integrity.
6 SIS operation and To ensure that the 16 ISA-TR84.00.03
maintenance functional safety of the
SIS is maintained during
operation and
maintenance.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

(Continued on next page)

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

(Table 1 continued from previous page)

Safety lifecycle phase or Objectives ANSI/ISA-84.00.01 ISA-84

activity Requirements Technical Report
Figure Title Clause Reference
1 box
number

7 SIS modification To make corrections, 17 Apply appropriate safety

enhancements, or lifecycle phase during
adaptations to the SIS, management-of-change
ensuring that the activity.
required safety integrity
level is achieved and
maintained.

8 Decommissioning To ensure proper review, 18 Apply appropriate safety

sector organization, and lifecycle phase during
ensure Safety project execution
Instrumented Function
(SIF) remain
appropriate.
9 SIS verification To test and evaluate the 7, 12.7 ISA-TR84.00.04 Annex C,
outputs of a given phase ISA-TR84.00.03, and ISA-
to ensure correctness TR84.00.02
and consistency with
respect to the products
and standards provided
as input to that phase.
10 SIS functional safety To investigate and arrive 5 ISA-TR84.00.04, Clause 3,
assessment at a judgement on the and Annexes A, C, D, E,
functional safety and S
achieved by the SIS.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

CONTENTS
1 Purpose ............................................................................................................................................... 17

2 Introduction.......................................................................................................................................... 17

3 Grandfather clause .............................................................................................................................. 18

3.1 General considerations .............................................................................................................. 19

3.2 Management-of-change considerations ..................................................................................... 19
4 Overview ............................................................................................................................................. 21

4.1 Lifecycle approach ..................................................................................................................... 22

4.2 Define a risk-management strategy ........................................................................................... 22
4.3 Implement the strategy............................................................................................................... 23
4.4 Validate, start-up, operate and maintain the strategy ................................................................ 26
4.5 Manage changes to the strategy ................................................................................................ 27
Annex A – Example methods for determining grandfather status ...................................................... 29

A.1 Purpose ...................................................................................................................................... 29

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

A.2 Timing......................................................................................................................................... 29
A.3 Approaches to the grandfather clause ....................................................................................... 30
Annex B – Operator action as an Independent Protection Layer (IPL) ............................................... 47

B.1 Purpose ...................................................................................................................................... 47

B.2 Key points ................................................................................................................................... 47
B.3 BPCS operator action ................................................................................................................ 48
B.4 Operator-initiated SIF ................................................................................................................. 48
B.5 Human response-time criteria .................................................................................................... 49
B.6 Verification of an operator-initiated SIF ...................................................................................... 52
Annex C – Management of functional safety ......................................................................................... 55

C.1 Purpose ...................................................................................................................................... 55

C.2 Identification of the right people ................................................................................................. 55
C.3 Development of a work process ................................................................................................. 56
C.4 Roles and responsibilities matrix................................................................................................ 56
Annex D – Verification, validation, and functional safety assessments ............................................. 85

D.1 Purpose ...................................................................................................................................... 85

D.2 Verification.................................................................................................................................. 85
D.3 Validation.................................................................................................................................... 85
D.4 Functional Safety Assessment (FSA) ........................................................................................ 86
Annex E – Audits ..................................................................................................................................... 112

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

E.1 Purpose .................................................................................................................................... 112

E.2 Audit frequency ........................................................................................................................ 112
E.3 Audit participants ...................................................................................................................... 112
E.4 Auditing against requirements.................................................................................................. 112
E.5 Audit preparation ...................................................................................................................... 112
E.6 Audit kickoff .............................................................................................................................. 113
E.7 Audit protocol ........................................................................................................................... 113
E.8 Procedure review ..................................................................................................................... 113
E.9 Interviews ................................................................................................................................. 114
E.10 Record review .......................................................................................................................... 114
E.11 Field audit ................................................................................................................................. 114
E.12 Presentation of findings ............................................................................................................ 114
E.13 Examples of audit findings ....................................................................................................... 114
Annex F – BPCS and its relationship to the SIS .................................................................................. 118

F.1 Purpose .................................................................................................................................... 118

F.2 Considerations on the use of the BPCS .................................................................................. 118
F.3 Sharing the logic solver between the SIS and the BPCS ........................................................ 121
F.4 Physically separate and diverse SIS logic solver..................................................................... 123
F.5 Sharing of field devices between the BPCS and the SIS ........................................................ 124
F.6 Example ................................................................................................................................... 128
Annex G – Failures - Types, classifications, sources and strategy for defense .............................. 134

G.1 Purpose .................................................................................................................................... 134

G.2 Systematic failures ................................................................................................................... 134
G.3 Random failures ....................................................................................................................... 135
G.4 Summary of differences between random and systematic failure ........................................... 135
G.5 Failure classifications ............................................................................................................... 135
G.6 Sources of failures by lifecycle phase ...................................................................................... 140
G.7 Common-cause failure ............................................................................................................. 142
G.8 Strategy for defense against failures ....................................................................................... 143
Annex H – SIF versus interlocks, permissives, and inhibits .............................................................. 148

H.1 Purpose .................................................................................................................................... 148

H.2 Interlock .................................................................................................................................... 148
H.3 Permissives .............................................................................................................................. 149
H.4 Inhibits ...................................................................................................................................... 149

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

H.5 Safety function.......................................................................................................................... 150

H.6 Safety Instrumented Function (SIF) ......................................................................................... 151
H.7 Safety Instrumented System (SIS) ........................................................................................... 152
Annex I – Continuous, high, and low demand mode .......................................................................... 154

I.1 Purpose .................................................................................................................................... 154

I.2 Introduction............................................................................................................................... 154
I.3 Continuous mode examples..................................................................................................... 157
I.4 High-demand-mode examples ................................................................................................. 158
I.5 Low-demand examples ............................................................................................................ 159
I.6 Application guidance ................................................................................................................ 162
I.7 Consideration of diagnostics in high/continuous demand ........................................................ 163
Annex J – SIL 4 versus inherently safer design .................................................................................. 165

J.1 Purpose .................................................................................................................................... 165

J.2 Re-evaluate the allocation of safety functions to protection layers .......................................... 165
J.3 Reduce risk by applying inherently safer principles ................................................................. 166
Annex K – Fault tolerance topics .......................................................................................................... 167

K.1 Purpose .................................................................................................................................... 167

K.2 General consideration .............................................................................................................. 167
K.3 Fault tolerance and common-cause failures ............................................................................ 168
K.4 Safe failure fraction .................................................................................................................. 173
Annex L – Device selection .................................................................................................................... 175

L.1 Purpose .................................................................................................................................... 175

L.2 Scope ....................................................................................................................................... 175
L.3 Terminology.............................................................................................................................. 176
L.4 Device selection process ......................................................................................................... 178
L.5 IEC 61508 compliance ............................................................................................................. 178
L.6 ANSI/ISA-84.00.01-2004 prior use assessment ...................................................................... 182
L.7 Optimal approach to device selection “user approved” ........................................................... 184
L.8 SIL claim limit considerations ................................................................................................... 194
Annex M – General purpose versus safety logic solvers ................................................................... 195

M.1 Purpose .................................................................................................................................... 195

M.2 General purpose logic solver background ............................................................................... 195
M.3 General purpose logic solvers for safety applications ............................................................. 196
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

M.4 Safety-configured logic solvers for safety applications ............................................................ 197

M.5 IEC 61508 compliant PE logic solvers ..................................................................................... 197

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex N – Design guidance ................................................................................................................... 199

N.1 Purpose .................................................................................................................................... 199

N.2 Communications between BPCS and SIS ............................................................................... 199
N.3 Architecture .............................................................................................................................. 200
N.4 Technology selection ............................................................................................................... 200
N.5 Electronic technology used in SIS............................................................................................ 202
N.6 PES technology used in SIS .................................................................................................... 203
N.7 Diagnostics ............................................................................................................................... 203
N.8 Field devices ............................................................................................................................ 206
N.9 User interface ........................................................................................................................... 208
N.10 Security .................................................................................................................................... 210
N.11 Wiring practices ........................................................................................................................ 211
N.12 Proof-test interval ..................................................................................................................... 212
N.13 Power sources.......................................................................................................................... 212
Annex O – Software ................................................................................................................................ 217

O.1 Purpose .................................................................................................................................... 217

O.2 What are the differences .......................................................................................................... 217
O.3 Software design considerations ............................................................................................... 219
O.4 Handling of software systematic errors .................................................................................... 220
Annex P – Response to detection of a dangerous fault ..................................................................... 223

P.1 Purpose .................................................................................................................................... 223

P.2 The basics ................................................................................................................................ 223
P.3 Manual shutdown requirements ............................................................................................... 225
P.4 Fault tolerant mode – Demand and continuous mode ............................................................. 226
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

P.5 No fault tolerance - Demand mode .......................................................................................... 227

P.6 No fault tolerance - Continuous mode ..................................................................................... 227
P.7 Advantages and disadvantages of the diagnostic alarm response alternatives ...................... 227
P.8 Examples.................................................................................................................................. 229
Annex Q – Setpoint guidance ................................................................................................................ 231

Q.1 Purpose .................................................................................................................................... 231

Q.2 Scope ....................................................................................................................................... 231
Q.3 Definitions ................................................................................................................................. 231
Q.4 Establishment of setpoints ....................................................................................................... 233
Q.5 Documentation ......................................................................................................................... 238

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Q.6 Testing and maintenance of SIS setpoints .............................................................................. 239

Annex R – Key performance indicators ................................................................................................ 241

Annex S – Differences between 1996 and 2004 versions ................................................................... 245

S.1 Clause 1 - Scope ...................................................................................................................... 245

S.2 Clause 2 – References ............................................................................................................. 245
S.3 Clause 3 – Abbreviations and definitions ................................................................................. 246
S.4 Clause 4 – Conformance to standard ...................................................................................... 246
S.5 Clause 5 – Management of functional safety ........................................................................... 246
S.6 Clause 6 – Safety lifecycle requirements ................................................................................. 247
S.7 Clause 7 – Verification ............................................................................................................. 247
S.8 Clause 8 – Process hazard and risk analysis .......................................................................... 247
S.9 Clause 9 – Allocation of safety functions to protection layers .................................................. 249
S.10 Clause 10 – SIS safety requirement specification ................................................................... 250
S.11 Clause 11 – SIS design and engineering ................................................................................. 250
S.12 Clause 12 – Requirements for application software, including selection criteria for utility
software ............................................................................................................................................... 251
S.13 Clause 13 – Factory Acceptance Testing (FAT) ...................................................................... 251
S.14 Clause 14 – SIS installation and commissioning ..................................................................... 251
S.15 Clause 15 - SIS safety validation ............................................................................................. 251
S.16 Clause 16 – SIS operation and maintenance .......................................................................... 251
S.17 Clause 17 SIS modification ..................................................................................................... 252
S.18 Clause 18 – SIS decommissioning .......................................................................................... 252

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
S.19 Clause 19 – Information and documentation requirements ..................................................... 252
Annex T – Acronyms and abbreviations .............................................................................................. 255

Annex U – References ............................................................................................................................ 259

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

1 Purpose
ANSI/ISA-84.01-1996 has been retired and replaced with ANSI/ISA-84.00.01-2004 Parts 1-3 (IEC 61511
Mod). The new standard is the ANSI/ISA adoption of the international standard, IEC 61511, and includes
one additional clause, a grandfather clause covering existing SIS (ANSI/ISA-84.00.01-2004 Part 1 Clause
1.0 y).

This technical report is divided into two parts.

• Part 1 provides guidance on a wide range of topics related to the standard.

• Part 2 provides a single user example to illustrate some of the lifecycle steps in ANSI/ISA-
84.00.01-2004.

ISA-TR84.00.04 Part 1 (ISA-TR84.00.04-1) contains four main clauses.

• Clause 1 is the purpose.

• Clause 2 explains the origins of the new standard and discusses its relationship to other
regulations, standards, and practices.

• Clause 3 and Annex A specifically address the grandfather clause and provide guidance on the
evaluation of existing SIS.

• Clause 4 provides an overview of the SIS lifecycle and references to subject-specific annexes for
additional guidance on key issues.

There is nothing in this guideline that precludes, replaces, or makes obsolete any requirement of
ANSI/ISA-84.01-1996 or ANSI/ISA-84.00.01-2004-1. This guideline is a “how to” approach and
provides informative, non-mandatory methods.

2 Introduction
In the United States of America, the Occupational Safety and Health Administration (US-OSHA)
regulation, 29CFR1910.119 (OSHA 1910.119), requires the identification and management of the
instrumented systems responsible for safe operation. ISA Standards Panel 84 (ISA84) developed
ANSI/ISA-84.01-1996 to define how to manage Safety Instrumented Systems (SIS) using a lifecycle
approach. The standard provided a formal, documented process for addressing the design, operation,
maintenance, testing and management of change for SIS. The efforts of the ISA84 committee resulted in
US-OSHA recognizing ANSI/ISA-84.01-1996 as representing good engineering practices for SIS.

During its initial development, the ISA84 committee relied on existing US functional safety practices, such
as those documented in OSHA 1910.119 and by the Center for Chemical Process Safety (CCPS)
Guidelines for the Safe Automation of Chemical Processes. Working in parallel to the ISA84 committee
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

effort, the International Electrotechnical Commission (IEC) was developing IEC 61508. Concepts
introduced in the draft international standard were incorporated into ANSI/ISA-84.01-1996, resulting in
ANSI/ISA-84.01-1996 being accepted as the US functional safety standard for the process sector.
Through ANSI/ISA-84.01-1996, owners/operators have become familiar with terms, such as safety
integrity levels, safety instrumented systems, and safety functions (i.e., safety instrumented function).

Since 1996, some countries have utilized ANSI/ISA-84.01-1996, while others have used their own
national standard or adopted IEC 61508 when it was released in 1999. In an era where design,
engineering, and operation can occur in multiple countries, this diversity of standards resulted in an
immediate need for an international, consensus process-sector standard.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

The IEC 61511 committee was formed to specifically address the process sector under the framework of
IEC 61508. This international consensus standard was issued in 2003. With the completion of IEC 61511,
the ISA84 committee accepted IEC 61511 as ISA-84.00.01-2004 (IEC 61511 modified). Once the
standard was accepted by ISA, the ISA84 committee immediately initiated the development of this
guideline. ANSI approved the new standard as ANSI/ISA-84.00.01-2004 in September 2004.

• The 1st edition of ISA-TR84.00.04 was intended for readers who were familiar with ANSI/ISA
91.00.01-2001, ANSI/ISA-84.01-1996, ISA-TR84.00.02, ISA-TR84.00.03, and ANSI/ISA-
84.00.01-2004 (IEC 61511 modified).

• ISA-TR84.00.04-1 Annex S provides an overview of the differences between ISA-84.01-1996 and

ISA-84.00.01-2004.

• This 2nd edition of ISA-TR84.00.04-1 amends and updates some guidance, but predominantly
expands guidance related to user approval (Annex L), setpoint determination (Annex Q), and
performance metrics (Annex R). Additional guidance on applying SIS as well as instrumented
protective systems can be found in CCPS Guidelines for Safe and Reliable Instrumented
Protective Systems, published in 2007.

3 Grandfather clause
The concept of the grandfather clause in ANSI/ISA-84.00.01-2004-1 originated with OSHA 1910.119. The
grandfather clause's intent is to recognize prior good engineering practices (e.g., ANSI/ISA-84.01-1996)
and to allow their continued use with regard to existing SIS.

The grandfather clause (ANSI/ISA-84.00.01-2004-1 Clause 1.0 y) states: “For existing SIS designed and
constructed in accordance with codes, standards, or practices prior to the issuance of this standard (e.g.
ANSI/ISA-84.01-1996), the owner/operator shall determine that the equipment is designed, maintained,
inspected, tested, and operating in a safe manner.”

NOTE For more detail, see OSHA 29CFR 1910.119 (d) (iii).

The grandfather clause establishes that the owner/operator of an SIS designed and constructed prior to
the issuance of the standard should demonstrate that the “equipment is designed, maintained, inspected,
tested and operating in a safe manner.” There are two essential steps:

1) Confirm that a hazard and risk analysis has been done to determine qualitatively or quantitatively
the level of risk reduction needed for each Safety Instrumented Function (SIF) in the SIS.

2) Confirm that an assessment of the existing SIF has been performed to determine that it delivers
the needed level of risk reduction.

NOTE The evaluation of the SIF should take into account various factors, such as device failure rates and associated
design, operation, maintenance, testing, inspection and management-of-change practices.

If the above activities have not been done, they should be scheduled for review at the next appropriate
opportunity. Various considerations related to timing are discussed in ISA-TR84.00.04-1 Annex A.2.

The grandfather clause releases the owner/operator from the design and construction requirements of
ANSI/ISA-84.00.01-2004-1 for existing installations if they can demonstrate these criteria. This leads to
questions regarding how to demonstrate compliance with the grandfather clause and at what point
modifications to the process or the SIS have become significant enough to warrant reassessment of the
adequacy of the SIS.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

NOTE 1 There are many processes that are not covered under OSHA 1910.119. Some owners/operators choose to manage these
processes under the same program as their covered processes. The discussion in this section is considered applicable to non-
covered process SIS.

NOTE 2 US-OSHA has published guidance on the interpretation of the OSHA 1910.119 grandfather clause with regard to the
Process Safety Management program (Refer to Appendix C to 1910.119 -- Compliance Guidelines and Recommendations for
Process Safety Management (Non-mandatory) and in various compliance letters published on www.OSHA.gov). The guidance
provided in this clause and ISA-TR84.00.04-1 Annex A is intended to supplement the US-OSHA guidance and to provide examples
of methodologies that various owners/operators are using to determine whether their SIS meets the intent of the grandfather clause
(ANSI/ISA-84.00.01-2004-1 Clause 1.0 y).

3.1 General considerations

The owner/operator should be aware that the grandfather clause only addresses the SIS design and
construction. The other requirements of ANSI/ISA-84.00.01-2004-1 should still be implemented, as
appropriate. Documentation, procedures, training, testing, and auditing requirements of ANSI/ISA-
84.00.01-2004-1 are applicable to all SIS, whether existing or new.

It is important for the owner/operator to develop an approach for addressing existing SIS. It is the
responsibility of the owner/operator to determine that existing SIS meet the intent of the grandfather
clause and to document the operating, testing, inspection and maintenance conditions under which this
remains true.

There are a variety of methods that can be employed to “determine and document” the applicability of the
grandfather clause. ISA-TR 84.00.04-1 Annex A is a collection of methods used by various
owners/operators on the ISA84 committee.

3.2 Management of change considerations

Owners/operators of grandfathered SIS (i.e., those SIS that have been determined to meet the intent of
ANSI/ISA-84.00.01-2004-1 Clause 1.0y) should acknowledge that this status does not provide an
indefinite shield against the full requirements of ANSI/ISA-84.00.01-2004-1. The grandfather clause does
not protect any owner/operator from the OSH Act General Duty clause, which requires that
owners/operators provide a safe working environment. And US-OSHA has already stated in their letter to
ISA, dated March 23, 2000, that “The employer may be in violation of the General Duty Clause, Section 5
(a)(1) of the OSH Act, if SIS are utilized which do not conform with S84.01 [1996] and hazards exist
related to the SIS which could seriously harm employees.”

Further, the process industries are under continuous pressure to improve the operation of their facilities.
This optimization results in an environment of constant change, in terms of retrofits, upgrades, and
expansions. At some point, the modification of the process unit and/or the SIS may be significant enough
to trigger a management of change (MOC) review of the grandfather clause status of the SIS. The
following sections provide examples of criteria that can be used to trigger a reassessment of the
applicability of the grandfather clause.

3.2.1 Process design

Any change to the process design, which changes the Process Flow Diagrams or considerably revises
the Process and Instrumentation Diagrams (P&IDs), can be expected to have an impact on the definition
of the SIF used to mitigate the process risk. The addition of new process equipment may require the
addition of new SIFs. The addition of a new chemical to the process could change the process hazard,
create new process hazards, and/or change the demand rate on the SIF. Existing SIFs that are affected
by a modification may also require re-design due to changes in the potential process hazard, the
definition of the safe state of the process, or the performance requirements of the SIS.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

3.2.2 Safety Requirements Specification (SRS)

The SRS provides the functional and integrity requirements for each SIF implemented in an SIS.
Changes to the SRS that may impact the grandfather status of the SIS are as follows:

• changes in the definition of the safe state of the process (e.g., modification of the SIS action),

• changes in the functional relationship between process inputs and outputs,

• changes in the selection of energize or de-energize-to-trip,

• changes in the expected SIS performance (e.g., increase in the expected number of demands on
the SIS, increase in the expected consequence of the event, the removal or decrease in the risk
reduction of other independent protection layers, which increase the SIS requirements),

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
• changes in the safety integrity level, and

• changes in the required testing interval.

3.2.3 SIS Design

Changes in the SIS design should be evaluated for impact to the functionality and integrity of each SIF.
Any change that can impact the SIL should be carefully evaluated. Examples include:

• changes in the separation of the SIS and the BPCS,

• changes in SIS logic solver technology ,

• changes in redundancy and architecture for process sensors, logic solver, or final elements (e.g.,
1-out-of-2 to 2-out-of-2 sensors),

• changes in the power sources to SIS elements (e.g., electrical power, hydraulic power, pneumatic
power),

• changes in the field device type or technology,

• changes in device failures (e.g., hardware aging, impact of process is greater than expected),

• changes in process demand on the SIS,

• changes in SIS equipment manufacturer,

• modifications to the operator; maintenance/engineering; and communications interfaces,

• changes in the SIS environmental controls (should remain within manufacturer specified ranges),

• changes in facilities for SIS maintenance and testing (changes in mechanical or electrical
equipment involved in testing, not changes in testing interval), and

• changes in wiring practices.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

3.2.4 SIS operation, maintenance, testing, and inspection

When evaluating changes to operating and maintenance procedures, it is important to keep in mind that
only those changes that can have a negative impact on the process risk need to be considered. One
possible change that may significantly impact the requirements or performance of the SIS is extending
the plant turnaround schedule such that offline inspection, preventive maintenance, and proof testing are
performed less frequently. Another possible change is a large reduction in operations or maintenance
manpower. As owners/operators reduce the available workforce, it may become difficult for the operators
to fulfill their requirements in response to SIS trips or alarms. SIS performance problems may also result
from reduced or inexperienced maintenance support. These issues potentially include:

• reduced operator diligence in diagnosing failures of SIS equipment,

• inability of maintenance to respond to SIS failures in a timely manner,

• increased errors in SIS equipment repair, calibration, inspection or testing due to, among other
causes, loss of plant knowledge through retirement of experienced personnel or transfer of duties
to external contractors,

• reduced efforts in preventive maintenance, and

• reduced documentation of problem resolution.

These inadequacies could lead to an increase in systematic errors due to inadequate testing or errors in
calibration and repair activities.

3.2.5 Management of change

Even if an existing SIS has been found to meet the intent of the grandfather clause, changes to the SIS or
the process to which it is providing protection may trigger the need to formally re-evaluate its grandfather
status. Therefore, MOC procedures should specifically address the issue of SIS modification. An MOC
review should be conducted whenever the change potentially affects the process risk.

Within ANSI/ISA-84.00.01-2004-1, MOC is a significant phase of the Safety Lifecycle Model. Prior to the
initiation of a change to the SIS or to the process, the impact of the change on the SIS performance
should be assessed according to the requirements of the appropriate lifecycle phase, i.e., the first phase
affected by the modification. The elements of all subsequent lifecycle phases are then addressed. This
includes evaluating the effect of the change on the SIL.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
4 Overview
ANSI/ISA-84.00.01-2004-1 provides an extensive set of requirements covering the SIS lifecycle. Some
specialized functions are also covered by industry practices that dictate unique requirements for specific
applications. The standard relies on a quality control process to ensure that the SIS achieves the
performance necessary to adequately reduce potential risk in the operating environment. The
performance target for this quality process is defined in the standard as the SIL, which is related to the
SIF’s average probability of failure on demand (PFDavg). The standard establishes four discrete ranges for
benchmarking the performance of each function in the SIS, where SIL 1 has the lowest (highest PFDavg)
and SIL 4 has the highest (lowest PFDavg) performance.

Achieving these performance ranges requires that the SIS be rigorously designed and managed. An
effective management system uses a rigorous approach to manage the risk throughout the process
equipment life. With early consideration of process hazards, the SIS can be tailored to meet operating,
maintainability and reliability goals. Safe operation requires that the process design, SIS design, and
operation and maintenance procedures are successfully integrated to achieve high integrity and reliability.
Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Finally, the management strategy should incorporate periodic assessments of existing equipment
performance to identify opportunities for further reduction of risk, thus yielding safer operation.

4.1 Lifecycle approach

ANSI/ISA-84.00.01-2004 covers a wide range of chemical process operations. Due to its broad scope,
the standard has many general requirements addressing the complete lifecycle of the SIS, starting with
the identification of SIS requirements in the risk assessment and ending when the SIS is
decommissioned. While there are many different ways of representing the lifecycle, a simple four-step
approach can be followed:

1) Define a risk-management strategy; establish a facility management system for how SIS are
identified, designed, inspected, maintained, tested, and operated to achieve safe operation and
perform a hazard and risk analysis to identify where SIS are needed and their target SIL.

2) Implement the strategy; develop a design basis to achieve the target SIL and execute the detailed
design to meet the requirements.

3) Validate, start-up, operate and maintain the strategy; implement the SIS following the design
basis and detailed design documentation and define what is required of operation and
maintenance personnel to sustain the SIL.

4) Manage changes to the strategy; ensure the SIS meets the target SIL by monitoring operation,
inspection, test, and maintenance records and making changes as necessary to improve its
performance.

The lifecycle approach can be used to address any risk, whether safety, environmental, asset, or
business related. Many governments require the use of recognized good engineering practices in the
design and management of the instrumented systems that maintain safe operation in the process
industry. Local regulations, applicable codes, or insurance practices may require the use of specific good
engineering practices. Consequently, the management strategy should incorporate current good
engineering practices and continuous improvement activities to provide a comprehensive program. ISA-
TR84.00.04-1 Annexes C, D, and E provide additional guidance on the management of functional safety.

4.2 Define a risk-management strategy

A chemical process operator has cradle-to-grave responsibility for a facility’s safe operation. Risk derived
from the operation of chemical processes can be successfully and cost-effectively managed throughout
the life of the process. The earlier a risk-management strategy is defined, the better it will work and the
less it will cost. Identify process hazards early in the project planning and process design, so measures
can be implemented to reduce or eliminate hazards through inherently safer design.

Once process design is complete, the risk associated with process operation will need to be managed for
the life of the process equipment. Although inherently safer design may increase the initial capital cost, it
substantially reduces long-term risks and their associated costs. Safety systems should only be applied
when inherently safer design becomes impractical because safety equipment requires long-term
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

investment in administrative, operating, and maintenance activities.

To develop the risk-management strategy, start with a process hazards analysis (PHA) and review the
process design and its control, operation, and maintenance practices. Select a multidisciplinary team with
expertise in these areas, and use an accepted hazard-evaluation procedure, such as a hazard and
operability (HAZOP), what-if, or checklist analysis, to determine how process deviations from intended

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

operation lead to process hazards. ISA-TR84.00.04-1 Annex I provides guidance for instances where the
SIF operates in high demand or continuous mode.

Identify the causes or conditions that lead to deviations. For example, low flow can be caused by the
failure of the flow control loop. Events can be caused by a single failure or by multiple failures. Ensure
that the identified causes are the minimum that will lead to the process deviation. The most common
initiating causes are related to control system failures, which can happen multiple times over the life of the
process. If the consequence is significant, safety systems are generally required to address identified
process hazards.

Estimate the severity of the consequence, taking into account likely event conditions. Occupancy during
an abnormal event is typically not the same as during normal operation. If abnormal operation occurs,
what are the responsibilities of the field operators or maintenance crew? If a safety alarm goes off, is the
field operator expected to respond locally? The slower the event, the more likely there will be field
response and higher occupancy, possibly including supervisory, operations, and maintenance personnel.
ISA-TR84.00.04-1 Annex B provides guidance with respect to the role of the operator in process safety.

The process risk of a particular event is related to how often the event could occur and the severity of the
consequences if it does. Compare the process risk to facility risk criteria to determine if the risk is
tolerable or whether additional protection is required to reduce it below the defined criteria. Residual risk
represents a likelihood that an unacceptable consequence could occur, so drive it as low as reasonably
practicable. ISA-TR84.00.04-1 Annex J provides guidance on how to address process risk that requires
SIL 4 equivalent risk reduction.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
To lower risk, implement a defense-in-depth strategy in which one or more independent protection layers
(IPLs) act to interrupt the event sequence. Verify during the PHA that identified IPLs are designed to
detect and respond to the hazardous event in a timely manner. IPLs can be implemented using a variety
of systems, such as safety alarms, pressure relief devices, and SIS. ISA-TR84.00.04-1 Annex H clarifies
the differences between interlocks, permissives, inhibits, safety functions, SIS, and SIF. Independence is
achieved when the IPL operation is not affected by the occurrence of the initiating event or by the failure
of other IPLs. ISA-TR84.00.04-1 Annex G discusses SIF failure and measures that should be taken to
reduce the likelihood of failure. In addition to addressing the risk arising from identified process
deviations, the risk-reduction strategy should also address secondary consequences associated with the
operation of the IPLs, such as reduced production, shutdown, and flaring. Secondary consequences can
be thought of as the side effects of the risk-reduction strategy — each time an IPL takes action, there is
an effect on the process. Determine the cost of the spurious operation of IPLs to establish the maximum
acceptable spurious activation rate. The final risk-reduction strategy should ensure that the side effects
are acceptable or properly managed.

4.3 Implement the strategy

The SIS functionality should be documented in a design basis that is maintained under revision control as
process safety information for the life of the system. The SIS design basis should address the following:

• Detection of and response to potential hazardous events

• Selection of equipment based on prior history

• Fault detection, such as diagnostics and proof testing

• Fault tolerance against dangerous failures

• Procedures for maintenance and test, including the use of bypasses (refer to ISA TR84.00.03 for
additional guidance)

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• Operation and maintenance procedures required when SIS equipment is out of service

• Emergency shutdown capability if the SIS fails to take action as expected

• Start-up and shutdown of the process equipment

The SIS design basis is covered by ANSI/ISA-84.00.01-2004 (Clauses 10 through 12). ISA-TR84.00.04-1
gives guidance on design requirements for the hardware in Annex N and software in Annex O. Uniform
facility practices should be considered to promote consistency in SIS implementation, as well as to
reduce training costs and the potential for human error.

4.3.1 Independence

The SIS should also be designed to be separate and independent from the basic process control system
to provide protection against postulated control system malfunctions. ISA-TR84.00.04-1 Annex F provides
guidance with respect to the role of the Basic Process Control System (BPCS) in process safety. SIS
operate best when they are initiated by direct measurement of the process deviation and take action on
the process in a manner that directly addresses the deviation, thereby achieving or maintaining a safe
state. For example, “when the high-pressure alarm initiates, open the pressure control vent,” or “when
high temperature occurs, close the steam valve.” This logic is simple enough that it can be implemented
in a hard-wired system. Use programmable logic controllers (PLCs) when the process logic is complex,
requires sequencing, or needs to be adjusted on operating mode.

4.3.2 PLCs

PLCs are complex integrated systems with the potential for large numbers of random and systematic
failures. Because of the failure potential, ANSI/ISA-84.00.01-2004 (Clause 11.5) requires safety-
configuration of PLCs for SIS. Safety configuration addresses the widely known failure modes of the
inputs, main processors, communications, utilities (e.g., power, instrument air) and outputs. This requires
diagnostics and fault tolerance capabilities that are generally not provided in process control but needed
to identify and manage PLC failures in safety applications. ISA-TR84.00.04-1 Annex M provides further
discussion of general-purpose, safety-configured and IEC 61508-compliant Programmable Electronic
(PE) logic solvers.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
4.3.3 User approved devices

A user approval process should assure that field equipment has an established history of performance in
a similar operating environment and that its failure mechanisms are understood and accounted for in the
design, operation, and mechanical integrity practices. ISA-TR84.00.04-1 Annex L provides guidance on
the selection of SIF devices. An SIS must be sufficiently robust to meet the required SIL under operating
environment conditions. For each installation, define the conditions that impact SIS equipment selection,
such as:

• process composition, e.g., solids, salts, or corrosives

• process operating conditions, e.g., extremes in temperature, pressure, or vibration

• external conditions, e.g., winterization needs or hazardous area classification

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

4.3.4 Response time

The SIS must detect the process hazard and respond in time to prevent the hazardous event. How much
time the SIS has to respond depends on the process dynamics and the conditions initiating its actions.
When multiple engineered safeguards are implemented to address an event, they are often designed to
operate in a preferred sequence. The available process safety time for any given safeguard starts when it
is required to take action and ends at the point where the event can no longer be prevented. In many
applications, it is desirable that each safeguard be capable of completing its action prior to the initiation of
the next one in the sequence, the goal being to achieve or maintain a safe state with the safeguard that
causes the least impact to process operation. Regardless, the need to allocate a limited process safety
time to multiple safeguards leads to less time being available for safeguards operating later in the
sequence.

The SIS begins protective action at a defined process condition or setpoint. ISA-TR84.00.04-1 Annex Q
provides guidance on the selection of SIF setpoints. The SIS’s speed of response is limited by the sensor
dynamics and overall instrument loop response time, which can be significantly affected by the process
design itself. The shutdown lag can be long (seconds to minutes), particularly in applications where there
is significant retained mass or energy that must be removed. It can also be short (milliseconds), such as
stopping a motor. Given the degree of uncertainty in the process safety time, the SIS should be capable
of completing its action within one-half of its allocated process safety time.

4.3.5 Support system considerations

Assess potential common causes in the process support systems, such as power, communications,
instrument air, cooling water and hydraulic power. ISA-TR84.00.04-1 Annex K.3.3 provides additional
guidance on support system requirements. Ensure that SIS support systems are designed to take the
affected equipment to a specified safe state as necessary to achieve the required integrity. Approval of
non-fail-safe design should consider the impact on the risk-reduction strategy assumptions, the type of
SIS, the support system integrity, and alternative means to achieve a safe state. Human and cyber
access to any SIS should be sufficiently restricted, using administrative procedures and physical means
to ensure that changes to the SIS are approved through a management of change process.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

4.3.6 Verification

ANSI/ISA-84.00.01-2004 Clause 11.9 also requires that the SIS PFDavg be verified quantitatively (refer to
ISA-TR84.00.02 for additional guidance on SIL verification). Ensure that the selected equipment is fit for
use in the operating environment, that the subsystems meet minimum fault tolerance requirements, and
that the system achieves the required functionality and integrity. ISA-TR84.00.04-1 Annex K provides
further discussion on fault tolerance. SIS equipment should be included in a mechanical integrity program
that seeks to maintain the SIS in the “as good as new” condition. Mechanical integrity includes a variety of
activities, such as inspection, maintenance, calibration, repair/replacement, and proof testing. An
equipment list should be maintained that identifies SIS equipment by a unique designation and includes
the required inspection and proof-test interval necessary to ensure the equipment remains fit for service.

4.3.7 Proof testing

The initial proof-test interval is determined based on offline test opportunities, relevant regulations,
equipment history in similar operating environments, manufacturer’s recommendations, and integrity
requirements. When proof testing is required more frequently than scheduled outages, online proof-test
and repair facilities will be necessary. If the online activity requires bypassing, document the measures or
safeguards put in place to compensate for the loss of SIS capability during the out-of-service period.
Assess bypass activities and potential hazards to define the compensating measures and the maximum
allowable repair time. Implement bypass alarms when practical, and ensure operating procedures
adequately communicate bypass activity across operator shift changes, e.g., re-initiate bypass and safety
alarms across shifts. Ensure that operators know the state of SIS equipment and what to do if abnormal

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

operation occurs. ISA-TR84.00.04-1 Annexes B and P provide guidance on operator response to alarms
and compensating measures when operating with a detected failure.

4.4 Validate, start-up, operate, and maintain the strategy

The SIS must undergo validation to obtain formal acceptance of the SIS by the plant operations staff. The
equipment is proven to work as required, and from this point forward, changes are reviewed and
approved according to the plant’s management-of-change practices. Validation is performed after
instrument calibration and loop checks have been completed. A validation plan is developed to ensure
orderly execution and thorough documentation and resolution of any findings. ISA-TR84.00.04-1 Annex D
provides further discussion on conducting functional safety assessments during the SIS lifecycle.

Validation demonstrates that the installed SIS operates according to the design basis and that
appropriate documentation is in place to support its long-term management. An input-to-output test is
used to prove that the SIS functions properly and that the SIS equipment interacts as intended with other
systems, such as the BPCS and operator interface. The Site Acceptance Test (SAT) also provides an
opportunity for a first-pass validation of the operating and maintenance procedures. Validation must be
completed prior to the initiation of any operating mode where a hazardous event could occur that would
require the operation of a new or modified SIS. Some users require that validation be repeated after any
major process outage or shutdown.

Clearly define the safe operating limits in the operating procedures, the consequences of deviating from
these limits, and the proper action to take when these limits are exceeded. The operator’s response to an
indication, alert, alarm, or incident is dictated first by procedures and training and then by experience.
Validate the operator’s response to SIS diagnostic and safety alarms. ISA-TR84.00.04-1 Annex B
provides guidance on SIS alarms. ISA-TR84.00.04-1 Annex P provides application guidance regarding
system behavior on detection of a fault. ANSI/ISA-84.00.01-2004 (Clause 16 and 17) addresses operator
and maintenance procedure requirements for SIS. Procedures should include:

• a description of the hazardous events being prevented

• a description of the SIS

• the appropriate operator response to detected SIS equipment failure and provisions for operation
with detected faults (i.e., compensating measures)

• coordination/communication with maintenance during any troubleshooting, repair or test activity

• conditions under which it is safe to reset the SIS

• use of start-up bypasses and the process conditions to be monitored during start-up

• the expected operator response when safety alarms are received and the setpoints for those
alarms

• trip setpoints, the expected safe state when a trip is completed, and the form of trip notification (if
provided)

• expected operator actions if a safe state is not achieved

• the “never exceed, never deviate” process conditions that require manual shutdown

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Installed safety equipment is subject to the same operational stresses as control equipment. However,
when control equipment fails, the failure can be detected because the process behaves abnormally. In
contrast, safety equipment typically operates on demand only, i.e., when an abnormal condition occurs,
so failure may not be detected until it is required to act. Equipment often demonstrates a failure rate over
time that follows a so-called bathtub curve.

Early failures are often caused by manufacturing, assembly, test, installation and commissioning errors.
Many early failures are the result of rough handling, improper pre-installation storage, poor installation
practices, or sloppy construction practices. Rigorous inspection, commissioning and validation activities
are necessary to identify and correct these failures.

The wear-out period is characterized by an increasing failure rate over time. Poor mechanical integrity
practices have been cited as a primary cause of equipment failure (HSE, 2005). Preventive maintenance
can extend equipment useful life and improve its reliability. Mechanical integrity records provide data that
equipment is being maintained in the “as good as new” condition and justify its continued use.
Consequently, maintenance personnel must be trained on the activities necessary to ensure equipment
integrity.

Periodic proof tests should be performed at a frequency sufficient to detect the transition from the useful-
life period to the wear-out period, so that the need for equipment replacement or upgrade can be
identified and planned (refer to ISA-TR84.00.03 for additional guidance on mechanical integrity of SIS).
Equipment failure should be investigated using root-cause analysis to reduce or eliminate failure causes,
such as changes to the installation or replacement of the equipment with something more suitable for the
operating environment. The proof-test interval should be periodically evaluated based on plant
experience, hardware degradation, demonstrated software reliability, etc. In the event that the equipment
performance does not meet the SIL requirements, the mechanical integrity plan (e.g., inspection,
preventive maintenance and proof testing) should be modified as necessary to achieve the required
performance (refer to ISA TR84.00.03).

Execute proof tests using operation and maintenance procedures that ensure the test is completed
correctly, consistently and safely. Proof tests should determine the “as-found/as-left” condition for all
defined operating modes. Documentation should be traceable to the procedure, equipment, and person
performing the test. Identify and assess deviations from the design basis and equipment specification,
e.g., undocumented changes or accelerated degradation. Use the proof-test results and findings to train
personnel and to verify procedure clarity and completeness. Implement procedures to track the time that
the equipment is out of service and to ensure that the equipment is returned to service following testing
(refer to ISA-TR84.00.03 for additional guidance).

Actual risk reduction can be demonstrated by mechanical integrity data and plant performance (refer to
ISA-TR84.00.04-1 Annex R and ISA-TR84.00.03). The records associated with any SIS must show that
the equipment can operate as specified during all intended operating modes. Failure tracking and
analysis is essential to quality assurance. Repeated failures likely indicate that the installed equipment is
not capable of meeting the performance requirements. Use root-cause analysis to determine why metrics
are trending in the wrong direction in order to implement action plans that improve the management
system, equipment, procedures, and personnel training. Identify special and previously unknown failures
and communicate these to personnel, ensuring that lessons learned are not hidden in mechanical
integrity records.

4.5 Manage changes to the strategy

A successful risk-management strategy accepts that humans are involved in every aspect of an SIS
lifecycle. Therefore, the integrity claimed for any SIS is limited by the quality management system that
identifies and seeks to eliminate flaws in the system. Human error must be reduced to the point where it
does not significantly impact system integrity. Assurance of personnel competency is key. ISA-
TR84.00.04-1 Annexes C, D, and E provide guidance with respect to management of functional safety.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Refer to ISA-TR84.00.03 for additional guidance of determining the competency of those associated with
the mechanical integrity plan.

Knowledge evolves over time as research and development yields operational enhancements to process
facilities. ISA-TR84.00.04-1 Annex R provides examples of key performance indicators that can be used
to monitor aspects of the SIS lifecycle. Events involving abnormal operation may identify weaknesses in
the risk-reduction strategy, leading to the need for more safeguards and improved performance metrics.
New ideas identify ways to lower risk further.

Finally, installed SIS equipment should be periodically assessed to determine whether equipment is
designed, maintained, inspected, tested and operating in a safe manner. Use a management-of-change
process to initiate, document, review and approve changes to SIS other than replacement-in-kind.
Evaluate changes to the process and its equipment to determine their potential impacts on the approved
SIS design basis prior to implementing the change. Personnel need to understand when hazard analysis
is required and why tracking change is important. ISA-TR84.00.04-1 Annex E provides examples and
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

guidance on how to organize and perform audits to ensure compliance.

Update documents to as-built status, incorporating changes made since the last formal drawing/document
revision. Maintain documentation under revision control for the life of the equipment. Documentation
should be traceable to the process hazard analysis and should be auditable.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex A – Example methods for determining grandfather status

NOTE -- Annex A is referenced in Clause 3.0.

A.1 Purpose

As discussed in Clause 3, the purpose of this annex is to illustrate approaches for determining whether an
existing SIS meets the intent of the grandfather clause (ANSI/ISA-84.00.01-2004-1 Clause 1.0 y). There
are two essential steps:

1) Confirm that a hazard and risk analysis has been done to determine qualitatively or quantitatively
the level of risk reduction needed for each SIF in the SIS.

2) Confirm that an assessment of the existing SIF has been performed to determine that it delivers
the needed level of risk reduction.

NOTE -- The evaluation of the SIF should take into account various factors, such as equipment failure and associated
design, operation, maintenance, testing, and inspection work practices.

If the above activities have not been done, they should be scheduled for review at the next appropriate
opportunity.

Clauses A.3.1 through A.3.8 provide examples of methods used by some owners/operators in evaluating
existing SIS. These methods are provided as examples and should not be considered the only acceptable
approaches. The owner/operator should select a method or methods based on their hazard- and risk-
analysis philosophy and prior design practices with consideration for the following:

• Development of a method for “determining and documenting” the grandfather status of

the SIS,

• Integration of this method into the existing process safety management program, and

• Consistent application of the method, considering potential risks to human health and the
environment.

• Once an owner/operator determines that the existing SIS does not meet the intent of the
grandfather clause, there should be a defined decision-making process to address the
identified deviations. The resolution to the identified deviations should be directed at
maintaining process safety, such as SIS upgrades, increased monitoring, increased

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
testing, etc.

A.2 Timing

The owner/operator should document the adequacy of the SIS at the cyclic PHA. Analysis of the
adequacy of the SIS should be expedited if the following occurs:

• Modifications to the process unit that impact process risk managed by the SIS

NOTE -- ISA-TR84.00.04-1 Clause 3.2 provides a list of management-of-change considerations.

• Modifications to the control system that impact protection layers used to achieve safe
operation

• When an incident or near-miss investigation has identified an SIS deficiency

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• When the review of another process unit designed according to similar practice has
identified an SIS deficiency

A.3 Approaches to the grandfather clause

Clauses A.3.1 through A.3.8 provide eight different approaches used by owners/operators in the
evaluation of the applicability of the grandfather clause. These methods are provided for illustrative
purposes only. Owners/operators are responsible for developing a method for use at their facilities.

A.3.1 Comparison with SIL requirements

At a minimum, the adequacy of an existing SIF should be reviewed and documented at the cyclic PHA,
such as those required by OSHA 1910.119. The cyclic PHA is one of the principal opportunities to review
an existing SIF and ensure its design and performance satisfies expectation. During the PHA, the team
identifies potential causes of process hazards and the associated consequence severity for various
hazard scenarios.

For those scenarios that involve medium to high risk to employees, the environment, or to the community,
an assessment of the protection layers is conducted to determine whether the required functionality and
integrity are provided by the existing design. This assessment is sometimes performed as part of the PHA
or in a more focused study that addresses only those scenarios of medium to high process risk.

During the assessment of the protection layers, the team reviews the following:

• Functionality

The functionality of each safety function is examined. For the SIS, the team should determine
whether the existing functionality is appropriate to achieve the required safety function. For
example, does the high pressure SIF address all initiating causes and isolate all necessary
sources of pressure? If the functionality is inadequate, the team should recommend the
necessary modification to the SIF to achieve the required safety function.

• Integrity

The team assigns a risk reduction to each safety function. For each SIF, the allocated risk
reduction defines the SIL. Typically, the verification of the SIL is performed after the study is
complete for all SIFs. The verification includes the device integrity, architecture, diagnostics,
testing, and potential common-cause failures. The examination is to verify consistency of the
installed SIF with the integrity requirements. This verification may include a calculation of the
Probability of Failure on Demand (PFDavg) for the SIF. The actual PFDavg is then compared to the
SIL assigned by the PHA team. If the actual PFDavg is inadequate, the team makes
recommendations for upgrading the SIF to meet the SIL.

• Independence

The team should examine how the safety functions are allocated to each protection layer, such as
the basic process control system or safety instrumented system. The assessment should focus
on minimizing the common-cause failures between the safety functions associated with each
identified process hazard. Then, each protection layer should be reviewed to ensure that
adequate independence and separation is provided between layers.

The team also reviews management-of-change documentation associated with the existing SIS. If
changes have been made to the process that might impact the expected performance requirements for
Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

the SIFs implemented in the SIS, the team reviews the PHA (e.g., Layer of Protection Analysis) to ensure
the defined Safety Integrity Level for each SIF is still adequate. The team also reviews all of the data and
assumptions used during the original PHA to determine whether they are still valid.

The team assesses the number of demands placed on each SIF to ensure they are consistent with what
was originally defined. For example, if the original premise was that the SIF would have about one
demand for every ten years, but, in reality, the SIF is exposed to one demand a year, the team modifies
the PHA assumptions based on this new operating experience. This may result in a higher SIL
requirement or in the determination that the SIF is operating in high-demand mode rather than low-
demand mode.

Finally, the team should also consider reviewing the periodic proof-test results to identify devices that
have failed repeatedly during tests. For example, if the team determines that the SIF has repeatedly failed
its periodic proof test due to a transmitter fault, the team should recommend that the design, installation,
and maintenance practices associated with the SIF be re-evaluated. The root cause analysis may result
in the selection of a different technology for the process variable measurement or in a revised installation.
Until the process variable measurement has been proven reliable in this service, the defined test interval
should be reduced.

A.3.2 Comparison with existing design basis

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
A flow diagram (Figure A.1) is provided to illustrate the method discussed in this section. This method
provides one approach for evaluating the grandfather status of an SIS. Alternative approaches can be
used. The owner/operator should decide and document which approach is suitable for their process
facility.

Step 1. Define process facility grandfather clause application rules.

After reviewing ISA-TR84.00.04-1 Clause 3.0, the owner/operator establishes ground rules that are to be
implemented whenever existing SIS are analyzed for grandfather clause application. An example of
ground rules is provided in Table A.1.

Table A.1 — Example Ground Rules (GR)

NOTE -- Example provided by one owner/operator

GR-1 The owner/operator utilizes approved and documented existing good engineering practices, such as:
ANSI/ISA-84.01-1996,
ISA "Alarm & Interlock Systems” 1984, ISBN 0-87664-736-0, or
Corporate standards.
NOTE -- Corporate standards should be verified against key ANSI/ISA-84.00.01-2004-1 requirements to
determine their suitability.

GR-2 The plant processes to be considered for grandfather clause implementation are process sector-related (e.g.,
continuous and batch) processes only.
GR-3 The process facility ground rules for upgrading each SIF are based on the following:
An SIF whose design basis is not in compliance with GR-1 should be upgraded to ANSI/ISA-84.00.01-
2004-1 as soon as possible.
b. An SIF whose design basis meets GR-1 should be upgraded to ANSI/ISA-84.00.01-2004-1 as part of the
next cyclical PHA review.

Step 2. List existing SIFs, then select one SIF at a time and proceed as noted below.

Step 3. Identify the design basis for each SIF.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Step 4. Analyze the SIF design basis and determine if it meets the grandfather clause ground rules.

a) If the SIF does not meet GR-1, then the SIF should be upgraded to meet ANSI/ISA-84.00.01-
2004-1 as soon as possible.

b) If the SIF does meet GR-1, each SIF should be evaluated to determine if it is designed, installed,
maintained, inspected, tested, and operating according to the design basis.

• If the SIF is designed, installed, maintained, inspected, tested, and operating according to the
design basis, the grandfather clause is applicable.

• If the SIF is not designed, installed, maintained, inspected, tested, and operating according to the

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
design basis, the SIF should be upgraded to meet the design basis.

Step 1
Define grandfather clause rules

Step 2
List existing SIS

Step 3
Select an SIS and identify design
basis for each SIF

Step 4

NO Does design basis YES

meet rules
established in
Step 1?

Upgrade to meet Does the actual SIF

agree with the design
ISA 84.-01-2004
NO basis?

YES
Upgrade SIF to Document
existing design acceptance of
basis and verify grandfather clause

Figure A.1 — Flow diagram for example approach presented in Annex A.3.2

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

A.3.3 Comparison with key ANSI/ISA-84.01-1996 requirements

In this method, the owner/operator conducts an assessment, comparing the existing SIS to key
requirements in ANSI/ISA-84.01-1996. Prior to the issuance of ANSI/ISA-84.00.01-2004-1, ANSI/ISA-
84.01-1996 was used as a good engineering practice for SIS by this owner/operator. The following
questionnaire was designed for use in verifying whether existing SIS meet the intent of the requirements
in ANSI/ISA-84.01-1996. To qualify for grandfathering using this method, any shortfall (i.e., less than
100%) requires a plan to bring the SIS in question into compliance with ANSI/ISA-84.00.01-2004-1.

NOTE 1 A Safety Instrumented System (SIS) should be designed, built, tested, and maintained to provide the required risk
reduction.

NOTE 2 Example provided by one owner/operator.

Table A.2 — Checklist for example approach presented in Annex A.3.3

No. Question
1. What percentage of the SIS are defined? – e.g. any of the following: logic narrative, cause and effects matrix,
logic diagram.
a. 100% ____
b. 50 to 99% ____
c. 25 to 49% ____
d. < 25% ____
Comment/explanation:
2. What percentage of the SIFs implemented with the SIS have a SIL assigned to them?
a. 100% ____
b. 50 to 99% ____
c. 25 to 49% ____
d. < 25% ____
Comment/explanation:
3. What percentage of the SIS were designed and built to meet the SIL of the SIF?
a. 100% ____
b. 50 to 99% ____
c. 25 to 49% ____
d. < 25% ____
Comment/explanation:
4. What percentage of SIS are tested frequently enough to maintain the SIL of the SIF?
a. 100% ____
b. 50 to 99% ____
c. 25 to 49% ____
d. < 25% ____
e. Don’t know ____
Comment/explanation:
Do current maintenance practices support the SIL of the SIFs – is the assumed Mean Time to Repair (MTTR)
5. on fault detection met? This should include analog input maintenance based on deviation alarms.
a. yes ____
b. no ____
c. don’t know ____
d. SIFs are tested at the following frequency ____.
Comment/explanation:

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

No. Question
6. Are SIS smart sensors write-protected, and do they require a safety review for modification?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
7. How well are the maintenance personnel or computer support personnel (whoever maintains the SIS) trained
on the SIS?
a. well trained ____
b. adequately trained ____
c. poorly trained ____
d. not trained ____
Comment/explanation:
8. How well are maintenance procedures maintained for the SIS?
a. well maintained ____
b. adequately maintained ____
c. poorly maintained ____
d. not maintained ____
Comment/explanation:
9. How well is maintenance documentation maintained?
a. well maintained ____
b. adequately maintained ____
c. poorly maintained ____
d. not maintained ____
Comment/explanation:
10. How well are Operations personnel trained on the SIFs of the SIS?
a. well trained ____
b. adequately trained ____
c. poorly trained ____
d. not trained ____
Comment/explanation:
11. How well are operating procedures maintained for the SIS?
a. well maintained ____
b. adequately maintained ____
c. poorly maintained ____
d. not maintained ____
Comment/explanation:
12. How well are the results of the SIS online testing documented?
a. well documented ____
b. adequately documented ____
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

c. poorly documented ____

d. not documented ____
Comment/explanation:

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

No. Question
13. What percentage of SIS inputs and outputs is shown on the P&IDs?
a. 100% ____
b. 50 to 99% ____
c. 25 to 49% ____
d. < 25% ____
Comment/explanation:
14. Are the SIS hardware, embedded software, and utility software under a formal revision and release control
program?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
15. Who on your site receives the critical problem notifications from the SIS manufacturer?
a. name ____
b. don’t know ____
Comment/explanation:
16. Is the SIS application logic under a formal revision and release control program?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
17. Do all SIS energize-to-trip circuits have an end-of-line current monitor?
a. yes ____
b. no ____
c. don’t know ____
d. does not apply, all circuits are de-energized to trip ____
Comment/explanation:
18. Are SIS Inputs or outputs forced as part of operating procedures?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:

A.3.4 Comparison with key ANSI/ISA-84.00.01-2004-1 requirements

Another approach to SIS evaluation is the development of a checklist based upon ANSI/ISA-84.00.01-
2004-1 requirements. The checklist should address major philosophical and technology issues defined in
ANSI/ISA-84.00.01-2004-1. Any “no” answers (e.g., response other than “a”) would exclude the SIS
under consideration from the “grandfather” clause. A few examples of the types of questions that could be
addressed in the checklist are provided below.

NOTE -- Example provided by one owner/operator.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Table A.3 — Checklist for example approach presented in Annex A.3.4

No. Question
1. Are the SIS defined? – E.g., any of the following: logic narrative, cause and effects matrix, logic diagram.
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
2. Have the Safety Instrumented Functions (SIFs) implemented with the SIS been assigned a Safety Integrity
Level (SIL)?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
3. Are SIS field devices and logic solver independent of the initiating cause?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
4. Are SIS field devices and logic solver independent of other protection layers?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
5. Are the SIS designed and built to meet the SIL of the SIF?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
6. Are the SIS tested frequently enough to maintain the SIL of the SIF?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
7. Are the SIS designed to meet the required fault tolerance for the SIL of the SIF?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
8. Are field devices and logic solver functionally separate from the BPCS?
a. yes ____
b. no ____
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

c. don’t know ____

Comment/explanation:

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

No. Question
9. Do current maintenance practices support the SIL of the SIFs – is the assumed MTTR on fault detection met?
This should Include analog input maintenance based on deviation alarms.
a. yes ____
b. no ____
c. don’t know ____
d. SIFs are tested at the following frequency ____.
Comment/explanation:
10. Are SIS smart sensors write-protected and do they require a safety review to modify?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
11. How well are the maintenance personnel or computer support personnel (whoever maintains the SIS) trained
on the SIS?
a. well trained ____
b. adequately trained ____
c. poorly trained ____
d. not trained ____
Comment/explanation:
12. How well are maintenance procedures maintained for the SIS?
a. well maintained ____
b. adequately maintained ____
c. poorly maintained ____
d. not maintained ____
Comment/explanation:
13. How well is maintenance documentation maintained?
a. well maintained ____
b. adequately maintained ____
c. poorly maintained ____
d. not maintained ____
Comment/explanation:
14. How well are Operations personnel trained on the SIFs of the SIS?
a. well trained ____
b. adequately trained ____
c. poorly trained ____
d. not trained ____
Comment/explanation:
15. How well are operating procedures maintained for the SIS?
a. well maintained ____
b. adequately maintained ____
c. poorly maintained ____
d. not maintained ____
Comment/explanation:
16. How well are the results of the SIS online testing documented?
a. well documented ____
b. adequately documented ____
c. poorly documented ____
d. not documented ____
Comment/explanation:

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

No. Question
17. Are the SIS inputs and outputs shown on the P&IDs?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
18. Are the SIS hardware, embedded software, and utility software under a formal revision and release control
program?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
19. Who on your site receives the critical problem notifications from the SIS manufacturer?
a. name ____
b. don’t know ____
Comment/explanation:
20. Is the SIS application logic under a formal revision and release control program?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
21. Do all SIS energize-to-trip circuits have an end-of-line current monitor?
a. yes ____
b. no ____
c. don’t know ____
d. does not apply, all circuits are de-energized to trip ____
Comment/explanation:
22. Are SIS Inputs or outputs forced as part of operating procedures?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
23. Historically, has the SIS performance met the operating demands?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:
24. Historically, has the spurious activation of the SIS caused process incidents?
a. yes ____
b. no ____
c. don’t know ____
Comment/explanation:

A.3.5 Comparison to Accepted Prior Design Practices - A

Clause A.3.5 illustrates one company's approach to determining if an existing SIF meets the grandfather
clause requirements. This approach involves four steps, as follows:

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Step 1: The required risk reduction is determined for each SIF, using an approved hazard and risk
analysis method.

Step 2: Review the historical performance of each SIF.

If the historical performance indicates the need to upgrade the current design and associated
functions, the grandfather clause should not be claimed, and the SIF should be upgraded to meet
ANSI/ISA-84.00.01-2004-1.

If the historical performance indicates the current design and associated functions are providing
the desired safe plant operation, proceed to step 3.

Step 3: Select one SIF (with its associated risk reduction) at a time and compare the existing SIF against
the required attributes in Table A.4. This table is developed for use by the owner/operator. It establishes a
pre-existing list of ground rules to determine whether an existing SIF meets the required risk reduction.
This table is used for existing SIFs only. New or modified SIFs are designed in accordance with
ANSI/ISA-84.00.01-2004-1.

NOTE 1 When an owner/operator develops this type of method, the owner/operator should continuously evaluate their internal
practices and corporate standards to ensure the ground rules and their associated risk reduction criteria are valid.

NOTE 2 Table A.4 defines minimum qualitative requirements that should be met for existing SIFs to be considered sufficient to
meet a specific level of risk reduction.

NOTE 3 The required risk reduction is referred to as a risk reduction factor (RRF) in Table A.4. The values provided in the table
represent the lower bounds of the range of risk reduction for which this architecture may be utilized, pending verification of the
PFDavg of the SIF. When the hazard and risk analysis establishes a risk reduction target of 10, the SIF should be designed to meet
SIL 1 or a risk reduction factor of >10 to 99. Likewise, when the hazard and risk analysis establishes a risk reduction target of 100
the SIF should be designed to meet a risk reduction of >100 to 999 or, for a RRF of 1000 (SIL 3), the risk reduction target is >1000
to 9999.

If the SIF satisfies the minimum requirements of Table A.4, the SIF is considered to meet the
grandfather clause. Proceed to step 4.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

If parts of the SIF do not comply with the minimum practices or use any unacceptable practices
(not acceptable) shown in Table A.4, those parts of the SIF should be upgraded to meet the
minimum practices in Table A.4. Alternatively, an upgrade of the SIF in accordance with
ANSI/ISA-84.00.01-2004-1 is recommended.

Step 4: Verify that the SIF meets its SIL requirements by acceptable analysis method(s).

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Table A.4 — Checklist for example approach presented in Annex A.3-4

NOTE -- Example provided by one owner/operator.

Independent protection layer specification credit from Risk Assessment

GENERAL SUBJECT
CATEGORY RRF 10 for SIS or RRF 100 for SIS RRF 1000 for SIS
BPCS or alarms

Programmable Logic Solver Acceptable Single system with Redundant system 1oo2 or
(PLC) diagnostic (overrun Redundant systems 2oo3
detection, fail safe with overrun detection and
properties) and watchdog fail safe properties
or
Dual system (without
watchdog) 1oo2

Programmable Logic Solver Acceptable AK 4* AK 5* or higher

(PLC/SIS) with DIN certificate 4 credits can be used for
AK-6* certified systems (DIN
VDE 801)

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Solid state logic No requirements System with fail safe logic Advanced system with fail
safe logic
SIS system
hardware Pneumatic logic Acceptable Not acceptable Not acceptable

Relays Acceptable Acceptable if high grade No, unless guided contacts

commercial quality. Need and prior use. No jumpers.
to review each system on Need to review each system
status. on status.

Distributed Control System Acceptable for 1 SIS Not acceptable Not acceptable
(DCS) credit or 2 credits
for BPCS and Alarm
on 1 platform if
applied into different
control boxes - prior
use

Separate systems Acceptable Acceptable Acceptable

SIS/ BPCS logic
solver hardware Integrated systems Acceptable Not acceptable unless IEC Not acceptable unless IEC
requirements 61508 compliant 61508 compliant

Separate systems Limited variability Limited variability Limited variability

language (e.g. language (e.g. ladder logic) language (e.g. ladder logic)
ladder logic), or or requirements of the user or requirements of the user
requirements of the and/or safety manual and/or safety manual
user and/or safety
manual

Integrated systems Function protected See user and/or safety See user and/or manual
SIS Logic solver against changes and manual requirements
Software requirements
override
requirements

General verification Program verification For verification For verification

requirements performed and requirements from user requirements from user
documented and/or safety manual and/or safety manual

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Independent protection layer specification credit from Risk Assessment

GENERAL SUBJECT
CATEGORY RRF 10 for SIS or RRF 100 for SIS RRF 1000 for SIS
BPCS or alarms

"Smart" Instruments Acceptable Acceptable 1oo2/ 2oo3/ Acceptable 1oo2/ 2oo3/

1oo1/1oo2/ 2oo3/ 1oo2D/ 2oo2D 1oo2D/ 2oo2D
1oo2D/ 2oo2D

Certified instruments Acceptable Acceptable Acceptable

Non-smart analog electronic Acceptable Acceptable 1oo2/ 2oo3 Acceptable 1oo2/ 2oo3
Instruments 1oo1/1oo2/ 2oo3

Pneumatic analog Acceptable Acceptable 1oo2/ 2oo3 Requires hazard and risk
instruments 1oo1/1oo2/ 2oo3 analysis team approval

Instrumentation
(sensors) Discrete measurements (e.g. Acceptable Acceptable 1oo2/ 2oo3 Requires hazard and risk
pressure switch) 1oo1/1oo2/ 2oo3 analysis team approval

Pneumatic transmitter with Acceptable Acceptable 1oo2/ 2oo3 Requires hazard and risk
switches (behind panel) 1oo1/1oo2/ 2oo3 analysis team approval

Pneumatic transmitter with Acceptable Acceptable 1oo2/ 2oo3 Acceptable 1oo2/ 2oo3
transducer (behind panel) 1oo1/1oo2/ 2oo3
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Separate sensors Acceptable Acceptable Acceptable

Sharing of Shared sensors Acceptable when Acceptable when two or Acceptable when two or
sensors two or more sensors more sensors are used more sensors are used
are used

Instrument Instrumentation according to Recommended Recommended Recommended

Installation proven practice

Final elements from an Acceptable Acceptable 1oo1/1oo2 Acceptable 1oo2

approved manufacturer 1oo1/1oo2
suppliers list

Control valve as final element Acceptable if the Acceptable as second final Acceptable second final
if: valve is not the only element element
-proof test and maintenance IPL which reacts
records demonstrate that it within the process
meets the shutoff & closing safety time for this
speed needs scenario (e.g. PSV
Final elements -the fail safe action is defined or alarm but non- NOTE: This architecture is
correctly safety related) not allowed for new or
-it is not shared with another upgraded installations.
IPL for the same scenario
-the interlock has to work
direct on the actuator

Analog operated block valves Acceptable like Acceptable like normal Acceptable like normal block
with direct actuation of SIS normal block valves block valves valves
function

Sensors Use proven test Use proven test interval or Unless known, use default
interval or use use default MTTF from MTTF from publications for
Test frequencies default Mean Time publications for PFD PFD calculations
calculated from to Failure (MTTF) calculations
PFD from publications for
PFD calculations

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Independent protection layer specification credit from Risk Assessment

GENERAL SUBJECT
CATEGORY RRF 10 for SIS or RRF 100 for SIS RRF 1000 for SIS
BPCS or alarms

Logic solver system Use system Use system manufacturer Use system manufacturer
manufacturer MTTF MTTF data for PFD MTTF data for PFD
data for PFD calculation calculation
calculation

Final element Use proven test Use proven test interval or Unless known use default
interval or use use default MTTF from MTTF from publications for
default MTTF from publications for PFD PFD calculations
publications for PFD calculations
calculations

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Maintenance and repair Procedures Procedures required. Procedures required.
required. Repair Repair time as required by Repair time as required by
time as required by instrument redundancy instrument redundancy
instrument
redundancy

Test procedures A detailed written test procedure should be prepared for each safety relevant
instrument. Test procedures should incorporate the testing of each element in
the loop, from the measuring element through the final control element.

Testing documentation Records of test completion dates (as-found/as-left) should be kept for the
current and preceding test (at least one year). The identity of the person
conducting the test and any unsatisfactory performance of the instrument is
recorded.
A history of poor reliability or proof-test failures requires action plans to
General correct.
requirements Fail safe design Fail safe condition of loop components is defined

Overrides and bypasses Generally no bypass or override should be designed or used. Any override or
bypass needs separate evaluation and approval. A procedure should be
followed when bypass or override is applied.

MOC Any change to SIS should follow an MOC procedure.

Audits Audit of SIS is done periodically as part of the US-OSHA safety audit. This
audit reviews performance and adequacy of the SIF and SIS.

* AK refers to the classification system established for PES in DIN VDE 0801, which is a German
standard.

A.3.6 Comparison with Accepted Prior Design Practices - B

In this method, the company has an Accepted Prior Design Practice that documents minimum design
requirements for the SIS. This design practice has been used for many years. To determine whether SIS
designed in accordance with this design practice can be considered for grandfather status, a two-step
evaluation is performed. First, SIL calculations are performed on the various SIS designed to the
Accepted Prior Design Practice. The calculation determines the suitability of the design practice to
achieve the risk reduction or integrity requirement. Second, the design practice is evaluated using a
method similar to those described in Annexes A.3.3 through A.3.5. This evaluation determined whether
SIS functionality is achieved. If the design practice is determined acceptable, any SIS designed in
accordance with the practice can be considered for the grandfather clause.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

For example, a company that is using their own classification system could map their internal
classifications to the different SILs. Table A.5 shows an example of how one company made this
comparison. The company should verify the SIL for the SIS that are grandfathered. SIL calculations of
multiple examples from each SIL level should be conducted to validate the design practice. Any
assumptions used to run the SIL calculations, such as testing interval, should be considered when
granting grandfather status to a specific SIS.

Table A.5 — Example of Mapping Prior Design Practice Classification to SIL Levels
NOTE -- Example provided by one owner/operator.

Accepted Prior Design Class SIL Level

Class 1 SIL 3
Class 2 SIL 2
Class 3 SIL 1

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
A.3.7 Comparison with a Recognized and Generally Accepted Good Engineering Practice

The United States Occupational Safety and Health Administration (US-OSHA) requires the use of
recognized and generally accepted good engineering practices (RAGAGEP), such as those documented
in industrial standards. There are many good engineering practices issued by industrial organizations,
such as NFPA, API, ASME, ANSI, ISA, etc. These industrial standards tend to be developed in response
to new knowledge, analysis tools, and technology. They rely upon the cumulative operating experience
throughout industry. They are often application-specific, addressing a specific type of process, such as
API 14C for off-shore platform safety, or fired equipment, such as NPFA 85/86 for boilers and furnaces.

NOTE -- It is important to recognize that the RAGAGEP may address more than process safety and may include requirements
directed at reducing equipment damage, improving operability, or improving reliability.

Industrial standards often define, in a prescriptive manner, the SIFs required to safely manage the
process or equipment. For existing SIFs, omission of the SIL verification would only apply when the
standard is prescriptive and clearly defines the required architectures and operation/maintenance
practices necessary to implement the SIF(s). The scope and coverage of the standard should result in an
SIS that provides safe process operation.

A typical example would be burner management systems for industrial heating equipment, such as fired-
process heaters, reformers, and boilers. Industrial standards and practices for this application would
include, but are not limited to, API practices, NFPA standards, and insurance practices (e.g., Factory
Mutual) that provide prescriptive requirements for the SIS to achieve functional safety in fired equipment.

An owner/operator should periodically perform a gap analysis to confirm that all requirements of the
standard have been achieved. Changes made to the standard should be carefully considered throughout
the life of the equipment. Additionally, the SIS should be managed appropriately with respect to
documentation, training, periodic proof testing, auditing, and management of change as defined by
ANSI/ISA-84.00.01-2004-1 requirements. Robustness of components used to construct the SIF(s) should
meet owner/operator’s requirements of “prior use” for the application in which they are applied. Finally,
any implied redundancy in the standard should be carefully considered.

One of the most important requirements when using this method is to determine that the process
equipment clearly falls within the scope of the standard. When equipment or process varies from the
standard scope, additional analysis using other techniques for determining applicability of grandfathering
are required. An example of a variation would be a waste fuel that is not included in the scope of a
standard governing a burner management system. Any special requirements for handling the waste fuel

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

would need analysis beyond the scope of the standard. An acceptable technique would be a hazard and
risk analysis (may be supplemented with fault-tree evaluation of risk) of those parts of the system that do
not specifically apply to the scope of the standard. In other words, the owner/operator determines the
functionality and integrity (SIL) requirements for those parts of the SIF that are outside the scope of the
standard.

A.3.8 Evaluation of existing automated shutdowns

Clause A.3.8 illustrates one company's approach to determining if an existing SIF meets the grandfather
clause requirements. This approach involves three steps, as follows:

Step 1: Identify existing automated shutdowns.

Step 2: Perform Hazard and Risk Analysis (H&RA).

• Identify the hazard scenario(s) that each automated shutdown is protecting against.

• Identify the process risk of the hazard scenario(s).

• Determine the overall required risk reduction necessary to reduce the process risk to the defined
risk criteria.

• Identify safety functions that fully mitigate the hazard scenario.

• Allocate risk reduction to each safety function as necessary to achieve the overall required risk
reduction.

• Allocate each safety function to a protection layer that is designed and managed to achieve its
allocated risk reduction.

Step 3 For each identified SIF, review the existing design and operating basis documentation for clarity,
correctness, and completeness. The design basis documentation should cover the following areas at a
minimum:

• Process hazard mitigated by the SIF.

• SIF description detailing the process variables measured and voting architecture, decision logic
for initiation of the mitigating action, and the final elements and voting architecture along with any
equipment necessary for actuation of the final elements (relays, solenoid operated valves etc.).
Any support systems required for SIF, such as air/hydraulic/electrical supply should be
documented.

• SIF reset functional description.

• SIF diagnostics and automated testing requirements.

• SIF alarms (diagnostic, pre-trip and trip, bypasses) requirements.

• SIF maintenance provisions (bypasses) requirements.

• SIF manual shutdown requirements.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• SIF logic solver requirements.

• SIF devices and required testing interval.

The operating basis documentation should cover the operation and maintenance requirements of
ANSI/ISA-84.00.01-2004-1 in the following areas:

• Operating procedures

• Test procedures

• Management of change procedures, including software and configuration management

• Failure tracking procedures

• Training procedures

• Audit procedures

Step 4 A quantitative assessment of the existing SIF is performed to determine that the design basis and
testing interval achieve the target SIL.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

This page intentionally left blank.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex B – Operator action as an Independent Protection Layer (IPL)

NOTE -- Annex B is referenced in the following: Clause 4.2, Clause 4.3, Clause 4.4, Annex K.3.3.1, Annex N.9.2, Annex 9.3, and
Annex P.2.

B.1 Purpose

The purpose of this Annex is to provide guidance for the design and limits of risk reduction that can be
claimed where an operator, as a result of an alarm, takes action on the process to achieve a safe state or
maintain safe operation.

NOTE 1 Refer to ANSI/ISA-84.00.01-2004-1, Clause 8.2.1, for requirements on hazard and risk analysis.

NOTE 2 Refer to ANSI/ISA-84.00.01-2004-1, Clause 11.3.1, through 11.3.3 for a discussion on the operator response to diagnostic
faults.

ANSI/ISA-84.00.01-2004-1 establishes the premise that operator action can be a part of an SIF. The
capability of the operator should be addressed when allocating risk reduction to an operator-initiated SIF.

NOTE -- Refer to ANSI/ISA-84.00.01-2004-1 Clause 3.2.72, NOTE -- -- 5, for additional guidance on the definition of SIS.

B.2 Key points

1. Operators often take control actions on a process through the BPCS. Normal process control actions
are generally not considered safety functions.

2. When the operator is expected to take action in response to an alarm to prevent a process safety
incident, the operator alarm and associated action is considered a safety function. These alarms are
classified as safety-related and are designed and managed in a manner that supports the allocated risk
reduction.

3. In general, no more than one order-of-magnitude risk reduction should be taken, irrespective of the
number of alarms or the protection layer allocation. This is due to potential operator/procedural common-
mode failure. Additional guidance on evaluating operator error is provided in Annex B.5.

4. Alarms for which an operator or facility worker is required to evacuate an area (e.g., fire and gas
alarms) and are not intended to direct the operator to take action on the process are generally not
considered safety instrumented functions. These alarms should not be allocated to the BPCS but may be
allocated to the SIS or to another independent protection layer. Refer to Annex F, Figure F.1, for an
overview of protection layers. These alarms are generally classified as safety-related and are designed
and managed in a manner that supports the allocated risk reduction.

5. Alarms for which an operator is required to notify maintenance to repair a faulty SIS device in response
to a diagnostic alarm may be part of the BPCS, but are subject to proof testing and management of
change. These alarms should be classified as safety-related, and operators should be trained on the
response to these diagnostic alarms. The devices should also be managed as safety-related
instrumentation under the mechanical integrity program, ensuring that validation, access security, and
management of change is practiced.

6. When credit for a risk reduction equal to or greater than 10 for a single operator action is proposed, the
following should be considered:

NOTE -- Layer of protection analysis (LOPA) is often implemented as an order-of-magnitude assessment. Consequently, it is typical
for the purpose of the LOPA calculation to assume a rounded off risk reduction factor of 10 for an operator action IPL implemented
in the BPCS layer when it has met the other criteria discussed in this Annex and in Annex F.

• All hardware involved should fully meet the requirements of ANSI/ISA-84.00.01-2004.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• Potential credit for the operator should be determined via rigorous analysis.

• A program should be implemented to ensure that all human-error analysis assumptions are
maintained or improved.

7. Process owners should also consider alarm-system guidance provided in other standards and
practices. For example, the Engineered Equipment and Materials Users’ Association (EEMUA), Health &
Safety Executive (HSE), and The International Society of Automation (ISA) have developed extensive
guidance on alarm management. Design of alarm systems should consider ISA 18.1-1979, ANSI/ISA
18.2-2009, ISA RP 60.3-1985, ISA RP 60.6-1984, EEMUA 191-2007, ANSI/IEEE-845-1999, ANSI/IEEE-
Std 1023-2004, IEEE-1289-1998 and NUREG-0700 Rev 2-2002.

B.3 BPCS operator action

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Operator actions that are implemented through the BPCS, in response to process conditions, can be
credited with a risk reduction of less than 10 under the following conditions:

• The guidance in ISA-TR84.00.04-1 Annex F.2 is followed.

• There is sufficient time for operator response. Refer to B.5.

• Operator actions are covered by an operating procedure.

• The operator is trained on the procedure.

• All devices involved in the hazard scenario detection and response are subject to proof testing,
access security, and management of change.

The hardware associated with a BPCS operator action is not covered by the standard. However, its
performance should be monitored to ensure that it is sufficient. Formal PFD calculation is typically not
required. Human factors should be considered in the design of any critical operator activity. For example,
the design of the BPCS operator interface should incorporate human factors engineering (HFE) principals
to ensure that the operator responds adequately to an alarm or process indication. However, a detailed
human-error analysis is not required for operator actions implemented in the BPCS. Refer to Table B-1 for
additional allocation and risk-reduction guidance.

B.4 Operator-initiated SIF

A risk reduction equal to or greater than 10 can be claimed where an operator, as a result of an alarm,
takes action to place the process in a safe state. To take credit for a risk reduction equal to or greater
than 10, a risk analysis should be performed to verify its feasibility. It is especially important to determine
whether there is sufficient human response time. Refer to Annex B.5 for more discussion on human
response time.

Operator-initiated SIFs can be allocated risk reduction when certain criteria are met. These criteria include
consideration for the human factors of the operator interacting with the process and the integrity of the
equipment used to bring the process to a safe state. For all safety-related operator actions, the alarm
should be covered by a procedure that uses a clear and reliable indication that a defined action is
required and includes a well-documented action. The devices should also be managed as safety-related
instrumentation under the mechanical integrity program, ensuring that validation, access security, and
management of change is practiced.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

An operator-initiated SIF is often associated with a “never exceed never deviate” alarm, where the
operator is expected to mitigate risk in much the same manner as an automated SIF. Operator-initiated
SIFs are generally used when it is not possible to completely automate the function. The manually
initiated action is typically comprised of the sensor detecting the hazardous condition, the logic solver that
determines that the safety condition exists, alarm presentation, human response, and the equipment used
by the operator to bring the process to a safe state. When risk reduction is taken for an operator-initiated
SIF, the PFDavg should be determined for the instrumented system. This is discussed further in B.6.

Finally, when allocating risk reduction, it is important to remember that one operator equals one response.
Multiple alarms generally do not yield higher performance because the operator is the single point of
failure for the necessary response. If the team has allocated risk reduction to an operator action in the
BPCS layer, additional risk reduction should not be taken for an operator action allocated to the SIS layer
for the same hazard scenario unless a detailed analysis is performed. When examining the overall risk
reduction that can be provided by the alarms, it is important to recognize the potential for common-mode
failure due to operator or procedural error.

B.5 Human response time criteria

Table B.1 provides an example of criteria that can be established for operator action as an IPL. According
to this example, the risk reduction allocation is related to the protection layer allocation, human response
time and the complexity of the action. The human response time should be less than the available
process safety time, when an operator response to an alarm is being considered for reducing the risk of a
specified hazard scenario. The available process safety time is the time it takes the process to go from
the alarm condition to the hazardous condition. Human error occurs when an operator fails to respond
correctly within the available process safety time.

The human response time is the time from the alarm/process indication to the completion of the actions
necessary to place the process into a safe state. The human response can be broken down into four
functions: (1) Recognize the unsafe condition, (2) Analyze the condition properly, (3) Perform the required
safety action, and (4) Continue to monitor the process to determine whether safety actions were
sufficient.

Sample times for human action in response to alarms are shown in Table B.1. These IPL time limits are
based on research and are confirmed by industry experience. If the owner/operator wishes to use shorter
response times or lower PFDavg values, the owner/operator is cautioned to do a detailed human reliability
assessment to confirm the assumed PFDavg. The values in the table below represent the PFD of the
entire IPL. They are not to be interpreted as PFDavg of the human action only.

There are a number of methods for evaluating the probability of human error. Two of the better-known
methods are the Technique for Human Error Rate Prediction (THERP) (Reference NUREG/CR-1278) and
the Accident Sequence Evaluation Program Human Reliability Analysis Procedure (Reference
NUREG/CR-4772). Error rates are usually established on a per-demand basis.

The nominal human error rates can be reduced or increased based on operator-related environmental
factors (quality of displays, control layout and clarity, control area environment, procedures, access),
personnel factors (training, experience), and stress factors (personal, shift schedules, response time
pressure, severity or magnitude-of-safety condition). The best source for determining the human error
rate would be company/facility-specific historical data, but in most organizations, this is not available.
Therefore, an owner/operator often uses other published, acknowledged sources and adjusts the human
error rate for their application and circumstances accordingly.

In addition to the initial evaluation of the credited operator action, a program should be established to
ensure that all assumptions about the reliability of the operator response are maintained and improved.
This would include, but is not necessarily limited to: initial training, refresher training, procedures
engineered to decrease the likelihood of human error, important human factors that have been identified,

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

potential for alarm overload, adequate time to respond to the safety alarm, adequate staffing, etc. See
Table B.2 for a checklist of human factors issues.

Table B.1 – Sample of IPL Criteria for Operator Response to Alarms*

The values in the table below represent the PFD of the entire IPL and should not be interpreted as the
PFD of the human action only. (CCPS 2001, CCPS 2008, and NUREG/CR-1278, 1983)

IPL Comments PFD from Literature Suggested IPL PFD

and Industry
Human response to a visual Simple well-documented 1.0 -- 1 x 10 -1 ~1 x 10 -1
observation of a process action with clear and reliable (limited by human
hazard (e.g., visible vapor indication that the action is response)
cloud, obvious loss of required. The operator does
containment) with ≥10 minutes not have to perform
response time (not a response troubleshooting or diagnostics
to instrumentation) to take the action.
Human response to a visual Simple well-documented 1 x 10 -2 1 x 10 -2
observation of a process action with clear and reliable (limited by human
hazard (e.g., visible vapor indication that the action is response)
cloud, obvious loss of required. Minor
containment) with ≥40 minutes troubleshooting or diagnostics
response time (not a response is allowed if needed before
to instrumentation) taking action.
Human response to BPCS Simple well-documented ≥ 1 x 10 -1 ~ 1 x 10 -1 **
indication or alarm with ≥10 action with clear and reliable (limited by
minutes response time indication that the action is ISA-84.00.01-2004)
required. The operator does
not have to perform
troubleshooting or diagnostics
to take the action.
Human response to BPCS Simple well-documented ≥ 1 x 10 -1 ~ 1 x 10 -1 **
indication or alarm with ≥40 action with clear and reliable (limited by
minutes response time indication that the action is ISA-84.00.01-2004)
required. Minor
troubleshooting or diagnostics
is allowed if needed before
taking action.
Human response to SIS Simple well-documented 1 x 10 -1 1 x 10 -1
indication or alarm with ≥10 action with clear and reliable (limited by human
minutes response time indication that the action is response)
required. The operator does
not have to perform
troubleshooting or diagnostics
to take the action.
Human response to SIS Simple well-documented 1 x 10 -1 to 1 x 10 -2 1 x 10-1
indication or alarm with ≥40 action with clear and reliable (limited by human or
minutes response time indication that the action is response) 1 x 10 -1 to 1 x 10 -2
required. Minor (as determined by
troubleshooting or diagnostics human reliability
is allowed if needed before assessment)
taking action.
Human response to SIS Simple well-documented 1 x 10 -1 -- 1 x 10 -3 1 x 10 -2
indication or alarm with more action with clear and reliable (limited by human or
than 24 hours response time; indication that the action is response) 1 x 10 -1 -- 1 x 10 -3
assumes multiple operators required. Minor (as determined by
have an opportunity to detect troubleshooting or diagnostics human reliability
the alarm(s) and take action is allowed if needed before assessment)
taking the action.
Assuming adequate documentation, training, and testing procedures, and drills for the human.

* Rounded to 1 x 10 for ease of computation, while recognizing the ISA-84.00.01-2004-1 limit of ≥10 .
-1 -1

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Table B.2 – Checklist for Human Factors Issues

Human Factors Engineering Issues Yes No N/A

Can the operator respond within the required time response for the SIF?
Are operators provided specific alarm-response procedures?
Are operators adequately trained relative to the required SIF action?
Are operators periodically evaluated for competency in SIF response?
Are operators physically capable of accomplishing the response action?
Are controls and displays adequate, effective, and suitable for operator tasks?
Is the operator action consistent with existing protocol and procedures, established
conventions and operator experience?
Do separate displays present consistent information?
Is display movement consistent/compatible with related control movement?
Is displayed information readable to the necessary precision, concise, complete, and
usable without extrapolation?
Is adequate information about normal and upset conditions displayed?
Is display failure readily apparent?
Are displays and controls located within recommended height and reach limits?
Are SIF alarms obvious to an operator?
Are related controls, displays, and alarms grouped together?
Is the possibility of accidental operator activation of SIF initiation minimized?
Is the SIF operator interface in an area that requires frequent operator attention?
Do displays support operator task requirements in terms of range, precision, and
accuracy?
Are normal operating ranges and alarm setpoints clearly identified?
Are the completions of commanded SIF actions (i.e. valve position, pump status)
displayed?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

B.6 Verification of an operator initiated SIF

As shown in Table B.1, the hazard and risk analysis may identify operator actions that are allocated to the
SIS layer. When risk reduction is taken for an operator-initiated SIF, the evaluation of the PFD of an
operator-initiated SIF is performed similarly to the evaluation of an automatic SIF. Figure B.1 is a
representation of an operator-initiated SIF. This figure is adapted from ANSI/ISA-84.00.01-2004-1, Clause
3.2.72, Figure 7.

Alarm Presentation
Sensors Logic Solver Operator Action Final Elements

NP NP NP NP
PE PE PE PE
H/W S/W H/W S/W H/W S/W H/W S/W

Support System
NP - Non-Programmable System
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

PE - Programmable Electronics

Figure B.1 – Example of operator-initiated SIF architecture

The verification of the operator-initiated SIF should consider the potential for operator error using user-
approved criteria or analysis techniques. This assessment should include the human interface design and
operating procedures.

Most automated SIFs are designed as de-energize to trip. As a result, the PFDavg calculation for these
SIFs generally does not take into consideration any utility systems. Operator action inherently requires
support systems to complete the safety function. Display/alarms require power to actuate the light and/or
horn for operator response. Therefore, the reliability of the electrical power system directly affects the
PFDavg of the credited operator action.

A simplified example of an operator-initiated SIF architecture is provided in Figure B.2. Figure B.3
provides an example of the use of Fault Tree Analysis to evaluate the PFDavg of the example architecture.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

PT: Pressure transmitter

FC: Fail closed

S: Solenoid

AS: Air supply

PAH: Pressure alarm high

Control
SIS Room
Logic PAH HS
Solver

PT
S

Figure B.2 – Operator initiated SIF action to close valve on high pressure

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Logic Solver
Failure

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Figure B.3 – Fault Tree Analysis of Figure B.2

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex C – Management of functional safety

NOTE -- Annex C is referenced in the following: Clause 4.1 and Clause 4.5.

C.1 Purpose

Management of functional safety is a new requirement in ANSI/ISA-84.00.01-2004-1, but it has always

been considered a necessary activity by OSHA 1910.119 and ANSI/ISA-84.01-1996. The intent of this
annex is to provide additional guidance on the management of functional safety.

C.2 Identification of the right people

The intent of ANSI/ISA-84.00.01-2004-1 is to achieve functional safety throughout all phases of plant
operation. To achieve functional safety, the standard requires identification of the following:

• The activities that should take place throughout the execution of a project to achieve safe
operation

• The activities that should take place during the operation of the plant to maintain safe operation

• The personnel who are responsible for conducting each activity

In addition to meeting the functional safety requirements, all designs should consider the reliability,
operability, and maintainability requirements of the process unit. Designing an SIF that requires frequent
off-line testing to achieve its SIL may not be supported by a plant that wants to increase its service factor
by extending the turnaround interval. Consequently, part of identifying the right people to work on SIS
projects is to determine whether they follow design practices that are geared toward the requirements of
the standard and achieve the plant targets for reliability, operability, and maintainability. The right people
also need to know a lot more than what is contained in the ANSI/ISA-84.00.01-2004. Knowledge of the
standard can supplement education and experience but cannot replace it. For example, the SIS specialist
should understand the process, the equipment, the operation, basic process control system design,
protection layer design, safety instrumented system design, human ergonomics, consequence modeling,
and hazard and risk analysis.

Clearly established roles and responsibilities enable the necessary resources to be defined early,
ensuring that the project is correctly staffed. Table C.1 provides an example of a roles-and-responsibilities
matrix. For this project, an SIS specialist was the project lead.

Personnel assigned to a specific project often represent multiple companies, such as the owner/operator,
engineering contractor, integrator, manufacturer, or consultant. For this reason, the standard refers to the
identification of individuals, departments, or organizations that are responsible for each lifecycle task.
Personnel education and experience should be evaluated to determine whether mentoring, supervision,
or additional training is necessary. For example, Table C.2 provides suggested education and experience
for the various disciplines that are shown in Table C.1.

All documents created for a project should be reviewed by an independent person from the creator of the
document. At certain stages of the lifecycle, the standard recommends that a functional safety
assessment be performed by an assessment team that contains at least one senior, independent,
competent person. This independent person can be an employee of the company or a contracted third-
party, as long as the reviewer understands the process hazards, the company’s management system, the
full SIS lifecycle, and the fundamentals of appropriate design, installation, operation, maintenance,
testing, and reliability. This person should not be part of the project team, report to project team
management or plant operations, and should have the authority to prevent the project from proceeding if
deviations are not addressed.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

C.3 Development of a work process

The owner/operator should define when verification, assessments, auditing and validation activities take
place to ensure that adequate time and resources have been assigned to these activities. The highest
quality projects are obtained when procedures or guidelines are in place to ensure that all activities occur
in the proper order with the necessary content. For example, many projects have experienced delays
when SIL verification was performed late in the project, and the SIS design was found to be inadequate.

Procedures for evaluating the performance of the SIF after it has been installed (e.g. performance audits,
tracking failure rates, etc.) should also be developed. For further information on auditing activities, refer to
ISA-TR84.00.04-1, Annex E. Table C.3 provides an example of the activities that should occur during
implementation of the ANSI/ISA-84.00.01-2004 lifecycle. It lists the information required in each clause,
including input information and output deliverables. Verification planning is also incorporated in this table
by referencing the verification activities for the referenced clauses.

C.4 Roles and responsibilities matrix

One option for the management of functional safety is developing and using a roles-and-responsibilities
matrix. The attached roles-and-responsibilities matrix is provided for illustration purposes only. It is
typically developed for each specific project. In the roles-and-responsibilities matrix, each clause or step
is divided into four activities – planning, inputs, outputs, and verification.

The verification portion includes all the specific requirements (all the “shall” statements) from the
standard. Whoever has the review responsibility for any lifecycle activity deliverable should consider
developing a verification list that addresses relevant requirements from the standard.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Table C.1 — Example roles and responsibilities matrix

ANSI/ISA-84.00.01-2004-1 CLAUSE SIS Project Area Operations Maint/Elec Process/ Project SIS Corporate/
Specialist Leader Supervisor Rep Rep Design Contractor Plant
(note 1) Engineer HS&E

Clause 5 – Define performance L R/A A P/R P P R

monitoring and corrective actions
required to establish the adequacy of
the quality management system.
Clause 6 – Define safety life-cycle L R/A P P P
phases, incorporating standard
requirements including technical
activity inputs, outputs, and verification
steps required to meet the safety
requirements.
Clause 8 – Hazard and risk assessment L R A R R P P A
(Layers of Protection Analysis, Layered
Risk Analysis, etc,)
Clause 9 – Allocation of safety
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

functions to protection layers

Clause 10 – SIS safety requirement L R A R R P P
specification (SRS)
Clause 11 – SIS design and engineering L R A R R P
Clause 12 – Requirements for L R A R R P
application software, including
selection criteria for utility software
Clause 13 – Factory acceptance test L R A R R P
(FAT) informative not normative
Clause 14 – SIS installation and L R A R R P
commissioning
Clause 15 – SIS safety validation (SAT) L R A R R P
Clause 16 – SIS operation and L R A R R P
maintenance
Clause 17 – SIS modification L R A R R P
Clause 18 – SIS decommissioning L R A R R P
Clause 19 – Information and L R A R P R P
documentation requirements

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Legend:

A – Approval. Decides when the activity or deliverable is complete.

L – Lead. May perform the work or just coordinate it. Has responsibility to see that the activity or
deliverable is completed.

P – Participate. Performs a portion of the work. Participates as a member of the team as directed by the
“Lead.”

R – Review. May provide initial examples or review the final material.

Blank – No involvement.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
NOTES

1. The successful implementation of a quality SIS requires that plant personnel and contractors work as a team. The SIS team
coordinates the work, gathers information to make informed decisions, and gains consensus on the final design. For each SIS
project, there are core members that take responsibility for design and implementation of the SIS. In addition, a number of additional
resources may be needed. The SIS team and the additional resources are provided below.

2. SIS project members assigned to every project:

• Project Manager - Coordinates activities. Manages the budget and schedule.

• SIS Specialist - Keeper of technology.

• Maintenance Representative - Coordinates maintenance input.

3. Other project members assigned by the unit installing the safety system:

• Area Supervisor - Person that owner/operator designates as having approval authority.

• Operations Representative - Coordinates operational input, for example, graphics design and location of manual
shutdown pushbuttons.

• Process Engineer - Coordinates process input, e.g., the trip setpoint values and justification for value.

4. Additional resources may include representatives from the following groups:

• Maintenance

• Operations

• Process engineering

• Reliability

• Health, Safety, and Environment

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Table C.2 — Examples of experience or skills for the disciplines represented in the
example Roles and Responsibility Matrix shown in Table C.1
Discipline Experience or Skills
SIS Specialist Very familiar with ISA-84.00.01-2004/ISA-84.01-1996
Understands the risk criteria to be applied during the design
Experience/training on hazard- and risk-analysis methodology
Knowledgeable in device common-mode/common-cause failures
Knowledgeable in the work process for selection of devices
Knowledgeable in the design, installation, and management of SIS
Knowledgeable in the appropriate selection of integrity and reliability data
Knowledgeable in the methods for verifying SIL
Understands the roles and responsibilities of the other parties in the project
Corporate/Plant Health, Experience/training with SIS lifecycle and understands personal role and responsibility
Safety, and Environmental
Representative Knowledgeable in the risk criteria to be applied during the design
Knowledgeable in hazard- and risk-analysis methodology
Experience/training in equipment design limitations, process hazards and interactions
with other process units
Process/Design Engineer Experience/training with SIS lifecycle and understands personal role and responsibility
Knowledgeable in the process under evaluation
Experience/training in hazard and risk analysis
Experience/training in the risk criteria to be applied during the design
Understands equipment design limitations, process hazards and interactions with
other process units.
Understands operating procedures for various modes of operation
Experience/training in the development of input information required by those
executing the SIS design
Experience/training in selection of SIS devices and technologies
Project SIS Contractor Knowledgeable with ISA-84-2004/ISA-84-1996
Understands the risk criteria to be applied during the design
Experience/training in hazard- and risk-analysis methodology
Experience/training in device common-mode/common-cause failures
Experience/training in the work process for selection of devices
Experience/training in the design, installation, and management of SIS
Experience/training in the appropriate selection of integrity and reliability data
Experience/training in the methods for verifying SIL
Maintenance/Electrical Experience/training with SIS lifecycle and understands personal role and responsibility
Representative
Knowledgeable in maintenance and testing practices and procedures
Knowledgeable concerning equipment (including fixed equipment and instrumentation)
failure history and causes.
Experience/training in process hazards
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Experience/training in integrity/reliability data

Experience/training in the impact of testing on SIS performance
Experience/training in the impact of maintenance activities on plant operation

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Discipline Experience or Skills

Operations Representative Experience/training with SIS lifecycle and understands personal role and responsibility
Knowledgeable in operating procedures, including response to diagnostic and critical
alarms
Experience/training in process hazards
Experience/training in integrity/reliability data
Experience/training in the impact of proof testing on plant operation
Experience/training in the impact of alarm response on safe operation
Experience/training in the impact of operational activities on safe operation
Area Supervisor Experience/training with SIS lifecycle and understands personal role and responsibility
Knowledgeable in operator training, responsibilities, and capabilities
Knowledgeable in maintenance training, responsibilities, and capability
Knowledgeable in process hazards
Experience/training in integrity/reliability data
Experience/training in the impact of operational activities on safe operation
Experience/training in the impact of testing on SIS performance

Table C.3 — Overview of activities, including verification, input information, output

deliverables, and performance monitoring associated with ANSI/ISA-84.00.01-2004-1

Clause 5 – Define performance monitoring and corrective actions required to establish the adequacy of the
quality management system.

Inputs:
1) Dangerous failure rates of safety instrumented system components assumed during the design
2) Demand rate on the safety instrumented system assumed during the risk assessment
3) Operations and Maintenance records: proof-test records; trip reports; near-miss evaluations; diagnostic alarm
performance records
4) Product defect/recall notices from component manufacturers
5) Device/technology performance databases from authoritative sources
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Outputs:
1) Comparison of observed failure rates, from user proof test and performance data, versus assumed dangerous failure
rates – 5.2.5.3
2) Comparison of observed demand rates, from user trip reports and near-miss evaluations, versus assumed initiating event
frequencies –5.2.5.3
3) Procedures that define the corrective action mechanisms to be used when failure or demand rates are greater than those
that were assumed during design. –5.2.5.3 NOTE -- -- 2
4) Procedure for identification and prevention of safety-related systematic faults – 5.2.5.3
5) Recommendations to address identified discrepancies
6) Implementation schedules and tracking reports for the recommendations
Verification: Assessment reports evaluating the SIF performance against the design expectations. – 5.2.6

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Activities:

1) Define the procedure and technique to be used to collect and track proof-test and performance data, including SIS failure
data.
2) Define the procedures and techniques to be used to collect data on actual process demands.
3) Define techniques and calculations to estimate failure rates from collected data.
4) Develop a roles-and-responsibilities matrix and assessor qualification requirements.
5) Establish a schedule for the performance of the assessments – 5.2.6.1.3.
6) Define the procedures for recording and sharing results and metrics for performance review.

Clause 6 – Define safety life-cycle phases, incorporating standard requirements, including technical activity
inputs, outputs, and verification steps required to meet the safety requirements.

Inputs: Company risk-management policy

Outputs:

1) Define phases & establish requirements for safety life-cycle activities – 6.1
2) Organize technical activities into a safety life cycle – 6.1
3) Ensure adequate planning exists so that the SIS meets the safety requirements – 6.1
Verification: (Clause 7)

Activities:

1) If one does not exist, develop a safety life cycle, incorporating standard requirements – 6.2.1
2) Define inputs, outputs and verification activities for each phase – 6.2.2
3) Safety planning for all safety life-cycle phases to define criteria, techniques, measures, and procedures to -- 6.2.3:
a. ensure that the SIS safety requirements (both function & safety-integrity requirements) are met for all relevant modes
b. ensure proper installation and commissioning of the SIS
c. ensure safety integrity of the SIF after installation
d. maintain the safety integrity during operation
e. manage the process hazards during maintenance activities of the SIS
4) Identify stages at which functional safety assessment activities occur – 5.2.6.1.3
5) Identify functional safety assessment team leader
6) Develop roles-and-responsibilities matrix and implementation schedule

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Clause 8 – Hazard and risk assessment (Layers of Protection Analysis, Layered Risk Analysis, etc,)
and Clause 9 – Allocation of safety functions to protection layers

Inputs:

1) Organization risk-ranking criteria

2) Process design – P&ID & PFD
3) Process description
4) Process safety information per OSHA 1910.119 (d)
Outputs:

1) The following is determined: – 8.1

a. hazards and hazardous events of the process and associated equipment
b. Sequence of Events (SOE) leading to hazardous event
c. process risk from hazardous event
d. requirements for risk reduction
e. safety functions required to achieve required risk reduction
f. which safety functions are SIFs
2) Safety functions allocated to protection layers – 9.1
3) The required SIFs determined – 9.1
The required SIL for each SIF determined – 9.
Verification: (Clause 7)

Activities:

1) Hazard and risk assessment requirements -- 8.2:

a. A hazard and risk assessment on the process and its associated equipment resulting in: – 8.2.1

1) description of each identified hazardous event and the factors that contribute to it

2) description of consequences and likelihood of the event

3) consideration of conditions including:

• normal operation

• start-up

• shutdown

• maintenance

• process upset

• emergency shutdown

4) determination of requirements for additional risk reduction necessary to achieve the required safety

5) description of measures taken to remove hazards and risk

6) description of assumptions made during analysis of risks, including probable demand rate, equipment failure
rates, and credit taken for operational constraints or human intervention

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`

Copyright International Society of Automation

Clause 8 – Hazard and risk assessment (Layers of Protection Analysis, Layered Risk Analysis, etc,)
and Clause 9 – Allocation of safety functions to protection layers

7) allocation of safety functions to protection layers, taking into account potential reduction in effectiveness due to
common-cause failures

8) identify safety function(s) applied as SIF(s)

b. The dangerous failure rate of the BPCS is not assumed to be better than 10-5 per hour – 8.2.2
c. The hazard and risk assessment is recorded in such a way that the relationship between the above items is clear. –
8.2.3
2) Allocation of safety functions to protection layers requirements – 9.2
a. The allocation process results in: – 9.2.1

1) the allocation of safety functions to specific protection layers

2) the allocation of risk-reduction targets to safety instrumented functions

b. The required safety integrity level of an SIF is determined by the risk reduction to be provided by that function – 9.2.2
c. For each SIF operating in demand mode, the required SIL is specified in accordance with either Table 3 or Table 4. –
9.2.3
d. For each SIF operating in continuous mode, the required SIL is specified in accordance with Table 4. – 9.2.4
3) Additional requirements for SIL 4 – 9.3
a. No SIF with an SIL higher than SIL 4 is allocated to an SIS. Such applications are to be avoided where reasonably
practicable. – 9.3.1
b. An SIF of SIL 4 requires the following criteria either a) or both b) and c): – 9.3.2

1) there has been an explicit demonstration by a combination of appropriate analytical methods and testing of the
target safety integrity failure measure having been met

2) there has been extensive operating experience of the components used as part of the SIF

3) there is sufficient hardware failure data, obtained from components used as part of the SIF, to allow sufficient
confidence in the hardware safety integrity failure that is to be claimed
4) Requirements on the BPCS as a protection layer – 9.4
a. The basic process control system may be identified as a protection layer – 9.4.1
b. The risk reduction claimed for a BPCS that does not conform with this standard when used as a protection layer is
less than 10 – 9.4.2
5) Requirements for preventing common-cause, common-mode and dependent failures – 9.5
a. The design of protection layers is assessed to ensure the likelihood of common-cause, common-mode, and
dependent failures between protection layers and between protection layers and the BPCS are sufficiently low in
comparison to the overall safety integrity requirements of the protection layer. – 9.5.1
b. The assessment considers: – 9.5.2

1) independence between protection layers

2) diversity between protection layers

3) physical separation between different protection layers

4) common-cause failures between protection layers and between protection layers and BPCS.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Clause 10 – SIS safety requirement specification (SRS)

Inputs:

1) Process hazard and risk assessment

2) List of safety functions with their target SIL
3) Description of allocation of safety requirements (Clause 9)
Outputs:

1) The safety requirements are derived from the allocation of safety instrumented functions and from those requirements
identified during safety planning – 10.2.1
2) SRS document
Verification (Clause 7)

Activities:

1) SIS safety requirements – 10.3

a. These requirements are sufficient to design the SIS and include the following: – 10.3.1

1) Description of SIFs

2) Requirements to identify and take account of common-cause failures

3) Definition of safe state for each SIF

4) Concurrently occurring safe states that create a separate hazard

5) Assumed sources of demand and demand rate on the SIF

6) Requirements for proof-test intervals

7) Response-time requirements to bring process to safe state

8) The SIL and mode of operation (continuous/demand) for each SIF

9) SIS inputs – pre-trip alarm and trip setpoints

10) SIS output actions, including tight shutoff when required

11) Functional relationship between inputs and outputs, including permissive requirements
12) Requirements for manual shutdown
13) Energize vs. de-energize-to-trip requirements
14) Start-up permissive requirements and sequence after a trip, including requirements for restarting SIF
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

15) Spurious trip-rate requirements

16) Failure modes and desired response of the SIS
17) All interfaces between SIS and other systems
18) Plant modes of operation and SIF required to operate in each mode
19) Application software requirements
20) Override/inhibits/bypass requirements
21) Response actions when SIS failure detected

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Clause 10 – SIS safety requirement specification (SRS)

22) Mean-time-to-repair requirements

23) Dangerous combinations of output states from the SIS to avoid
24) Extremes of environmental conditions
25) Identify normal and abnormal modes and operating procedures
26) Requirements for SIF to survive major accident e.g. valve to remain open during fire.
b. The software SRS is derived from the SRS and the chosen architecture of the SIS – 10.3.2

Clause 11 – SIS design and engineering

Inputs:
1) SIS SRS
2) Software SRS
Outputs:
1) One or more SIS designed to provide the SIFs that meet the specified SIL – 11.1
2) The selected SIS components or subsystems meet the specified requirements – 11.5.1.1
3) The integration of component or subsystem in the SIS architecture meets the specified requirements – 11.5.1.2
4) The components or subsystems in terms of associated SIFs and safety integrity meet the specified acceptance criteria –
11.5.1.3
Verification (Clause 7)

Activities:
1) SIS design and engineering general requirements – 11.2
a. The SIS is designed in accordance with the SRS taking into account the requirements of this clause – 11.2.1.
b. When the SIS implements both safety and non-safety instrumented functions, then all hardware and software that
can negatively affect any SIF under normal or fault conditions is treated as part of the SIS and designed to the
requirements of the highest SIL – 11.2.2.
c. When SIFs with shared common hardware and software have different SILs then the shared or common hardware
and software conforms to the highest SIL unless it can be shown that the lower SIL cannot affect the higher SIL’s SIF –
11.2.3
a. When the BPCS does not qualify to this standard then the BPCS is designed to be separate and independent to the
extent that the functional integrity of the SIS is not compromised – 11.2.4
b. Operability, maintainability, and testability requirements were addressed during the design to facilitate
implementation of human-factor requirements (e.g. bypass for testing and alarming when bypassed) – 11.2.5
2) The SIS is designed to account for human capabilities and limitations and is suitable for the tasks assigned operators and
maintenance. The design of all human machine interfaces (HMI) follows good human-factors practice and accommodates
the likely level of training – 11.2.6

3) Unless the SRS specifies otherwise, the safe state is maintained until reset initiated – 11.2.7

4)
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Unless the SRS specifies otherwise, the manual S/D is independent of logic solver – 11.2.8

5) The design of the SIS takes into consideration all aspects of independence and dependence between the SIS and BPCS,
and the SIS and other protection layers – 11.2.9

6) A device used to perform part of an SIF should not be used for basic process control purposes, where failure of that
device results in a failure of the BPC function which causes a demand on the SIS, unless an analysis is completed to
determine overall risk acceptable – 11.2.10

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

7) Energize to trip requires: – 11.2.11 & 11.6.2

1) Loss of circuit integrity detection

2) Power supply integrity

3) Loss of power detection

8) Requirements for system behavior on detection of a fault – 11.3
a. A detected Fail Dangerous fault in a system that can tolerate a single fault requires: – 11.3.1

1) Going to the safe state or

2) Repairing the fault within the MTTR

b. A detected Fail Dangerous fault in a demand mode in a non-redundant subsystem requires: – 11.3.2

1) Going to the safe state or

2) Repairing the fault within the MTTR with additional measures and constraints providing risk reduction at least
equal to the SIS
c. A detected Fail Dangerous fault in a continuous mode SIS that cannot tolerate a single fault requires going to safe
state – 11.3.3
d. When the operator takes specific action to achieve or maintain a safe state in response to a detected fault, the alarm
is part of the SIS 11.3
e. When operator action is to report detected fault to maintenance for repair, the diagnostic alarm may be part of the
BPCS, but is subject to proof testing and management-of-change requirements – 11.3

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
9) Requirements for fault tolerance – 11.4
a. For SIFs, the sensors, logic solvers and final elements have a minimum hardware fault tolerance – 11.4.1
b. Table 5 shows the requirements for PE logic-solver fault tolerance – 11.4.2
c. Table 6 shows the requirements for non-PE logic-solver hardware fault tolerance provided dominant failure mode is
to the safe state or dangerous failures are detected (else fault tolerance increased by one) – 11.4.3
d. Requirements for reducing non-PE logic-solver hardware fault tolerance by one: – 11.4.4

1) Hardware selected based on prior use

2) Device only allows adjustment of process-related parameters

3) Adjustment of process-related parameters is protected

4) Function has an SIL requirement less than 4

10) General requirements for the selection of components and subsystems – 11.5.2
a. SIL 1 to SIL 3 SIS components for use in an SIS are in accordance with IEC 61508-2 & 3 (manufacturer
documentation), meet required fault tolerance (11.4), have been assessed for prior use (11.5.3), or meet the
requirements for full variability language (FVL) (11.5.6). – 11.5.2.1
b. SIL 4 SIS components are accordance with IEC 61508-2 & 3 – 11.5.2.2
c. The suitability of the components and subsystems was demonstrated through consideration of: – 11.5.2.3

1) Manufacturer hardware and embedded software documentation

2) If applicable, appropriate language and tool selection

d. The components and subsystems are consistent with the SIS SRS – 11.5.2.4
11) Requirements for the selection of components and subsystems based on prior use – 11.5.3
a. Appropriate evidence is available showing that components and subsystems are suitable for use in the SIS. –
11.5.3.1
b. Evidence for suitability of use includes: – 11.5.3.2

1) Manufacturers quality, management and configuration management systems

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

2) Adequate identification and specification of components or subsystems

3) Demonstration of performance of components or subsystems in similar operating conditions

4) Volume of operating experience

12) Requirements for selection of Fixed Program Language (FPL) & Limited Variability Language (LVL) (11.5.5.2)
programmable components and subsystems based on prior use – 11.5.4
a. Requirements 11.5.2 (general requirements) and 11.5.3 (requirements for the selection of components and
subsystems based on prior use) also apply – 11.5.4.1
b. FPL unused features of the components and subsystems identified and established that they are unlikely to
jeopardize the required SIFs – 11.5.4.2,
c. The FPL suitability determination considers: – 11.5.4.3

1) characteristics of I/O signals

2) modes of use

3) functions and configuration used

4) previous use in similar applications and physical environment

d. Using FPL in an SIL 3 application requires a formal assessment to include: – 11.5.4.4

1) The FPL device is both able to perform the required functions and the probability of random and systematic
failures is low enough to achieve the SIL

2) The appropriate standards for hardware and software were applied

3) The FPL device has been used or tested in configurations representative of intended operational profiles
e. Using FPL in an SIL 3 application requires a safety manual for the FPL device that identifies the constraints for
operation, maintenance, and fault detection for typical configurations and the intended operational profiles – 11.5.4.5
13) Requirements for selection of LVL programmable components and subsystems based on prior use – 11.5.5
a. The requirements of Clause 11.5.5 may only be applied to PE logic solvers used in SIL 1 or SIL 2 SIFs – 11.5.5.1
b. Requirements 11.5.4 also apply (FPL programmable components and subsystems based on prior use) – 11.5.5.2
c. A difference between the LVL component’s target operational profile or physical environments and previous
experience requires an assessment based on analysis and testing of said component or subsystem to show that the
likelihood of systematic faults is sufficiently low – 11.5.5.3
d. Operating experience to justify suitability takes into account: – 11.5.3.4

1) the SIL of the SIF

2) the complexity and functionality of the component or subsystem

e. A safety configured PLC used in an SIL 1 or SIL 2 application requires: – 11.5.5.5

1) understanding unsafe failure modes

2) using techniques for safety configuration that address the identified failure modes

3) embedded software has established prior use in safety applications

4) protection against unauthorized or unintended modifications

f. When any PE logic solver is used in an SIL 2 application, documentation exists of a formal assessment showing
that: – 11.5.5.6

1) able to perform required function, PFD acceptable,

2) measures implemented to detect faults during program execution and initiate appropriate reaction including all
of the following: – 11.5.5.6

• program sequence monitoring

• protection of code against modification or failure detection by online monitoring

• failure assertion or diverse programming

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• range check of variables or plausibility check of values

• modular approach

• appropriate coding standards used for embedded and utility software

• tested in typical configuration, with test cases of intended operational profiles

• trusted software modules and components have been used

• system has undergone dynamic analysis and testing

• system does not use artificial intelligence or dynamic reconfiguration

• fault insertion testing documented

g. Using a PE logic solver in an SIL 2 application requires a safety manual that identifies the constraints for operation,
maintenance, and fault detection for typical configurations of the PE logic solver and the intended operational
profiles – 11.5.5.7

14) Requirements for selection of FVL programmable components and subsystems 11.5.6 PE logic solvers programmed
using FVL are in accordance with IEC 61508-2 & 3 – 11.5.6.1
15) Field devices – 11.6
a. Field devices are selected and installed to minimize failures from process and environmental conditions that could
result in inaccurate information – 11.6.1
b. Energize-to-trip discrete I/O circuits consider the application of method(s) to ensure circuit and power-supply integrity
– 11.6.2 & 11.2.11
c. Each field device has its own dedicated wiring. Exceptions for: – 11.6.3

1) multiple discrete sensors connected in series that measure the same process condition

2) multiple final elements connected to a single output

3) a digital bus communication with overall safety performance that meets the integrity requirements of the SIF it
services
d. Smart sensors write-protected with administrative control, exception requires appropriate safety review. – 11.6.4
16) Operator interface requirements – 11.7.1
a. Where Operator SIS HMI interface in the BPCS account is taken of credible failures in BPCS operator interface –
11.7.1
b. The SIS design minimizes the need for operator selection of options and the need to bypass while unit running and
protects against operator error (repeat or confirmation step) – 11.7.2
c. Bypass switches are protected by key locks or passwords – 11.7.3
d. SIS status information critical to maintaining the SIL is available as part of the operator interface, including: –
11.7.1.4

1) where the process is in its sequence

2) indication that a protective SIS action has occurred

3) bypass indication

4) indication that automatic action(s) has occurred such as degradation of voting or fault handling

5) status of sensors and final elements

6) loss of energy
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

7) results of diagnostics

8) failure of required environmental conditioning equipment

e. SIS operator interface design prevents changes to SIS application software from the BPCS. Selective writing from

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

the BPCS to the SIS is managed so the safety functionality is not compromised. – 11.7.1.5
17) Maintenance/engineering interface requirements – 11.7.2
a. Any failure of the maintenance/engineering interface does not prevent the SIS from bringing the process to a safe
state – 11.7.2.1
b. The maintenance/engineering interface provides the following functions with access security protection for each: –
11.7.2.2

1) SIS operating mode, program, data, means of disabling alarm communication, test, bypass, and maintenance

2) SIS diagnostics, voting, & fault handling

3) Add, delete, or modify application software

4) Data necessary to troubleshoot SIS

5) Where bypasses are required, they are designed and installed such that alarms and the manual shutdown are
not disabled
c. The maintenance/engineering interface is not used as the operator interface – 11.7.2.3
d. Enabling and disabling the read-write access is only carried out by using a configuration or programming process
using the maintenance/engineering interface with appropriate documentation and security measures – 11.7.2.4
18) Communication interface requirements – 11.7.3
a. Any failure of the communication interface does not prevent the SIS from bringing the process to a safe state –
11.7.3.1
b. The SIS is able to communicate with the BPCS and peripherals with no impact on the SIF – 11.7.3.2
c. The communication interface is sufficiently robust to withstand EMI, including power surges, without causing a
dangerous failure of the SIF – 11.7.3.3
d. The communication interface is suitable for communication between devices referenced to different electrical ground
potentials – 11.7.3.4
19) Maintenance or testing design requirements – 11.8
a. The design allows testing of the SIS either end-to-end or in parts. Where the interval between scheduled process
downtime is greater than required proof-test interval, online testing is performed – 11.8.1
b. Where online proof testing is required, test facilities are an integral part of the SIS design to test for undetected
failures – 11.8.2
c. Testing or bypass facilities conform with: – 11.8.3

1) SIS is designed in accordance with maintenance and testing requirements specified in SRS

2) Operator is alerted to the bypass of any portion by an alarm and/or operating procedure
d. Forcing I/O in the logic solver is not part of: – 11.8.4

1) application software

2) operating procedures

3) maintenance unless supplemented by procedures, access security, and annunciation

20) SIF probability of failure – 11.9
a. Calculations verify that the PFD of each SIF is equal to or less than the target PFD specified in the SRS – 11.9.1
b. The calculated PFD of each SIF due to hardware failures takes into account: – 11.9.2

1) the architecture of the SIS

2) estimated failure rate of each subsystem due to random hardware faults – in any mode causing PFD faults
detected diagnostics tests

3) estimated failure rate of each subsystem due to random hardware faults – in any mode causing PFD faults
undetected diagnostics tests

4) the susceptibility of the SIS to common-cause failures

5) the diagnostics coverage of any periodic diagnostics test

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

6) proof-test intervals

7) MTTR for detected failures

8) Estimated rate of PFD of any communication process which would cause a dangerous failure (both detected
and undetected)

9) Susceptibility to Electromagnetic Coupling (EMC) disturbances

10) Susceptibility to climatic and mechanical conditions

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Clause 12 – Requirements for application software, including selection criteria for utility software

Inputs:

1) SRS
2) Function Blocks -- prior use, else should use 61508-3
Outputs:

1) Defined software safety life cycle – required activities defined to develop application software for each programmed SIS

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
subsystem (sensor, logic solver, and final elements) – 12.1.1.1
2) How to select, control, and apply the utility software used to develop the application software is defined – 12.1.1.1
3) Adequate planning exists to ensure that the functional safety objectives allocated to the application software are met –
12.1.1.1
4) Requirements provided for the specification of the application software SRS for each programmable SIS subsystem
necessary to implement the required SIFs consistent with the architecture of the SIS – 12.2.1.1
5) Insure suitable application software validation planning is carried out – 12.3.1.1
6) Application software architecture created that fulfills the application software SRS and is consistent with the hardware
architecture – 12.4.1.1
7) Requirements placed on the software by the hardware and embedded software architecture of the SIS reviewed and
evaluated – 12.4.1.2
8) Suitable set of tools selected to develop the application software – 12.4.1.3
9) Design and implement or select application software that fulfills the specified requirements for software safety – should be
analyzable, verifiable, and capable of being safely modified – 12.4.1.4
10) Verify requirements for software safety are met or that the required software safety instrumented functions have been
achieved – 12.4.1.5
11) Demonstrate that the application software meets the software SRS when running on the SIS hardware and embedded
software – 12.5.1.1
12) Ensure that software continues to meet the software SRS after modifications – 12.6.1.1
13) The application software verification information is satisfactory – 12.7.1.1
14) The output results satisfy the defined requirements for each phase of the application software safety life cycle – 12.7.1.2
Verification (Clause 7)

Activities:

1) Life-cycle requirements for application software – 12.1

a. Specify an application software safety life cycle during safety planning that satisfies the requirements – 12.1.2.1
b. For each phase of the software safety life cycle define the: – 12.1.2.2

1) elementary activities

2) objectives

3) required input information

4) output results

5) verification requirements

6) responsibilities
c. The logic solver is suitable for the required safety integrity of each SIF – 12.1.2.3
d. Methods, techniques, and tools selected for each life-cycle phase to: – 12.1.2.4

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

1) minimize risk of introducing faults to the application software

2) detect and remove existing software faults

3) ensure remaining software faults do not lead to unacceptable results

4) ensure software maintainability

5) demonstrate software has the required quality

e. For each phase of the application software safety life cycle, the verification results are available – 12.1.2.5
f. If application software changes pertained to earlier life cycle phases, then the earlier and following phases were re-
examined and if changes were required, repeated and re-verified. – 12.1.2.6
g. Application software, SIS hardware and embedded software, and the utility software tools are under configuration
management – 12.1.2.7
h. Application software test planning addressed: – 12.1.2.8

1) Policy for integrating software and hardware

2) test cases and test data

3) types of tests to perform

4) test environment, tools, support software, and configuration description

5) test completion judging criteria

6) physical locations

7) dependence on external functionality

8) appropriate personnel

9) non-conformances
2) Application software SRS – 12.2

a. An application software safety requirement specification (SRS) is developed. – 12.2.2.1

b. The requirements should be expressed and structured so they are: – 12.2.2.5

1) clear to all those who use the document

2) verifiable, testable, and modifiable

3) traceable back to the SIS SRS

c. Application software SRS inputs for each SIS subsystem includes: – 12.2.2.2

1) specified safety requirements for each SIF

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

2) requirements resulting from SIS architecture

3) any requirements from safety planning

d. The application software SRS is sufficiently detailed to allow design and implementation at the required safety
integrity and to allow assessment of the functional safety. To be considered: – 12.2.2.3

1) application software supported functions

2) capacity and response-time performance

3) operability of equipment and operator interfaces

4) all relevant modes of operation as specified in SRS

5) action to be taken on bad process variable

6) proof test and diagnostics tests of external devices

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

7) software self-monitoring

8) other SIS-device monitoring (sensors & final elements)

9) online testing

10) reference to input documents

e. The application software developer reviews the application software SRS, identifies any deficiencies, and informs
the SIS subsystem developer – 12.2.2.4
f. The application software SRS provides information allowing proper equipment selection. To be considered: –
12.2.2.6

1) functions that enable maintaining the safe state

2) functions related to detection, annunciating, and management of faults in subsystems

3) function related to off-line testing

4) functions related to online testing

5) functions that allow the SIS to be safely modified

6) interfaces to non-safety-related functions

7) capacity and response-time performance

8) the safety integrity levels for each of the above functions

3) Application software safety validation planning – 12.3
Application software validation planning is carried out in accordance with Clause 15 – 12.3.2.1

4) General software application requirements – 12.4.2

a. For application programs using FVL, the development, test, verification and validation are in accordance with IEC
61508-3 – 12.4.2.1
b. The design method is consistent with the development tools and any restrictions defined in the equipment safety
manual – 12.4.2.2
c. The features of design method and applicable language are: – 12.4.2.3

1) features to control complexity (e.g. modularity & abstraction)

2) expression of defined behavior, arithmetic and logical functions, sequencing, design assumptions

3) comprehension by developers

4) verification and validation, including coverage

5) application software modification support (e.g. modularity, traceability, documentation)

d. The application software design should: – 12.4.2.4

1) include integrity and reasonability checks

2) be traceable to the requirements

3)
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

be testable

4) have the capacity for safe modification

5) keep the complexity and size of the SIF application software to a minimum
e. When the application software implements SIFs of different SILs, the target SIL of the SIFs are identified.
f. The software is designed to the highest SIL unless independence between the SIF can be shown in the design –
12.4.2.5
g. The use of previously developed software library functions is justified. Their suitability is based on: – 12.4.2.6

1) for FVL compliance with IEC 51508-3

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

2) for FPL compliance with Clause 11.5.4

3) for LVL compliance with Clause 11.5.5

h. The application program documentation contains: – 12.4.2.7

1) company and authors – legal entity

2) description

3) inputs and outputs

4) configuration management, including history of changes

5) standard library functions used

6) logic convention used

7) traceability to application functional requirements.

5) Application software architecture requirements – 12.4.3
a. The design of the application software architecture is based on the required SIS safety specification within the
constraints of the system architecture of the SIS – selected subsystem design, tool set, and safety manual. –
12.4.3.1
b. The description of the application software architecture design includes: – 12.4.3.2

1) provide a comprehensive description of the internal structure, including the operation of the SIS subsystems
and its components

2) include specification of all identified components (hardware & software) and description of connection and
interaction between identified components

3) identify software modules included in the SIS subsystem but not used in any SIF

4) describe order of logical processing of data, including any limitations imposed by scan times

5) identify non-SIF and ensure they cannot affect the proper operation of any SIF
c. The methods and techniques to develop application software should be identified and justified - 12.4.3.3
d. The methods and techniques should be consistent with SIS safety manual. - 12.4.3.4
e. The features used for maintaining the safety integrity of all data are described and justified 12.4.3.5
6) Requirements for support tools, user manual, and application languages – 12.4.4
a. A suitable set of tools selected, including: – 12.4.4.1

1) application programming language sub-set

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
configuration management

3) simulation

4) test harness tools

5) automatic test coverage measurement tools

b. The suitability of the tools is verified – 12.4.4.8
c. The application language selected should: – 12.4.4.4

1) use a translator/compiler that has been assessed to establish its fitness for purpose

2) be completely and unambiguously defined or restricted to unambiguously defined features

3) match the characteristics of the application

4) contain features that facilitate detection of programming mistakes

5) support features that match the design method

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

d. When 12.4.4.4 cannot be met, the justification for the language used details the fitness for purpose of the language
and any additional measures, which address any identified shortcomings of the language. The justification is
documented during the application software architecture design description. – 12.4.4.5
e. The safety manual addresses: – 12.4.4.7

1) the use of diagnostics to perform safe functions

2) list of approved/verified safety libraries

3) mandatory test and system shutdown logic

4) use of watchdog

5) requirements for and limitations of tools and programming languages

6) safety integrity levels for which the device or system is suitable

f. Verify the suitability of the tools (see 6a above): – 12.4.4.8
7) Application software development requirements – 12.4.5
a. Prior to starting the detailed application software design, the following information is available: – 12.4.5.1

1) software SRS

2) description of the application software architecture design (12.4.3) including ID of application logic & fault
tolerant functionality, list of I/O, generic software modules & support tools, and programming procedures
b. The design of each application module addresses robustness, including: – 12.4.5.3

1) input variable (including global variables) plausibility check

2) full definition of I/O interfaces

3) system configuration checks – existence and accessibility of expected hardware & software modules
c. The design of each application software module and its associated structural tests is specified – 12.4.5.4
d. The application software is reviewed to ensure conformance to the specified design, design principles, and the
requirements of safety validation planning. – 12.4.5.6

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
e. The application software should be structured to achieve modularity, testability, capacity for safe modification and
traceability. – 12.4.5.2
8) Application software module testing requirements – 12.4.6
a. Configuration check of each input through the logic to the output through review, simulation, and testing techniques
to confirm I/O data is mapped to the correct logic – 12.4.6.1
b. Application software module check through review, simulation, and testing techniques to determine that the intended
function is correctly executed, and unintended functions are not executed. – 12.4.6.2
c. The application module testing results are available – 12.4.6.3
9) Application software integration testing requirements – 12.4.7
a. Tests show that all application software modules and components/subsystems interact correctly with each other and
with the underlying embedded software and perform their intended functions – 12.4.7.1
b. The application integration testing results are available – 12.4.7.2
c. Modifications during the application software integration testing were subject to a safety impact to determine: –
12.4.7.3

1) all software modules impacted

2) necessary re-design and re-verification activities

10) Integration of the application software with the SIS subsystem – 12.5
a. Integration test verifying the compatibility of the application software with the hardware and embedded software
platform is specified as early as possible in the software life cycle to ensure that the functional and performance
safety requirements can be met – 12.5.1
b. Modifications during the application software integration with the SIS subsystem were subject to a safety impact to
determine: – 12.5.2.2

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

1) all software modules impacted

2) necessary re-design and re-verification activities

c. The application integration test with the SIS subsystems testing results are available, including: – 12.5.2.3

1) configuration items under test

2) configuration items supporting test

3) personnel involved

4) test cases and test scripts

5) test results

6) whether the objectives and criteria of the test have been met

7) for failures – reason for failure, analysis of failure, records of correction including re-test and re-verification.
11) FPL and LVL software modification procedures – 12.6.1
a. FPL and LVL software modification are in accordance with Clauses 5.2.6.2.2. & 5.2.7 & 17 with the additional
following requirements: – 12.6.2.1
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

1) a modification-effects analysis on the safety of the process and the software design status is used to direct the
modification

2) safety planning for and re-verification of the modification is available and followed

3) The planning for required conditions during modification and testing is considered

4) affected documentation updated

5) details of SIS modification activities available

6) modification and verification is performed per plan

12) Application software verification – 12.7.1
a. Verification planning for each phase of application software safety life cycle – 12.7.2.1
b. Results of each phase verified for: – 12.7.2.2

1) output adequacy against requirements

2) adequacy of review, inspection, and testing coverage of the outputs

3) compatibility between outputs generated at different life-cycle phases

4) correctness of data

Clause 13 – Factory acceptance test (FAT) informative not normative

Inputs:

1) SIS logic solver

2) SIS application software
3) FAT procedure
Outputs:

Logic solver and software tested ensuring SRS satisfied – 13.1.1

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Verification (Clause 7)

Activities:

1) If required, the FAT should be specified as part of the Safety Plan during the design phase – 13.2.1
2) FAT planning should specify the following: – 13.2.2
a. Type of tests – black box, performance testing, environmental testing, interface testing, degraded or fault-mode
testing, exception testing, application of SIS maintenance and operating manuals.
b. Test cases with description and required data
c. Other systems/interfaces required
d. Logic-solver configuration
e. Testing criteria for judging completion
f. Procedures for corrective action on failure of test
g. Test personnel competences
h. Physical location of FAT
i. Test environment and tools
3) The FAT should be conducted on defined version of logic solver – 13.2.3
4) The FAT should be in accordance with the FAT planning – 13.2.4
5) Each test should include: – 13.2.5
a. version of test planning used
b. SIF and performance characteristics being tested
c. Detailed description of test procedures
d. Chronological record of test activities
e. Tools, equipment, and interfaces used
6) FAT test result documentations should include: – 13.2.6
a. the test cases & test results
b. whether objectives and criteria are met
c. reasons for failures analyzed and corrective actions documented
7) Modifications or changes during FAT should be subjected to a safety analysis to determine: – 13.2.7
a. extent of impact on each SIF
b. extent of required re test

Clause 14 – SIS installation and commissioning

Inputs:

1) SIS application software

2) a FAT was performed, the version of the application software, logic-solver firmware, and utility software should be the
same as final version of the FAT
3) Loop sheets for SIF inputs & outputs
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

4) SIS SRS
5) SIS integration test plan

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Outputs:

1) SIS installed according to the specifications and drawings – 14.1.1

2) SIS commissioned so that it is ready for the final system validation – 14.1.1
Verification (Clause 7)

Activities:

1) Installation and commissioning plan defining: – 14.2.1

a. activities
b. procedures, measures, & techniques to use
c. schedule
d. persons, departments, and organizations responsible
2) All safety instrumented system components properly installed according to the design and installation plan – 14.2.2
3) Commissioning documentation, including failures and any reason for failures confirming the following: – 14.2.3 & 14.2.4
a. proper grounding
b. energy sources properly connected and operational
c. transportation stops and packing material removed
d. no physical damage present
e. instruments properly calibrated, loop checks complete
f. field devices operational
g. logic-solver inputs/outputs operational
h. interface to other systems and peripherals are operational
4) When the installation does not meet the design specs, an evaluation is required. If the differences have no impact on
safety, the documentation is updated to as-built. If there is a negative impact on safety, the installation is modified to meet
the design and safety requirements. – 14.2.5

Clause 15 – SIS safety validation (SAT)

Inputs:

1) SIS design – SRS

2) SIS installed and commissioned
3) SIS safety validation plan
Outputs:
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

SIS validated through inspection and testing so that the installed and commissioned SIS and its associated SIFs meet the
requirements specified in the SRS. NOTE -- -- a qualified FAT may qualify for completing the logic verification requirements –
15.1.1

Verification (Clause 7)

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Activities:

1) SIS validation planning defines all activities required for validation include the following items: – 15.2.1
a. validation activities, including SIS validation, with respect to the SRS including implementation and resolution of the
resulting recommendations

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
b. validation of all relevant modes of operation
c. procedures, measures, and techniques to be used for validation
d. schedule
e. persons, departments and organizations responsible for validation activities
f. reference to information against which validation is carried out
2) Application software validation planning includes the following: – 15.2.2
a. Identify safety software to validate for each mode of process operation before commissioning commences
b. Validation technical strategy information including:

• manual and automated techniques

• static and dynamic techniques

• analytical and statistical techniques

c. the measures and procedures for confirming that each SIF conforms with the software safety instrumented functions
(12.2) and the software safety integrity requirements (12.2)
d. the required environment for validation activities (i.e. calibrated tools and equipment)
e. pass-fail criteria, including:

• required process and operator input signals with their sequence and values

• expected output signals with their sequence and values

• other acceptance criteria, i.e., memory usage, timing, and value tolerance
f. policies and procedures for evaluating validation results, particularly failures
3) Where validation requires measurement accuracy, the required instruments are calibrated using a traceable standard
specification within an uncertainty appropriate to the application. If such a calibration is not feasible, an alternative method
is used and documented. – 15.2.3
4) The SIS validation and the associated SIFs validation is in accordance to the validation planning including: – 15.2.4
a. SIS performing as specified in SRS under all operating conditions
b. Confirmation that adverse interactions between the BPCS and other interface devices do not adversely affect SIS
operation.
c. Where required, proper SIS communications with BPCS and other systems
d. Inputs, logic solver, and outputs perform in accordance with SRS
e. SIS documentation consistent with installed system
f. SIF performs as specified with invalid process variables (bad PV for inputs)
g. Proper S/D sequence activated
h. Alarm annunciation and HMI graphics
i. Any computations in SIS are correct
j. Reset functions are per SRS
k. Bypass functions per SRS
l. Startup overrides per SRS
m. Manual S/D per SRS
n. Proof-test intervals documented in appropriate procedures

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

o. Diagnostic alarms per SRS

p. Loss of utilities actions per SRS
q. Confirmation of EMC immunity
5) The software validation documentation shows that the software safety requirements (12.2) are correctly performed and
that the software does not jeopardize the safety requirements under SIS fault conditions and in degraded mode of
operation or by executing software functionality not defined in the specification – 15.2.5
6) Documentation for SAT test results, including: – 15.2.6
a. version of validation test used
b. SIF tested with reference to requirements identified during validation planning
c. tools and equipment used for testing, along with calibration data
d. results of each test
e. version of the test specification used
f. criteria for acceptance of the integration tests
g. version of SIS hardware and software tested
h. discrepancies between expected and actual results
i. analysis to continue or issue change request and return to appropriate step in life cycle when discrepancies occur
7) When discrepancies occur between expected and actual SAT results, the analysis made and decision whether to
continue the validation or to issue a change request and return to an earlier part of the development life cycle is available
as part of the results of the safety validation – 15.2.7
8) After the SIS validation and prior to the identified hazards being present (start-up) the following activities are carried out: –
15.2.8
a. All bypasses returned to normal
b. Isolation valves set to start-up position
c. Test materials removed
d. All forces removed
9) Pre-Start-up Safety Review (PSSR) completed including:
a. Current operating procedures
b. Current maintenance procedures
c. P&IDs show SIS I/O
d. Loop diagrams and loop sheets for SIS I/O

Clause 16 – SIS operation and maintenance – operate and maintain the SIS so that the functional safety and
the required SIL of each SIF is maintained.

Inputs:

1) Required testing frequency from SIL validation

2) SIS requirements
3) SIS design
4) Plan for Operation & Maintenance
Outputs:

1) Ensure that the required SIL of each SIF is maintained during operation and maintenance – 16.1.1

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

2) Operate and maintain the SIS so the designed functional safety is maintained – 16.1.1
Verification (Clause 7)

Activities:

1) Operation and maintenance planning for the SIS provides the following: – 16.2.1
a. routine and abnormal operation activities
b. proof testing, preventive and breakdown maintenance activities
c. procedures, measures, and techniques used for operation and maintenance
d. documentation verifying adherence to operation and maintenance procedures
e. schedule for when these activities take place
f. persons, departments, and organizations responsible for these activities
2) Operation and maintenance procedures in accordance to the relevant safety planning, including: – 16.2.2
a. routine actions to maintain the “as designed” functional safety of the SIS, i.e., proof-test intervals
b. actions & constraints required to prevent unsafe state or to reduce consequences of hazardous event during
maintenance or operation, e.g., bypassing for testing or maintenance
c. documentation required for system failure and demand rates
d. documentation required for showing results of audits and tests on the SIS
e. maintenance procedures when faults or failure occur in the SIS including:

1) Procedures for fault detection and repair

2) Procedures for revalidation

3) Maintenance reporting requirements

4) Procedures for tracking key performance indicators (refer to ISA-TR84.00.04-1 Annex R)

f. ensuring maintenance equipment used during normal maintenance is properly calibrated and maintained
3) Operators and maintenance proceeds in accordance to relevant procedures – 16.2.3
4) Verification that Operations are trained on the function and operation of the SIS in their areas including: – 16.2.4
a. SIS trip points and actions
b. the hazards the SIF is protecting against
c. bypasses and when they should be used
d. manual S/D switches and when they should be used
e. system reset or restart switches
f. action to be taken on any SIS diagnostic or system alarms
5) Maintenance personnel are trained as required to sustain full functional performance to the target integrity (hardware &
software) – 16.2.5
a. Discrepancies between expected and actual behavior are analyzed and when necessary modifications are made to
ensure required safety is maintained. This includes: – 16.2.6
b. the actions taken following a system demand
c. equipment failures during routine testing or an actual demand
d. the cause of the demands
e. the cause of false trips
6) Operation and maintenance procedures may require modification following: – 16.2.7
a. functional safety audits
b. tests on the SIS
7) Written proof-test procedures are developed for every SIF to reveal covert dangerous failures. These procedures describe

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

every step and include: – 16.2.8

a. correct operation of each sensor and final element
b. correct logic action
c. correct alarms and indications
8) Proof testing and inspection – 16.3
9) Periodic proof tests are conducted using a written procedure to reveal undetected faults – 16.3.1.1
10) The entire SIS is tested, including sensors, logic solver, and final elements – 16.3.1.2
11) The frequency of testing is determined using the PFDavg calculation – 16.3.1.3
12) Any deficiencies found during the proof tests is repaired in a safe and timely manner – 16.3.1.4
13) At some periodic interval, the frequency testing is reevaluated based on various factors, including: – 16.3.1.5
a. historical test data
b. plant experience
c. hardware degradation
d. and software reliability
14) Application logic changes require full proof testing. Exception allowed if appropriate review and partial testing of
changes carried out to ensure changes were correctly implemented – 16.3.1.6
15) Each SIS is periodically visually inspected to ensure there are no unauthorized modifications or observable deterioration –
16.3.2
16) Maintained records demonstrate that proof tests and inspections were completed as required, including: – 16.3.3
a. Description of tests
b. Date of tests
c. Name of person(s) performing tests
d. Unique identifier of system tested
e. Results of test

Clause 17 – SIS modification

Inputs:

1) Revised SIS SRS

2) MOC procedure
Outputs:

1) Modifications to any SIS are properly planned, reviewed, and approved prior to making the change. – 17.1.1
2) Ensure that the required safety integrity is maintained, despite any changes to the SIS – 17.1.1 --``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Verification (Clause 7)

Activities:

1) Prior to making any modifications to the SIS, procedures for authorizing and controlling changes are in place – 17.2.1
2) Procedures include a clear method of identifying and requesting the work to be done and the hazards that may be
affected. – 17.2.2
3) Impact analysis on functional safety of modification required, any impact to safety requires returning to first affected step
in life cycle affected by modification – 17.2.3

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

4) Modifications do not begin without proper authorization – 17.2.4

5) Appropriate documentation is maintained including: – 17.2.5
a. Description of modification or change
b. Reason for change
c. Affected hazards identified
d. Impact analysis on SIS
e. Required approvals
f. Tests verifying change properly implemented and tested
g. SIS logic solver configuration history
h. Tests to ensure functional safety not affected by changes
6) Modifications are made by qualified personnel who are properly trained. All affected and appropriate personnel should be
notified of and trained regarding the change. – 17.2.6
7) Documentation updated to show change

Clause 18 – SIS decommissioning

Inputs:

1) As-built SRS
2) Process information
3) MOC procedure

Outputs:

1) Prior to decommissioning any SIS, a proper review has been conducted and the required authorization has been obtained
– 18.1.1
2) Required SIFs remain operational during decommissioning activities – 18.1.1
3) Decommissioned SIS
Verification (Clause 7)

Activities:

1) Prior to decommissioning the SIS, procedures for authorizing and controlling changes are in place – 18.2.1
2) Procedures include a clear method of identifying and requesting the work to be done and the hazards that may be
affected. – 18.2.2
3) Impact analysis on functional safety as a result of decommissioning required. The assessment includes an update of the
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
hazard and risk assessment to adequately determine any safety life-cycle steps that need to be taken. The assessment
also considers: – 18.2.3
a. Functional safety during decommissioning activities
b. Impact of decommissioning an SIS on adjacent operating units and facility services
4) The results of the impact analysis are used to reactivate relevant requirements of this standard (e.g. verification and
validation)
5) Decommissioning activities do not begin without proper authorization. – 18.2.5

Clause 19 – Information and documentation requirements

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Inputs: (none)

Outputs:

1) The necessary information is available and documented so that all phases of the safety life cycle can be effectively
performed – 19.1.1
2) The necessary information is available and documented so that verification, validation, and functional safety assessment
activities can be effectively performed – 19.1.1
Verification (Clause 7)

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Activities:

1) The documentation required by this standard:

a. is available – 19.2.1
b. has unique identities – 19.2.3
c. has designations indicating type of information – 19.2.4
d. is traceable to the requirements of the standard – 19.2.5
e. has a revision index – 19.2.6
f. is structured to enable searching for relevant information – 19.2.7
g. is revised, amended, reviewed, and approved under the control of an information control scheme – 19.2.8
2) The following is maintained as up-to-date documentation: – 19.2.9
a. Hazard and risk assessment results and related assumptions
b. SIS equipment with its safety requirements
c. Organization responsible for maintaining functional safety
d. Procedures necessary to achieve and maintain functional safety of the SIS
e. Modification information for all changes to the SIS – (MOC)
f. SIS design, implementation, test, and validation documents

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex D – Verification, validation, and functional safety assessments

NOTE -- Annex D is referenced in the following: Clause 4.1,Clause 4.4, Clause 4.5, and Annex E.5.

D.1 Purpose

In ANSI/ISA-84.00.01-2004-1, verification, validation and functional safety assessment are three very
distinct activities that are carried out during the lifecycle of an SIS, and it is important to understand the
importance and requirements of each of these activities.

D.2 Verification

As described in ANSI/ISA-84.00.01-2004-1, Clause 3.2.92, verification is the activity of demonstrating for

each phase of the SIS lifecycle that the results satisfy the defined objectives and requirements for that
phase of the lifecycle. It is important that verification planning take place early in a project. As described
in ANSI/ISA-84.00.01-2004-1, Clause 7, verification activities are the quality control checks for the
project. The amount of verification required for a project is dependent on the scope of work and the
number of parties involved in implementing the SIS. The only required verification activity is the
verification of the SIL of the SIF in accordance with ANSI/ISA-84.00.01-2004-1, Clause 11.9.

Some of the typical Verification activities on a project include the following:

• Verification that the Hazard and Risk Analysis has been conducted and all Safety Instrumented
Functions have been identified.

• Verification that the Safety Requirement Specification has been properly completed, and all the
requirements as defined by Clause 10 have been defined.

• Verification that the SIF has been properly engineered and designed per the Safety Requirement
Specification. This usually requires a review of drawings, specification, and SIL calculations.

• Verification of the Factory Acceptance Test on the Logic Solver.

• Verification of the SIL of the SIF.

D.3 Validation

As described in ANSI/ISA-84.00.01-2004-1, Clause 3.2.91, validation is a mandated requirement of

demonstrating that after installation the safety instrumented functions and safety instrumented system(s)
satisfied the safety requirement specification. In ANSI/ISA-84.01-1996, this is called the Pre-Startup
Acceptance Test (PSAT). It is also commonly called Site Acceptance Test (SAT).
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

During the validation activity, each SIF device is exercised sufficiently, so that the validation team is
confident the SIF performs as intended, and all documentation reflects the as-built system. In addition,
validation determines that all interfaces with the BPCS and operation displays (alarms, graphics,
recorders, etc.) function as required.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

D.4 Functional Safety Assessment (FSA)

A functional safety assessment is an investigation of the ability of an SIF to achieve the necessary
functional and integrity requirements. The investigation is based on the evidence available at the time of
the assessment. As the lifecycle progresses, more evidence is available for examination.

D.4.1 Overview

ANSI/ISA-84.00.01-2004-1, Clause 5.2.6, identifies five different potential stages of a project where a
FSA may be conducted. These stages are shown in Figure 8 in ANSI/ISA-84.00.01-2004-1. Only the
Stage 3 FSA is required, which occurs after the SIS has been designed, installed, commissioned and
validated. However, assessment at all five stages should be considered based on the scope, complexity,
and integrity requirement of the SIS. Assessment at various stages often reduces downstream changes
by identifying problems earlier.

The Stage 3 FSA should be completed prior to introduction of hazardous materials into the process.
ANSI/ISA-84.00.01-2004-1, Clause 5.2.6.1.2, does require that at least one senior, competent,
independent (from the main project team) person take part in the FSA. This “competent” person should
be able to review the hazard and risk analysis, design, implementation, and testing to ensure that
everything had been successfully completed. This “senior” person should also have the authority to
prevent the start-up of the process unit if necessary.

Assessment at Stage 3 fulfills most of the requirements of the PSSR in OSHA 1910.119. During a PSSR,
the assessment team confirms that all pending hazard and risk analysis issues have been resolved. The
team ensures that the SIS is properly installed, commissioned, and validated in accordance with the SRS.
They also confirm that all necessary training for operating, maintenance, and engineering personnel has
been completed, and all testing and maintenance procedures have been written. When conducting this
Stage 3 assessment, it is important to review the results of the validation tests, review the written test
procedures, and interview operators and maintenance craftsmen to ensure they have been adequately
trained on the SIF and the hazard it is protecting against.

If the assessment team feels the SIF has not been properly designed, installed, or validated, they should
escalate their finding to senior management. Likewise, if they discover testing procedures have not been
written or personnel have not been properly trained, these findings should also be forwarded to the plant
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

senior management.

Although the standard (consistent with OSHA 1910.119) only mandates the Stage 3 FSA, many
companies elect to conduct similar assessments after the other four stages. They also have specific
requirements for the composition of the assessment team and its independence from the project team.

D.4.2 Functional Safety Assessment checklists

Functional Safety Assessments can utilize checklists to facilitate the assessment at the various lifecycle
stages. This qualitative assessment is a continuous process carried out at each life-cycle phase, i.e.,
specification, design, manufacture, commissioning and operation of the system. The use of a checklist
ensures that:

(a) the documentation necessary for a safe and reliable system is being produced and is available to the
assessors.

(b) any shortcomings in design or procedure identified by the assessment can be corrected in such a way
that changes are confined to a single life-cycle phase and have the minimum effect in other areas.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

If the assessment is carried out at a later stage in the life cycle, then the assessment should cover all
previous phases using the relevant checklists.

The purpose of the checklists is to provide a stimulus to critical appraisal of all aspects of the system
rather than to lay down specific requirements. To this end, many of the questions are of a general nature,
and the assessor uses judgment in the application of the questions related to the particular system being
assessed. The following example checklists were adapted from ones originally published by the Health &
Safety Executive in Programmable Electronic Systems in Safety Related Applications Part 2 General
Technical Guidelines.

The following checklists are examples only. These checklists do not cover all of the detailed
requirements of ANSI/ISA-84.00.01-2004. It should be noted that many of the checklists
make references to other administrative or engineering procedures. Consequently, these
checklists are used in conjunction with documented process safety and engineering
practices to ensure compliance with ANSI/ISA-84.00.01-2004.

The checklists are provided as follows:

Checklist 1: Hazard and Risk Analysis

Checklist 2: Safety requirements specifications

Checklist 3: Hardware specification and design

Checklist 4: Application software specification and development

Checklist 5: Installation

Checklist 6: SIF Validation

Checklist 7: Application Software Validation

Checklist 8: Operations

Checklist 9: Hardware maintenance and modification

Checklist 10: Application software maintenance and modification

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 1: Hazard and Risk Analysis

Item Item Y N NA Comments
No

1.1 Is there a hazard and risk analysis procedure that is

compliant with ANSI/ISA-84.00.01-2004-1. Clauses 8 and
9?

For example:
(i) Does it document sources of demand?
(ii) Does it document the demand rate?
(iii) Is the assumed failure rate of the BPCS higher than
10-5/hr?
(iv) Is the risk reduction claimed for the BPCS less than
10?

1.2 Has the hazard and risk analysis been conducted to

define the hazards to be mitigated using SIF?

1.3 Does the hazard and risk analysis clearly identify the
initiating causes and associated frequency of occurrence
for potentially hazardous events?

1.4 Does the hazard and risk analysis clearly identify the
protection layers used to mitigate potentially hazardous
events?

1.5 Have the potential common-cause faults between the

following been assessed?

For example,
SIS and BPCS?
SIS and the initiating cause?
SIS and other protection layers?

1.6 Have a hazard and risk analysis been conducted to

determine the functional and integrity requirements of
identified SIFs?

1.7 (i) Has a maximum acceptable spurious trip rate been

specified for each SIF where necessary?

(ii) Has the target been adequately researched?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 1: Hazard and Risk Analysis

Item Item Y N NA Comments
No

1.8 Has there been an evaluation of whether there are any

combinations of SIF actions that could lead to a hazard
(e.g., multiple relief to flare system) ?

1.9 (i) Are the SIF de-energize-to-trip?

(ii) Are the SIF energize-to-trip? If so, has the hazard and
risk analysis examined the impact of power loss on safe
operation?

1.10 (i) Are any other utilities required for the SIF operation
(e.g., pneumatic supply for air-to-move valves)?

(ii) Has the hazard and risk analysis examined the impact
of loss of utilities on safe operation?

Checklist No 2: Safety requirements specification

Item Item Y N NA Comments
No

2.1 Is there a procedure for establishing the safety requirements

specification for the SIFs identified in a hazards & risk
analysis?

2.2 Do functional and integrity requirements originate from a

hazard and risk analysis and, if not, on what basis was the
SRS formulated?

2.3 Is there a formal procedure to check the SRS against the

known hazards?

2.4 Has the safe state been identified for each identified SIF?

2.5 Is there a clear and concise description of each SIF to be

implemented by the SIS?

2.6 (i) Are non-safety functions to be implemented in the SIS?

(ii) Are they clearly identified?

NOTE -- APPLY ALL FURTHER CHECKLISTS TO THE NON-

SAFETY FUNCTIONS, AS APPROPRIATE.

2.7 Are the SIFs defined for every operating state of the plant,
including start-up, normal operation, abnormal, shutdown, and
maintenance? (E.g., certain SIFs or alarms may be inhibited or
may be operated at different setpoints during start-up.)

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 2: Safety requirements specification

Item Item Y N NA Comments
No

2.8 Are the SIF defined for every operating mode of the SIS?
(E.g., auto, manual, maintenance; different SIFs may apply in
different modes.)

2.9 Are the necessary conditions for a safe transition between the
operating modes in item 2.7 above adequately defined, and
are unsafe transitions prevented by SIF design?

2.10 Has testing interval for all SIF devices been specified?

2.11 Has means-to-execute diagnostics and/or testing been

specified?

2.12 Has the mean time to repair for the SIS been specified?

2.13 Are the SIF inputs defined with their setpoints?

2.14 Are the SIF outputs defined with regard to safe-state action,
speed-of-closure requirements, tightness, of shutoff, etc?

2.15 (i) Are the SIF de-energize-to-trip?

(ii) Are the SIF energize-to-trip?

(iii) If energize-to-trip, have provisions been made to ensure

integrity of the power at the required integrity?

(iv) If energize-to-trip, have provisions been made to allow safe

shutdown in the absence of power?

2.16 (i) Are any other utilities required for the SIF operation?

(ii) Have these utilities been evaluated to determine whether

they provide the required performance?

2.17 Have the extremes of all environmental conditions been

identified?
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

2.18 Have any special requirements been set based on survivability

of major event?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 2: Safety requirements specification

Item Item Y N NA Comments
No

2.19 (i) Have any special SIS logic-solver requirements been

identified, such as sequencing, speed, and accuracy?

(ii) Are they consistent with the defined inputs and outputs?

2.20 Have the requirements for the operator in maintaining safety

been defined?

For example:
(i) manual initiation of SIF?
(ii) manual shutdown on SIF fault or faults during various
operational states of the SIF?
(iii) use of overrides/inhibits/bypasses?
(iii) resetting the SIF after shutdown?
(Iv) starting up the plant?

2.21 In the event of BPCS failure, is sufficient information given to

the operator to allow manual shutdown if required?

2.22 Have the provisions been specified for maintaining safe

operation during maintenance and modification of:

(i) the SIS?

(ii) the process?

2.23 Does the specification avoid the need for the SIFs to be
bypassed under certain conditions?

If so, NOTE

(i) have adequate grounds for bypassing the SIFs been

established?

(ii) have facilities been specified to control bypasses, to ensure

that the bypassed state is clearly indicated, and to ensure the
removal of bypasses after maintenance?

(iii) have procedures for the safe use of bypasses been

developed covering the actions to be taken before, during, and
after their application?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 2: Safety requirements specification

Item Item Y N NA Comments
No

2.24 Have provisions been specified for the proof testing of SIF
devices with a minimum of physical bypasses, such as
jumpers?

For example, have provisions been specified that avoid the

need for disconnections at terminals or other undesirable
means for:
(i) the injection of test signals?
(ii) the monitoring of the result of a test?

2.25 Do the SIFs as described meet the following:

(i) fault tolerance requirements?

(ii) functional requirements?

(iii) integrity requirements?

(iv) maximum spurious trip rate?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 3: Hardware specification and design

Item Item Y N NA Comments
No

3.1 Is there an engineering process for conducting a design

review aimed at:

(i) ensuring that all the requirements of the SRS are met?

(ii) eliminating errors in design?

(iii) ensuring that the performance requirements, such as

integrity and spurious trip rate, are met?

(iv) ensuring that the devices are user-approved for

operating environment?

(iv) ensuring that aspects relevant to construction,

installation, operation, maintenance, and modification are
considered?

(v) ensuring that assumptions made in the hazards & risk

analysis remain true?

For example:
Independence of BPCS and SIS?
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Independence of initiating cause and SIS?

Independence of SIS and other protection layers?

3.2 Does the engineering process incorporate procedures for

the consideration of new information or management of
changes to the requirements as the design proceeds?

3.3 Is there an effective system for ensuring coordination

between different parties involved in the project (e.g.
owner/operator, design contractors, field construction
company, and manufacturers)?

3.4 Is there liaison between the designers and the operational

administration in order to ensure that:

(i) the principles of operation, maintenance, and test

assumed in the design are correct?

(ii) adequate facilities are provided for operational

requirements?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 3: Hardware specification and design

Item Item Y N NA Comments
No

3.5 Has a philosophy been adopted in the design of the SIS

hardware so that a large proportion of failures tend to put
the plant into a safe state?

(i) loss of power supply?

(ii) cabling faults (open or short circuit or earth faults)?

(iii) loss of instrument air?

(iv) loss of hydraulic supply?

3.6 Have measures been taken to detect those failures that do

not automatically result in a safe state?

For example, has a dynamic rather than a static mode of

operation been adopted so that failures resulting in a stuck
SIS output state can be detected, e.g., by watchdog timer?

3.7 Has the physical operating environment of the SIS been

defined, and has the hardware properly specified with
regard to:

(i) temperature range?

(ii) humidity?

(iii) vibration and shock?

(iv) ingress of water and dust?

(v) contaminating gases?

(vi) hazardous atmospheres?

(vii) power supply voltage tolerance?

(viii) ionizing radiations?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 3: Hardware specification and design

Item Item Y N NA Comments
No

3.8 Have adequate precautions been specified to protect

against electrical interference in the environment of the SIS
with regard to:

(i) inherent design of the SIS?

(ii) installation practices (e.g. separation of power and

signal cables)?

(iii) Are all inputs and outputs protected from damage from
voltage spikes that may be induced on input cables?

(iv) EMC test program, including conducted interference on

power supplies, electro-static discharges, and radiated
interference?

(v) Are all outputs that switch inductive loads protected

from damage from switching spikes?

3.9 In the selection of SIF devices by prior use, has a review

been conducted of the manufacturing process to determine
the following:

(i) Are there specifications and procedures for the quality of

materials, workmanship, and inspection?

(ii) Are they appropriate to the expected operating

environment?

(iii) Is there supervision to ensure the application of

specifications and procedures during manufacture?

(iv) Does the manufacturer perform management of

change reviews to determine whether manufacturing
changes could impact the device performance?

3.10 In the selection of SIF devices, has previous operational

experience been utilized?

(i) Where it is possible to use proven designs of hardware,

have they been used?

(ii) If a proven design is used, has it been critically

examined for suitability to the new environment?

(iii) Has previous experience of failure as well as

successful operation been sought and examined?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 3: Hardware specification and design

Item Item Y N NA Comments
No

3.11 (i) Does the design use only use those features that are
fully specified by the manufacturer?

(ii) Are all components used under the conditions for which
their performance is specified?

3.12 Have any special requirements identified for survivability of

a major event been executed in the hardware design?

3.13 Have suitable interfaces between the sensors and final

elements and the logic solver been specified, and has the
scaling between input and output signals and plant
parameters been defined?

3.14 Have suitable communication interfaces been defined with

regard to communication protocols and electrical
interference?

3.15 Is the operator/SIS interface well-defined in terms of data

display, alarms, etc?

3.16 Is the engineering/SIS interface separate from the

engineering/BPCS interface? If not, what provisions have
been made to prevent unintentional modification of SIS
logic when making changes to the BPCS, and are those
provisions sufficient for the highest SIL in the SIS?

3.17 Does the hardware design match the SIF requirements for
the following:

fault tolerance requirements?

functional requirements?

integrity requirements?

maximum spurious trip rate?

testing requirements?

3.18 Are the people carrying out the design aware of the
meaning and importance of Common-Cause Factor
(CCF)?

3.19 Have the effects of CCF been considered in the design?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 3: Hardware specification and design

Item Item Y N NA Comments
No

3.20 Are design reviews carried out, which includes the

identification and elimination of CCF (e.g., components
common to all systems and capable of causing failure of
the total configuration)?

3.21 (i) In specifying the level of redundancy to meet the safety

integrity, have common-cause faults been taken into
account?

(ii) If identical redundancy is used, are there available

diagnostics that minimize the potential for common-mode
faults?

(iii) Have means been provided to address potential

systematic error?

3.22 If diversity has been specified to reduce random hardware

CCF, is there a management of change process to ensure
that the diversity remains as specified?

3.23 If diversity has been specified to reduce random hardware

CCF, has the diversity been evaluated to determine
whether there is increased potential for human error?

For example:
(i) more complicated testing?
(ii) are different training, resources, tools, etc., ,needed?
(iii) have means been provided to address potential
human error?

3.24 Does the redundancy configuration allow each SIF

subsystem and all its devices to be proof tested?

3.25 Is the final design checked against the safety requirements

specification by an independent person prior to
programming the application software?

3.26 Have adequate provisions been made for all reasonably

foreseeable future expansions to the SIS or the plant?

Checklist No 4: Application Software Specification and Development

Item Item Y N NA Comments
No

4.1 Are there standards and procedures for the development of

the application software?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 4: Application Software Specification and Development

Item Item Y N NA Comments
No

4.2 Is there supervision to ensure the application of standards and

procedures?

4.3 Is there a procedure for generating and maintaining adequate

documentation related to the application software?

4.4 Has the final SIF design been checked against the SRS by an
independent person prior to programming the application
software?

4.5 Are design reviews carried out in the development of the

application software involving owners/operators, system
designers, and programmers to ensure compliance with the
SRS?

4.6 Is there a procedure for documenting and correcting any

deficiencies in the design and/or specification revealed during
the programming of the application software?

4.7 Is the completed (e.g. issued final) application software

checked against the owner/operator requirements by persons
other than those producing the application software?

4.8 Is there a procedure to manage changes to the application

software design to ensure that the required functionality and
integrity of the SIF is maintained?

4.9 Are departures from or enhancements to the SRS

documented?

4.10 Are standard (library) software packages modules used? If so,

(i) are they appropriate to the application?

(ii) have any modifications to them been carried out to the

original standards and procedures?

(iii) is there a procedure for the control of changes to library

programs?

4.11 Does the configuration workbench provide a means to ensure

a clear and unambiguous statement of functions used?

4.12 Is the method of programming readily understood by those

carrying out the programming? For example, if a ladder
diagram PLC programming technique is used, are the people
involved familiar with and experienced in the design of relay
logic?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 4: Application Software Specification and Development

Item Item Y N NA Comments
No

4.13 Does the configuration workbench:

(i) encourage the use of small and manageable modules?

(ii) allow access to certain data to be restricted to defined

modules?

(iii) permit operations to be carried out on variables of the

expected type?

(iv) allow the definition of variable type sub-ranges?

4.14 Does the configuration workbench provide adequate tools for

program development, for example:

(i) facilities for printing the program and I/O reference listing?

(ii) facilities for cross referencing the inputs with the derived
outputs?

(iii) facilities for checking program operation by the simulation

of input logic states?

4.15 Are automated tools used as an aid to the development of the

application software in:

(i) documentation?

(ii) consistency checking?

(iIi) control flow analysis?

(iv) data flow analysis?

(v) information flow analysis?

(vi) semantic analysis?

(vii) emulation or simulation of the application software?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 4: Application Software Specification and Development

Item Item Y N NA Comments
No

4.16 (i) Is the application software sufficiently modular and

annotated so that it is understandable to both SIS designers
and programmers?

(ii) When non-safety functions are implemented in the

application, are these clearly identified?

(iii) Are safety functions implemented in the application

software clearly identified?

(iv) Is the data used by the various functions protected as far

as possible from write access by other modules?

(v) Are modules reviewed to ensure minimum size and

complexity?

4.17 Within the application software, is there a clear and concise

statement of:

(i) each SIF to be implemented?

(ii) information to be given to the operator at any time?

(iii) required action on each operator command including illegal

or unexpected commands?

(iv) communications requirements between the SIS and other

equipment

(v) initial states for all internal variables and external

interfaces?

(vi) required action on power down and recovery? (e.g. saving

of important data in non-volatile memory)

(vii) different requirements for each phase of plant/ machine

operation? (e.g. start-up, normal operation, shutdown)

(viii) anticipated ranges of input variables and the required

action on out-of-range variables?

(ix) required performance in terms of speed, accuracy, and

precision?

(x) constraints put on the software by the hardware (e.g.

speed, memory size, word length)?
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

(xi) internal self-checks to be carried out and the action on

detection of a failure?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 4: Application Software Specification and Development

Item Item Y N NA Comments
No

4.18 Does the application software contain adequate fault (e.g.,

error) detection capabilities for error containment, recovery, or
safe shutdown procedures?

4.19 Is use made of a suitable graphical representation of control

flow (e.g., flowcharts) and data flow (e.g., flag and register
values) or other means of assuring that the application
software operation is clearly and easily understood?

4.20 Are there guidelines for the design of data structures?

4.21 Are there guidelines for constraining the control flow of the
program by the use of acceptable control flow structures?

4.22 If a concurrent processing philosophy has been adopted rather

than sequential task execution:

(i) has the need for this been established?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
(ii) have suitable concurrent processing design methods been
adopted?

(iii) has the use of interrupts been kept to a minimum?

4.23 (i) Has a means been defined of testing the program prior to
installation and commissioning?

(ii) Is the test method designed to simulate process conditions

as well as normal conditions, thereby finding faults as well as
proving correct operation?

Checklist No 5: Installation
Item Item Y N NA Comments
No

5.1 (i) Are there specifications and procedures for quality of

materials, workmanship, inspection and testing?

(ii) Are they appropriate to the expected operating

conditions?

(iii) Is there supervision to ensure the correct application of

the specifications and procedures during installation?

5.2 Have personnel been trained on the procedures to the level

appropriate for the task that they are assigned to?

5.3 Are the people carrying out the installation aware of the
meaning and importance of CCF?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 5: Installation
Item Item Y N NA Comments
No

5.4 Are installation procedures designed, managed and

supervised to minimize the introduction of CCF?

5.5 Is there sufficient independence between those carrying out

the work and those inspecting it?

5.6 Are the SIS installation activities included in the overall plant
construction program in such a way that:

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
(i) there is no interference by other construction activities?

(ii) ithe SIS is protected against them?

5.7 (i) Are the standards that have been specified for the
operational phase adequate for the installation phase when
the environment may be relatively severe?

(ii) If not, have adequate precautions been taken, e.g.,

storage areas for use during installation?

5.8 (i) Is the SIS inspected in order to reveal damage caused by

installation activities?

(ii) Is the inspection program coordinated with construction

activities to ensure that completed and inspected work is not
violated by subsequent activities?

(iii) Are the necessary records maintained?

5.9 Are installation and inspection procedures sufficiently

explicit in their detail so that they do not leave important
decisions or interpretations to be made by installation
personnel?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 5: Installation
Item Item Y N NA Comments
No

5.10 Are items, such as junction boxes, equipment, and cables

protected from the following:

(i) steam leaks?

(ii) water leaks?

(iii) oil leaks?

(iv) heat sources?

(v) mechanical damage?

(vi) corrosive vapors?

(vii) flammable atmospheres?

5.11 Have possible external causes of CCF been identified (e.g.,

fire, flood, vehicle impact, etc), and is the degree of
segregation between each part of the redundancy systems
adequate?

5.12 Are protection, segregation or other special requirements of

the design strictly observed?

5.13 Are all SIS and associated cables identified in such a way
as to minimize inadvertent interference?

5.14 Is there sufficient independence in the installation of

equipment (e.g., separate process connections)?

5.15 Is the SIS functionally separate from the basic process

control systems so that there is a low probability of an
external influence causing failure of both?

5.16 Is the installation consistent with the SRS?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 6: SIF Validation

Item Item Y N NA Comments
No

6.1 (i) Are there specifications and procedures for the

validation of each SIF?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
(ii) Are they appropriate to the expected operating
conditions?

(iii) Is there supervision to ensure the application of

specifications and procedures during validation test?

6.2 (i) Are there procedures for the proof testing of SIF devices
as defined in the safety requirements specification?

(ii) Are they sufficiently explicit in their detail not to leave

important aspects to decisions or interpretations by the
persons involved?

(iii) Is the calibration or performance of test equipment

verified before and after proof testing?

(iv) Are test records maintained?

(v) Do the tests cover as much of the SIS as is necessary,

as assumed in the safety requirements specification?

(vi) When it is necessary for testing, have means for

communication between persons at different locations
been well planned to reduce communication mistakes?

(viii) If online proof testing is to be carried out, do the

procedures ensure that this can be done safely?

6.3 Has training been given appropriate to the tasks being

carried out and the personnel involved?

6.4 If part of a redundant subsystem fails under test:

(i) is the cause of failure established?

(ii) are similar items inspected for a similar potential cause

of failure?

Checklist No 7: Application Software Validation

Item Item Y N NA Comments
No

7.1 Are there standards and procedures for software testing?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 7: Application Software Validation

Item Item Y N NA Comments
No

7.2 Is there supervision to ensure the application of standards

and procedures?

7.3 Is there a procedure for generating and maintaining

adequate documentation for:

(i) the tests carried out?

(ii) the results of tests?

7.4 Is there a procedure for documenting and correcting any

deficiencies in the specification, design, or application
software revealed during tests?

7.5 Are departures from or enhancements to the SRS

documented?

7.6 Are any SRS modifications reviewed through management

of change?

7.7 Is application software testing reviewed by those

responsible for the specification, design, and programming
of the application software?

7.8 (i) Is the final test documentation checked to ensure that all
SRS requirements have been tested and met?

(ii) Is the checking carried out by persons other than those

involved in the design, programming, or testing of the
application software?

7.9 Is the software tested in the final-use environment (i.e., the

target processor and the actual peripherals, memory, etc.),
rather than in an emulator?

7.10 Is each software module tested individually as fully as

possible before incorporation into the full program?

7.11 (i) Are there specified criteria for the coverage of tests (for
example, is each control flow path through the program
tested to ensure that each statement is executed at least
once)?

(ii) If not, is the coverage of the tests known?

(iii) Are test results analyzed to reveal any areas of the

software that show an unexpectedly high rate of failures in
test?

(iv) If so, are the reasons for the high rate of failure
established?

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Checklist No 7: Application Software Validation

Item Item Y N NA Comments
No

7.12 Have arithmetic functions been tested with the sets of input
values that give the maximum and minimum computed
results to ensure that no overflow conditions are reached?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
7.13 If any of the tests have revealed discrepancies between the
documented and the actual performance, have these been
resolved with the manufacturer?

Checklist No 8: Operations
Item Item Y N NA Comments
No

8.1 Is there a management system to ensure that the SIS is

unaffected by:

(i) activities external to the SIS, such as maintenance and

modification of the plant or the building (e.g., arc welding)?

(ii) departures from the environmental conditions assumed

at the design stage (e.g., the installation of machinery
liable to cause electrical interference, an increase in local
ambient temperature due to an equipment heat extraction
system)?

8.2 (i) Is there a fault reporting system?

(ii) Are the results analyzed to identify areas of integrity or

reliability lower than assumed in the original safety
analysis?

(iii) Are the results analyzed to identify possible systematic

failure causes?

(iv) Is there a process to initiate measures to minimize

device faults and systematic failures?

(v) Are process demands placed on the SIS documented?

8.3 Have appropriate procedures been developed and

implemented to prevent unauthorized access to the
system?

8.4 Are operating instructions and procedures adequately

documented?

8.5 Are the operating personnel aware of the meaning and

importance of CCF?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 8: Operations
Item Item Y N NA Comments
No

8.6 Is there an acceptable user/operator manual for

Programmable Electronic Systems (PES)?

8.7 Does the user/operator manual describe the risk

associated with possible failures and the necessary action
on failure?

8.8 Is there supervision to ensure the continued adherence to

operating procedures?

8.9 Has training been given appropriate to the tasks being

carried out, and the personnel involved?

8.10 Is there an administrative procedure to ensure that the

operating procedures remain adequate throughout the life
of the SIS?

For example:
(i) Are operating procedures reviewed?
(ii) Are the training needs of operational personnel
reviewed?
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Checklist No 9: Hardware maintenance and modification

Item Item Y N NA Comments
No

9.1 Have maintenance procedures been drawn up to ensure the

safety of the plant during maintenance?

9.2 Are maintenance procedures sufficiently explicit in their

detail so that they do not leave interpretations or important
decisions to be made by maintenance personnel?

9.3 Is there supervision to ensure the continued adherence to

agreed procedures?

9.4 Are those involved in maintenance and modification

activities aware of the meaning and importance of CCF?

9.5 Has training been given appropriate to the tasks being

carried out and the personnel involved?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 9: Hardware maintenance and modification

9.6 Is there an administrative procedure to ensure that the

maintenance procedures remain adequate throughout the
life of the SIS?

For example:
(i) Are maintenance procedures reviewed?
(ii) Are the training needs of maintenance personnel
reviewed?

9.7 Are maintenance procedures designed, managed, and

supervised to minimize the introduction of CCF? For
example, is the testing staggered so that all devices in a
redundant subsystem are tested at different times?

9.8 Are maintenance, modification, and test activities on the

SIS:

(i) limited to authorized persons following agreed

procedures?

(ii) reviewed as satisfactory on completion?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
9.9 On detection of a failure, is repair carried out in a time
consistent with that assumed in any safety requirements
specification?

9.10 Is there a procedure that strictly controls the conditions

under which alarms, trips, and control functions may be
bypassed?

9.11 (i) Is the final action of any maintenance or test procedure to

ensure that the SIF is returned to its normal operating state?

(ii) Is the above verified by independent inspection?

9.12 If damage or degradation is found in one device in a

redundant configuration, do the procedures require that the
other devices be inspected for similar faults?

9.13 Is there a management of change procedure that considers

the adequacy of the SIS when changes are made to the
process or its associated protection layers that might impact
process risk?

9.14 Is hardware configuration under management of change

control?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 9: Hardware maintenance and modification

9.15 Are there procedures for addressing failures of SIF devices?

Do these procedures recommend analysis of the failure?

Do these procedures recommend the incorporation of

lessons learned into the SIS design?

Checklist No 10: Software maintenance and modifications

Item Item Y N NA Comments
No

10.1 Is access to the SIS software limited to authorized and

competent people?

10.2 Are there formal procedures for changes to the software

which specify:

(i) level of authorization necessary for changes of various

types? (E.g., a higher level of authorization may be
required for changes to functionality than for changes to
setpoints.)

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
(ii) degree of assessment of the proposed changes to
ensure that the original level of safety integrity is
maintained?

(iii) people who may check and authorize changes of

various levels?

(iv) people authorized to carry out changes of various

levels and record all aspects of the change?

(v) documentation that should be updated?

10.3 Are there adequate procedures for the control of software

versions in use and the update of all similar SIS?

10.4 For spares which contain software in permanent memory

(firmware), is there a procedure to ensure that either:

(i) the original software version is used?

(ii) the version of software contained is totally compatible

with the original software (i.e., upward compatible) and
with other existing SIS hardware and software?

10.5 Can the software version in use be easily checked?

10.6 Are the consequences of incorporating new, enhanced

versions of the embedded software fully considered before
use?

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Checklist No 10: Software maintenance and modifications

Item Item Y N NA Comments
No

10.7 If errors are found in the embedded software, are they

reported to and corrected by the manufacturer and
incorporated into the PES only after checking and testing
of the correct code?

10.8 Is application software under management-of-change

control and version tracking?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

This page intentionally left blank.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex E – Audits
NOTE -- Annex E is referenced in the following: Clause 4.1 and Clause 4.5.

E.1 Purpose

Owners/operators should have procedures for conducting audits to ensure they are satisfying the
requirements for their SIS. ANSI/ISA-84.00.01-2004-2, Clause 5.2.6.2, provides very good guidance on
how these audits should be organized and carried out. This annex provides additional guidance for
conducting these audits based on how several operating companies have been conducting similar audits
for the past few years. It is only being offered as an example of how to organize and perform audits.
Again, these companies are only sharing how they have conducted these safety audits and have no
intent to imply that what they have described below is the only correct method for conducting audits.

E.2 Audit frequency

There is no “optimum” frequency for conducting these audits. In general, operating companies are
conducting their audits every three to five years. The interval of audits may need to be changed based on
audit history. For example, plants may start out with a three-year interval. Then, depending on the
number of negative findings, they may choose to adjust the interval to two years, or even lower. Likewise,
if very few negative findings are observed during multiple audit cycles, the interval could be extended out
to four or five years.

E.3 Audit participants

The individuals conducting the audit should be independent of the plant personnel and plant at which the
audit is being performed. They could be either from a central engineering facility or from another plant
location. The best audit team is made up of individuals who are competent in the areas being audited and
who are empowered to perform the audit. The audit team may include personnel from a department
inside the organization reporting directly to management or an individual/organization from outside. The
reason it is good to have someone from outside the plant to conduct these audits is they are able provide
an unbiased observation of their findings. Besides, it’s hard to find and identify your own mistakes.

E.4 Auditing against requirements

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
There should be complete agreement on the requirements against which the plant is to be audited. For
example: Will the plant be audited against corporate standards/requirements, plant
standards/requirements, or national/international standards? The standards or requirements used to
conduct the audit should be written and published so that everyone is in agreement on expectations.

E.5 Audit preparation

Several months prior to the audit, the lead auditor and a location coordinator should be identified. These
two individuals should begin coordinating activities, office space, transportation and expectations. The
location coordinator should forward to the auditor copies of all plant procedures (classification
procedures, design standards, list of all Safety Instrumented Functions with assigned SIL, control room
locations, management-of-change procedures, testing procedures, etc.).

The location coordinator should also forward to the lead auditor, an organization chart that is used to
identify personnel the auditors may wish to interview. About two to three weeks prior to the audit, the lead
auditor should identify all plant personnel they wish to interview. Once the location coordinator obtains
this list of interviewees, they should begin setting up an interview schedule. It is best to interview
management first, followed by first-line supervision, engineering, and then finally, maintenance and

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

operating personnel. By following this schedule, the auditors hear from management what they “think” is
going on but then find out what is “really” going on when they talk to the engineers, maintenance, and
operating personnel. It is also beneficial to talk to operators late in the day, i.e., during the swing or
graveyard shifts. It is during these shifts that the operators are more relaxed and more willing to share
their thoughts with you (e.g., management and supervisory personnel are not around to hear what they
have to say). Besides, during the swing or graveyard shifts, operators are usually not writing maintenance
permits and have more free time to talk to the auditors.

Several days prior to the beginning of the audit, the plant management should issue a NOTE -- -- to all
personnel telling them about the audit -- why it is being conducted -- and to encourage open and candid
discussion with the auditors. The NOTE -- -- should emphasize that the auditors are there to give
constructive feedback that both reinforces what the plant is doing well and identifies areas where the
plant has a potential to improve.

The lead auditor should prepare a list of questions pertinent to the scope of the audit. ISA-TR84.00.04-1
Annex D.4 Functional Safety Assessment provides example checklists that could be addressed during
the audit. In addition, refer to the CCPS book, “Guidelines for Auditing Process Safety Management
Systems,” 2011.

E.6 Audit kickoff

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
On the first day of the audit, each auditor should receive the normal required plant safety training and
security clearance/badges. They should also meet with location management to review expectations and
report out schedule.

E.7 Audit protocol

The audit typically focuses on the following:

• Procedure review

• Interviews (management, supervisors, engineers, maintenance and operators)

• Record review

• Field auditing

E.8 Procedure review

When reviewing the plant procedures, it is important to ask yourself the following four questions:

• Do the right procedures exist?

• Do the people understand the procedures?

• Are the procedures being followed?

• Are the procedures effective?

Only by reviewing the procedures, interviewing the plant personnel, reviewing the records and conducting
a field audit will the auditors gain the answer to these questions.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

E.9 Interviews

Auditors should go into the interviews with a set of questions to encourage the interviewee to begin
talking. The questions should be unique for the type of person being interviewed, e.g., the questions for
management personnel should be different than what is asked of an operator.

When conducting an interview, it is important to remember that you are there to listen. You should only
talk enough to get the interviewee comfortable enough to talk, and then listen for what they think are
problem areas. Most of what you find out during the audit is learned from the plant interviews. Again,
listen for the “red warning flags” that the interviewee throws out and waits for you to follow up on.

E.10 Record review

You generally review the plant records after you have finished all of your interviews. The records review
includes:

• A review of the testing results. Are the tests being completed as scheduled? Do they include a
complete test of the SIS from sensor to final element? Do they include an as–found/as-left
condition? Are all failures identified and corrected?

• Take a close look at the written test procedures. By reviewing the test procedures, you can
usually get a feel of how well the actual test is being conducted.

• A review of the management-of-change records. Are all changes being properly reviewed and
approved? Are the operators being trained on the change? Is the plant documentation being
updated to reflect the change?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
E.11 Field audit

After you have completed your operator interviews, take a walk around the unit and look at the condition
of their safety instrumented systems. Do the devices look well maintained, are they properly labeled and
tagged, do you see any unauthorized or undocumented bypasses, etc.?

E.12 Presentation of findings

At the completion of the audit, a full report should be made to the location management of the audit
findings. It is important to report out both the positive observations as well as the negative observations. It
is also important to be able to “grade” the negative findings so that the plant management places the
necessary priority to get the higher concerns corrected.

The following is being shared to aid in understanding what can be found during audits and to illustrate the
value of conducting audits.

NOTE In reviewing this list that is being shared, it is important for the reader to be aware that these findings were found at a
number of chemical plants and refineries and not at just one location. Plant management personnel were also very happy to be
made aware of these findings and made immediate efforts to get them corrected.

E.13 Examples of audit findings

E.13.1 Operation and accountability

• No clear ownership of the Safety Instrumented Systems, e.g., do they belong to engineering,
maintenance, operation, etc.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• No periodic report issued to plant management on the health of these systems, e.g., what was
found when the systems were tested.

• Management did not want any SIS in their units; e.g., they did not want to be bothered with
testing.

E.13.2 Classification of SIL

• Inconsistency in the SIL classification of similar SIS from unit to unit.

• No SIL classification when there should be.

E.13.3 Design

• Poor ergonomics on the design of manual shutdown switches and bypass switches (look the
same).

• Bypass and shutdown switches poorly labeled, missing covers or switch internals.

• Separation between BPCS and SIS instrumentation not adequate.

• SIS components in the field not clearly labeled according to company policy, e.g., have red tags
or painted red.

• Excessive use of Energize-to-Trip philosophy.

• Inappropriate use of 2oo2 logic when fault tolerance is required.

• Operators reported some systems did not work when called upon.

• Excessive use of direct mounted process temperature and pressure switches.

• Use of non-IEC 61508 compliant logic solvers as documented in company requirements.

• No online testing capability as documented in the SRS.

• Operators reported excessive number of nuisance trips.

• Systems not designed adequately for defined SIL.

• SIF reset action automatic instead of manual.

E.13.4 Bypassing

• No written or agreed-upon approvals required before a system is bypassed.

• No written or agreed-upon mitigation plans for when a system is being bypassed.

• Found systems bypassed, but no one was aware of it.

• Systems being bypassed for extensive periods of time (months/years).

• Plant bypass procedures not being followed.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

E.13.5 Excessive use of bypassing

• Some management did not want their units to shutdown under any circumstances, e.g., tell their
operators to put the system in bypass during plant upsets.

• Systems not working on a valid demand because the system was bypassed.

E.13.6 Management of Change (MOC)

• Poor MOC procedure that does not provide specific guidance on authority for approving changes.

• Changes are not reflected on permanent documentation or test procedures.

• Operators disabling alarms but not logging in as required.

• No clear understanding when an MOC is required, e.g., changes to alarm settings, sensor
technology, setpoints, valve material, etc.

• Not always proof testing an SIS after a change is made.

• SIF removed or deleted without explanation.

E.13.7 Documentation

• Documentation does not reflect current installed system.

• Some critical documentation missing, e.g., logic or electrical schematics.

• Design documentation does not exist.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

• SIF exists but not documented in maintenance systems, shown on P&IDs or described in
procedures.

• Maintenance craftsmen don’t know where to go to get the current documentation.

• It takes a long time (years) to get documentation corrected.

E.13.8 Training and understanding

• Operators do not have a good understanding of how their SIS work or the hazards they are
guarding against.

• Operators are not being trained periodically on their SIFs.

• Operators do not understand why setpoints are set where they are.

E.13.9 Testing and inspection

• The name of the person that conducted the test/inspection is not identified on the test results.

• The required “inspection” is not being conducted.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• Test equipment is not being periodically re-certified to a recognized standard.

• Systems are not being tested at the defined test interval.

• Inadequate written test procedures or, in some cases, written test procedures do not even exist.

• Required steps in the test procedures are being skipped.

• Testing of final element is not being done, or at least, it is not being recorded.

• Systems not being tested from sensor to final element.

• No plant procedure for tracking testing due dates or identifying which systems are behind in
testing.

• Not recording as-found and as-left conditions.

• Pressure by management to complete testing at the end of the turnaround.

• Known failed devices left in failed mode for extended period of time with no action plans to
correct.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex F – BPCS and its relationship to the SIS

NOTE -- Annex F is referenced in the following: Clause 4.3 and Annex P.2.

F.1 Purpose

This annex provides guidance with respect to the role of the Basic Process Control System (BPCS) in
process safety. Clauses F.2 through F.5 provide background information to stress the following:

• Control functions belong in the BPCS,

• SIFs belong in an SIS,

• SIFs are not located in the BPCS in accordance with ANSI/ISA-84.00.01-2004-1

NOTE 1 ANSI/ISA-84.00.01-2004, Clause 11.2.4, states, “If it is intended not to qualify the basic process control system
to this standard, then the basic process control system shall be designed to be separate and independent to the extent
that the functional integrity of the safety instrumented system is not compromised.”

NOTE 2 Designing and managing the BPCS as an SIS requires the application of the lifecycle requirements in the
standard to the entire layer, including the hazard and risk analysis, design documentation, functional safety management,
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

validation of changes, and management of change. There is no longer a BPCS and an SIS, as separate entities. It is now
one entity; an SIS that executes SIF and control functions.

• Control functions may be placed in an SIS that is designed and managed according to the
requirements of ANSI/ISA-84.00.01-2004-1.

NOTE The hazard and risk analysis takes into account potential common-cause failures between the control functions
(which may be the initiating cause) and the SIF. The effect of the failure of the logic solver, corruption of the data
highways, software mistakes, and access security at the engineering interface are just a few of the items that become
more difficult to analyze when combined systems are implemented.

Clause F.6 provides an example of the independence assessment, which can be performed as part of the
hazard and analysis, e.g., layers of protection analysis and quantitative risk assessment.

F.2 Considerations on the use of the BPCS

ANSI/ISA-84.00.01-2004-1, Clauses 8 and 9, place restrictions on the Hazard and Risk Analysis (H&RA)
assumptions with regard to the BPCS. These limitations are applicable when the BPCS is not
implemented in accordance with ANSI/ISA-84.00.01-2004-1.

F.2.1 BPCS as an initiating cause

ANSI/ISA-84.00.01-2004-1, Clause 8, requires that a Hazard and Risk Analysis (H&RA) be performed to
determine the initiating causes for process hazards and to identify safety functions that can be used to
mitigate each initiating cause. ANSI/ISA-84.00.01-2004-1 restricts the assumptions made with regard to
the dangerous failure rate for a control function allocated to the BPCS layer that does not fully comply
with the requirements of the standard. The dangerous failure rate must not be assumed to be less than
10-5/hour (ANSI/ISA-84.00.01-2004-1 Clause 8.2.2). This limitation is related to potential systematic and
hardware failures within the BPCS:

1) The BPCS and its components are typically not designed in accordance with the SIS lifecycle.
The use of the lifecycle minimizes the potential systematic failures through the design, testing,
validation, or management processes of ANSI/ISA-84.00.01-2004-1.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

1) Industry-published data, as well as manufacturer data, has shown that the random, hardware
failure rate is in the range of 10-5/hr and 10-6/hr for typical BPCS hardware (e.g., DCSs and
PLCs).

NOTE This data represents typical programmable logic controllers and distributed control systems. Lower failure rates
can be achieved by BPCS logic solvers that meet the requirements of IEC 61508 or ANSI/ISA-84.00.01-2004-1, Clause
11.5.

F.2.2 BPCS as a protection layer

ANSI/ISA-84.00.01-2004-1, Clause 9, limits the risk reduction that can be claimed for a BPCS that is not
implemented according to the requirements of ANSI/ISA-84.00.01-2004-1. The risk reduction must be
assumed to be less than or equal to 10 (ANSI/ISA-84.00.01-2004-1 Clause 9.4.3). Clause 9 also requires
that the allocation take into account potential common cause, common mode, or dependent failures that
could cause more than one protection layer to fail.

As shown in Figure F-1, the BPCS can be used to implement various functions (e.g., operator response
to alarm, process control loops, and discrete process logic) provided the following:

• An H&RA has taken into account the potential initiating causes for the process hazard being
mitigated by the BPCS

NOTE 1 For example, if a failure of the BPCS can result in a pressure loop becoming uncontrolled in a potentially
hazardous manner, it is not logical to presume that a shutdown function, intended to be performed by the same errant
BPCS, would function correctly.

NOTE 2 Where a detailed hazard analysis of the BPCS demonstrates that the control and protective elements within the
BPCS are functionally independent, it may be possible to conclude that a failure in the controlling part has a sufficiently
low probability of causing the failure of the protective function. In such cases, it may be appropriate to take credit for the
BPCS as a protection layer, even if the BPCS can initiate the process hazard. In accordance with ANSI/ISA-84.00.01-
2004-1, Clause 9, the risk reduction claimed for the BPCS as a protection layer must be less than or equal to 10.

NOTE 3 For more guidance on this topic, refer to ANSI/ISA-84.00.01-2004-2, Clause 9.4.

• An analysis has been performed that addresses potential common-cause failures between the
initiating causes and the BPCS

• The risk reduction assumed for the BPCS can be achieved by the BPCS design, operation,
maintenance, and management of change practices

• Administrative controls are used to control access to and modification of the protection layers
within the BPCS (Refer to ISA-TR84.00.04-1 Clause F.2.2.1 for more information.)

• Means exist to validate the functionality of the protection layer after changes are made to the

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
functions within the BPCS (Refer to ISA-TR84.00.04-1 Clause F.2.2.2 from more information.)

• Functional separation of the BPCS protection layer from any SIS protection layers

NOTE -- Physical separation is strongly recommended to avoid common-mode failures.

• The risk reduction assumed for the BPCS is less than or equal to 10 (ANSI/ISA-84.00.01-2004-1
Clause 9.4.3).

NOTE -- As long as a risk reduction of less than or equal to 10 is claimed for the BPCS as a protection layer, the BPCS
does not need to comply with ANSI/ISA-84.00.01-2004-1. However, since layer of protection analysis (LOPA) is often
performed using an order of magnitude assessment, it is typical to assume a risk reduction of 10 in the LOPA for the
BPCS layer if it meets the criteria discussed in this technical report. Risk reduction can only be allocated to one function in
the BPCS layer, unless further quantitative risk analysis in accordance with ANSI/ISA-84.00.01-2004-1 has been
conducted. This analysis is not trivial and involves a detailed assessment of the overall system design, including

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

hardware, software, communications, power supplies, interfaces, etc. At a minimum, this analysis would need to take into
account the integrity of the hardware, separation of the protection layers to prevent common-cause failures, management
of the software systematic errors, access security to hardware and software, management of changes, configuration
control, and periodic validation.

COMMUNITY EMERGENCY RESPONSE

Emergency broadcasting

PLANT EMERGENCY RESPONSE

Evacuation procedures

MITIGATION
Mechanical mitigation systems
Safety instrumented control systems
Safety instrumented mitigation systems
Operator supervision

PREVENTION
Mechanical protection system
Process alarms with operator corrective action

Safety instrumented control systems

Safety instrumented prevention systems

CONTROL and MONITORING

Basic process control systems
Monitoring systems (process alarms)
Operator supervision

PROCESS

Figure F.1 — Protection layers (ANSI/ISA-84.00.01-2004 Part 1, Figure 9)

F.2.2.1. Administrative controls

If the BPCS is utilized as a protection layer, appropriate administrative controls should be in place:

• Access security to prevent unauthorized bypass of the system, such as the operator placing the
BPCS function in manual, bypass (e.g., soft or physical) of a field device, or setpoint change
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

• Testing procedures to ensure that testing is performed as required for claimed risk reduction.

• Access security to prevent unauthorized modification of the system

These administrative controls typically exceed those applied to BPCS control functions. Additionally, the
administrative controls limit the degree to which operators or application engineers can interact with and
modify the BPCS control parameters and applications.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

F.2.2.2. Validation

To claim risk reduction for any protection layer, periodic validation (through inspection, testing, or some
other proven means) is required to ensure that the layer has the required functionality. BPCS functions
that are allocated risk reduction should be documented as protection layers and tested in accordance with
OSHA 1910.119 requirements.

F.3 Sharing the logic solver between the SIS and the BPCS

The significant issues associated with sharing the logic solver between the SIS and the BPCS are the
following:

• Functional capability of the logic solver in performing the control functions and the SIF

• Integrity of the logic solver to achieve the hazard rate necessary for the combined system

• Access security to the SIF

• Protection of the SIF from unapproved and unintended writes

• Management of changes to the SIF

Control instrumentation is constantly challenged; it is expected to perform its function frequently. The
memory associated with typical BPCS logic solvers is continually performing control functions, which may
include batch control, sequencing, and advanced process control algorithms. In contrast, most SIFs are
dormant and operate on a standby basis, taking action only when a process demand occurs. To properly
design a logic solver for use in implementing an SIS, an assessment of its design should be performed to
identify potential failure modes and to determine their effects. One method is failure modes & effects
analysis. The design of the logic solver then incorporates external means to detect and respond to these
failures.

Thus, the design and implementation of an SIS logic solver requires the following:

• Extensive design (e.g., diagnostics, response-time considerations)

• Engineering (e.g., identification of unsafe failure modes)

NOTE -- The diagnostic requirements for the SIS can place a heavy demand on the memory used in typical BPCS logic solvers.
This can result in scan times that are unacceptable for the SIS.

• Record keeping (e.g., proven in use, prior use, unsafe failure identification, data collection)

To detect dangerous faults, high levels of diagnostic and testing capabilities are incorporated into the
configuration of the SIS logic solver. A “single entity” may not be capable of achieving the SIS and control
objectives. The necessary redundancy, diagnostics, and testing can also make the cost of implementing
the entire BPCS to ANSI/ISA-84.00.01-2004-1 requirements prohibitive. Refer to ISA-TR84.00.04-1,
Annexes L and M, for more discussion concerning the analysis, selection, and design of SIS logic solvers
(e.g., safety-configured, general-purpose PLCs and safety PES). ISA-TR84.00.04-1, Annex G, discusses
failure types and fault detection.

NOTE -- The implementation of control functions in the SIS logic solver can significantly increase the cost associated with long-term
operation, maintenance, testing and management of the control functions. However, there may be some applications, such as
rotating equipment and packaged systems, where the higher operating cost is offset by other considerations.

The shared hardware and software should have the integrity necessary to achieve the target hazard rate
identified in the H&RA. (The target hazard rate is the tolerable frequency of the undesired consequence
Copyright 2011 ISA. All rights reserved.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

posed by the hazard.) To illustrate, first assume full independence and separation of the control function
and the safety function. If we assume the control function has an initiating cause frequency of 1 in 10
years, and the target hazard rate is 1x10-3/yr, the SIF should provide a minimum risk reduction of 100
(SIL 2) to achieve the target, i.e., target = initiating cause frequency * SIF PFDavg or 1x10-3/yr = 1/10 yr x
0.01.

Now, consider the case above where the BPCS function and safety function are shared in the same logic
solver. The target hazard rate has not changed; it is still 1x10-3/yr. By sharing the logic solver, significant
common-mode failure is introduced. A failure of the shared system can cause a dangerous failure of the
control function and, at the same time, the dangerous failure of any SIF mitigating the hazard caused by
the loss of control. This means that as soon as a failure occurs in the control system, the hazard occurs.
The SIF is considered to be operating in continuous mode rather than demand mode (see ISA-
TR84.00.04-1, Annex I, for a detailed explanation). As a result, the entire system should be treated as an
SIS in accordance with the requirements of ANSI/ISA-84.00.01-2004 and should be capable of meeting
the hazard-rate target with a dangerous failure rate less than 1x10-3/yr (or less than 1x10-7/hr). Table 4,
located in ANSI/ISA-84.00.01-2004-1, Clause 9, places such a system in the SIL 3 range.

In the above example, there was no distinction between process field equipment (sensors and final
elements) and the logic solver. In an actual installation, it may be possible to provide independence
between the field hardware used for control and that used for risk reduction. Consider a common logic
solver with one control loop having its own sensor and control valve and one SIF with its own sensor and
final element. For this example, the control loop can be an initiating event for the hazard scenario that the
SIF is designed to prevent.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Consider two cases to calculate the hazard rate for the system:

• For the BPCS loop field devices, the hazard rate is the sum of the dangerous failure rate of the
BPCS sensor and valve multiplied by the sum of the PFDavg of the SIF sensor and valve. The SIF
sensor and valve are operating in a demand mode.

Hazard rateFIELD DEVICES FAIL = (λBPCS SENSOR + λ \BPCS VALVE) * (PFDSIS SENSOR+PFDSIS VALVE)

• For the logic solver (including I/O cards), the hazard rate is the dangerous failure rate of the logic
solver itself. As noted above, the logic solver is operating in a continuous mode.

Hazard rateLOGIC SOLVER FAILS = λLOGIC SOLVER

NOTE -- The dangerous failure rate for a safety-configured, fault-tolerant logic solver is often significantly lower than
dangerous failure rates of field devices.

The total hazard rate is the sum of the two bullets above and should be less than 1x10-3/year target
hazard rate.

Hazard rateTOTAL = Hazard rateFIELD DEVICES FAIL + Hazard rateLOGIC SOLVER FAILS < 1x10-3/year

Typically, the predominant hazard rate is due to the dangerous failure rate of the control loop field devices
that can fail in such a way as to initiate a demand on the SIF. The reader should bear in mind that the
evaluation for sharing control and safety functions in the same equipment is not trivial, and the
requirements imposed by the standard are present for good reason. From a lifecycle standpoint, the
“single physical entity” should be regarded and treated as an SIS, in accordance with the requirements of
ANSI/ISA-84.00.01-2004-1. When implementing control and SIFs in the same logic solver, consider the
following:

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• Assessment of the overall system, including the main processor, input & output modules,
gateway, operator station, engineering console, data communication, and utilities (for common-
mode, common-cause, and dependent failures) to ensure that the required risk reduction is
provided

• Provision for access security to the SIS software, such that revisions to any control function do
not impact the SIFs in the SIS

NOTE -- Access security is a concern, because process engineers often optimize control loops, yielding better production
and product quality. Control system optimization is a necessary function for any profitable operation, but without proper
security, such changes can result in the inadvertent modification of SIS logic. In systems with a single level of security, the
BPCS software is subject to the same access security and rigor of management of change as the SIS software. This may
severely limit process control optimization and/or modification activities.

• Treatment of all shared interfaces and components as safety, unless hardware and software
configuration provides functional separation

• Use of more stringent MOC procedures for all the control-function modifications

• Means exist to validate the functionality of the SIS after changes are made

NOTE -- The scope of the validation testing is dependent on the degree to which the impact of the change can be
isolated.

• Restriction of writes to prevent unauthorized or unintended writes to the SIS logic

NOTE -- It is becoming increasingly common for the BPCS to utilize advanced process controllers and/or predictive
software that make frequent writes to BPCS controllers. If not properly safeguarded, these writes can potentially corrupt
SIS data, leading to unknown consequences.

• Implementation of a system architecture that utilizes prior-use methods to achieve functional

separation of control function and the SIF and provides access/security for the system operation

Caution for ISA-TR84.00.04 Part 1 Annex F.3:

When combining the control functions and SIFs in one system, do not underestimate the
complexity of the analysis and design that is required to meet these requirements. Further,
the required rigor of the administrative controls requires a high level of discipline among all
personnel interacting with the combined system. This rigor must be maintained for the life of
the SIS.

For example, during maintenance, startups, turnarounds, etc., it may be desirable to make
temporary changes to the BPCS functions. Failures of the administrative procedures may
result in the corruption and failure of the SIS.

F.4 Physically separate and diverse SIS logic solver

ANSI/ISA-84.00.01-2004-1 does not require physical separation. However, many owners/operators do

use physical separation and diverse logic solvers. It is paramount to remember the primary purpose of
many SIS. The SIS is designed to restore the plant to a safe state when the process moves out of the
normal operating envelope for a number of causes, including a failure or erroneous operation of the
control functions. The need for the SIS to act as a layer of protection in the event of control function
failure has resulted in many standards and practices recommending that SIF and control functions be
implemented in physically separate and diverse equipment.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

This physical, as well as functional, separation of SIS and BPCS has served the industry well for several
reasons:

• Separate hardware and software implementation of SIS and BPCS virtually eliminates common-
mode failures.

NOTE -- Modern SIS and BPCS designs include not only sophisticated fail-safe designs (SIS logic solver), but also
redundant, diagnostic configurations that provide automatic switch-over actions in case of detected hardware or software
malfunction. These redundant configurations are designed to achieve maximum up-time (SIS and BPCS) while
simultaneously providing a low probability to fail on demand (SIS). The different processing requirements of BPCS versus
SIS designs (i.e., continuous versus standby) make the realization of truly redundant, high availability, high reliability

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
combined SIS-BPCS design especially difficult.

• Separation of SIS and BPCS allows for separate maintenance of the respective systems, often by
different operating staff.

• Separation of SIS and BPCS is aligned with the concept of protection layers. The separate SIS is
an independent protection layer when the BPCS fails.

• Reduction in the amount of analysis that should occur to ensure that the SIS and BPCS are
properly designed, verified, and managed.

Refer to ISA-TR84.00.04-1, Annex K, for information regarding fault tolerance, including a treatment of
separation and diversity.

F.5 Sharing of field devices between the BPCS and the SIS

It is frequently proposed to share field devices, such as sensors and valves, between a control function
and an SIF. In this section, it is assumed that the control function and SIF are performed in physically
separate systems. The control function is allocated to the BPCS, and the SIF is allocated to the SIS. This
section first illustrates the complexity of sharing field devices and then discusses various means to share
them with appropriate analysis and design.

Due consideration is also required on the potential role of SIF devices in mitigating damages when
incidents do occur. External fires can often damage control valves or actuators, which are not designed to
be fire-safe, and therefore cannot play a role in mitigating a fire after it has occurred. Separate fire-safe
SIF isolation valves can be vital in mitigating such events.

The following should be considered if any components are shared between the BPCS and SIS:

• The failure of any hardware or software outside the SIS should not prevent any SIF from
operating correctly.

• The failure of a BPCS component does not result in the initiating cause for the process hazard
and the failure (or defeat/bypass) of the SIF that protects against the specific scenario under
evaluation.

• The probability of common-mode, common-cause, or dependent failures, such as plugged lead

lines, maintenance activity including bypasses, incorrectly operated line isolation valves, etc., has
been adequately evaluated and determined to be sufficiently low.

• The shared components are managed according to ANSI/ISA-84.00.01-2004-1, including proof

testing, access security, and management of change.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• The sensor (e.g. transmitter, analyzer, and switch) is powered by the SIS. The signal is
transmitted to the BPCS by an optical isolator or other means to ensure that no failure of the
BPCS affects the functionality of the SIS.

• The valve is designed such that there is no BPCS failure that could result in the SIS not being
able to take action with the shared valve.

• The valve design should be functionally compatible with both SIS and BPCS service.

NOTE -- This can be difficult as many BPCS valves are installed “flow to open,” and many SIS valves are installed “flow to
close.” Actuator power requirements for an SIS valve may differ from that of a control valve. While control valves may be
of double seat, balanced plug designs, SIS valves are often single seat, globe valves for reduced leakage.

• The owner/operator should determine that the process leakage rate through the control valve
does not impair the execution of the SIF.

• For pneumatically operated valves, a solenoid valve operated by the SIS may be located in the
air supply of the control valve actuator. When the SIS commands the valve to go to the shutdown
position, the solenoid valve vents the air off the control valve actuator.

• For electrically operated valves, the wiring should be such that the SIS places and keeps the
control valve in the shutdown condition, no matter what the BPCS is doing.

• Any online testing requirements for the valve or other shared device should be possible without
impairing the operation of the BPCS control function.

F.5.1 When the field device is not the initiating cause

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

When the failure of a BPCS field device is not the initiating cause, BPCS sensors and final elements can
be shared as part of the SIS given the above listed considerations (Annex F.5).

F.5.2 When the field device is the initiating cause

When a BPCS field device is a potential initiating cause, these components should not be used as the
sole means of detecting or responding to the process hazard. For example, assume that a control loop is
the initiating cause for the process hazard. The control transmitter is a potential root cause for the failure
of the control loop. This control transmitter should not be used as the sole means for detecting the
resultant process hazard and executing a safe shutdown. Since the control transmitter is the potential
cause for the process hazard, it cannot also be the cure for the process hazard.

Another example would be the use of a control valve as an SIS valve. Even if the control valve is
specified to fail-safe on loss of air, valve failure (e.g., damaged spring, stuck/frozen packing, stem build-
up, seat wear/damage) may result in the loss of both the BPCS and SIS functions. This is an important
consideration when components used in BPCS control functions, such as transmitters or valves, are also
utilized by the SIS.

Sharing BPCS field devices with the SIS to achieve a redundant configuration may be acceptable, but
requires additional analysis (e.g., ANSI/ISA-84.00.01-2004-1, Clause 11.2.10) to determine whether the
shared devices are initiating causes for the hazard scenario under evaluation. Further, the fault tolerance
requirements of ANSI/ISA-84.00.01-2004, Clause 11.4, should be examined. If the device is a potential
initiating cause for the hazard scenario, it should not be used to meet the fault tolerance requirements.
For example, SIL 3 requires a minimum fault tolerance of 1 for the final elements when other criteria of
ANSI/ISA-84.00.01-2004, Clause 11.4.4.4, are met, yielding the requirement for a 1oo2 architecture. The
control valve cannot be used to meet the fault tolerance requirement, if it is the initiating cause for the
hazard scenario under consideration.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Consider an SIF that has been specified to have one SIS sensor and one SIS valve. The design provides
the required risk reduction for the scenarios that it is protecting against. The designer also sees a BPCS
sensor that measures the same process variable and a BPCS control valve that provides the same final
control action. However, the BPCS sensor and control valve may be initiating causes for the process
hazard that the SIF protects against.

The designer reasons that adding the BPCS sensor to the SIF reduces the risk for scenarios where the
BPCS sensor is not part of the initiating cause. Likewise, the designer reasons that adding the BPCS
control valve to the SIF reduces the risk for scenarios where the BPCS control valve is not the initiating
cause. The cost of adding the BPCS sensor and control valve to the SIF is primarily a wiring and
programming cost, since it does not require piping modifications. The SIS would then utilize 1oo2 voting
sensors (i.e., the control transmitter and the dedicated SIS transmitter) to initiate closure of two isolation
valves (i.e., the control valve and the dedicated SIS valve). This arrangement is not easily evaluated by
Layers of Protection Analysis (LOPA), which is semi-quantitative. For simplification purposes, it generally
assumes that each protection layer is completely independent of the initiating cause and other protection
layers.

To examine the above arrangement, fault-tree analysis is often used to assess the hazard rate for the
process hazard, considering each initiating cause and its protection layers. A fault tree for such an
arrangement would include the following major branches, which would be summed to achieve the overall
hazard rate:

Hazard rateTOTAL = Hazard rateLOGIC SOLVER FAILS + Hazard rateSENSOR FAILS + Hazard rateVALVE FAILS

• The hazard rate associated with the SIF logic solver is its dangerous failure rate of the SIF logic
solver.

Hazard rateLOGIC SOLVER FAILS = λLOGIC SOLVER

• For the BPCS sensor failure, the hazard rate is calculated using the dangerous failure rate of the
BCPS sensor multiplied by sum of the PFDavg of the 1oo1 voting SIF sensor and 1oo2 voting on
the valves.

Hazard rateSENSOR FAILS = λSENSOR * (PFD1oo1 SENSOR + PFD1oo2 VALVES)

• For the BPCS valve failure, the hazard rate is calculated from the dangerous failure rate of the
BPCS valve multiplied by sum of the PFDavg of the 1oo2 voting on the sensors and 1oo1 voting
on the valves.

Hazard rateVALVE FAILS = λVALVE * (PFD1oo2 SENSORS + PFD1oo1 VALVE)

Numerical results associated with three cases are shown in Figure F-2 where the PFDavg is calculated by
dividing the hazard rate of the configuration (e.g., mitigated hazard rate) by the hazard rate of the system
without any SIF (e.g., unmitigated hazard rate).

Mitigated Hazard Rate = Unmitigated Hazard Rate * PFDSIF

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

The graphic shows the risk reduction for each configuration. The risk reduction for a fully independent SIF
with 1oo2 voting sensors and 1oo2 voting valves was determined to have a PFDavg of 0.001. For an SIF
with a 1oo1 sensor and 1oo1 valve, the PFDavg was found to be 0.03. In the fault-tree analysis for the
1oo2 architecture at the same proof-test interval, where the redundant field device is provided by a BPCS
sensor or valve, which can be the initiating cause, the PFDavg was calculated to be 0.007.
Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Thus, additional risk reduction can be achieved using existing BPCS field elements. However, this
approach should only be used when fault tolerance has been provided in accordance with ANSI/ISA-
84.00.01-2004, Clause 11.4. For SIL 1 and SIL 2, this requires at least one (1) SIS sensor or valve in
addition to the control sensor or valve using fault tolerant architectures, such as 1oo2, 2oo3. This
approach should not be used for architectures that do not have fault tolerance, such as 1oo1, 2oo2, etc.
Further, for SIL 3, two sensors and final elements independent of the initiating cause should be provided
to meet the fault tolerance requirements.

NOTE -- While 1oo2 configurations can achieve a reduction in PFDavg, the use of 1oo2 voting effectively doubles the frequency of
spurious trips. While spurious trips are often seen as having little impact on safety, (i.e., only a financial consequence), there can be
serious safety implications. After any spurious trip, the plant has to be restarted. In this fired-heater example, this typically requires
introduction of fuel gas into a hot firebox with a field operator initiating manual light off. Thus, the operator is in the field in close
proximity to the furnace. In addition, the operator is often under intense scrutiny to get the plant back online quickly. This stress can
lead to increased probability of human error.

Figure F.2 — Comparative risk reduction for shared field devices.

Lower values provide more risk reduction. The owner/operator is strongly cautioned to perform
quantitative risk analysis when BPCS components are used by the SIF that are also potential initiating
causes for the event. The quantitative risk analysis could be performed using reliability block diagrams,
fault-tree analysis, or Markov modeling. This type of analysis is discussed in the Center for Chemical
Process Safety book, “Guidelines for Chemical Process Quantitative Risk Analysis,” Second Edition,
American Institute of Chemical Engineers, New York, 2000. These analyses are not trivial and should be
performed by skilled practitioners knowledgeable in the methodology and the process and/or system
being analyzed.
NOTE -- While the risk analysis may show an improvement in the PFDavg, installation and maintenance considerations may off-set
any advantage of sharing BPCS and SIS components. For example, online testing of an SIS trip valve becomes more complex
when there is a BPCS valve tripped by the same signal. Any time field testing or maintenance becomes more complex, the scope
for human error increases (e.g., spurious trip during testing, leaving systems bypassed after testing etc.).
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

F.6 Example

This example is provided for illustrative purposes only. It uses a fired heater low-pass
flow SIF to illustrate various technical points. The design is not intended for use in any
real application. The reader should review relevant application specific standards and
technical reports to ensure that the process hazards are identified and that the design is
complete.

Additionally, the data used in the example was chosen simply to illustrate the
calculation. This data may not be representative of the performance of field
instrumentation in any application. The reader of this document must ensure that any
data used for compliance with ISA-84.01-2004 is appropriate for the intended
operational profile.

The fuel gas to a fired heater is controlled by a BPCS control function (function TIC-1), which throttles a
fuel control valve, CV-1, as shown in Figure F-3. A hazard analysis was performed to identify process
hazards and to determine whether the safeguards were sufficient to mitigate the process hazards. The
team determined that when the heater was firing hard, a low-pass flow through the tubes could result in a
high firebox temperature with the potential for tube rupture, furnace fire and structural damage to the
furnace.

Typically with fired heaters, there are other SIFs associated with loss of flame, loss of pilot gas, or loss of
main fuel gas. These SIFs are not covered in this example.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Figure F.3 — Example of independent BPCS and SIS on fired heater

The team first examined the potential initiating causes for the over-temperature. These included but were
not limited to:

1) Low pass flow due to loss of supply.

2) Excess firing due to failure of the fuel gas control loop

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

While the safety consequence associated with damaging the furnace was low, the economic
consequence was quite severe, resulting in significant downtime for the process unit and loss of
production.

NOTE -- In the analysis of this process hazard, the probability of significant loss of containment outside the furnace was low, so the
probability of impacting an operator or technician is also low. Other process hazards associated with a furnace can impact

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
personnel. The hazard and risk analysis is used to identify these hazard scenarios. The team examines the nature of the loss of
containment and determines whether personnel could be in the immediate area during the event. In situations where the equipment
itself is malfunctioning (e.g., furnace burner instability, furnace flooding etc.) or the process is being started up, there is a high
probability that an operator or technician is in the field.

The team felt that the existing design had two safeguards (i.e., protection layers):

1) A control loop TIC-1 using a temperature transmitter TT-1 that closes the control valve CV-1
using its positioner in response to increased temperature.

2) An SIF using a temperature transmitter TT-2 that de-energizes a solenoid-operated valve SV-2 to
vent air from the spring return, fail-closed valve BV-2, when high heater temperature is detected.

After reviewing these existing protection layers, the team decided to recommend that Layers of Protection
Analysis (LOPA) be used to determine the process risk, to ascertain the required risk reduction, and to
allocate the risk reduction to the various protection layers.

The team first examined the frequency of the initiating causes for the over-temperature. These included
but were not limited to:

1) Low-pass flow due to loss of supply. Frequency determined to be 1/10 years.

2) Excess firing due to failure of the fuel gas control loop. Frequency determined to be 1/10 years.

NOTE -- ANSI/ISA-84.00.01-2004-1, Clause 8, limits the assumed dangerous failure rate to not less than 10-5 /hr, which is
approximately 1 in 11.4 years. For ease of calculations, LOPA often uses 1 in 10 years.

Further, a process specialist had previously determined that the heater must be firing at a high rate in
order for structural damage to occur. This enabling event was determined to be present only ten percent
(10%) of the time. This yielded a probability of the enabling event of 0.1.

The process risk was determined by examining the frequency and the consequence of the process
hazard. The process hazard frequency was calculated using the initiating cause frequency and the
enabling event probability. For each cause, the process hazard frequency was 1 in 100 years (i.e., 1/10
years * 0.1). Comparison of the process hazard frequency and the consequence severity showed that the
process risk was unacceptable per the site risk criteria. A safety function was required that would provide
a risk reduction of 10 (PFDavg =0.1) to reduce the process risk to the site risk criteria.

F.6.1 Initiating cause is loss of supply – BPCS is not the initiating cause

In this scenario, low-pass flow is caused by the loss of process supply. Assuming that the BPCS is not
the initiating cause (i.e., there is no BPCS flow controller or other function that could fail and cause the
loss of process supply), a BPCS layer can be considered for risk reduction. An investigation determined
that the control loop is normally operated in automatic mode, and there is a procedure to maintain safe
operation when the loop is placed in manual.

Preliminary analysis of the BPCS loop (i.e., TT-1, TIC-1, and CV-1) indicated that it has a PFDavg of 0.05,
using the failure rates of the individual components. However, this system is not designed and maintained
in accordance with ANSI/ISA-84.00.01-2004-1. Therefore, the BPCS loop is assumed to have a PFDavg of
0.1.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

NOTE 1 ANSI/ISA-84.00.01-2004-1, Clause 9, limits the assumed risk reduction to less than or equal to 10 (PFDavg ≥ 0.1). For
ease of calculation, LOPA often uses a PFDavg of 0.1.

NOTE 2 There is a separate issue regarding whether the TIC-1 control loop would be fast enough to reduce heat input to the
furnace commensurate with the rate of decrease of pass flow. For initiating causes, such as loss of a feed pump, it is likely that the
TIC-1 control loop would not be effective as a layer of protection. For the purposes of this example, it is assumed that the TIC-1 can
provide protection.

Preliminary analysis of the local, hardwired SIF (i.e., TT-2, SV-2, and BV-2) indicated it had a PFDavg of
0.03, using the failure rates of the individual components. This SIF was designed and maintained in
accordance with ANSI/ISA-84.00.01-2004-1. Therefore, the SIF is assumed to have a PFDavg of 0.03.

This PFDavg provides the amount of risk reduction that was determined to be required from the site risk
criteria. The frequency of the scenario of loss of containment is calculated by multiplying the initiating
event frequency by the probability of the enabling event and the PFDavgs of any protection layers:

0.1/yr x 0.1 x 0.1 x 0.03 = 3E-05/yr

This is summarized in Table F-1 for the loss of process flow due to causes external to the BPCS.

Case Initiating Cause Enabling Event PL 1 PL2 Outcome

1 Loss of Process Excess Firing BPCS Loop TT-2 Closes BV-2 Vessel Fails
Flow through TT-1, TIC-1
tubes Closes CV-1

0.1/yr 0.1 0.1 0.03 3E-05/yr

Table F.1 — LOPA table for BPCS loop as a protection layer

In this scenario, using the BPCS as a protection layer is acceptable because it meets the LOPA criteria; it
is independent of the initiating cause and any other protection layers. (For more information, please refer
to the Center for Chemical Process Safety book, Layer of Protection Analysis: Simplified Risk
Assessment, American Institute of Chemical Engineers, New York: 2001).

F.6.2 Initiating cause is BPCS control loop failure – BPCS is the initiating cause

In this scenario, the BPCS temperature control loop is the initiating cause. Therefore, the BPCS
temperature control loop cannot be used as a protection layer for this scenario. Preliminary analysis of
the local, hardwired SIF (i.e., TT-2, SV-2, and BV-2) indicated it had a PFDavg of 0.03, using the failure
rates of the individual components. This SIF was designed and maintained in accordance with ANSI/ISA-
84.00.01-2004-1. Therefore, the SIF is assumed to have a PFDavg of 0.03.

0.1/yr x 0.1 x 0.03 = 3E-4/yr

The LOPA results are shown in Table F-2 for the scenario where the initiating cause is failure of the TC-1
control loop such that valve V-1 fails open. In this scenario, the BPCS cannot be used as a protection
layer because it is not independent of the initiating cause.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Case Initiating Cause Enabling Event PL 1 PL 2 Outcome

TT-1, TC-1, CV-1 Excess Firing BPCS Loop TT-2 Closes Vessel Fails
Fail such that CV- TT-1, TIC-1 BV-2
1 Fails Open Closes CV-1
2
0.1/yr 0.1 1* 0.03 3E-04/yr

* Uses same components as the initiating cause.

Table F.2 — LOPA table for BPCS loop as an initiating cause

F.6.3 Shared field devices

In the fired heater example, the designer proposes to use the temperature transmitter TT-2 to de-energize
the solenoid valve SV-1 that vents air from the control valve CV-1 and to de-energize the solenoid valve
SV-2 that vents the air from the block valve BV-2 in the fuel gas line. In this design, no failure of the
BPCS hardware or software can prevent the SIF from venting air from the control valve actuator. The SIF
consists of the high temperature, as measured by the temperature transmitter TT-2 initiating closure of
the control valve CV-1 and the block valve BV-2. This system is shown in Figure F-4.

SIS TT
2
Fired Heater
I.A. TY
1 I.A.

SV-2 SV-1
De-Energize De-Energize
to vent to vent
TIC TT
1 1

BV-2 CV-1

Figure F.4 —Example of sharing BPCS control valve with SIS on Fired Heater

The designer recognized that this proposed change to the design as presented in Annex F.6 was a
significant change that required an evaluation by the LOPA team or risk assessment group. As discussed
previously, the high temperature in the furnace could be caused by the failure of the temperature control
loop. The temperature control loop consists of TT-1, TIC-1, TY-1, and CV-1. The failure of any of these
components could result in the process demand on the protection layer.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

The LOPA team looked at the LOPA rules. The initiating cause, control valve CV-1, is shared by the
control loop and by the SIS. The protection layer is not completely independent of the initiating cause.
The simple math of multiplying the initiating event frequency by the probability of failure of each protection
layer would not yield correct hazard rate.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

NOTE -- For more information, please refer to the CCPS book, Layer of Protection Analysis: Simplified Process Risk Assessment,
American Institute of Chemical Engineers, New York: 2001.

As discussed previously, a quantified approach is recommended. For this example, fault-tree analysis
was performed to determine the risk reduction provided by the protection layers for each initiating cause
for the revised design. A summary of the fault-tree analysis is presented below in Table F.3. The hazard
rate due to all causes, TT-1, TIC-1, and CV-1, is 2.2E-04.

It is important to note that only those protection layers that can mitigate the initiating cause are given
credit in the analysis. The calculation results in an optimistic result when the calculation is done by simply
multiplying the initiating event frequency of the entire BPCS loop by the probability of failure of the SIF
without regard for the common mode existing between them. This is shown in Table F.3 as “Incorrect
Way.”

Case Initiating Cause Enabling Event PL 1 PL 2 Outcome

Control transmitter Excess Firing BPCS Loop TT- TT-2 Closes Vessel Fails
TT-1 fails 1, TIC-1 Closes CV-1, BV-2
CV-1
0.02 0.1 1 (Annex F.6) 0.016 3.2E-05/yr

BPCS TIC-1 fails Excess Firing BPCS Loop TT- TT-2 Closes Vessel Fails
1, TIC-1 Closes CV-1, BV-2
CV-1
2A (revised
SIS) 0.04 0.1 1 (Annex F.6.2) 0.016 6.4E-05

Control valve CV-1 Excess Firing BPCS Loop TT- TT-2 Closes Vessel Fails
fails 1, TIC-1 Closes BV-2 only
CV-1
0.04 0.1 1 (Annex F.6.2) 0.03 1.2E-04
Overall Risk due to all scenarios 2.2E-04
Control loop fails, Excess Firing BPCS Loop TT- TT-2 Closes Vessel Fails

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
TT-1, TIC-1, CV-1 1, TIC-1 Closes CV-1, BV-2
CV-1
Incorrect
0.05 0.1 1 (Annex F.6.2) 0.016 8E-05
Way!

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

This page intentionally left blank.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Annex G – Failures - Types, classifications, sources, and strategy for defense

NOTE -- Annex G is referenced in the following: Clause 4.2, Annex F.3, Annex J.2, and Annex K.1.

G.1 Purpose

To ensure that an SIF achieves the risk reduction defined in the H&RA, the factors most likely to cause its
failure should be identified, and measures should be taken to reduce the likelihood of the failure. Two
basic types of failure should be considered when designing the SIF:

• Random failures

• Systematic failures

Both random and systematic failures can potentially affect multiple devices within a subsystem (e.g., 1oo2
voting transmitters), causing all of the devices to fail within a short period of time. These failures are
known as common-cause failures. The Safety Integrity Level (SIL) as defined by ANSI/ISA-84.00.01-2004
considers random hardware failures only. The SIL does not consider systematic failures. The most
effective defense against systematic failures is full integration of the ANSI/ISA-84.00.01-2004-1 lifecycle
and functional safety management concepts into the project management process. The standard
provides assessment, design, operation, and maintenance strategies to reduce the potential for random,
systematic, and common-cause failure.

G.2 Systematic failures

Systematic failures are due to mistakes or errors made in the SIF design and management and cause the
SIF to fail every time a particular set of conditions occurs. Because it is not feasible to test the SIF under
every possible combination of operating conditions, faults may remain hidden until a particular set of
circumstances arises and the SIF fails to function or fails spuriously.

There are three important types of errors that can lead to systematic failure:

• Specification errors include mistakes and omissions made during the design process, such as
incorrect actuator sizing or inappropriate materials of construction selection. Specification errors
exist from the point of installation and remain throughout the SIF life.

• Equipment errors, such as a bad installation, improper bypassing, and poor maintenance, may
occur at any stage in the Safety Lifecycle.

• Software errors may arise from errors in the initial programming or be introduced when the
software is modified, intentionally or unintentionally.

Due to the nature of these errors, it is impossible to predict how often systematic failure leads to SIF
failure. Unlike random, hardware failures, redundancy may not be effective against systematic failures,
because the redundant devices are often affected by the same systematic failure. Under the same
operating conditions, all redundant devices could fail due to a common systematic failure. A partially
effective barrier against systematic failures is to use device diversity, i.e., redundancy is provided using a
different device, system, technology, programmer, etc. If one device fails, the other continues to work if
the cause of failure does not result in the failure of both components. Use caution to avoid deterioration of
SIF performance from the use of diverse devices with poor performance characteristics. The most
effective defense against systematic failure is full integration of the ANSI/ISA-84.00.01-2004 safety
lifecycle and functional safety management concepts into the project management process.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

G.3 Random failures

The SIF hardware is often manufactured with electrical, electronic, programmable electronic, and
mechanical components. Each component wears out or breaks down after a different length of time,
depending on how well it was originally manufactured, how much it has been used, the variation in the
operating conditions, etc. Since these components are lumped together to make a device, the failures of
the device appear to be random, even though the failure distributions of the individual components may
not be random.

If it can be demonstrated that an SIF device (e.g., a block valve) has dominant time-based failure
mechanisms (i.e., they wear out), the random failure rate model can lead to erroneous conclusions and
practices. For example, in calculating test intervals, a random model may lead to testing more frequently
than actually required during the early life of the device and testing too infrequently during the later wear-
out phase. Owners/operators should be aware that reliability models (e.g., Weibull) are available that
divide failures into infant mortality, random, and wear-out modes. This guideline assumes failures are
random.

One very effective barrier against random device failures is to implement redundancy. Fault tolerance is
provided using multiple devices in voting configurations that are appropriate for the SIL. If one device
breaks down, another device is available to provide the safety action. Since failures occur randomly, it is
less likely that multiple devices fail at the same time.

By observing the operation of a device over time, data can be collected about how often it breaks down.
This information can be used to estimate how long a device is likely to last before it stops working
properly. However, in the case of PE devices and logic solvers, the technology is evolving so rapidly that
the reliability data collected on any device is often limited unless databases are pooled.

G.4 Summary of differences between random and systematic failure

The following table presents the differences between random and systematic failure.

Table G.1 — Summary of the important differences between random and systematic
failures

Random Failures Systematic Failures

Will always occur under the same conditions No Yes

Effectively prevented by redundancy Yes No

Effectively prevented by diversity in Yes Partially

redundancy

G.5 Failure classifications

Device failures result in a specific failure mode, e.g., a transmitter could fail with the signal stuck within
the acceptable range. Experience and knowledge of how the device functions is necessary to identify the
failure modes. These modes can then be classified as either safe, where the failure causes the device to
go toward its safe state, or dangerous, where the failure causes the device to fail to function. In the case
of a transmitter, a stuck signal would be considered a dangerous failure.

Device failures can sometimes be detected by online, automatic diagnostics that notify the plant operator
that the device has failed so that compensating measures can be implemented. These failures are
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

classified as “detected,” leading to the identification of dangerous detected (DD) or safe detected (SD)
failures. If online diagnostics are not available, the failure may remain undetected until a process demand
occurs or the device is proof tested. These “undetected” failures may be dangerous undetected (DU) or
safe undetected (SU).

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Other terms have been used through the years for these failure classifications:

• Initiating instead of safe

• Inhibiting instead of dangerous

• Overt instead of detected

• Covert instead of undetected

Figure G.1 illustrates the primary and secondary concerns of each failure classification and how they
affect the plant operation. The Probability to Fail on Demand Dangerous Undetected (PFDDU) is related
to the Safety Integrity Level, which is defined by the H&RA findings and documented in the safety
requirements specification.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Figure G.1 — Breakdown of failure classifications

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Another way of illustrating the failure classifications of a device is a Venn diagram, which provides a
visual representation of the data sets. The diagrams are drawn using the area of a rectangle to represent
all possible outcomes. In Figures G.2 through G.4, Venn diagrams are used to represent the set of all
possible failures.

Safe Undetected Safe Detected

Dangerous Undetected Dangerous Detected

Figure G.2 — Venn Diagram of failure classifications

The probability of failure associated with each of the failure classifications shown in Figure G.2 can be
defined by equations using simplifying assumptions. The most important assumption is that failures are
random (i.e., effectively occurring at equal time intervals over the life of the device or subsystem). First, a
few terms:

λ= Failure Rate
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

TI = Testing Interval

DC = Diagnostic Coverage, a measure of built-in diagnostics

β = Common-Cause Factor

S = Safe, Superscript

D = Dangerous, Superscript

Total = S+D, Superscript

SD = Safe Detected Superscript

SU = Safe Undetected, Superscript

CCF = Common-Cause Failure, Superscript

DD = Dangerous Detected, Superscript

DU = Dangerous Undetected, Superscript

MTTR = Mean Time to Repair

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

MTDF = Mean Time to Dangerous Failure

λTotal = λS + λ D , total failure rate

λS = λSD + λSU , safe failure rate

λSD = DCxλS , safe detected failure rate

λSU = (1 − DC )xλS , safe undetected failure rate

λD = λDD + λDU , dangerous failure rate

λDD = DCxλD , dangerous detected failure rate

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
λDU = (1 − DC )xλD , dangerous undetected failure rate

Now, the equations:

TI
PFD DU = λ DU x
2

PFD DD = λDD x MTTR

PFD D = PFD DU + PFD DD

βλ = λCCF ∴ βλ D = λ D
CCF

These terms and equations can be substituted into the Venn diagram as shown in Figures G.3 and G.4.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Safe Undetected Safe Detected

PFDSU PFDSD

DD
PFD
DU
PFD
Dangerous Undetected Dangerous Detected

Spurious Trips≤ PFD + PFD

SD DD

PFD D = PFDDD + PFD DU

Figure G.3 — Venn Diagram showing the probability of failure on demand for each failure classification

Safe Undetected Increasing Safe Detected

Coverage

PFD = λ
TI
λ × MTTR
SD SD
= ×
SU SU
PFD 2

λ
TI
= ×
λ
DU DU
= × MTTR
DD
PFD 2 Increasing PFD
DD

Coverage

Dangerous Undetected Dangerous Detected

[
SpuriousTrips ≤ DC × λS × MTTR + DC × λD × MTTR ] [ ]
 TI 
PFD D = (1 − DC ) × λD ×  + DC × λD × MTTR
2
[ ]

 TI 
PFD DU = (1 − DC )× λD × 
 2
[
PFD DD = DC × λD × MTTR ]
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Figure G.4 — Venn Diagram showing the probability of failure on demand for each failure classification

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

It should be noted that diagnostics do not change a dangerous failure to a safe failure. Diagnostics only
change the failure classification from undetected to detected. The failure classification is still dangerous,
and the device would still fail to function correctly in the face of a process demand. Detected failures are
only considered safe when failure detection provides notification to an operator who is capable of making
an effective response and maintaining safe operation until repair is completed and the device is returned
to service.

The diagnostics are incorporated into the calculation using the diagnostic coverage (DC). The PFDavg for
dangerous, detected (DD) failures is

PFD
DD
= [DC × λ D ]× MTTR

The PFDavg for dangerous undetected (DU) failures is

= [(1 − DC )× λ D ]×
DU TI
PFD
2
The probability of failure on demand is

PFD = PFD + PFD

D DU DD

Assuming that TI >> MTTR, the PFDavg is reduced as the diagnostic coverage shifts the percentage of the
failure rate from undetected to detected. In addition, increased diagnostic coverage does not necessarily
increase the spurious trip frequency. The SIF can be designed such that the detected failure is alarmed,
rather than causing an immediate shutdown if the design incorporates fault tolerance (i.e., device
redundancy is provided) and other compensating measures have been identified that can bring the
process to a safe state if a process demand occurs while the faulted device is under repair.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

G.6 Sources of failures by lifecycle phase

Out of Control: Why control systems go wrong and how to prevent failure, HSE Books 2003, is intended
to raise the awareness of the causes of control system failures by describing actual case studies. While
the analysis may not be considered statistically significant due to its small sample size (i.e., only 34
incidents were studied), the analysis does illustrate the importance of the safety lifecycle in the
management of process risk.

Figure G.5 shows the relative breakdown in the causes of process incidents identified in the HSE study. It
should be noted that the data presented is not restricted to failure of safety instrumented systems. It
covers the analysis of various technologies applied as protection layers throughout industry. Since these
technologies share many of the same failure modes as the SIS, the overall analysis is applicable to the
design and management of SIS. As can be seen in Figure G.5, the majority of these failures cannot be
eliminated by simply choosing a different device, increasing the diagnostic coverage, or decreasing the
testing interval. Failures to pay attention to detail, particularly during the specification phase, and failure to
properly manage technical issues are the root causes of many failures. These failures can only be
addressed through implementation of the ANSI/ISA-84.00.01-2004 lifecycle process and its associated
verification and validation steps.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Figure G.5 — Primary cause of failure by lifecycle phase

The following were identified as root causes in the HSE study:

• Safety requirements specification

• Functional requirements specification

• Safety integrity requirements specification

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
• Design and implementation

• Installation and commissioning

• Operations and maintenance

• Actions by operation personnel

• Actions by maintenance personnel

• Changes after commissioning

• Modification and retrofit

• De-commissioning

The HSE study suggests that most failures are related to inadequate specification. This may be due to a
lack of personnel experience or training or simply due to errors made during the assessment of the
following:

• Process hazards

• Required device functionality

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• Failure modes associated with the devices used to implement the protection layers

The HSE study demonstrates that attention to detail is essential in the design and management of SIF.
Inadequate procedures, training, and MOC contribute to SIF failure as readily as random hardware
failure. Improper operational or maintenance activities can completely disable an SIF, no matter how fault
tolerant the SIF design. To combat these errors, operation and maintenance procedures should be clear
and consistent with operator or maintenance technician expectations to reduce the potential for error.
Back-checks and independent confirmation should be used to verify that the SIF is operational after any
maintenance activity. Design practices can also reduce operator or maintenance technician errors that
could potentially lead to failure.

Therefore, the verifications, functional safety assessments and audits recommended by ANSI/ISA-
84.00.01-2004 should be used to ensure that the requirements defined in the hazard and risk analysis are
met and that predictable failures do not defeat the intent of safety requirements specification.

G.7 Common-cause failure

The terms “common cause” and “common mode” have been used interchangeably in published literature,
causing confusion. ANSI/ISA-84.00.01-2004-1 defines a common-cause failure as “failure, which is the
result of one or more events, causing failures of two or more separate channels in a multiple channel
system, leading to system failure.” A common-mode failure is defined as “failure of two or more channels
in the same way, causing the same erroneous result.” It should be noted that common-cause failures can
be random or systematic. Some examples of common-cause failures include:

• Specification errors (systematic)

• Hardware design errors (systematic)

• Hardware failures (random)

• Software design errors (systematic)

• Human-machine interface design (systematic)

• Environmental, e.g., temperature extremes, humidity, corrosion, EMC, vibration, Radio Frequency
Interference (RFI), electrostatic discharge, mechanical shock (random)

• Process physical properties, e.g., temperature, corrosion, plugging, chemical attack (random)

• Single elements, e.g., common-process connections, energy sources (random)

• Maintenance, e.g., tools, procedures, calibration, training (systematic)

• Susceptibility to operate incorrectly, e.g., training, procedures, activity under abnormal stress
(systematic)

Often reliability engineering practitioners make the assumption that all common-cause failures are
common-mode. This is a conservative assumption and simplifies modeling. For the purpose of this
guideline, all common-cause failures are synonymous with common-mode failure.”
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Common-cause failures can be safe, dangerous, detected, or undetected. Those common-cause failures
that exhibit random behavior are typically modeled using the beta factor method. (Refer to ISA-

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

TR84.00.02 for further discussion on this method.) The beta factor is generally between 0 and 5% when
the good engineering practices provided in ANSI/ISA-84.00.01-2004 and this guideline are followed. If
these practices are not followed, the beta factor can be significantly greater. Those failures that exhibit
systematic behavior are managed using the ANSI/ISA-84.00.01-2004 function safety management
concepts.

The common-cause failure rate for dangerous undetected is expressed as

CCF
β ×λ DU =λ DU

Common-cause failures may be reduced during design, using appropriate fault avoidance measures.
Consider using the following methods:

• Implement devices according to manufacturer’s recommendations

• Provide manufacturer with application-specific information

• Follow the recommended verification and functional safety assessments in ANSI/ISA-84.00.01-

2004

• Redundancy, diverse or identical, as appropriate

• Separation of (i.e., distance between) redundant components

• Inspection and testing to identify potential problems affecting multiple devices

G.8 Strategy for defense against failures

The underlying strategy for defenses against systematic, random, and common-cause failures involves
improving three fundamental aspects of an installation

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
1) the overall quality,

2) the configuration, and

3) the availability.

The principles governing these three fundamental aspects are briefly discussed in the following
paragraphs. The roles of the availability, the configuration, and the overall quality in tackling systematic
and random failures are summarized in Figure G.6. Refer to Annex K for more information concerning SIF
design and combating common-cause failure.

G.8.1 Overall quality

The overall quality refers to the precautions taken to guard against systematic failures. Specification
errors, equipment errors, and software errors can easily occur during normal maintenance activities.
Improving the overall quality involves careful thought and planning at every step of the lifecycle process.
The use of an approved quality management system is recommended.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

G.8.2 Architecture

The architecture refers to the way in which the SIF devices are arranged and the arrangement of the SIS
relative to other protection layers. Fault tolerant architectures supplemented with the careful use of
diversity reduce the risk of random failures, as well as systematic failures. ISA-TR 84-00-04, Annex K,
provides guidance on minimum fault tolerance requirements.

Strategy for Reduces the Types of Failures

Failure Defense Likelihood

Overall Quality

Systematic Failures
Specification Errors
Equipment Errors
Software Errors

Configuration

Random Failures
Availability Equipment Failures
Mimimize Failures
Detect failures
Checklists
Diagnostics
Proof Tests

Figure G.6 — Improving the overall quality, the configuration, and the availability of a safety protection
layer can help to reduce systematic and random failures

G.8.3 Availability

The availability of the SIF is related to its ability to perform its design function when required. Improving
availability means protecting the system against the consequences of random failures. Figures G.7 and
G.8 illustrate how SIF performance can be maximized, and maintenance costs can be minimized. An In--
Plant Reliability Data System (IPRDS) can provide data to serve as a basis for selecting device failure
rates. This data can also provide a basis for the prior use evaluation of devices. (Refer to ISA-
TR84.00.04-1 Annex L for more information on prior use.)

ANSI/ISA-84.00.01-2004-1, Clauses 16.2.2 and 16.3.3, identifies the data to be maintained on the
SIS/SIF by Operations and Maintenance respectively. The IPRDS provides data to determine process
demand frequencies and device failures, as described in ANSI/ISA-84.00.01-2004-1, Clauses 16.3.1.5. It
also provides failure mode information that can be used to develop diagnostic techniques and to serve as
the basis for device checklists, revealing a greater percentage of the dangerous failures. ANSI/ISA-
Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

84.00.01-2004-1, Clause 11.3, describes requirements for operators and devices upon detection of a
fault.

Armed with an understanding of how devices fail relative to the specific design and installation practices
allows maintenance to select appropriate testing intervals, to develop procedures for detecting failures,
and to maintain stores’ stock levels to minimize the MTTR. Furthermore, activities and procedures can be
developed to capture proof-test substitutes, such as actual demands, shutdowns, and startups, which can
be used to extend proof-test intervals without sacrificing SIF performance.

Dangerous Undetected Failure Exposure Time = MTDF + MTTR ~ MTDF

Safe

Dangerous Undetected Failures Are

Safety Instrumented Function Revealed Only By A Proof Test Or By
Status A Demand, Whichever Comes First,
And Then They Are Repaired
Fail

Proof Test Interval

Dangerous Failure Exposure Time to Failure on Demand

Equals Mean Time To Detect Failure Plus Mean Time To Repair
MTDF + MTTR = Exposure Time to Failure on Demand

Dangerous Detected Failure Exposure Time = MTDF + MTTR ~ MTTR

Safe

Dangerous Detected Failures Are

Safety Instrumented Function Immediately Detected And Repaired
Status

Fail

Proof Test Interval

Figure G.7 — Illustration of the importance of MTTR and proof test in achieving Safety Instrumented
Function performance

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`

Copyright International Society of Automation

In Plant Reliability
Data Sy stem

Equipment Selected λ D = λ DU + λ DD , dangerous failure rate

with Minimum λ DD
= DC × λ , dangerous
D
detected failure rate
Total Failure Rates and
Undetected Failure Rates λ DU = (1 − DC ) × λ D , dangerous undetected failure rate
DC = Diag nostic Coverage of checklists and diagnostics

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Dev elop Checklists
and Diagnostics to λD = (1 − DC ) × λD + DC × λD
Maximize Pe rcentage
of Detected Failures

Dev elop Procedures

=λ × MTTR
to Minimize MTTR DD DD

Detected Failures PFD

Dev elop Proof -Test Procedures and def ine Test Interv als

Dev elop Procedures

to Minimize Pro of Tests
=λ × TI
DU DU
by Capturing Data f rom PFD 2
Shutdowns, Startups,
and Demands
Perf ormance Achiev ed with Mean Time To Repai r (MTTR), Diagnostic
Cov erage (DC), and Proof -Test Interv al

Determine Proof -
PFD D = (1 − DC ) × λ D
TI
Test Interv al f or + DC × λ D × MTTR
Undetected Failures 2
to Achiev e PFD Target
= + PFD
D DU DD
PFD PFD
Figure G.8 — Activities and procedures contribution to availability defenses against random failures

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

This page intentionally left blank.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex H – SIF versus interlocks, permissives, and inhibits

NOTE -- Annex H is referenced in the following: Clause 4.9.

H.1 Purpose

Throughout the process industry, multiple terms have been used to refer to what are now called safety
instrumented systems. This annex is intended to clarify the differences between interlocks, permissives,
inhibits, safety functions, SIS, and SIF. Since many of these terms have historical references, the
terminology is discussed in relation to ANSI/ISA-84.01-1996 and IEC 61508. This facilitates
understanding of how these terms evolved into the current definitions of ANSI/ISA-84.00.01-2004-1.

H.2 Interlock

H.2.1 Definition

1)
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

To join or be joined firmly as by a mutual interconnection of parts. (Collins Concise English

Dictionary).

2) A device, especially one operated electro-mechanically, used in a logic circuit to prevent an

activity being initiated unless preceded by certain events. (Collins Concise English Dictionary).

3) Initiates or prevents a predefined action in response to a predetermined condition. (Guidelines for

Safe Automation of Chemical Processes [modified from "interlock system"]).

4) Detects an out-of-limits or abnormal condition or improper sequence and either halts further
action or starts corrective action. (Guidelines for Engineering Design for Process Safety [modified
from "interlock system"]).

H.2.2 Overview

The term "interlock" is still used today in industry sectors. Its definition varies depending on the sector
(e.g., rail, machinery, process) it is relating to, and if "interlock" is being used as a noun or a verb.

All subsequent "interlock" discussion herein relates to the process sector only.

In some applications, the use of the word "interlock" refers only to "safety interlocks" while in other cases
the word "interlock" is preceded by "safety" to indicate a "safety interlock" and "process" to indicate a non-
safety-related interlock or “process interlock.”

The four definitions presented above illustrate some of the differences in the definition of interlock. As a
result, the use of the term "interlock" in ANSI/ISA-84.01-1996 was rejected by the ISA Standards Panel
84 (ISA84).

ANSI/ISA-84.01-1996 did use the term "interlock" in a few instances (clauses 3.1.53, 7.2.3, and B1.6.2) to
facilitate understanding of the new terms introduced in ANSI/ISA-84.01-1996. Today, the term "interlock"
is not used in either IEC 61508 or ANSI/ISA-84.00.01-2004-1.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

H.2.3 ANSI/ISA-84.01-1996 analysis

ANSI/ISA-84.01-1996 utilizes either "safety function" (clause 1.4) or "SIS" (clause 1.6) as a replacement
for "safety interlock" (e.g., see clauses 5.2.1 and 9.7.3.1 respectively).

The issuance of ANSI/ISA-84.01-1996 was closely followed by the issuance of IEC 61508. IEC 61508 did
not use the term "interlock" but instead, either used the term "E/E/PE safety function" or "E/E/PE safety-
related system." This remains significant because many safety products utilize IEC 61508 as their
development and documentation guide. In the case of IEC 61508, the term "safety function" applied not
only to E/E/PE technology but also to "other technology safety-related systems or external risk-reduction
facilities."

H.2.4 ANSI/ISA-84.00.01-2004-1 difference

ANSI/ISA-84.00.01-2004-1 utilizes "safety instrumented function" (clause 5.0) in lieu of "safety interlock."

NOTE -- ANSI/ISA-84.00.01-2004-1 does utilize "safety function" (clause 4.0) identical to its IEC 61508 definition (see clause 1.1.3).

H.3 Permissives

H.3.1 Definition

1) granting authorization to do something (Collins Concise English Dictionary).

2) condition within a logic sequence that should be satisfied before the sequence is allowed to
proceed to the next phase (ANSI/ISA-84.01-1996 Clause 3.1.36).

H.3.2 Overview

Permissive is a common term used in industry. Permissive typically refers to a subset function of an SIF
(e.g., a permissive where a minimum pressure is required to allow the valve to open). It is not typically
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

considered synonymous with SIF.

H.3.3 ANSI/ISA-84.01-1996 analysis

Examples of the use of "permissives" can be found in clauses 3.1.58.1, 5.3.5, 9.4c, and B10.1.3c.

H.3.4 ANSI/ISA-84.00.01-2004-1 difference

Use of the term "permissives" in ANSI/ISA-84.00.01-2004-1 (Clauses 3.2.81.2.1 and 10.3.1-11th bullet)
is identical to ANSI/ISA-84.01-1996.

H.4 Inhibits

H.4.1 Definition

1) To stop, prevent, or decrease the rate of a chemical reaction (Collins Concise English Dictionary).

2) Not allow an action to occur (ANSI/ISA-84.01-1996 Clauses 9.7 & B 9.3.3).

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

H.4.2 Overview

Inhibit is applied as a verb to describe the function of an SIF, SIS, or a protection layer and as a noun. It
is not used as synonym for an SIF. It is used as a synonym for terms such as "stop," "prevent," or
"decrease."

H.4.3 ANSI/ISA-84.01-1996 analysis

Example applications of the term "inhibit" used as a verb can be found in Clauses 9.7 and B 9.3.2.

H.4.4 ANSI/ISA-84.00.01-2004-1 difference

"Inhibit" has the same meaning in ANSI/ISA-84.00.01-2004-1 as it has in ANSI/ISA-84.01-1996. Example

application of "inhibit" can be found in ANSI/ISA-84.00.01-2004-1 Clause 10.3.1.

NOTE -- In this case, "inhibit" is used as a verb.

H.5 Safety function

H.5.1 Definition

1) Function to be implemented by an E/E/PE safety-related system (i.e., SIS), other technology

safety-related system, or external risk-reduction facilities, which is intended to achieve or maintain
a safe state for the equipment under control, in respect of a hazardous event. (IEC 61508 Part 4
Clause 3.5.1).

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
2) Function to be implemented by an SIS, other technology safety-related system, or external risk
reduction facilities, which is intended to achieve or maintain a safe state for the process, with
respect to a specific hazardous event. (ANSI/ISA-84.00.01-2004-1 Clause 3.2.68)

H.5.2 Overview

As discussed in 1.1.3, "safety function" has different meanings if you are comparing ANSI/ISA-84.01-1996
with ANSI/ISA-84.00.01-2004 (or IEC 61508). It can be seen from the above definitions that ANSI/ISA-
84.00.01-2004 and IEC 61508 definitions are essentially identical. However, ANSI/ISA-84.01-1996 has
not defined "safety function" but has used it as a synonym for safety instrumented function (see 1.4.3).
The result is the definition of "safety function" changes when transitioning from ANSI/ISA-84.01-1996 to
ANSI/ISA-84.00.01-2004.

H.5.3 ANSI/ISA-84.01-1996 analysis

"Safety function" is used throughout ANSI/ISA-84.01-1996. The following limited sampling of clause
references illustrate the use "safety function" throughout ANSI/ISA-84.01-1996, such as Clauses 5.2.1,
5.4.1, 6.2.1, and 6.2.2.

H.5.4 ANSI/ISA-84.00.01-2004-1 difference

The committee developing ANSI/ISA-84.00.01-2004 was faced with two different definitions of "safety
function" (i.e., one definition in ANSI/ISA-84.01-1996 and another in IEC 61508). The definition of "safety
function" used in IEC 61508 was adopted for ANSI/ISA-84.00.01-2004-1. This facilitated global
compatibility and recognition for this term.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

"Safety function" is primarily used in ANSI/ISA-84.00.01-2004-1 to address the identification of

safeguards that meet the specific design, risk reduction, and management requirements (ANSI/ISA-
84.00.01-2004-1, Clauses 8 and 9). To address the ANSI/ISA-84.01-1996 "safety function" definition,
ANSI/ISA-84.00.01-2004-1 added the term "safety instrumented function. "

NOTE -- The ANSI/ISA-84.00.01-2004 committee did not replicate all the terms used in IEC 61508. Since IEC 61508 is a multi-
sector standard, some new terms were introduced in the standard that more suitably apply to the process sector that ANSI/ISA-
84.00.01-2004 addresses.

H.6 Safety Instrumented Function (SIF)

H.6.1 Definition

1) Safety function with a specified safety integrity level, which is necessary to achieve functional
safety (ANSI/ISA-84.00.01-2004-1 Clause 3.2.71).

H.6.2 Overview

An SIF is a safety function allocated to the safety instrumented system during the hazard and risk
analysis. It is implemented using instrumentation and controls, such as the sensor(s), logic solver(s), and
final element(s), to prevent or mitigate a specific process hazard. SIFs are often automatically initiated but
may also be manually initiated. When manually initiated, the probability of failure of the operator should
be considered when verifying the risk reduction that can be achieved from the SIF. Refer to Annex B for
more discussion of operator-initiated SIFs. Each SIF is allocated a target risk reduction during the hazard
and risk analysis. The target risk reduction is related to the SIL.

Figure H.1 illustrates the relationship between the SIF and the SIS. The implementation of SIFs in an SIS
varies with the technology used. The following is a list of typical packaging relationships:

Technology SIF to SIS Ratio

Electrical 1 SIF per SIS
Electronic multiple SIFs per SIS
Programmable electronic multiple SIFs per SIS

SIF #1 SIF #1
SIF #2 SIF #2
SIF #3 SIF #3

Figure H.1 — Definition of Safety Instrumented System and Safety Instrumented Function (* SIS user
interface may be part of the SIF. Refer to ISA-TR84.00.04-1 Annex B)

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

H.6.3 ANSI/ISA-84.01-1996 analysis

ANSI/ISA-84.01-1996 does not use the term “safety instrumented function.”

H.6.4 ANSI/ISA-84.00.01-2004-1 difference

ANSI/ISA-84.00.01-2004-1 introduced the concept that safety functions are identified during the hazard
and risk analysis and allocated to protection layers. When the safety function is allocated to the safety
instrumented system, the function becomes a safety instrumented function. The SIF is designed to
mitigate a specified safety-related process risk using sensor(s), logic solver(s), and final element(s). At
this time, SIF is a process industry sector specific term.

H.7 Safety Instrumented System (SIS)

H.7.1 Definition

(1) Instrumented system used to implement one or more safety instrumented functions. An SIS is
composed of any combination of sensor (s), logic solver (s), and final elements(s) (ANSI/ISA-84.00.01-
2004-1 Clause 3.2.72 - portion of definition only).

H.7.2 Overview

No further guidance.

H.7.3 ANSI/ISA-84.01-1996 analysis

SIS is used in ANSI/ISA-84.01-1996.

NOTE -- ANSI/ISA-84.01-1996 may discuss "SIL of an SIS." The reader should determine what the specific intent is by analyzing
the application of the term.

H.7.4 ANSI/ISA-84.00.01-2004-1 difference

As stated previously, SIF is assigned a target SIL. An SIF is implemented using an SIS per the safety
lifecycle. SIS is a process-sector specific term.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

This page intentionally left blank.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex I – Continuous, high, and low-demand mode

NOTE -- Annex I is referenced in the following: Clause 4.9 and Annex P.1.

I.1 Purpose

This annex provides guidance on how to evaluate the mode of operation of SIF. ANSI/ISA-84.00.01-
2004-1, Clause 9, requires that the owner/operator determine whether the SIF is operating in a low-
demand, high-demand, or continuous mode. When the SIF operates in high-demand mode, the standard
requires that the SIF be designed and managed as a continuous mode SIF, so this annex will refer to
these SIF as “high demand/continuous mode.” ANSI/ISA-84.00.01-2004-1 has specific requirements for
high-demand/continuous mode SIF in Clause 11.3 on system behavior in response to detected faults (see
ISA-TR84.00.04-1 Annex P) and Clauses 9 and 11.9 on SIL verification (see ISA-TR84.00.02).

I.2 Introduction

A demand mode SIF operates in response to a process demand that occurs when the process deviates
from normal operation to the extent that action must be taken to prevent the process variable from
exceeding the safe operating limits. The majority of SIF experience infrequent demands (i.e., less than
once per year), so they operate in what is known as low-demand mode. As the demand rate increases,
there is a transition from low-demand mode to continuous-mode operation. Continuous mode SIFs act
continuously to prevent the hazard such that the dangerous failure of the SIF results in an immediate
hazard. In other words, the dangerous failure of the SIF is an initiator of the hazardous event.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
In the process industries, the majority of SIF operate on low demand, e.g., a BPCS control loop fails
resulting in a high pressure, which is detected by the SIF (demand) causing it to close its block valve
(operates). Due to the prevalence of low-demand SIF, many published papers and technical reports
discuss the implementation of demand mode SIFs only. This has led to the impression that high-
demand/continuous mode SIFs do not exist in the process industry.

Over the years, two rules of thumb have been proposed to assist in this determination. These rules of
thumb are intended to focus attention on those SIFs that require additional analysis and special design
and verification methods. If either of these rules is met, the SIF should be considered high demand.

First, ANSI/ISA-84.00.01-2004 states that any SIF that is required to operate more than once a year due
to a process demand should be treated as a high-demand-mode SIF. The SP84 committee strongly
recommends that if you have an SIF that is required to function more than once per year that
consideration be given to implementing an inherently safer design and to improving the automated or
manual control systems to reduce the demand rate. Refer to ISA-TR84.00.04-1, Annex J, for more
discussion of Inherently Safer Design.

Second, if the mean time to demand is less than twice the test interval, the SIF should be considered
high-demand mode (e.g., if the mean time to demand is 10 years, a proof-test interval longer than 5 years
would be high-demand mode). Another way to state this is that when the demand frequency is more than
half the periodic proof-test frequency, the application should be considered a high-demand/continuous-
mode application (e.g., if the demand frequency is 1 in 10 years, a test frequency longer than 1 in 5 years
would suggest high-demand mode). This is because the PFDavg calculation generally applied to verify the
SIL of low-demand mode SIFs is not applicable to continuous-mode SIFs. The PFDavg math applies to low
demand mode where testing is being performed at a sufficient frequency to detect dangerous failures
before a process demand occurs. In continuous-mode SIFs, this is not true, because the SIF must be
functional at all times, and its failure results in the immediate hazard. Table 1 shows the practical
application of this relationship.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Table 1

Demand Minimum Proof-Test Mean Time To Maximum Proof-

Frequency Frequency Demand Test Interval
-1 -1
(Yr ) (Yr ) (Yr) (Yr)
0.10 0.20 10 5
0.5 1 2 1
1 2.00 1 0.50
2 4.00 0.5 0.25
*As proof-test intervals are increased, it is also important to recognize that the useful life of the equipment
as it relates to the random failure rate portion of the bathtub curve should not be exceeded.

To better understand the complexity of determining the operating mode, it is useful to consider examples
of low-demand, highdemand and continuous-mode SIFs. Take for example, the initial design of a storage
tank. The tank is manually filled on average 25 times per year. The filling procedure requires the operator
to be in continuous attendance throughout the filling operation. A high-level SIF is provided as an
independent protection layer to address operator error during the filling operation. If one were to assume
that the probability of operator error is 0.01, the demand rate would be:

Demand rate = fill rate X probability of operator error (1)

Demand rate = (25/year)(0.01) = 0.25/year or 1 in 4 years

As long as the proof-test interval for the SIF is less than or equal to two years, this application can be
considered a low-demand application. If the proof-test interval is increased, or the number of fills is
increased, given a two-year proof-test interval, this application transitions from low-demand to high-
demand mode.

Suppose, however, that when the tank is commissioned, the operator responsible for the filling operation
is assigned multiple tasks to perform during the filling operation, since the time to fill the tank is typically
over an hour. Instead of continuous attendance, the operator performed various tasks, and the actual
procedure performed evolved into the operator always allowing the SIF to shut off the pump. In the
operator’s mind, this was a productivity improvement. As this change occurred and became the defacto
procedure, the SIF became part of the control scheme, since the termination of feed is triggered by the
SIF rather than by direct operator response to the process variable. With this change, SIF failure directly
results in overfill, since the operator does not shut off the pump by procedure. The SIF is now operating in
continuous mode, where the hazard rate is determined by the SIF failure rate.

Looking at a variation of this example, assume now that the filling operation is performed daily or 365
times per year. Also, assume that the operator follows the original procedure by monitoring the process --``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

variable and terminating the feed prior to SIF initiation. Using the calculation presented previously, the
demand rate would be:

Demand rate = fill rate X probability of operator error

Demand rate = (365 demands/year)(0.01/demand)

= 3.65 demands/year or 1 demand every 100 days

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

This demand rate indicates that the SIF needs to be tested at least every 50 days to meet the demand-
mode criteria. However, from a practical viewpoint, the SIF is being tested very frequently to address the
estimated demand rate rather than addressing the real need to ensure that the SIF provides the required
performance. As stated previously, if the SIF meets either the demand rate or test frequency rule, the SIF
should be considered high-demand mode. Since the SIF operates every 100 days, the SIF meets the
highdemand rate rule of more than one demand per year. Testing more frequently does not affect the
SIF’s mode of operation.

For a single channel system (1oo1), the PFDavg is given by the equation:

λDU TI
PFD avg =
2 (2)

Where λDU is the dangerous undetected failure rate, TI is the proof-test interval, and λ *TI<1.
DU

If the SIF has a dangerous failure rate of 1/50 years and is tested annually (i.e., demand by test):

PFDavg = (1/2)(1/50 years)(1 year) = 0.01

Continuing with this analysis, the hazard rate is:

HR = DR x PFDavg (3)

Where HR is the hazard rate, DR is the demand rate, DR*TI<1 and HR*TI<1.

Hazard rate = 3.65 demands/year* 0.01/demand = 0.0365 /year = 1/27 years

The estimated hazard rate (1/27 years) is higher than the SIF failure rate (1/50 years), which is not
possible. Instead, the analysis should have considered that the SIF is actually operating in a high-demand
mode (i.e., the SIF is the initiating cause), and the hazard rate is limited by the SIF failure rate or 1/50
years. The mechanical integrity of the SIF should be sufficient to ensure that its failure rate is equal to or
less than 1/50 year.

I.3 Continuous mode examples

• Temperature control of a batch reactor: In a particular batch reaction process, temperature

control is critical to the safe operation of the process, as excess heat resulting from control failure
could cause a runaway reaction. The reaction kinetics are such that insufficient time is available
for an operator to respond to a high-temperature alarm. It was also determined that any actions
initiated by a high-temperature SIF would be inadequate to prevent an overpressure demand on
the rupture disk due to the response time of the sensor.

Consider two hazardous events: release of hazardous material to the atmosphere and reactor
rupture. The temperature control is the only layer of protection preventing the release of
hazardous material, it operates in a continuous mode, and its dangerous failure results in the
release. An adequately sized rupture disk does provide a layer of protection for reactor rupture,
and in this case the temperature control still operates in continuous mode, and its dangerous
failure results in a demand on the rupture disk. The rupture disk operates in low-demand mode.

• No separation of BPCS and SIS: As discussed in Annex F, if a BPCS function (e.g., a control
loop) is the initiating cause for a process hazard, and it is implemented in the SIS logic solver that
is also responsible for executing an SIF that mitigates the process hazard, the SIF is operating in
a continuous mode. The failure of the SIS logic solver results in the initiating cause and the failure
of the SIF, so the logic solver would be considered as operating in a continuous mode.
Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

I.4 High-demand mode examples

• Batch reactor: If the reactor charge is too high, a runaway reaction can occur. It was determined
that the charge should be stopped based upon total mass flow, level, or weight to prevent
overcharge. Assume that the cycle time for each batch is ten hours with a four-hour turnaround
time between batches. If the reactor were in operation for 50 weeks out of the year (8400 hours),
that would represent 600 demands/year (8400hr/yr /14hr/demand). The reactor charge cutoff is
acting as a control function, and the initiating event frequency is determined by its failure rate.

• Batch reactor: A batch process produces an off-gas that contains hydrocarbons. The off-gas is
sent to a catalytic incinerator to destroy the hydrocarbons prior to the off-gas being relieved to the
atmosphere. High hydrocarbons in the off-gas can cause excessive heating in the catalytic
incinerator and potential damage to the catalyst. An SIF is implemented to detect high
hydrocarbons and take action to trip the steam and flood the header with nitrogen. The SIF was
assigned an SIL 2 in the process hazards analysis. The planned SIF design has a dangerous
failure rate of 1/200 years (0.005/year) and achieves SIL 2 at annual testing (PFDavg=0.0025).

The batch process is tripped once every 3-4 batches, and 100 batches are produced annually.
This means that the SIF operates approximately 25 to 35 times per year, which is high-demand

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
mode operation per the rule of 1 demand per year. Looking at this on the basis of the hazard rate
equation:

HR = DR * PFDavg = 35 demand/year* 0.0025/demand = 0.085 events/year

The calculated hazard rate is greater than the SIF dangerous failure rate, which is not possible.
The hazard rate is limited by the SIF dangerous failure rate. The SIF is operating as a control
function, and the process hazards analysis should be changed to reflect the SIF as the initiating
cause. Consideration should be given to modifying the process control scheme to reduce the
number of SIF operations.

• Hazardous by-product forming: A hazardous by-product is formed in a chemical reaction at a very

small rate (ppm). The only control is on the main reaction. The by-product accumulates over a
month in the reactor and becomes a hazard when it reaches a certain concentration. An online
analyzer for the by-product stopping the recycle stream when high concentration is detected
provides the only protection against this hazard and was initially defined as an SIF. Under normal
operation, the demand on the SIF occurs four times a year. This indicates that it may be more
appropriate to consider this as a high-demand mode SIF. The final determination depends on the
dangerous failure rate of the analyzer function.

• Gas Pump Control Shutoff: Gas stations employ fuel pumps that are designed to stop flow of gas
when the car’s gas tank is full. When the gas pump control fails to function, the car’s gas tank is
overfilled. The fuel pump shutdown represents an example of a protective system operating in
high-demand mode, as there are several demands on the fuel pump shutoff a day.

As shown in the previous examples, the situations that are considered to be “high demand” or
“continuous demand” are actually BPCS functions that are required to be extremely reliable because
there is no back-up protection system. An SIS operating as a protection system (i.e. low demand) is used
to move a process to a safe state upon detection of an abnormal condition. If a process condition always
occurs at the end of every batch, then it is not unexpected. Many practitioners believe that high-demand
mode safety functions should not exist in the process industry, and where they are identified, they should
be re-engineered to convert them to low-demand mode.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

In the first high-demand mode SIF described above, the instrumented systems could be re-engineered
with the charge cut-off allocated to the BPCS layer and an SIF allocated to the SIS layer. The SIF could
use an independent device to measure the charge and close a separate valve if overcharging occurs. The
demand would still be created by the charge cut-off failure, but the SIF would operate independently to
mitigate the hazard. If the charge cut-off control is designed using good practices, the SIF should operate
in a demand mode.

I.5 Low demand examples

• Steam Drum: In this example, the level controls and protection are independent. If there is a level
control failure, an alarm sounds, providing an opportunity for an operator to restore the process to
a safely controlled state. The SIF is provided by a low-level shutdown in order to remove heat and
stop the boiling process. In this case, the demand on the SIF is expected to be less than 0.1 per
year.

• Reactor: A process hazards analysis identifies a hazard associated with a reactor dump valve. If
the dump valve opens when the reactor is not depressurized, downstream equipment is over-
pressured. An SIF is implemented to prevent the reactor dump valve from opening when the
pressure is high, using a solenoid-operated valve that controls the instrument air supply to the
dump valve actuator. To support batch operation, the SIF energizes the solenoid-operated valve
for each batch when the reactor pressure is low. However, from a safety perspective, the SIF
prevents a hazardous event only when the control system fails and tries to open the control valve
when the reactor is under pressure. This failure is estimated to be approximately 1 in 10 years.
The SIF is operating in demand mode with regard to the hazard.

• Autoclave: A reaction is performed in an autoclave that is pressurized to 25 Barg. When the

reaction is completed, the pressure reduces to < 5 Barg and the autoclave is vented to the gas
processing unit. Venting is performed using two BPCS control valves that operate together with
one opening quickly to begin depressurization and the second modulating to control the pressure.

The hazardous event is initiated by the failure of either of the BPCS control valves when the
reactor is at high pressure (>5 Barg). The scenario will result in a loss of containment due to
overpressure of equipment in the gas processing unit. Due to the scenario risk, an SIL 1 SIF is
proposed to detect high pressure and isolate the vent line.

The design team considered various options for implementing the proposed SIF and evaluated
each proposal’s mode of operation.

Case 1: When high pressure in the reactor is detected, the BPCS control valves are not enabled.

The SIF could be implemented using a dedicated pressure transmitter on the reactor and
dedicated solenoid-operated valve on the each control valve. The SIF would not allow air to
control valve positioners unless the pressure was < 5 Barg. This SIF design was determined to
not be sufficiently independent of the initiating cause since it relied on the control valve for
isolation.

Mode of operation: The scenario is caused by failure of the BPCS control valves. Since the SIF
also uses these valves, the SIF would also fail if the control valves failed to seat. The SIF
operates in demand mode, but it is not independent of the process control system.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Case 2: When high vent-line pressure is detected, isolation valves on each vent line are closed.

If the control valves open during the high pressure (25 Barg) phase, the pressure would
instantaneously rise in the vent line, so the SIF would need to operate within seconds to prevent
a pressure transient in the downstream equipment. The design could be feasibly implemented
with 2 pressure transmitters and 2 isolation valves. The required response time could be met
using quick vents (fast-acting solenoids) to rapidly close the isolation valves.

Mode of operation: The scenario is caused by failure of the BPCS control valves. The hazards
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

analysis determined that this occurred approximately 1 in 10 years. Since a demand on the SIF
would occur on 1 in 10 years, the SIF operates in demand mode.

Case 3: When high pressure (>5Barg) in the vent-line header is detected, and the BPCS control
valves are not closed as detected by closed limit switches, a block valve on the vent-line header
is closed.

A block valve will be closed by the SIF if the BPCS control valves are determined to be open by
limit switches, and the pressure in the vent line is too high. The required response time could be
met using quick vents (fast-acting solenoids) to rapidly close the isolation valves. The presence of
2 conditions is necessary for the SIF to operate, increasing the SIF complexity. The 2 conditions
and the response are independent of the initiating cause. However, the use of the limit switch
addresses the failure mode that the valve opens completely, but does not address the failure
mode that the control valve may not seat properly (partial failure).

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Mode of operation: Although the SIF is detecting the opening of the control valves 4 times per
day, which corresponds to the normal operation of the autoclave batch cycles, the SIF is not
operating in continuous mode. The scenario is caused by failure of the BPCS control valves. The
hazards analysis determined that this occurred approximately 1 in 10 years. Since a demand on
the SIF would occur on 1 in 10 years, the SIF operates in demand mode.

Case 4: When low pressure (<5Barg) in the vent-line header is detected, a block valve on the
vent-line header is opened.

A block valve will be held closed by the SIF until the pressure is <5 Barg. If the control valves fail
to seat properly during the high-pressure phase, the block valve will prevent venting to the
downstream equipment. The reaction is a batch process that cycles 4 times per day. When the
SIF detects <5 Barg, the block valve is opened. Consequently, the SIF operates 4 times per day.

Mode of operation: Although the SIF operates as part of normal operation 4 times per day, the
SIF is not operating in continuous mode. The SIF dangerous failure is not the initiating cause of
the hazardous event. The operating mode is determined by the process demand from a hazards
standpoint. The hazardous event caused by misoperation of the control valve failure is estimated
at 1/10 years. The SIF operates in demand mode with regard to the hazard.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

I.6 Application guidance

As the SIF operation transitions from low-demand to continuous mode, there is a point where the failure
of the SIF can no longer be described using the PFDavg math. The owner/operator should understand the
difference between the types of demands, so that the appropriate level of rigor is applied to any risk
calculation. For the most part, SIFs operate in a low-demand mode and the typical PFDavg calculations
are good enough. On occasion, an application is encountered where it is more appropriate to evaluate the
SIF as high-demand or continuous mode. In high-demand/continuous mode, the SIL should be verified by
determining the SIF failure rate rather than the Probability to Fail on Demand (PFDavg). Fortunately, a
more rigorous mathematical model can be used when an SIF is operating in high-demand/continuous
mode. It is important to recognize those cases where high demand actually exists.

ANSI/ISA-84.00.01-2004-1, Clause 9.2.3, provides two tables for defining the SIL requirements. Table 3
provides the SIL requirements in terms of PFDavg. Table 4 provides the SIL requirements in terms of
Frequency of Failure (e.g., failures per hour) and defines the acceptable hazard rate for the high-
demand/continuous SIF. ANSI/ISA-84.00.01-2004-1, Clause 9.2.3, states that when Table 4 is used,
neither the proof-test interval nor the demand rate is used in the determination of the safety integrity level.
This means that the Table 4 requirements should not be converted into PFDavg requirements, using the
proof-test interval or the demand rate. Erroneous results can easily occur if a high-demand mode SIF is
treated as a low-demand mode SIF, followed by incorrect use of Tables 3 and 4 (ANSI/ISA-84.00.01-
2004-1 Clause 9.2.3).

For example, for an SIL 1 continuous-mode SIF, the lower bounds of the probability of failure is 10-5
failures/hour. This should not be converted into a PFDavg requirement by multiplying it by the expected
proof-test interval (e.g., if the testing interval is 5 years, 10-5/hour * 5 years *8760 hours/year = 0.438) or
by multiplying it by the demand frequency (e.g., if the demand rate is 10 times per year, 10-5/hour * 10
demands/year * 8760 hours/year = 0.876). While the units may cancel out yielding a unitless number, the
math is incorrect and the “PFDavg” is meaningless. For high demand/continuous mode SIFs, the SIL
verification calculation should be performed to determine the actual frequency of failure (e.g., failures per
hour).

Table I-1 provides the hazard rate (HR) calculated from the simplified equation, which is typically the
basis of Layers of Protection Analysis (LOPA), and a more rigorous equation based on the exponential
distribution. The shaded area shows that for high-demand mode SIFs, the simplified equation yields a
hazard rate that exceeds the failure rate λ of the SIF, which is 0.1/year. In the case of either high-demand
or continuous mode, the simplified mathematics developed for low-demand mode are not adequate, and
more advanced assistance should be obtained from someone knowledgeable in the applicable
mathematics of modeling such cases.

For high-demand cases, the equation requires more scrutiny. For example, assume that a batch
controller has a mean time to demand of 14 hours (8760/14=625 demands/year) and the frequency of
failure for the reactor charging controls are:
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

λ = 0.1 per year, considered to have an SIL 1 rating with a proof-test interval of one year.

Using the simplified equation (eq. 2), we would have the following result:

PFDavg = (0.1 * ½) = 0.05 and HR = 625 demands/year x 0.05/demand ≈ 30 hazards/year.

This can be seen to be incorrect, as the hazard rate cannot exceed the failure rate of the SIF
components. This occurred because a basic assumption of the simplified equation has been violated; the
mean time to demand should be greater than the test interval. In this case, the mean time to demand is
14 hours and the test interval is 1 year; the opposite of what it should be. Dangerous failures are much

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

more likely be found by demand rather than by test, so the simplified equation yields incorrect results.
When the rigorous equation is used, the calculated hazard rate is 0.1 per year, a rate identical to the
controller failure rate.

I.7 Consideration of diagnostics in high/continuous demand

When the demand frequency is more than twice the periodic proof-test frequency, the application should
be considered a high-demand mode application. Therefore the equations and techniques that use test
interval as a key variable are not valid. In effect, one cannot take credit for periodic inspection unless it is
done very frequently. Credit may be taken for diagnostics that cause the device to fail to the safe state
(i.e. automatic process shutdown on any detected dangerous failure) in the high-demand case, as long as
the diagnostic time period plus the time necessary to safely return the process to a safe state is less than
the available process safety time (the time period between initiation of a demand and the hazard).

When a fault tolerant architecture is allowed to degrade to a less safe architecture rather than
automatically tripping the process, repair in a timely fashion is essential to maintain the SIL of the SIF or
SIS. In such an application, diagnostics are used to reveal failures that would otherwise be undetected.
The mean time to repair (MTTR) used in the calculations should include all of the time necessary to
restore the equipment to full operating health. This would include the diagnostic detection time, any
troubleshooting time, and the repair time necessary to correct the failure and return the equipment to
service.

Finally, an MTTR is included as part of the assumptions in the manufacturer’s safety manual, and the
achievement of this MTTR may be a critical parameter in the SIL claim limit for the device. Refer to ISA-
TR84.00.04-1, Annex L, for more information concerning safety manuals and SIL claim limits. The
assumed MTTR should be compared to what is physically possible for the actual process unit, given its
staffing and resources. The chosen MTTR should be included in the mechanical integrity program,
supported by procedures that detail the maximum time for restoration, and the expected operator and
maintenance actions to maintain safe operation during repair. Refer to ISA-TR84.00.03 for more
discussion of MTTR, mechanical integrity, and the impact of repair deferral.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Table I.1 Hazard rate calculation examples

Demand Rate Proof-Test Interval Hazard Rate Hazard Rate

(per yr) (year) Simplified Equation Rigorous Equation
(per year) (per year)
0.1 0.25 0.00125 0.0012
0.1 0.5 0.0025 0.0025
0.1 1 0.005 0.0049
0.1 2 0.01 0.0095
0.1 3 0.015 0.0139
0.1 4 0.02 0.0181
1 0.25 0.0125 0.0118
1 0.5 0.025 0.0221
1 1 0.05 0.0393
1 2 0.1 0.0632
1 3 0.15 0.0777
1 4 0.2 0.0865
10 0.25 0.125 0.0713
10 0.5 0.25 0.0918
10 1 0.5 0.0993
10 2 1 0.0999
10 3 1.5 0.0999
10 4 2 0.1
100 0.25 1.25 0.0999
100 0.5 2.5 0.1

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
100 1 5 0.1
100 2 10 0.1
100 3 15 0.1
100 4 20 0.1

Assumptions
HR = Hazard Rate (frequency of hazardous event)
DR = Demand Rate (frequency of the initiating event that places a demand on the SIF)
SIF Failure Rate is constant = 0.1/year

PFDavg follows an exponential distribution, where λ = Failure Rate and TI = Test Interval

Equations: Henley and Kumamoto, 1981

λTI
Simplified Equation: HR= DR x PFDavg = DR
2

Rigorous Equation:

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex J – SIL 4 versus inherently safer design

NOTE -- Annex J is referenced in the following: Clause 4.2.

J.1 Purpose

When safety functions are allocated to protection layers (Clause 9), sometimes an SIL 4 SIF (safety
instrumented function) may seem to be required to meet the risk reduction target. This Annex provides
guidance on how to address process risk that requires SIL 4 equivalent risk reduction.

J.2 Re-evaluate the allocation of safety functions to protection layers

Where it appears that a risk reduction equivalent to SIL 4 SIF is required, it is first recommended that
additional analysis be performed to ensure that the risk has been properly assessed. As shown in Table
J.1, quantitative risk assessment should be considered to verify the hazardous event frequency, and
consequence models should be considered to verify the consequence severity. If the risk has been
properly assessed, consider inherently safer principles to redesign the process to reduce the risk.

When inherently safer design is not practical, the ISA84 committee strongly recommends the use of
multiple independent protection layers using diverse technology as an alternative to a single SIL 4 SIF.
This provides the best protection against common-mode/common-cause failures (see ISA-TR84.00.04-1,
Annex G).

The ISA84 committee strongly advises against the implementation of a single SIL 4 SIF because of the
difficulty of achieving the required PFDavg due to the impact of common-mode/common-cause failures.
Design, verification, validation, and management rigor must be significantly greater to achieve SIL 4 from
any single system. Practices similar to nuclear sector requirements are necessary to achieve SIL 4 from a
single system, e.g., multiple logic solvers, extensive prior use (many years), actual failure-rate data (long-
term), independent verifications/assessments, and detailed documentation. When considering splitting
the requirements into multiple instrumented functions allocated to multiple systems, additional analysis,
verification, and assessment should be performed to ensure overall risk reduction is met. This may
include:

• Analyze design and management strategy to identify systematic errors affecting multiple
functions/systems

• Assess dependencies introduced by common specification, operating environment, and

mechanical integrity plan

• Assess common cause between SIS and the cause of demand

• Assess common cause with other instrumented systems providing risk reduction

• Verify hazardous event frequency using quantitative risk assessment

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Table J.1 — Checklist for evaluating feasibility of SIL 4 SIS

Topic Question Comment

1 Consequence and its severity Is the consequence and its Consider dispersion and
severity for this scenario consequence modeling to verify
correctly understood? the severity estimate
2 Initiating event frequency Is the estimate for the initiating Consider quantitative risk
event frequency correct? assessment to verify the
Can the initiating event initiating event frequency
frequency be reduced by
redesign of the process?
3 Inherently safer principles Can the risk be reduced by See discussion in J.3
applying inherently safer
principles?
4 Selection of devices Are suitable components and Components and subsystems
subsystems available? must be in accordance with IEC
61508-2 and IEC 61508-3

J.3 Reduce risk by applying inherently safer principles

The basic concept of inherently safer process design is to reduce the hazard of a process by reducing or
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

eliminating the hazards associated with materials and operation of the process. This approach is
described in detail in the CCPS book, Inherently Safer Chemical Processes, A Lifecycle Approach, 2nd
edition, 2008. In brief, there are four major strategies for inherently safer design:

Minimize - Use smaller amounts of hazardous substances (also called Intensification).

Substitute - Replace the material with a less hazardous material.
Moderate - Use less hazardous conditions, a less hazardous form of a material, or facilities that minimize
the impact of a release of hazardous material or energy (also called Attenuation and Limitation of Effects).
Simplify - Design facilities that eliminate unnecessary complexity and make operating errors less likely,
and that are forgiving of errors that are made (also called Error Tolerance).
Successful application of these principles can potentially reduce the risk enough that an SIF is not
required, or if an SIF is required, a lower risk reduction than SIL 4 can be used. It should be noted that
there is always a trade-off in applying inherently safer principles; one type of risk may be reduced, but
another risk may increase. There may be trade-offs between yield, productivity, cost, and safety risk.
These trade-offs should be evaluated from a system perspective, looking at all of the requirements for a
process including environmental, health and safety, sustainable development, operational, quality, and
business.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex K – Fault tolerance topics

NOTE -- Annex K is referenced in the following: Clause 4.3, Annex F.4, Annex G.8.2, and Annex P.2

K.1 Purpose

This annex provides guidance on the relationship between the minimum fault tolerance requirements and
SIL claim limits (or SIL Capability).

K.2 General consideration

A concern regarding the probabilistic approach used in IEC 61508 and ANSI/ISA-84.00.01-2004-1 to
determine the adequacy of the SIF design is that owners/operators could mistakenly assume
unrealistically low failure rates for the SIF devices. The resulting erroneously low PFDavg could potentially
lead to inadequate risk reduction. There are many sources of failure rate data, and sometimes it is difficult
to decide what number best represents the device in the field application. ISA-TR84.00.02 provides more
information on device failure rates, including a sampling of data from five owners/operators.

ANSI/ISA-84.00.01-2004-1 requires the use of minimum fault tolerance (i.e. device redundancy) to ensure
that adequate protection is provided. The required fault tolerance is related to the device complexity. It is
important to note that the device’s safe failures tend to drive the process toward the safe state, whereas
the safe failure fraction is based on the safe failures and the dangerous detected failures. Thus, there is

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
an implicit assumption in the safe failure fraction that the requirements of ANSI/ISA-84.00.01-2004-1,
Clause 11.3, are met. Refer to ISA-TR84.00.04-1, Clause K.4, for more information concerning the safe
failure fraction.

NOTE -- When a detected dangerous fault results in the immediate initiation of the safe state action, it is highly reasonable to
consider the dangerous fault to be “safe.” When the diagnostic simply alarms, it is assumed that appropriate action by the operator
can be and will be taken when required, in accordance with the operating procedures developed for compliance with ANSI/ISA-
84.00.01-2004-1, Clauses 11.3 and 16. Otherwise, the safe failure fraction becomes excessively optimistic. The owner/operator
should account for this when developing operating and alarm response procedures. Refer to ISA-TR84.00.04-1, Annex B, for more
guidance on operator response as part of an SIF.

A typical SIF consists of three subsystems: 1) Sensor, 2) Logic Solver, and 3) Final Control Element.
Each SIF subsystem should meet a minimum fault tolerance based on the target SIL. The fault tolerance
requirements establish the need for redundant devices, such as redundant transmitters or redundant
channels.

NOTE -- "Channel" is defined in ANSI/ISA-84.00.01-2004-1, Clause 3.2.4. A channel refers to a subsystem of an SIS. ANSI/ISA-
84.00.01-2004-1, Clauses 3.2.6.1, 3.2.11, 3.2.45, and 3.2.65, provide further clarification of "channel" by using it in other definitions.
The only time it is used in the body of the standard is in the 4th bullet of ANSI/ISA-84.00.01-2004-1, Clause 15.2.4.

The minimum fault tolerance requirements are documented in ANSI/ISA-84.00.01-2004-1, Clause 11.4.
Clause 11.4.2, Table 5, provides the required fault tolerance for PE Logic Solvers. Clause 11.4.4, Table
6, provides the required fault tolerance for Sensors, Final Control Elements, and non-PE Logic Solvers.

To determine the required fault tolerance for PE logic solvers, the SIL of the SIF and the SFF of the PE
logic solver should be determined. The SIL is documented in the Safety Requirement Specification. The
SFF of the PE logic solver is typically determined by a failure mode and effect analysis (FMEA) and is
often supplied by the manufacturer for the specific version being specified.

For sensors, final control elements, and non-PE logic solvers, the minimum fault tolerance is determined
based only upon the SIL of the SIF. Table 6 was developed based on IEC 61508-2 fault tolerance criteria
for PE devices and assumes a SFF between 60% and 90% for any device specified. This assumption
simplified the fault tolerance requirements of IEC 61508-2, allowing the elimination of the distinction
between Type A and Type B devices. This resulted in the fault tolerance tables in ANSI/ISA-84.00.01-
2004-1, Clause 11.4, being more conservative than those in IEC 61508 for some Type A devices. As a

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

result, use of the fault tolerance tables associated with IEC 61508 Type “A” devices may result in a
relaxation of the fault tolerance requirements, if adequate diagnostic coverage is provided.

It may also be able to justify less fault tolerance than required by Table 6, when the dangerous failure
modes of the SIF devices and associated process interfaces are well understood. Clause 11.4.4 states
that if the selection of a device is based on prior use, then, under specific conditions, the fault tolerance
for sensors, final control elements, and non-PE logic solvers can be reduced by 1. The reduction of fault
tolerance is acceptable, since prior use establishes the field application data, which includes the random
hardware failures for the device itself and the random failures due to the process and field device
interfaces.

ANSI/ISA-84.00.01-2004 also recognizes that there are a small number of sensors, final control elements,
and non-PE logic solvers that have a SFF greater than 90% in the field application. Therefore, ANSI/ISA-
84.00.01-2004-1, Clause 11.4.5, allows use of the fault tolerance requirements referenced in IEC 61508-
2, Tables 2 and 3, as an alternative to ANSI/ISA-84.00.01-2004-1 fault tolerance tables. The use of the
IEC 61508-2 tables requires that the SIL of the SIF and SFF of each specified device or subsystem be
evaluated in its intended application environment. This assessment covers a larger boundary, e.g.,
process connections, and more failure modes, e.g., process and environmental-related failures, than is
typically included in the manufacturer’s analysis. Using IEC 61508-2 allows the required fault tolerance to
be reduced by 1 when the specified devices have a SFF > 90% for SIL 2 or SIL 3 SIFs. The IEC 61508
tables can be used to determine the required fault tolerance as long as the SFF is based on the field
application. A similar assessment can be made to determine the required fault tolerance for the PE logic
solver according to ANSI/ISA-84.00.01-2004-1.

For field devices, extreme caution should be used in reducing the minimum fault tolerance from
ANSI/ISA-84.00.01-2004-1, Clause 11.4.4, Table 6. Understanding the dangerous failure modes of the
process interfaces is not trivial, and misapplication could result in the SIF being under-designed for the
SIL target. Owners/operators should be cautious when using manufacturer data to support reduction in
the fault tolerance and should review the assumptions, boundaries, and sources for the data. The
methods used by manufacturers to calculate the device failure rate vary considerably.

For example, some manufacturers use field return data. While field return data may seem to provide a
“field” failure rate, the techniques used by the manufacturer in collecting the data may be poor (e.g., the
manufacturer may not track all shipments to the process industry sector or may not require that all
devices be returned when failed.) Any process used to collect field return data should be documented, so
that an evaluation of its effectiveness can be conducted.

Other manufacturers use predictive models, involving estimated failure rates and assumed failure modes
and distributions. While a mathematical model of the failure rate may appear more rigorous, a number of
assumptions are made during the analysis that may or may not be valid for a particular field application.
The assessment may not include the full device boundary (e.g., the process connection, the sensor,
power supplies) or all components necessary to make a device functional. Further, the mathematical
models often ignore the impact of the process on the device. When calculating the SFF, the device failure
rate in the intended application is used.

K.3 Fault tolerance and common cause failures

Redundant hardware configured in a manner that prevents a single failure from resulting in a system
failure is often used to achieve higher safety integrity. Studies have shown that the performance of fault
tolerant systems is limited by common-cause failures. Modeling has shown that common-cause failures
can dominate the PFDavg calculation. Therefore, designers should be careful to minimize the potential for
common-cause failures. Primary techniques used to achieve this goal are physical separation, hardware

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

redundancy, and administrative diversity. Refer to ISA-TR84.00.04-1, Annex G, for more discussion on
common-cause failure.

K.3.1 Physical separation

When two devices in a fault tolerant subsystem are identical, they likely fail in a similar way when
presented with a stress (electrical surge, RFI, electro-static discharge, mechanical shock and vibration,
chemical corrosives, dirt, etc.) One method used to reduce the chance of common cause failure is to
physically separate the redundant devices to the extent possible. The objective is to reduce the chance of
a common stressor. Both physical separation and electrical separation are important. A weak design is to
implement redundant devices in close proximity on a single I/O board. The physical and electrical
common stress is nearly identical. In such implementations, the potential for common-cause failure is
higher because the chances of a single stressor impacting both are higher. Better design techniques
involve physical separation or other techniques to reduce common stress.

Although physical separation can reduce the effects of common-mode failures, the owner/operator should
also evaluate the likelihood that these common-mode failures occur at the same time. Only simultaneous
common-mode failures are of concern. Typically, electronic component stress results in failures at
different times, often separated in time by months or years. In these situations, the advantages of
physical separation may be outweighed by the economic advantages of installing the redundant hardware
in the same physical location or cabinet.

In assessing overall process risk, it is often more important to ensure separation and diversity between
the BPCS and the SIS than it is to ensure diversity in the selection of SIF devices. The use of diverse SIF
devices can lead to maintenance problems and human error due to the inherent differences between the
diverse parts of the SIF.

K.3.2 Redundancy

Redundancy is often used to achieve the required SIL and fault tolerance. In designing the SIF, the
designer should first determine the redundancy necessary to achieve the SIL and fault tolerance
requirements. Then, the resulting SIF reliability should be compared with process operability goals to
determine if the selected architecture achieves the desired spurious trip rate. As an example, a 1oo2
architecture enhances SIL and provides a fault tolerance of 1, but it provides a lower reliability SIF than a
1oo1 architecture. In such a situation, the designer may choose a 2oo3 architecture, which improves
reliability without substantially reducing SIL.

Redundancy is applicable to both hardware and software. It can be implemented using identical or
diverse devices. When assessing the integrity of an SIF, the potential for common-cause faults should be
considered. Elimination or reduction of the common fault source is a very effective means to reduce the
potential for failure. In addition, diverse redundancy can be employed to reduce the potential for common-
cause faults. Some examples of common-cause faults were given in Annex G.7, such as:

• Environmental, e.g., temperature extremes, humidity, corrosion, EMC, vibration, RFI, electrostatic
discharge, mechanical shock.

• Process physical properties, e.g., temperature, corrosion, plugging, chemical attack.

• Single elements, e.g., common process connections, energy sources.

Redundant devices using different technologies may also decrease common-cause susceptibility if the
redundant units respond differently to a common stress. This can be accomplished by designing
redundant subsystems using “diverse technology.” Many think that using "different manufacturers"
provides diversity. This is not true if both devices respond similarly to the same stress. Diversity works
only if the redundant devices respond differently to a common stress.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Diverse redundancy uses different technology, design, manufacture, software, firmware, etc., to reduce
the influence of common-cause faults. Measures that can be used to achieve diverse redundancy include,
but are not limited to, the use of different measurements (e.g., pressure and temperature) when there is a
known relationship between them and the use of different measurement technologies for the same
process variable (e.g., Coriolis flow and Vortex flow). An example of input diversity is the use of a
Resistance Temperature Detector (RTD), Infrared (IR), or bimetal to achieve technology diversity in
measuring temperature. An example of output diversity is closing a block valve and turning off a pump to
stop flow.

Diverse redundancy should not be used where its application requires the use of low-reliability devices,
resulting in an SIF design that does not meet the reliability requirements. It should also not be used when
the diversity results in the loss of online diagnostics, e.g., use of a switch and a transmitter eliminates the
possibility of performing signal comparison and alarming any deviation. Furthermore, the potential for
increased maintenance error should be considered when applying diversity because the probability of
error may outweigh any theoretical advantages from implementing diverse devices.

K.3.3 Support system requirements

Sometimes SIFs are designed such that support systems or utilities are required for the safe state to be
achieved. Energize-to-trip outputs and air-to-move valves are common examples of SIF implementation
where the dominant failure mode is not to the safe state condition. In these cases, the fault tolerance
requirements provided in ANSI/ISA-84.00.01-2004-1, Clause 11.4.4, is increased by one, unless the
dangerous faults can be detected online and annunciated to the operator while maintaining safe
operation.

The following provides a brief discussion of basic design principles that address the relationship of power
sources to shutdown actions of safety instrumented systems. Some typical support systems include

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
electrical, pneumatics, and hydraulics.

K.3.3.1.1 Support system failure results in safe state

Power Supply. The majority of SIFs are designed to go to the safe state on loss of power. This design
philosophy is known as de-energized to trip (DTT). When DTT is implemented, the SIF device is specified
so that its "shelf" position is the safe state. When power is removed (i.e., de-energized), the SIF device
goes to the safe state.

• When using electro-mechanical relays, shelf-state, normally open contacts are used. Energizing
the relay coil closes the contact, completing the circuit. De-energizing the coil returns the contact
to shelf state breaking the circuit.

• When dealing with instruments, determination of output contact shelf position may be more
difficult. An example of such an application is a contact shown as normally open with a
subscription like "O, C, C, O." This would indicate a normally open contact (shelf position),
contact closes when the instrument is powered up, contact remains closed during in-range
sensing, contact opens on out-of-range sensing (e.g., shutdown).

With DTT, a blown fuse, an open wire, or any power disruption results in a transition of the SIF to the safe
state. Although the SIF is configured to go to the safe state, spurious trips can cause additional safety
and/or economic issues. This can be a major concern for continuous operations, where a spurious trip
can result in a loss of several million dollars and potential safety concerns that always accompany a
shutdown and resulting re-startup. Consequently, it is important when designing a DTT system that power
supply redundancy and battery back-up are provided to minimize the probability of spurious trips. In
addition to implementation of reliable power supply systems, proper maintenance of the power supply

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

system is crucial to ensuring operational reliability. Maintaining power to critical systems allows the
system to sequence through orderly shutdown, reducing the possibility of creating hazardous conditions
or damaging equipment. This also provides the operator an opportunity to monitor the plant and initiate
manual shutdown when there is a general power failure.

DTT can also be applicable to the final elements when the final elements have mechanisms (spring
return) to take the final element to the safe state on loss of supply pressure, typically pneumatic or
hydraulic.

DTT systems can be designed to meet high reliability goals by providing redundancy for power supplies,
inputs, outputs and final elements. For example, consider the following:

• Electrical power sources – Dual 120 VAC, 24 VDC feeds, one plant power and the other
Uninterruptible Power Supply (UPS) with battery backup. Low-voltage alarms should be provided
for each source.

• Field power supplies – Dual 24 VDC power supplies, one fed by plant power and the other fed by
the UPS with battery backup. The outputs from the power supplies are diode OR’ed with the
resulting output powering the field devices. Low-voltage alarms should be provided for each
power supply.

• Inputs – Redundancy, such as 2oo2 and 2oo3, can be employed on the inputs to prevent a
single, safe failure of a device or circuit from causing a spurious shutdown. The inputs can also
be connected to separate input modules on the logic solver to increase reliability even further.

• Outputs – Typically the outputs are either relays (motor controls) or solenoid-operated valves
(SOV). In DTT SIS, the predominant failure mode for these devices is coil ”burnout.”
Redundancy, such as 2oo2 or 2oo3, can be employed on the outputs to prevent a single safe
failure of a device or circuit from causing a spurious shutdown. The outputs can also be
connected to separate output modules on the logic solver to increase reliability even more.

Pneumatic supply. Since the loss of air supply can result in the final element moving to the safe state,
these systems should be evaluated with the same scrutiny as power for electrical devices. Redundancy of
air supply (bottle or backup compressors), diversity in air compressor drivers (steam/electric), air
accumulators, and low-pressure alarms can be used to increase air supply integrity.

Hydraulic supply. Since the loss of hydraulic supply can result in the final element moving to the safe
state, these systems should be evaluated with the same scrutiny as power for electrical devices.
Redundancy of hydraulic supply pumps, hydraulic accumulators, and low-pressure alarms can be used to
increase hydraulic supply integrity.

K.3.3.2. Support system failure results in dangerous state

Power Supply. An energize-to-trip (ETT) design means that power is required for the SIF to achieve the
safe state. ETT was predominantly implemented in the past to overcome poor reliability of the main power
supply system. When de-energize-to-trip is used with no alternate power source (e.g., uninterruptible
power supply), a dip in power results in the process going to the safe state. This causes major financial
loss and potential safety concerns that normally accompany a process trip and restart. To overcome poor
power supply reliability, some facilities chose to implement ETT in order to maintain process reliability.
These circuits have the inherent advantage that a loss of power does not result in a spurious trip, hence
improved process uptime can be achieved. The disadvantage is that power is required to safely shutdown
the process, so loss of power presents the potential for a failure to trip on demand situation.

NOTE -- For economic protection applications, ETT is often used on rotating machinery (e.g. compressors) where the
consequences of a spurious trip can have serious financial considerations and where there is no risk of loss of containment due to

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

failure to trip on demand events. Analysis should be performed to determine that a loss of power does not directly result in a process
hazard, placing a demand on the SIS.

ETT can also be applicable to the final elements when the final elements require air or hydraulic pressure
to move to the safe state (e.g., double-acting actuators). These devices do not have spring-return
mechanisms to take the final element to the safe state on loss of supply pressure, typically pneumatic or
hydraulic.

ETT systems should be designed to ensure that power is available, and the circuits to the field devices
(inputs/outputs) are intact. Typically, diagnostics, such as end-of-line detection to verify loop continuity,
backup power, such as batteries, and power monitoring with low-/no-voltage alarms are implemented to
ensure power availability when needed for shutdown purposes. It is also very important that these backup
power systems be designed to allow periodic testing to ensure they perform when called upon.

Key issues for ETT systems include:

• Power source redundancy from main feed through field device power supplies. Each source
should be monitored separately and initiate alarms to operations.

• Battery backup should be designed to allow adequate time for an orderly and complete shutdown.

• The load bearing capability of the battery backup should be tested as part of the periodic
maintenance routine. Voltage-level monitoring and testing may not identify a loss of load-bearing
capability.

• End-of-line monitoring should be provided for all discrete inputs and outputs.

• End-of-line monitoring does not identify all potential faults or weaknesses in the circuits. For
example, a weak fuse or coil may not be detected by end-of-line monitoring and could “burn” on
application of full current. For this reason, detailed inspection of ETT systems should be
performed to ensure that wiring and fuses are well maintained, and these systems may require
more frequent full-functional tests. Input/output redundancy can be implemented to allow online
proof testing. For example, 2oo2 solenoid-operated valves (SOV) can be energized one at a time
without actuating the process valve, providing a full-functional test of the electrical system (output
module, fuse, wiring and the SOV).

• When fire survivability is a concern, wiring to/from redundant devices should be provided through
diverse routes. Additionally, there may be requirements for fire protection for wiring and junction
boxes.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
• A hazard and risk analysis should be performed to determine that a loss of power does not create
a hazardous condition that directly results in a demand on the SIS. If loss of power places a
demand on the SIS, a procedure should be provided that outlines the appropriate operator
response to be taken on loss of power.

NOTE -- If the hazard and risk analysis shows that loss of power can be an initiating cause for the process hazard, the use of an
ETT SIF would result in a potential common-cause failure (i.e. loss of power results in the initiating cause and the failure of the SIF).
In this scenario, a means of achieving the safe state in the absence of power should be provided.

• Examine the safety manual associated with any SIF devices. Many SIF devices are not assessed
for use in an ETT service.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• Always combine prior use with quantification techniques in assessing the adequacy of the power
sources and/or power supplies.

• When quantitatively verifying a DTT system, the power is not considered in the PFDavg for the
SIS. For ETT systems the power is a direct contributor to the PFDavg and should be considered in
the PFDavg calculations.

Obviously whether the SIF is energized or de-energized to trip, an awareness of each scheme’s unique
attributes and limitations are needed to select a design most appropriate for the SIS.

Pneumatic supply. Pneumatic supply is typically considered when an air-to-move final element is used
(double-acting actuators). Since the movement of the final element is dependent upon air availability
these systems should be evaluated with the same scrutiny as power for electrical devices. Redundancy of
air supply (bottle or backup compressors), diversity in air compressor drivers (steam/electric), air
accumulators and low-pressure alarms can be used to increase air supply integrity.

Hydraulic supply. Hydraulic supply is typically considered when a pressure-to-move final element is
used (double-acting actuators). Since the movement of the final element is dependent upon hydraulic
pressure availability, these systems should be evaluated with the same scrutiny as power for electrical
devices. Redundancy of hydraulic supply, hydraulic accumulators, and low-pressure alarms can be used
to increase air supply integrity.

K.3.4 Administrative diversity

Administrative diversity may also be used to help reduce the potential for common-mode failure. This
involves the development and implementation of procedures that facilitate opportunities to recover from
mistakes in design, operation, and/or maintenance. Examples may include, but are certainly not limited
to, periodic audits of work process effectiveness, inspections, and tests performed by multiple individuals
on a rolling basis rather than the same person all the time, etc.

K.4 Safe failure fraction

The fault tolerance requirement for PE logic solvers is based on the SIL and the SFF. ANSI/ISA-84.00.01-
2004-1 uses the following definitions:

Safe Failure – Failure that does not have the potential to put the safety instrumented system in a
hazardous or fail-to-function state

Safe-Failure Fraction – The fraction of the overall random hardware failure rate of a device that results in
either a safe failure or a detected dangerous failure.

In other words, the safe-failure fraction is a measure that indicates the probability of a subsystem failure
being either safe or detected by diagnostics. The measure is applied to each major subsystem in a safety --``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

instrumented function (sensor, logic solver, final element) separately.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

The safe-failure fraction can be defined mathematically as:

λSD + λSU + λ DD
SFF = SD
λ + λSU + λ DD + λ DU
Where

λ = λS + λD , where λ is the failure rate, s is safe, d is dangerous

λSD = DC S * λS , where DCS is the diagnostic coverage for safe failures, λSD is the safe detected failure

λSU = (1− DC S )* λS , where λ

SU
is the safe undetected failure

λ DD = DC D * λ D , where λ
DD D
is the dangerous detected failure, DC is the diagnostic coverage for
dangerous failure

λDU = (1− DC D )* λD , where λ

DU
is the dangerous undetected failure

It should be noted that the safe failure fraction is a ratio of failure rates. It is a measurement that does not
depend on the total failure rate. A device can have a high total failure rate, and as long as the failures are
safe or detected, the SFF is also high. This means that a device can have a high SFF and be highly
unreliable. Process users need reliable equipment to ensure safe operation. Possessing a high SFF does
not necessarily mean that the device performance is adequate for safety service. Refer to Annex L for

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
guidance on user approval of SIF devices.

If a variable “%Safe” is defined as:

λS
% Safe =
λS + λD
then the SFF can be expressed as:

SFF = % Safe + (1 − % Safe )* DC D

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Annex L – Device selection

NOTE -- Annex L is referenced in the following: Clause 2, Clause 4.3, and Annex F.3

L.1 Purpose

ANSI/ISA-84.00.01-2004-1, Clause 11.5, addresses the requirements for SIF device selection. The
standard lists two forms of evidence used to justify device selection:

• Designed in accordance with IEC 61508-2 and IEC 61508-3

• “Prior use” evidence in accordance with ANSI/ISA-84.00.01-2004-1, Clauses 11.4 and 11.5.3
through 11.5.6

NOTE -- “Prior use” is a process industry sector term that is used in lieu of the IEC 61508 term “proven-in-use.” The intent is that the
user should have knowledge through prior use that the selected device can operate as required and can support the SIF SIL in the
intended operating environment.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
The purpose of this annex is to provide guidance on:

• The work processes used to select devices (sensors, logic solvers, control elements)

• The relationship between the two forms of evidence noted above

• The impact of software language used on the device selection process

• How to gather and evaluate “Prior Use” information

• Additional SIL claim limit considerations

L.2 Scope

ANSI/ISA-84.00.01-2004-1, Figure 3, defines the relationship between ANSI/ISA-84.00.01-2004-1 and

IEC 61508. The development of hardware devices, embedded software, and application programs using
full variability language are not addressed by the requirements of ANSI/ISA-84.00.01-2004-1 and are
instead referenced in IEC 61508-1 and IEC 61508-2.

ANSI/ISA-84.00.01-2004-1 defines the requirements for the selection and implementation of SIF devices.
This annex will provide guidance related to the:

• Selection of SIF devices (sensors, logic solvers, final elements) per the requirements of
ANSI/ISA-84.00.01-2004-1, Clause 11.5

• Basis and methods that establish “Prior Use” as described in ANSI/ISA-84.00.01-2004-1 Clause
11.4 and 11.5.3 through 11.5.6

This annex will not provide separate guidance for the selection of embedded and utility software.
Owners/operators should approve configuration interfaces, operating systems, and programming
software in conjunction with the hardware since the proper selection of a complex system, such as a PE
logic solver, requires consideration of the interconnection, integration, and interaction of the software and
the hardware.

Guidance is not provided in this annex on the development of application programs using limited
variability, and implementation of devices using fixed programming as described in ANSI/ISA-84.00.01-
2004-1, Clause 12. Additional guidance on these topics is provided in ANSI/ISA-TR 84.00.04-1, Annex O.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

This annex will also not provide guidance for manufacturers or manufacturers that want to make claims
regarding the use of their device to implement a SIF. ANSI/ISA-84.00.01-2004-1, Clause 1 and Figure 3,
both reference IEC 61508-1 and IEC 61508-2 for these requirements. ANSI/ISA-84.00.01-2004-1, Clause
1, states the standard is intended for use under the following conditions:

“(b) applies when the equipment that meets the requirements of IEC 61508, or ANSI/ISA-
84.00.01-2004-1, Clause 11.5, are integrated into an overall system that is to be used for a
process sector application; does not apply to manufacturers wishing to claim that devices are
suitable for use in safety instrumented systems for the process sector (see IEC 61508-2 and IEC
61508-3).”
“(d) applies when application software is developed for system sharing limited variability or fixed
programs; does not apply to manufacturers, safety instrumented system designers, integrators,
and users that develop embedded software (system software) or use full variability languages

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
(see IEC 61508-3).”
L.3 Terminology

The terminology utilized in this annex is taken from existing functional safety standards (e.g., IEC 61508,
ANSI/ISA-84.01-1996, ANSI/ISA-84.00.01-2004). However, the context and meaning of these terms vary
slightly depending on which functional safety standard is referenced. As a result, it is essential that key
terms be clearly defined in the context of this annex.

• “Alpha test” is defined as the first functional test of a device and is the responsibility of the
manufacturer to define and complete. Alpha tests generally include one or more owner/operator
test sites, or include simulated end-user testing completed by the manufacturer or an
independent test laboratory. If problems occur during Alpha test(s), the equipment or installation
is modified followed by a repeat of the alpha test(s) until test requirements are satisfied.

• “Beta tests” are conducted after successful completion of Alpha tests. Generally, multiple test
sites are established. The manufacturer selects owners/operators with an inherent interest and
need for the equipment under test. The feedback from these owners/operators is focused on its
performance and the availability of manufacturer support for the equipment. Beta test operation
provides the manufacturer with enough information to proceed with commercial production (e.g.,
final product realization). This includes product specifications, installation, and operation manual
directions, installation details, and any other requirements for successful operation.

• “IEC 61508 Certification” is defined as the analysis of a device design, manufacture and
documentation, including hardware, software and overall system operation, which confirms the
device conforms to the requirements detailed in IEC 61508-2 and IEC 61508-3 for a specific SIL
claim limit. ANSI/ISA-84.00.01-2004-1 and IEC 61508-1 do not specify how this analysis is to be
completed. The standards also do not specify the requirements of the assessment process or
competencies of the assessor. Therefore manufacturers and manufacturers of devices may
complete IEC 61508 Certification analysis (self-certify), may select an independent third party, or
may choose an approved and recognized laboratory to complete this analysis.

Local jurisdictional authorities may have specific requirements or registrations necessary to be

considered an approved and recognized laboratory for certifying safety equipment. In the US, OSHA has
a specific program (http://www.osha.gov/dts/otpca/nrtl/) to become a Nationally Recognized Testing
Laboratory (NRTL), while ISA has a program administered by the Automation Standards Compliance
Institute (ASCI) Chartered Test Laboratories (ACTL). In general, laboratories provide a broad range of
certification services, such as hazardous area classification, intrinsically safe, and explosionproof
requirements. The owner/operator is cautioned that being a recognized laboratory does not necessarily
mean that the laboratory is competent to certify equipment in accordance with IEC 61508.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Since there is no standard methodology for IEC 61508 certification, a detailed review of any certification
claim should be completed by the user. It is recommended that the certification report be used in
conjunction with actual operating experience before final selection of SIF devices.

• “IEC 61508 Compliant” is defined as the analysis of a device based upon the actual use and
testing completed by the manufacturers and/or owners/operators. This analysis may include the
output from Failure Mode Effect Analysis (FMEA), circuit analysis, unsafe failure mode analysis,
fault insertion testing results, and detailed analysis of embedded software and diagnostics. IEC
61508 Compliant does not require a formal review of the device design per IEC 61508-2 and IEC
61508-3 but instead relies on information obtained from actual users’ operating experience,
manufactures’ experience, and other process sector data sources. Similar to IEC 61508
Certification, the standards do not detail how an IEC 61508 Compliant assessment should be
completed.

Since there is no standard methodology for assessing IEC 61508 compliance, a detailed review of any
compliance claim should be completed by the user. It is recommended that the compliance report be
used in conjunction with actual operating experience before final selection of SIF devices.

• “Prior use” is defined as the selection of a device based upon actual operating experience. Prior
use analysis should use the operating data for the device under selection and meet the
requirements of ANSI/IS 84.00.01-2004-1 Clauses 11.4 and 11.5.3 through 11.5.6.

NOTE -- ANSI/ISA-84.00.01-2004-1 refers to “proven in use” (PIU) at times in lieu of consistently using the term “prior use.” In each
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

of these cases, “PIU” should be interpreted as “prior use” unless the PIU term is used with a specific reference to IEC 61508.

“Operating experience” relates to the amount of successful field application experience that a device
requires prior to being user-approved for the installation. The amount of experience necessary to approve
a device varies based on the quality and breadth of the IEC 61508 analysis, the ANSI/ISA-84.00.01-2004-
1 prior use information, the SIL claim limit (or SIL Capability), and the manufacturer’s recommendations.

• “Proven in use” (PIU) refers to the requirements defined in IEC 61508-2 Clause 7.4.7.

• “SIL claim limit” refers to the integrity that can be achieved by an individual device due to its
compliance with the IEC 61508 lifecycle, its PFDavg or frequency of failure, and the level of design
requirements met per IEC 61508-2 and IEC 61508-3. IEC 61508-2 and IEC 61508-3 reference
different design requirements based upon the SIL claim limit the device is to achieve, where SIL 1
claim limits have the minimum number of requirements and SIL 3 claim limits have higher
requirements. Second, how the device is used and the intervals between proof tests may also
impact the SIL claim limit allowed. The safety manual should reference any restrictions on the use
of the device, which include details related to its configuration, interfaces, installation, diagnostics,
mean time to repair, fault response, and proof testing interval. For the SIL claim limit to be valid,
the device should be implemented in accordance with its safety manual, unless further analysis
has been conducted to justify the deviation.

NOTE -- 1 The above definition of SIL claim limit may differ from other industry standards, such as IEC 62061 to reflect differences
in process sector terminology.

NOTE -- 2 A device does not have an SIL, since SIL is a quantitative measure of the performance of the overall SIF. IEC 61508
expands the use of the SIL terminology to device design requirements documented in IEC 61508-2 and IEC 61508-3. Therefore, a
“SIL 3 device” means that the device has either completed an evaluation that the device design meets the requirements of IEC
61508-2 and IEC 61508-3 to the SIL 3 requirements and/or has been analyzed to these same requirements through prior use or IEC
61508 Compliance assessments. Since a SIL claim limit can be achieved through different methods and may have many restrictions
for use, always ask the manufacturer of a device how the claim limit was achieved and any restrictions for use that may apply.

NOTE -- 3 When using a “SIL claim limit” to infer a device PFDavg (assumes no data is available), it is recommended to use the
conservative value of the SIL range for the device PFDavg. For example, for a “SIL 3 claim limit” device, the PFDavg range is 10-3
through 10-4. The conservative value (10-3) should be used unless more precise data is available. Manufacturers will typically

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

document the PFDavg for a device in accordance with the safety manual. It is important to ensure that the PFDavg used represents
the failure of the device in the actual operating environment in which the device is to be used.

L.4 Device selection process

Device selection is a process to evaluate several parameters to ensure the device meets the safety
requirements of the SIF. The process should include the identification of the target SIL, the device
technology required to execute the safety function, whether the device is a PE or non-PE device, and if
PE, what type of programming language is used. A typical process is illustrated in Figure L.1.

ANSI/ISA-84.00.01-2004-1 is the standard for SIF of SIL 3 or less. If you have a SIL 4 SIF, ANSI/ISA-
84.00.01-2004-1 does not apply, and one must follow the lifecycle requirements of IEC 61508.

ANSIISA-84.00.01-2004-1 allows owners/operators to select SIF devices that are compliant with IEC
61508-2 and IEC 61508-3 or demonstrated through prior use that the device can operate as required and
support the target SIL. There are no limits to the application of devices designed per IEC 61508, but the
standard does limit prior use justification for PE logic solvers using limited variability software language.
While prior use may be applied to PE logic solvers, using limited variability software language for claim
limits equal to or less than SIL 2, it is not appropriate for SIL 3 claim limits. This limitation is in place to
recognize the potential for systematic dangerous failures. PE sensors and control elements that are
supplied with fixed programming language cannot be modified by the user. Logic solvers (and any other
device) may be supplied with limited variability or application-specific programming language. Due to
potential systematic failures that cannot be detected, the standard requires that for SIL 3 SIFs, PE logic
solvers must be designed per IEC 61508-2 and IEC 61508-3.

ANSI/ISA-84.00.01-2004-1 assumes that the owner/operator has considered and addressed the
application requirements for the device. These are typically the same type of requirements considered for
BPCS performance. These may include the technology required to detect the process conditions, to make
decisions on the actions to take, and to take action on the process, the correct measurement or control
ranges, the materials of construction necessary for the environment and process conditions, and the
correct installation practices. The device safety manual may outline different requirements based upon
the SIL claim limit, and these must be followed.

L.5 IEC 61508 compliance

IEC 61508 is the generic functional safety standard covering the lifecycle of safety-related systems in a
wide variety of industrial sectors (e.g., process, rail, machinery, medical) and serves as the basis for
manufacturers when developing devices to be used by any sector for a safety-related application. It is
also the framework for the sector standards and provides the essential requirements necessary to
achieve functional safety.

ANSI/ISA-84.00.01-2004-1 is the process industry sector standard developed according to the IEC 61508
framework and is the USA implementation of IEC 61511-1 (IEC process sector standard). To understand
the relationship of IEC 61508 to ANSI/ISA-84.00.01-2004-1 review ANSI/ISA-84.00.01-2004-1 Figures 2
and 3.

IEC 61508 addresses safety-related systems, including devices used to implement SIF. IEC 61508-2
provides hardware and system requirements for device design, while IEC 61508-3 provides software
requirements for device design. For each section, there are different levels of requirements based upon
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

the claim limit the device is to achieve. When a manufacturer wishes to claim that a device can be used in
an SIF application with a specific SIL claim limit (or SIL capability limit), the device should be designed to
meet the requirements of IEC 61508 Parts 2 and 3 for that specific claim limit.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Figure L.1 — Work process for selecting devices

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

L.5.1 Benefits of IEC 61508 certified devices

ANSI/ISA-84.00.01-2004-1 recognizes that there are potential advantages in selecting an SIF device that
has been designed in compliance with the requirements of IEC 61508-2 and IEC 61508-3. Using such
devices assures the owner/operator of the following:

• The manufacturer has used the safety lifecycle approach to the device design and configuration
management

• The device hardware design meets the requirements of IEC 61508-2 for the specified SIL claim
limit

• The device embedded software meets the requirements documented in IEC 61508-3 for the
specified claim limit

• The manufacturer supplies a Safety Manual providing criteria for the proper use of the device in
an SIS application

• The manufacturer’s engineering and manufacturing processes use good quality management
system practices (example: ISO 9001:2008) for hardware and software development, verification
and validation to requirements, configuration management, and a management of change
process is in place

• A process exists at the manufacturer to ensure that all major changes to the device design are
properly managed through the lifecycle process and these changes are evaluated against the
original safety requirements. Any changes to the original certification are communicated to the

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
owners/operators

• A documented assessment process is used to verify IEC 61508 requirements are met

• An assessment has been completed documenting the device random hardware failure rates
using Failure Mode Effect Analysis (FMEA). The results are documented and available to
owners/operators in the following format:

1) Safe and dangerous failure classifications and rates of the device

2) Specific response of the device in the detection of a fault

3) Any special requirements such as those required to properly detect and respond to a fault
condition

The random hardware failure results are also used to calculate the Safe Failure Fraction (SFF) of the
device and the PFDavg or Frequency of Failure for continuous-mode devices. The PFDavg provided by the
manufacturer is based upon specific proof-test intervals and the mean time to repair specified by the
manufacturer. For different assumptions, the user can use the fundamental failure rates provided and
determine a PFDavg for their specific application. Details on SFF and PFDavg are included in Annex K.

This information provides a major benefit to owners/operators, especially for PE logic solvers and PE field
devices, where the FMEA can be very complicated, and embedded software could include potential
systematic dangerous failure conditions.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

It is important to understand that the FMEA results typically only include random hardware failures and do
not include systematic errors. Owners/operators must account for systematic failures for the integrated
SIF, consisting of sensor(s), logic solver, and final element(s). The device manufacturer will address
systematic errors by following IEC 61508, Parts 2 and 3, for the specific claim limit. Owners/operators
should address reducing systematic error potential through using the ANSI/ISA-84.00.01-2004 lifecycle
and implementing techniques outlined in Annex K that may include additional fault tolerance, independent
means, and more frequent inspection and proof testing.

L.5.2 Limitations of IEC 61508 certified and compliant devices

Devices with an IEC 61508 claim limit have value for owners/operators in ensuring safety requirements
are documented and satisfied by the manufacturer. However, an IEC 61508 SIL claim limit does not
necessarily imply the device is reliable or has documented any actual usage in process sector
applications. IEC 61508 claim limits can be obtained through analysis and assessment techniques only,
and since no field experience is required to make a claim limit or obtain certification, owners/operators
should use caution when specifying such devices for SIS applications unless the reliability of the device in
actual operating conditions are known.

NOTE -- Manufacturers are using a variety of terms to indicate the ability of devices to achieve a particular SIL. They may refer to a
device as “suitable for use in an SIL X application,” “fit for use in an SIL X application,” “SIL qualified,” or “SIL rated.” In these cases,
additional review is often required to define the SIL claim limit because these terms are not used by the standard and, therefore, do
not have a consensus definition.

A second limitation relates to the boundary of coverage of failure modes covered by the IEC 61508
certification. The FMEA used to determine the device failure rates for an IEC 61508 SIL claim limit device
is limited to the device boundary only and will typically not include potential dangerous failure modes of
the process interfaces, installation parameters, power supplies, or communication interfaces. Failures
associated with the process interfaces are very prominent in sensors, including plugged process lines,
frozen lines, corrosion and gas permeation, and in valves, including seat damage, plugging, deposition,
corrosion, and stem buildup.

NOTE -- Regardless of the device selection method, there may be substantial requirements for the proper implementation of a
device, as documented in the installation, operation, maintenance, and safety manual(s).

Consequently, establishing an IEC 61508 claim limit should be viewed as the first step in compiling the
evidence for proper device selection. For field devices, understanding how the device operates in the
proposed process application is critical to safe and reliable operation of the SIS. To obtain evidence, the
owners/operators should assess the field installation and operating environment including the process
interface, installation, power supply, and communication interface. Obtaining field history that the device
performance in the operating environment is understood will assist with specifying the fault tolerance and
proof-test intervals. Historical device field history can be obtained via many methods, including historical
data of similar devices from the same manufacturer in BPCS applications, work order history, evaluation
of inspection/proof-test data, etc. In addition to these techniques, using data from previous versions of the
device can be useful. For the PE logic solver, an IEC 61508 evaluation is generally recommended due to
the complexity of the analysis of the hardware and software. For SIL 3 SIF, ANSI/ISA-84.00.01-2004-1
requires that the device be designed per IEC 61508-2 and IEC 61508-3.

DUE TO ITS INHERENT LIMITATIONS, THE BEST PRACTICE IS TO SUPPLEMENT ANY IEC 61508
CLAIM INFORMATION WITH ACTUAL FIELD EXPERIENCE.

Finally, when designing the SIS, the owner/operator needs to be aware that ANSI/ISA-84.00.01-2004-1
addresses the safety lifecycle requirements for SIS and will not cover basic engineering practices used
for process sector instrumentation and controls. Both standards assume that designers are using good
engineering practice for the design and selection of SIS devices. This is especially critical for the selection
of sensors and final control elements. One must ensure the right sensor technology is specified that can
measure the process condition and the right final elements that can take action as required. For example,
the block valve is often the most critical element in any SIF. Yet a significant design attribute for the block

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

valve, the ratio of available actuator power to required actuator power, is not addressed in either IEC
61508 or ANSI/ISA-84.00.01-2004-1. Therefore, strict adherence to these standards is not a substitute for
good engineering design practice.

L.6 ANSI/ISA-84.00.01-2004 prior use assessment

Devices used in SIF may be non-PE (e.g., mechanical switch) or PE (e.g., electronic pressure transmitter
or a PLC type logic solver). PE devices may also include software as part of their design. Devices can be
designed with fixed programming language (FPL), software that cannot be modified by the end user, or
limited variability programming language (LVL) that is modified by the end user. Since software always
has the potential for systematic faults, which may in some cases result in dangerous faults, ANSI/ISA-
84.00.01-2004-1 documents additional requirements for prior use justification based upon the target SIL
level and the type of programming language used by the device.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
The device selection process in ANSI/ISA-84.00.01-2004 Clause 11.5 is illustrated in Figure L.1. This
process defines when prior-use information is considered sufficient to justify use of a device in an SIF
application and no claim limit per IEC 61508 is required. The prior use evaluation fulfills specific
requirements in ANSI/ISA-84.00.01-2004-1, Clauses 11.4 and 11.5.3 through 11.5.6. The methodologies
and approaches for prior-use justification may vary, depending on the device type (e.g. programmable
versus non-programmable, field device versus PE logic solver), the device’s installed base, and the
owners/operators’ experience with the device.

If the device is PE, additional evidence is necessary, depending on whether the device is an FPL or LVL
device. FVL devices cannot be selected based on ANSI/ISA-84.00.01-2004-1 review only; evidence of
compliance to IEC 61508-2 and 61508-3 must also be provided.

The performance of an SIF device is generally evaluated based on information gathered during alpha and
beta testing, formal compliance assessment, and field operation. Manufacturers supply this information
on request in the form of test results, assessment reports, and user references. An owner/operator may
accept the manufacturer’s information or may supplement this initial information (e.g. alpha, beta, and
operating experience) with further device analysis. This analysis may include bench or field testing,
operation in control applications, failure tracking and analysis, and/or maintenance record review. The
prior use evaluation may also include quantitative analysis of the device PFDavg in actual field installation.
ANSI/ISA-84.00.01-2004-2, Clause 11.5.3, provides guidance concerning the use of an approved
manufacturer’s list.

Prior-use evaluation involves gathering information concerning the device performance in similar
applications that the device is planned for use. This information should be documented and updated over
time as additional field performance data is gathered. Prior use demonstrates the functionality and
integrity of the installed device, including the process interfaces, full device boundary, communications,
and utilities. As a general rule of thumb, the failure rate of a device is estimated based on devices
operating in similar application environments, where the operating experience is sufficient to demonstrate
the claimed mean time to failure on a statistical basis to a single-sided, lower confidence limit of at least
70% (ANSI/ISA-84.00.01-2004-1, Clause 11.9.2 Note).

Owners/operators and manufacturers may adopt internal notification practices to assist in the collection
and distribution of prior-use information. For example, an owner/operator or manufacturer may utilize
email, memorandums, or “technical alert systems” to flag problems relating to use of a specific device in
either a BPCS or SIS application. This alerts personnel assigned responsibility for the SIS to problems
relating to the use of specific devices in critical applications.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

L.6.1 Benefits of ANSI/ISA-84.00.01-2004 prior-use assessment

First, prior use has significant benefits for owners/operators since the device operation and reliability are
known through actual historical use in process sector applications. Second, prior use also includes the
operational history of the device interfaces, closing a significant gap in the evaluation and assessment of
IEC 61508 claim limit devices. Operating experience provides significant benefit for selection of field
devices; it establishes the performance of the device in the actual application environment. This ensures
that the integrity and reliability assessments, including failure modes and effects analysis, are consistent
with the field application. Thus, the prior-use evaluation yields a sound rational basis for the selection of
the devices in similar services.

Typically, prior use is established through good operating experience by the owner/operator, licensor, or
engineering contractor. However, it is ultimately the responsibility of the owner/operator to confirm that
the ANSI/ISA-84.00.01-2004-1 prior-use approach is valid for the proposed application.

L.6.2 Limitations of ANSI/ISA-84.00.01-2004 prior-use assessment

The largest limitation of prior-use justification is establishing the collection, recording, and analysis of
operating history for a device. Proof-test documentation, diagnostic alarm records, and process demand
event records can supply the needed information for assessment of the probability of failure on demand
(see ISA-TR84.00.02). The primary challenge for establishing operating experience is that maintenance
records often do not include the information needed to determine the failure mode, or even that the prior
use of the device was in an appropriately similar operating profile.

Another challenge is the continual effort necessary to track changes to the device, so that it can be
determined when prior-use evidence is no longer applicable. An owner/operator may only have a limited
number of devices in a specific application, which prevents the calculation of any statistically viable failure
rates. This is why it is important for owners/operators to participate in industry organizations, such as
OREDA, NAMUR, and CCPS Process Equipment Reliability Database (PERD).

Manufacturers make changes frequently to devices due to component obsolescence, improvements, and
added features. In some cases, these changes are significant enough that historical prior-use evidence is
no longer applicable. Even minor changes can have a drastic impact on the functionality of a device if the
manufacturer decides to change (or even update) the compiler or linker of the embedded software.
Therefore, when prior-use justification is used as the basis for the selection of a SIF device,
owners/operators must have a process in place to obtain the necessary operating history and develop a
process for management of change.

L.6.3 Non-PE devices and PE devices using Fixed Programming Language (FPL)

When selecting devices for a SIF, one must understand the device design for correct application of
ANSI/ISA-84.00.01-2004-1 requirements. Devices used on SIF may be non-PE (e.g., mechanical switch)
or PE (e.g., electronic pressure transmitter or a PLC-type logic solver). PE devices may also include
software as part of their design. Devices can be designed with fixed programming language (FPL),
software that cannot be modified by the end user, or limited variability programming language (LVL) that
is modified by the end user, since software always has the potential for systematic faults, which may in
some cases be dangerous faults. ANSI/ISA-84.00.01-2004-1 documents additional requirements for prior-
use justification based upon the target SIL and the type of programming language used by the device.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

ANSI/ISA-84.00.01-2004-1 allows prior-use justification of non-PE devices and PE devices, using FPL
(e.g. a SMART Transmitter), when the SIL claim limit is less than 4 (i.e., SIL 4 claim limit per ANSI/ISA-
84.00.01-2004-1 is not allowed). If an SIL 3 claim limit is required, formal assessment should be
performed as part of the prior use evaluation, and a safety manual should be prepared based on the
results of the assessment. ANSI/ISA-84.00.01-2004-1, Clause 11.5.4, provides the requirements for

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

applying prior use to the selection of these devices. ANSI/ISA-84.00.01-2004-2 Clause 11.5 provides
guidance on the prior-use evaluation.

For non-PE devices, software is not used to execute the SIF, so the prior-use evaluation focuses on
verifying the functionality and integrity of the hardware in its application environment. It is also important
to monitor for changes in the hardware that could impact functionality and integrity.

In implementing prior use for PE devices using FPL, changes to the embedded software should also be
considered due to concerns over the management, verification, and validation of the software
modification. For example, consider Brand X transmitter that has been used at the particular site for 8
years. Plant experience has shown that nearly every time this transmitter is re-ordered; the transmitter
has a new software version. An evaluation of the changes made to the transmitter should be performed to
ensure that the new software version has been adequately tested and that the modification does not
impact the functionality or integrity of the SIF. Further, write-protect strategies should be implemented
such that one cannot inadvertently change device parameters that could impact execution of the SIF.

L.6.4 PE Devices using Limited Variability Language

ANSI/ISA-84.00.01-2004-1 allows the justification of the use of PE devices using LVL, such as PE logic
solvers, when the SIL claim limit is less than SIL 3 (i.e., SIL 3 claim limit based upon prior use alone is not
allowed). Prior use has been successfully applied to PE logic solvers for many years, relying on

• development of prior-use data (ANSI/ISA-84.00.01-2004-1 Clause 11.5);

• determination of unsafe failure modes (e.g., using FMEA); and

• safety configuration (ANSI/ISA-84.00.01-2004-1, Clause 11.5.5.5) of the device to address the

unsafe failure modes.

Prior to the release of IEC 61508, PE logic solvers used in safety instrumented system applications were
often certified for compliance with the German standard DIN VDE 0801. These PE logic solvers were
rated based on “AK Classes 1 through 6.” These certifications can be considered in the evaluation of the
acceptability of the use of the PE logic solver in an SIS application, however owners/operators should
note that the current recognized standard for PE devices (sensors, logic solvers, and control elements) is
IEC 61508.

Prior use may play a significant role when modifying, maintaining, and “grandfathering” existing PE logic
solvers. However, it is rarely enough to determine adequacy of a PE logic solver due to the following:

• Typically impractical due to the complexity of the analysis required to identify potential failure
modes and effects

• Complicated by the rapid technology changes, which leads to a low-installed base of any one
particular version, making the development of prior-use history difficult (unless the owner/operator
limits technology changes)

L.7 Optimal approach to device selection “user approved”

ANSI/ISA-84.00.01-2004-1 allows two approaches for the selection of SIF devices: designed per IEC
61508-2 and IEC 61508-3 or through prior use justification. There are benefits and limitations to both
approaches. The optimal approach is to ensure the selected device meets both safety and reliability
requirements, especially for sensors and final control elements. This can be obtained by combining the

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

two approaches as appropriate for the device technology to ensure that selected devices operate as
required and support the SIF SIL in the intended operating environment.

ANSI/ISA-84.01-1996 recognized that it was necessary for owners/operators to determine whether an SIF
device worked in the process application. ANSI/ISA-84.01-1996 referred to this as “user approved.” The
1996 standard defined “user approved” as “hardware, software, procedures, etc., that the user has
evaluated and determined to be acceptable for the application.” ANSI/ISA-84.00.01-2004-1 also
recognizes that owners/operators need to evaluate expected field performance when selecting SIF
devices because many field devices are not designed in compliance with IEC 61508-2 and IEC 61508-3.
In the ANSI/ISA-84.00.01-2004-1 standard, this concept is referred to as “prior use.”

What has changed since the ANSI/ISA-84.01-1996 standard is that SIF devices have become much more
complex, using embedded software, more complex application circuits, and extended use of limited
variability programming for PE logic solvers. Manufacturers also now revise devices more often to add
features and address component obsolescence. Therefore owners/operators need the assistance of
manufacturers to develop devices that meet safety requirements and have management-of-change
processes in place. These attributes are the center piece of IEC 61508 compliance.

The optimal approach to select devices is to collect information regarding field experience and the
device’s compliance to specific IEC 61508 requirements. For example, a manufacturer may provide a
failure-modes-and-effects analysis for the device based on IEC 61508 criteria. This analysis may include
the failure-modes listing, failure rate, and diagnostic coverage assumptions for the device as
manufactured.

As discussed previously, these evaluations often do not include the failures associated with the process
or installation, so it is important to look carefully at the defined device boundary and the assumptions with
regard to the assessment. These evaluations also do not cover the potential systematic failures related to
application software design or the quality of installation design practices.

The manufacturer’s analysis is then balanced with field history in similar applications to obtain a better
understanding of potential device performance. Prior use is established for each selected device (e.g.,
Brand X pressure transmitter) in its operating profile, which includes examination of process,
environmental, and field installation conditions that may affect the device’s operation. Prior use requires
review of the manufacturer’s design and development processes to ensure the required level of quality
control. Further, any data used to justify prior use should be carefully assessed to ensure it adequately
represents the device in the operating profile.

The extent of operating experience versus IEC 61508 compliance information is a function of device
complexity (e.g. non-PE vs. PE) and the application (e.g. SIL 1, 2, or 3). The owner/operator should
recognize in the planning stage that prior use justification has a significant qualitative feature that may
become apparent when comparing IEC 61508 compliance results versus operating experience results.

There are also many issues surrounding the assumptions made in the IEC 61508 compliance
assessment, including where and how the data was obtained and the boundary of the assessment.

With this background, the following guidelines can be used for selecting a device:

• IEC 61508-compliant devices should be evaluated to ensure that the device operates in its
intended application. This may include gathering prior-use information or simulated testing of a
statistical sample.

• All non-PE devices and PE devices using FPL can be selected based on prior use for an SIS
application. Prior-use evaluation can begin during beta testing.

• Alpha and beta testing should be supplemented with actual field operating experience.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• Where IEC 61508 compliance information is available, the typical duration required to establish
prior use is reduced.

• Prior use is often used where devices designed in compliance with IEC 61508 are not available;
hence, prior use plays a significant role in the application of the “grandfather clause” (refer to
TR84.00.04-1 Clause 3.0 and Annex A).

• IEC 61508 compliance is the preferred method for selecting PE devices using LVL due to the
potential for systematic failures related to hardware and software faults.

Before addressing prior-use information, it is important to recognize the overlap between IEC 61508
compliance and ANSI/ISA-84.00.01-2004-1 prior use. Each approach involves the examination of the
probability of failure on demand (or frequency of failure) and utilizes alpha and beta testing of the device
balanced with some degree of actual operating experience. The best approach is to utilize a combination
of both approaches, leading to SIF devices with a low potential for dangerous failures and proven
reliability in the process application. Two examples are provided to illustrate why IEC 61508 compliance
(or IEC 61508 certification) and operating experience should be considered.

Example #1: PE device using LVL- IEC 61508-compliant information only.

If IEC 61508 compliance only is used, it cannot be confirmed that the device functions properly when
implemented in the intended application. Reasons for this include improper electromagnetic compatibility
(EMC), harmful airborne particulate, power line conditioning issues, plant’s lack of
design/operation/maintenance experience with the device, and hardware/software limitations as defined
in the safety manual. Refer to Clause L.4 for additional issues relating to IEC 61508 compliance
assessments.

Example #2: PE device using LVL -- prior-use information only.

If prior-use information only is used, the operating time required to gather statistically significant data is
extensive, and any change to the device would require a re-evaluation of its prior use. Prior use alone
may not disclose significant, undetected dangerous failure modes. As a result, the process sector utilizes
IEC 61508 compliance (or IEC 61508 certification) in conjunction with prior-use information, as defined in
ANSI/ISA-84.00.01-2004-1, Clauses 3.2.53, 3.2.60, and 11.5.3.

Figure L.2 illustrates the relationship between IEC 61508 compliance and ANSI/ISA-84.00.01-2004-1
prior-use information, when examining alpha and beta testing, analysis, testing, and operating
experience. As a minimum, an understanding of the unsafe failure modes (safe and dangerous) is
required, so appropriate counter measures (e.g., watchdog timer, etc.) can be implemented.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

SIL 1 SIL 2 SIL 3 SIL 1 SIL 2 SIL 3

claim claim claim claim claim claim
limit limit limit limit limit
Necessary Requirements

limit

IEC 61508 Compliance Operating Experience

(analysis and/or testing) (Prior Use)

Operating Experience Analysis and/or Testing

Beta Testing Beta Testing

Alpha Testing Alpha Testing

IEC 61508 Compliance Approach ISA 84.00.01-2004 Prior Use Approach

A) B)

(Gray area in Figure L.2.B indicates that prior-use information alone may not be sufficient for some devices)

Figure L.2 — Evidence supporting user approval

L.7.1 User approval example

L.7.1.1. Purpose

Approve and document field devices and non-PE logic solvers for use in SIS, based on combining prior-
use history in operating facilities and IEC 61508 compliance from manufacturer. The list should be used
by project and maintenance personnel to ensure that only approved equipment is used in SIS
applications.

L.7.1.2. Scope

L.7.1.2.1 A team of personnel knowledgeable in the instrumentation and controls should review
information relevant to determining the suitability of equipment for use in SIS. Typically, the
team consists of someone knowledgeable in the SIS applications at the operating facility
(referred to as the SIS Specialist), a maintenance technician (or control system technician)
and instrument/analyzer reliability engineer/technician.

L.7.1.2.2 The information reviewed includes manufacturer information, such as equipment manuals,
product advisory notices, and manufacturer’s recommendations/practices and previous
installation history, such as work orders, proof-test records, and near-miss/incident reports.
The review should cover the equipment hardware, software, and interfaces, including
communications and displays. Previous history may consider control, protective, and safety
applications.

L.7.1.2.3 Equipment is approved through an evaluation process that takes into account the operating
history, historical performance/reliability, manufacturer’s recommendations, and
manufacturer’s IEC 61508 certification information (e.g., installation and maintenance manual,
safety manual, IEC 61508 certification report, failure-rate data), product quality, manufacturer
support (e.g., obsolescence and advisory notices). The overall evaluation process may include
performance data from multiple facilities or from a single facility, depending on company size
and strategy.
Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

L.7.1.2.4 The approval process results in a list (or table) of equipment approved for use in SIS
applications. This list should be periodically reviewed to ensure that new or modified versions
of equipment are evaluated in a timely manner and that the list considers performance based
on current operating and maintenance plans.

L.7.1.2.5 The approved equipment list should be traceable to the root model number of manufacturer
products.

L.7.1.2.6 This process does not address the selection of PE logic solvers.

L.7.1.3. Key screening parameters for list inclusion

L.7.1.3.1 Hardware performance is highly affected by the process application and ambient environment.
Consequently, this review focuses on installed equipment performance and depends on
monitoring its performance in the operating environment. A minimum of 1 year of operating
experience and an installed base sufficient to yield a minimum of 100,000 hours of operation
in multiple installations is generally recommended. A minimum operating time allows sufficient
time for early failures, such as those related to specification, handling, installation and
commissioning, to be identified, adequately understood, and accounted for in the equipment
manual.

Hardware changes can impact prior-use historical data, so operating experience with previous hardware
revisions may not be sufficient to justify approval of a new version. Users should understand any
significant changes to the device to ensure the new version will function properly in the SIS. Significant
changes are defined as changes to materials of construction (special focus on wetted-part materials),
changes to product form, and/or changes to product function. A functional evaluation is required to ensure
the version changes do not impact the historical data used to justify a device used in the SIS.

• Perform an evaluation of changes to materials of construction, since material changes could lead
to incompatibility with process fluids leading to corrosion.

• Review device form changes, since modifications to mounting or installation parameters may be
needed.

• Review function changes to ensure these will not impact the device operation in the SIS.

L.7.1.3.2 When programmable components are evaluated (e.g., transmitters, analyzers, or logic
solvers), previous history with the software may not be sufficient to justify approval of a new
version. An understanding of the changes from one software version to another is critical to
the evaluation. In some cases software changes are completed to simply add new capabilities,
address component obsolescence, or fix minor nonconformances that may have no impact on
its use in the SIS. However users should understand that even minor changes to software
coding can have negative consequences on the final product if the development process is not
controlled or all of the use cases have not been tested and verified to meet requirements.

The type of the programmable component (FPL versus LVL) will also affect the rigor of the required
evaluation. A functional evaluation is needed to determine whether specific software changes affect the
expected performance (integrity and reliability), specification, installation, configuration, diagnostics, or
proof-test requirements.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

L.7.1.3.3 Due to the inherent complexities of software development, validation, and verification,
functional testing alone may not be sufficient to ensure changes to software versions will not
negatively impact the new version’s use in an SIS.

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

It is recommended that the user have a basic knowledge of the manufacturer software development
methods, development tools, configuration management processes, and testing verification and validation
methods to ensure the programmable component quality and that all changes are documented against
the component’s functional specification.

Manufacturers should have basic good software development, testing, and configuration management
processes in place.

Examples of good software practices include following IEC 61508-3 or Capability Maturity Model (CMM)
and ensuring the software processes are controlled under the manufacturer quality management system
(example: ISO 9001:2008).

One benefit of devices designed per IEC 61508-3 is that part of meeting these requirements is to have a
quality software design, verification, validation, and configuration management process in place.

NOTE 1 A common problem with firmware and utility software upgrades is compatibility within existing integrated systems
comprised of other hardware and software products. However for fixed programming language devices, compatibility is limited to the
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

communication interface (example HART communication).

NOTE 2 Capability Maturity Model (CMM) was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University
in Pittsburg, PA, USA. The SEI developed a set of best practices and an assessment method for the development, verification, and
validation of complex software models.

L.7.1.3.4 Devices should allow adjustment of process-related or device configuration-related

parameters only, e.g., adjust measurement range. The adjustment feature should be protected
through either jumper or password.

L.7.1.3.5 The manufacturer should have a documented quality control system in place, governing
aspects such as software revision changes and communication of potential performance
issues to users (example: ISO 9001:2008). The IEC certification process shall cover the
quality control system and should ensure management-of-change processes are in place.

L.7.1.4. Key Tasks and Responsibilities

L.7.1.4.1 The maintenance or reliability technician should have access to and provide the following
typical documentation for team review:

• Computerized Maintenance Management System (CMMS) work order data and repair work order
data

• Specification documentation and equipment manuals

• Any manufacturer response to previously reported failure or performance issues

L.7.1.4.2 The team leader, SIS Specialist, or I/A Reliability Engineer will identify and prioritize
equipment to be reviewed.

L.7.1.4.3 The maintenance or reliability technician will pull work order data, from the CMMS for the
previous 2 years, using the following recommended categorizations:

• Equipment Field Tag Number

• Equipment Group Code /Technology Measurement Family (flow, press, temp.)

• Equipment Type Code (specific measurement principle within that measurement family (e.g.,
vortex, differential pressure, Coriolis)

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• Manufacturer

• Model Number

• Location Description

• Process Service Group or Pipe Spec

• Production Unit

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
• Process Unit

• Date Installed

• Cumulative Time in Service

Details on how and why these categorizations are used in reliability data capture and analysis are
described in ISA-TR84.00.03.

L.7.1.4.4 The team should review the available information and fill out Table L.1 to determine whether
the equipment should be approved for use and to identify any minimum practices required for
successful operation. Per the approval section, devices having the “not approved” or
“pending” box checked will not be added to the approved list. Where data is only sufficient to
support use in a control or diagnostic/monitoring application, this should be indicated by a
mark in appropriate data column of the approved list. If a device is approved for use in a
safety application, but with restrictions, those restrictions will also be documented in the
approved list, e.g., only approved for river water service, etc.

L.7.1.4.5 A user equipment “manual” should be developed for approved equipment. Depending upon
the equipment complexity, the “manual” could consist of one page to several pages, noting
special considerations that have been learned over time and that need to be accounted for in
design and long-term maintenance planning.

This manual should include references to the manufacturer installation, operation, maintenance, and
safety manuals or instructions as applicable.

The user equipment manual should contain the application-specific information on how the equipment
should be installed, configured, operated, and maintained to achieve the required performance in the
operating environment, particularly noting any performance issues, such as performance or life
expectancy degradation due to process application or ambient environment extremes. The user manual
may require a subset of the allowable options in the manufacturer manuals or require specific alternatives
that have been determined through operational history to be necessary for the application.

Deviations from manufacturer recommendations should be justified and documented.

NOTE -- The user manual should not be confused with the safety manual supplied by the manufacturer with equipment certified to
IEC 61508.

L.7.1.5. Life Cycle Maintenance of Approved List

L.7.1.5.1 The approved list should have an owner, such as an SIS specialist or I/A reliability engineer,
who has the following responsibilities:

Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

• Ensure the list is reviewed and updated on a defined interval.

• Ensure devices are added only after field operating history has been obtained and reviewed.

• Review and remove previously approved devices where performance issues warrant. Frequent
repair/“bad actor” work orders written against equipment should trigger an investigation, e.g. two
or more in a 90 day period.

• Equipment review documentation should be retained per document retention practices.

Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Table L.1 — Equipment approval form

NOTE -- This form can be applied to the approval of new equipment that has been previously installed in non-safety applications
and to support the continued use of existing field equipment as part of an overall reliability program (see ISA-TR84.00.03).

Device Technology: List Installed Process Applications:

Manufacturer:

Root Model #:

Firmware Software Version:

A. Determine the length of service.

1. Does installed base provide equivalent of 10,000 hours of operation in multiple process Yes No
applications for a simple (non-PE) device?

2. Does installed base provide equivalent of 100,000 hours of operation in multiple process Yes No
applications for a complex (PE) device?

3. Length of Service > 1 year Yes No

4. Only for Length of Service < 1 year: Is there justification for use (e.g., use in other units, sites, Yes No
etc.)? List references here and attach to this form:
B. Determine current approvals.

1. Does the equipment meet:

a. Hazardous location requirements? Yes No
b. Other required approvals? Yes No

2. Does the equipment comply with IEC 61508? Yes No

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

If no, prior use must be justified based on A1 or A2.

C. Review maintenance records and equipment failure investigation reports

1. Are all special maintenance issues covered in the manufacturer or user safety manual? Yes No
Describe service:

2. Does the current maintenance plan address the expected (or remaining) useful life? Yes No

3. Do maintenance records indicate that the equipment is performing as expected (i.e., Yes No
functional, integrity, and reliability)?

4. Is the normal maintenance interval (e.g., at turnaround) adequate? Select NO if equipment Yes No
requires frequent maintenance due to installation issues or a particular service.

5. Are all necessary service restrictions listed in the manufacturer or user safety manual? Yes No

6. Have equipment diagnostics performed as expected? Yes No

D. Discuss manufacturer support

1. Is device type/model #/software still supported by manufacturer? Yes No

2. Is manufacturer support likely to continue? Yes No

If no, a substitute should be evaluated separately.

3. Is adequate technical support provided by the manufacturer? Yes No

If no, a substitute should be evaluated separately.

4. Have manufacturer-issued product advisory notices (if any) been evaluated, and did the Yes No
evaluation of these notices support continued approval status?

Copyright International Society of Automation

E. Discuss product quality

1. Does manufacturer have a documented quality program or plan? Yes No

List (ISO9000 or other reference):

2. Has manufacturer met quality expectations? Yes No

If no, describe problem(s):
F. Examine Manufacturer Equipment Manual

1. Do the manufacturer recommendations cover installation and configuration techniques for this Yes No
application?

2. Does the manufacturer recommend inspection, preventive maintenance, proof-test practices Yes No
or intervals? If no, these must be covered in User Equipment Manual.

3. Is the facility Mechanical Integrity (MI) program consistent with the above manufacturer Yes No
recommendations?
G. Examine User Equipment Manual

1. Are all feature- or configuration-option restrictions (e.g., any that should not be used for SIS Yes No
applications) documented in the user manual?

2. Are necessary restrictions enforced (e.g., by jumper, password, or restricted access)? Yes No

3. Are installation diagrams available and up to date? Yes No

4. When (if) the user manual deviates from the recommendations of the manufacturer Yes No
equipment manual, is the basis documented in the user manual?

5. Is the user manual sufficient to ensure proper use of the equipment? Yes No
H. Make recommendations

1. Is the recorded information sufficient for approval? Yes No

List any missing items to address:

2. Should the equipment be used for process safety applications? Yes No

List restrictions here (process specific, ambient environment, etc) and attach details to this form:

3. Are current installation detail practices adequate? Yes No

List improvement opportunities and attach details to this form:

4. Does review of product history support the current inspection, preventive maintenance, Yes No
condition-based maintenance, proof-test procedures, and intervals?

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
List improvement opportunities and attach details to this form:

5. Should the equipment be placed in service or remain in service? Yes No

If the equipment should be obsoleted/retired or removed from service, indicate the priority for
action and attach details to this form:

Approval

Approval Status Not Approved Pending

Approved with Restrictions Approved

Approved for: Control Only Diagnostic Only Protective Safety

Copyright International Society of Automation

L.8 SIL claim limit considerations

When referring to a device, it is important to remember that the term SIL refers to the PFDavg (or
frequency of failure if continuous model) of an SIF. A device by itself does not have an SIL. It has a
PFDavg. The device implemented in an SIF contributes to the PFDavg of the SIF (which should achieve the
target SIL). IEC 61508-2 and IEC 61508-3 extended the use of “SIL” to represent the target-risk reduction
level of a device design. This has led to confusion when referring to the level of safety design. When
referring to a device, “SIL” should always be followed by “claim limit.” For example transmitter Brand X
has a “SIL 2 claim limit.”

Achieving an SIL claim limit involves substantially more than the calculation of the PFDavg. To reach a
specific SIL claim limit the device design must comply with the design requirements of IEC 61508-2
(hardware and system) and IEC 61508-3 (software). The actual design requirements that must be
satisfied differ based upon the SIL claim limit the device is to achieve. SIL 3 claim limit design
requirements are more stringent that SIL 1 claim limit design requirements. These requirements also
include an evaluation of the manufacturer’s product development process, quality management system,
manufacturing process, and validation plans. The evaluation of SIL claim limit involves fault insertion
testing to verify diagnostics and calculations to determine the PFDavg. The SIL claim limit is also restricted
by the fault tolerance tables in IEC 61508. The manufacturer is further required to provide a safety
manual for the device, which should outline any specific implementation requirements necessary to
achieve the SIL claim limit. These requirements often include proof-testing intervals and diagnostics.

It is important to consider the following when examining the relationship of the SIL claim limit of a device
used to implement an SIF and the SIL of the SIF.

• Lower SIL claim limit devices may not be combined to achieve higher SILs for continuous mode
SIFs.

• For FPL devices in demand mode SIFs, lower SIL claim limit devices can be used to achieve
higher SILs in accordance with ISA-TR84.00.02, Part 1, and the fault tolerance requirements

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
(Refer to Annex K). FPL device redundancy and/or external diagnostics are typically used to
achieve higher SIL claim limits for the FPL device subsystem. For example, a single PE
transmitter typically achieves an SIL claim limit of no more than SIL 1 to 2. However,
appropriately configured redundant, transmitters (e.g., 1oo2, 2oo3) are routinely used in SIL 3
applications. The increased PFDavg is attainable because of the fault-tolerant voting configuration
of the transmitters.

With proper installation and maintenance, the common mode failure for the PE hardware should be quite
low. The PE software systematic errors are also mitigated through manufacturers’following the design
requirements of IEC 61508-3

For LVL devices in demand-mode SIFs, redundancy and diagnostics alone are not sufficient to achieve
higher SIL claim limits. LVL devices are significantly more complex, using embedded, utility, and multi-
functional application software (e.g., logic solvers). For example, the following could be considered:

• Diverse hardware and software channels, such as a logic solver and a relay, or two diverse logic
solvers

• Use of the application software in the BPCS to emulate the SIF logic (e.g., mirroring, shadowing)
with comparison of the output status resulting in an appropriate response (e.g., alarming, return to
a safe state), as determined by the hazard and risk analysis.

Copyright International Society of Automation

Annex M – General purpose versus Safety Logic Solvers

NOTE -- Annex M is referenced in the following: Clause 4.3 and Annex F.3.

M.1 Purpose

Programmable Electronic (PE) logic solvers have played an important part in process safety for thirty
years. In the last decade, industry has been inundated with new terms and requirements as the functional
safety standards evolved. ANSI/ISA-84.00.01-2004-1 requires the following:

• For SIL 3, the PE logic solver must be compliant with IEC 61508.

• For SIL 1 and 2, the PE logic solver can be selected based on prior use and IEC 61508
compliance.

• If prior use is selected, the PE logic solver must be safety configured and meet certain prior-use
criteria.

• For new SIS, IEC 61508-compliant PE logic solvers are strongly recommended.

These new terms and requirements have resulted in some confusion when relating pre-existing practices
and terminology to today’s practices. This annex is intended to bridge that communication gap by
discussing general-purpose, safety-configured and IEC 61508-compliant PE logic solvers.

M.2 General-purpose logic solver background

• A Programmable Logic Controller (PLC) is considered a PE logic solver in ANSI/ISA-84.00.01-

2004-1. The following provides a brief history of the PLC in order to explain the evolution of
general-purpose logic solvers toward today's safety logic solvers. The same principles that apply
to differences in general-purpose logic solvers and safety logic solvers can be used to analyze
other logic-solver families (e.g., single-loop controllers, distributed control system logic solvers).

• Up until the late 1960s, the automotive industry utilized electromechanical relays to control their
automotive assembly lines. In the late ‘60s, industrial-grade Programmable Controllers (PC) were
introduced. The owner/operator would purchase the PC components (e.g., inputs, outputs, I/O
chassis) and apply them as needed. The largest market was the automotive industry, since the
task of re-wiring each relay at the end of a model year could be replaced with an application
program revision, saving time and money. As a result, the PC was driven by the needs of the
automotive industry in its early development.

• In the ‘70s, the personal computer was introduced, and the US industry began using the term
Programmable Logic Controller (PLC) rather than programmable controller to allow the use of the
abbreviation “PC” for personal computers. Today there are still some countries in Europe that use
the abbreviation “PC” for programmable logic controllers.

• PLCs have been used in safety applications since the 1970s. Many types and sizes of PLCs have
been built and are available for use in the process sector. The definition of PLC can be found in
many texts. One such definition states: "PLCs can be thought of in simple terms as industrial
computers with specifically designed architecture in both their Central Processing Unit (CPU) and
their interfacing to field devices (i.e., sensors and final elements).” When applying PLCs, the
owner/operator was responsible for properly configuring the PLC for safety applications. Until the
late ‘80s, the use of the words "general purpose" with the term “PLC” was redundant, since most
PLCs were built as commodity products that could be arranged by the owner/operator to handle a
wide range of process-sector applications.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

As PLC use became more widespread, potential faults became apparent. Some of these faults included:

• Random turn on of all inputs

• Random turn on of all outputs

• Dangerous failure of individual output

• Core memory was very susceptible to electro-magnetic coupling (EMC)

• Power supply failure resulted in spurious PLC performance

• Improper packaging of PLC components (incorrect mounting hole spacing between racks)
causing EMC problems

• Operating system problems with each new revision level

These faults drove industrial control manufacturers to innovate their products, yielding a dazzling array of
PLCs. Each model had new and diverse features, such as remote I/O, cathode ray tube programming
panel, proportional/integral/derivative control capability, read-only memory, and modified operating
systems. As the capability to detect and respond to faults improved, other industrial sectors, including the
process and off-shore petroleum sectors, began utilizing PLCs.

During the late ‘80s, the use of PLCs changed as the potential hazards associated with the inappropriate
use of PLCs became apparent. Over the last 15 years, PLC manufacturers have designed and built PLCs
specifically to handle functional safety applications in the process sector. PLCs are now expected to meet
IEC 61131 (programmable controllers) requirements for implementation of the hardware and software
and for the evaluation of environmental and functional needs. Many PLCs also meet IEC 61508
requirements and are supplied with a detailed safety manual. This safety manual includes reliability data
for the logic solver (e.g., SIL claim limit, safe-failure fraction) and application design, installation,
operation, and maintenance guidance to achieve the SIL claim limit. Today, safety logic solvers are often
certified by a Nationally Recognized Testing Laboratory, such as those listed on the Occupational Safety
and Health Administration (OSHA) website (www.osha.gov), to meet specific requirements defined in IEC
61508.

M.3 General-purpose logic solvers for safety applications

The application of PLCs to the process sectors required that the owner/operator understand the PLC
dangerous failure modes and their frequency, methods to mitigate these problems, and proper testing to
recognize undetected dangerous failure modes. This situation required a close working relationship
between the owner/operator and the manufacturer. Those manufacturers who were capable of providing
support in this effort have survived the hectic crowded PLC market of the ‘70s and ‘80s.

When configuring a general-purpose logic solver for SIS applications, consider the following:

• Interview personnel at a facility that has successfully applied (e.g., designed, installed, operated,
maintained, programmed) the PE logic solver in a non-safety-related application, such as process
control, to determine what the application history has been.

• Select the PE logic solver based on prior use.

NOTE -- Some IEC 61508 compliance information may be available.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`

Copyright International Society of Automation

• Determine whether the logic solver manufacturer can supply safety components (e.g., fail-safe
outputs) and use these to the extent possible.

• Determine whether the PE logic solver meets the hardware fault tolerance required by ANSI/ISA-
84.00.01-2004-1, Table 5.

• Implement supplemental hardwired systems (e.g., electro-mechanical relay or trip amp) to

provide an independent backup when the PE logic solver does not meet the fault tolerance
requirements or probability of failure-on-demand requirements.

• Implement access control for the application software and understand how the manufacturer
supports this capability.

• Understand how to utilize the manufacturer's revision level tracking and establish a procedure to
track software modifications through management of change.

• Analyze the logic solver components to define the potential dangerous, hardware failure modes.

• Implement diagnostics to detect the dangerous failure modes, e.g., watchdog timer (see
ANSI/ISA-84.00.01-2004-2, Annex E).

• Read-only memory with redundant application safety program monitored once a second to
ensure integrity of read/write memory, redundant I/O with comparator diagnostics.

• Check of final element position versus software command status.

• Redundant I/O and application software with alternate online operation and off-line testing.

• Shadowing refers to the ability of the control system (BPCS) to emulate the safety instrumented
function so that a continuous diagnostic can be made to identify problems (e.g., systematic and
common-cause).

M.4 Safety-configured logic solvers for safety applications

The safety-configured logic solver is a composite of features in M.3, arranged to meet the target SIL of
the safety-configured logic solver. See Clauses 3.2.40.1 and 11.5.5.5 in ANSI/ISA-84.00.01-2004-1.

M.5 IEC 61508 compliant PE logic solvers

An IEC 61508-compliant PE logic solver has the following characteristics:

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
• It is typically certified by a nationally recognized testing laboratory.

• It is an off-the-shelf device.

• It has a safety manual provided by the manufacturer that provides application guidance for the
owner/operator.

IEC 61508-compliant PE logic solvers are widely available from most control system manufacturers
servicing the process sector.

Copyright International Society of Automation

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Annex N – Design guidance

NOTE -- Annex N is referenced in the following: Clause 4.3.

N.1 Purpose

This section is an updated version of ANSI/ISA-84.01-1996, Annex B. It is included to ensure that the
good practices described in ANSI/ISA-84.01-1996, Annex B, were maintained. Some of this information is
incorporated into ANSI/ISA-84.00.01-2004-2.

N.2 Communications between BPCS and SIS

Communications between the BPCS and SIS can enhance the overall safety of the application.
Comparing the SIS and BPCS process variables can provide enhanced diagnostics for the sensors,
improving the integrity of the SIS and BPCS sensors. However, communications, particularly writes to the
SIS, can compromise the safety integrity of the SIS. Provision should be made to ensure all writes are
valid and do not negatively impact the system safety or operation.

There are five basic ways to approach external communication between BPCS and SIS:
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

1) No bus or highway communication between BPCS and SIS.

This is acceptable for all SILs.

2) Hardwired communication between BPCS and SIS for each device (e.g., contact status in SIS is
transmitted to BPCS with a pair of wires).

If the SIS requires hardwired communication for the successful execution of the safety function,
the input point, wiring, output point, BPCS, and all components required for the BPCS to perform
its required task should be taken into consideration for the SIS to meet the required SIL rating.

3) Read-only 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 SIS include, but are not
limited to, hardwired switch (or jumper) to limit write access and implementation of the SIS in SIS
ROM.

4) Read/write communications with write protection of the SIS.

This is acceptable for SIL 1 and 2, but use of this method for SIL 3 requires additional safety
review and analysis. Measures to achieve write protection of the SIS include, but are not limited
to, limited time window for write access, controlled write to specific registers, and software switch
(e.g., password) to limit write access.

5) Read/write communications with limited or no write protection of the SIS.

SIS communication write protection measures (e.g., programming tool control, self-configured
passwords) are typically implemented to provide access security and management-of-change
control. Use of this method for SIL 2 requires additional safety review and analysis. Sole use of
this method in SIL 3 is strongly discouraged

Copyright International Society of Automation

N.3 Architecture

Selection of the SIS architecture is an activity performed during the conceptual design step of the safety
lifecycle. The architecture has a major impact on the overall safety integrity of the SIS. The architecture
also influences SIS reliability (likelihood of spurious trips). Some of the activities involved in determining
the SIS architecture are

• selection of energize-to-trip or de-energize-to-trip design;

• selection of sensor and final element configurations (e.g., whether single or redundant sensors
are needed on inputs, such as 1oo1, 1oo2, 2oo2, or 2oo3, as well as final trip valve
configurations, such as single valve, double block valve, double block & bleed);

• evaluation of PE logic solver configuration;

• selection of redundancy for SIS power sources and/or supplies;

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

• selection of operator interface components (e.g., computer monitor, alarm annunciator,

pushbuttons) and their method of interconnection to the SIS;

• 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);

• estimation of the safe failure fraction (SFF) used to determine fault tolerance requirements;

• defining the proof-test requirements;

• determining equipment reliability and failure rates associated with failure classifications; and

• defining user interfaces.

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 requires redundancy in sensors, logic solver and final elements, and enhanced
diagnostics and on-line validation of the SIF functionality to avoid the need for frequent testing.

The owner/operator should determine the failure rates of the SIS devices, diagnostic coverage, test
intervals, redundancy, safe failure fraction, etc., and evaluate each specific SIS to validate its
performance.

N.4 Technology selection

Safety Instrumented Systems (SIS) can be developed using Electrical, Electronic, or Programmable
Electronic (E/E/PE) technologies. A hybrid scheme combining technologies (e.g., PE, Electrical, etc.) may
be used to develop an SIS.

Copyright International Society of Automation

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 ANSI/ISA-84.00.01-2004-1.

N.4.1 Electrical technology used in SIS

N.4.1.1. Direct-wired systems

Direct-wired systems have the discrete sensor directly connected to the final element. This technology
often provides minimal diagnostic coverage, so the testing interval may have to be decreased.

N.4.1.2. Electromechanical devices

Electromechanical devices include relays and timers. Relays are often used where simple logic functions
are used to provide the necessary safety logic. Extensive operating experience with relays and their
mature technology make acceptance of this device in an SIS widespread. Relays have very predictable
failure modes, and their failure rates are well known.

Successful users of relays in SIF applications have followed some simple guidelines. They include using
a relay that

• has a good in-plant track record;

• has the proper fail-safe position (e.g., shelf-state when completely disconnected) characteristics
when installed;

• is found reliable through lifecycle testing;

• is user-approved for SIF applications; and

• is suitable for the environment in which it is placed (e.g., hermetically sealed).

The relay SIS has other attributes that should be considered:

• The on/off status can be readily obtained by checking contact position (e.g., open or closed).

• Its interconnected logic is very difficult to change (requires rewiring).

• It is simple, understood by plant personnel, and easily supported.

• It is easily identified and secured as a critical control device.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

• It has failures that can be isolated to reduce common-mode failures.

While relays have a very low failure rate, relay logic should not be considered inherently fail-safe. Even if
the relays are properly selected and applied, the contacts may weld or the spring may not return the
switching contacts to the de-energized position.

Electromechanical relay logic systems should consider the following criteria:

• Contacts open on coil de-energization or failure.

• The coil has gravity dropout or dual springs.

• Contacts are of proper material and rating.

Copyright International Society of Automation

• Energy-limiting load resistance is installed to prevent contacts from welding closed.

• Use of contacts that are rated properly for amperage.

• Proper arc suppression of the contacts is provided for inductive loads.

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 buildup on contacts,
resulting in unreliable operation (e.g., load dropout). This is referred to as contact wetting. When utilizing
these special contacts, specific analysis is needed for these contacts to ensure that a fail-to-safe
electromechanical system is being designed.

N.4.1.3. Motor-driven timers

Motor-driven timers provide acceptable performance for SIF 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.

N.5 Electronic technology used in SIS

N.5.1 Solid state relays

Solid state relays are often used in high duty-cycle application and have unsafe failure modes that can be
identified and quantified. Appropriate design features should be added to detect and alarm failures. Some
additional applications of solid state relays are described in the following paragraphs.

N.5.2 Solid state timers

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

NOTE -- RC circuitry is often used in the time setting portion of pulse-counting timers. This does not preclude the use of these
timers.

The pulse-counting timer, sometimes referred to as a digital timer, can use a number of methods to
achieve pulse counting. These include

• a line frequency (50 or 60 Hz);

• an electronic oscillator;

• a quartz crystal oscillator; and

• a user-approved safety crystal oscillator (e.g., quartz). -- recommended because of high

repeatability and good reliability

N.5.3 Solid state logic

Solid state logic refers to the transistor family of components like Complementary 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
Copyright 2011 ISA. All rights reserved.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

modules, or in highly integrated, high-density chips. They differ from typical computer-type equipment in
that they have no 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-to-safe requirements (e.g., indeterminate failures) that should be recognized.

Solid state logic has generally been integrated with direct-wiring and relay schemes for SIS. Solid state
logic is not recommended for SIS, unless provided with additional diagnostics to test for unsafe failures.
PESs are sometimes used as a diagnostic tool to make solid state logic systems suitable for SIS.

N.5.4 Pulsed electronic logic

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

Pulsed electronic logic can be considered in an SIS if it meets the requirements of ANSI/ISA-84.00.01-
2004-1 and is user-approved (i.e., prior-use).

Pulsed electronic logic can offer high safety integrity. However, some functions are not available with
pulsed solid state systems or electronic logic, such as calculation capability, higher-level communications,
and networking.

N.6 PES technology used in SIS

The PES can be a programmable controller, a distributed control system controller, or an application-
specific, stand-alone, micro-programmable logic controller (micro-PLC). The complexity of the PES
results in numerous paths to failure, including dangerous and safe failures. Many failures are unsafe.
Some techniques that can be used to minimize these failures of PES are

• extensive diagnostics to detect dangerous faults;

• use of redundancy, fault tolerance (e.g., 2oo3), and similar architectures;

• use of Watchdog Timers, both internal and external; and

• use of outputs with diagnostics to detect output module failures.

Select PES technology for SIS when

• there are large numbers of inputs and outputs;

• logic requirements are complex, such as sequencing or computational functions;

• extensive data communications with the BPCS is required; and

• different trip points are required for different operations (e.g., batch application recipe selection).

N.7 Diagnostics

N.7.1 General considerations

Diagnostics are tests, which are performed periodically to detect some of the dangerous faults that
prevent the SIS from responding to a demand. Various types of faults that can occur are included in Table
N.1:

Copyright International Society of Automation

Table N.1 — Fault types

Fault Type Example

Faults that immediately disable the capability of the SIS to respond Stuck on or stuck off of a critical output point
to a demand (critical faults)
Faults that in combination with other faults disable the capability of Diagnostic of a critical output point not
the SIS to respond to a demand (potential critical faults) 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 Burned out, not critical LED
a demand (benign faults)

A dangerous 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. It is important to
detect and repair critical faults prior to a process demand on the SIF.

Faults can result in two types of failures:

• Random failures, a spontaneous failure of a component

• Systematic failures (or errors), a hidden fault in design or implementation

Hardware is prone to random failures, but can also have systematic failures (incorrect timing, components
used outside their specified range, etc.). Software is generally free of random failures, but can have
systematic failures. Failures are typically found and corrected when they result in a safe failure spurious
trip of SIF, they are found during SIF testing, or when the SIF fails to trip on demand. Sometimes,
systematic software failures can exist for the life of the SIF, and the set of conditions necessary to initiate
the failure never occur. In these cases, the systematic failure is essentially benign and does not impact
safe operation. Random hardware failures are addressed by verifying that the SIF achieves the required
SIL. The implementation of the safety lifecycle minimizes systematic failures in software and hardware.

Random failures occur spontaneously. Depending on the persistence of the fault over time, two
conditions are possible:

• Permanent random faults persist until they are repaired.

• Dynamic random faults (cross-talk, thermal faults, etc.) occur under certain circumstances and
disappear.

N.7.2 Diagnostic tests

Diagnostics may be accomplished using a variety or combination of methods, such as:

• Monitoring hardware integrity (e.g., impedance monitoring in thermocouples)

• Selecting devices that have internal diagnostic capability (e.g., Input/Output module self tests)

• Incorporating external diagnostic capability through design (e.g., automated testing of solenoid
valves, partial stroke testing of isolation valves, or comparison of redundant analog signals)

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• Using watchdog timers

• Using end-of-line monitoring

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 device may not always result in a safe response of the SIS, as
this is application specific.

N.7.3 Diagnostic coverage

Diagnostic techniques are generally 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.

Improved diagnostic coverage of SIF devices may assist in satisfying the requirements of the target
Safety Integrity Level. Examples of specific failures that may be covered by diagnostics are listed in Table
N.2. This or a similar list of failures may be needed to identify those areas where diagnostic coverage is
required.

Critical and potentially critical faults, such as faults to CPU/RAM/ROM, 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 kinds of faults are therefore stricter. Additionally, failures that carry a high failure
probability have to be detected with more confidence. Further, the detectability of failures must be taken
into account; failures that are detectable using simple means should be implemented whenever possible.

For each diagnostic implemented, the following should be identified:

• Testing interval

• Resulting action on fault detection

Both criteria should meet the safety requirements specification.

Where certain diagnostics are not "built in" to the manufacturer-supplied equipment, appropriate
diagnostics may be implemented at the system or application level. 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 N.2 — Diagnostic tests for programmable electronics

Hardware Software

possible cause detection possible cause detection

Data Chip error Hardware fault testing Wrong constants

Address Indexing Hard limit checking
Time Wrong circuit Event Event verification
Component out of
Scheduling Scheduler monitor
specification
Assertions
Plausibility check
Processing Voter fault Random voter test Algorithm
Reverse computation
diversity

Copyright International Society of Automation

N.8 Field devices

N.8.1 General considerations

Many common-cause failures of field devices may be avoided through proper application of redundancy
and/or diversity. For example, 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. Diversity that prevents the use of
diagnostic comparison is not recommended.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
• It is important to use devices with a high degree of predictability, i.e. how it will fail. It is also
important to know that the device works in the operating environment and that device
performance has been verified through actual field service.

The following may enhance the application of field devices in SIS:

• Continuously compare redundant sensors while system operates (e.g., alarm or shutdown on
unacceptable deviation).

• At each shutdown, compare sensor readings with each other and determine whether fail-safe
condition was achieved. (E.g., use these comparisons as permissives for the next startup. This
reduces Mean Time To Detection of field device failures. This also applies to monitoring of valve
position with limit switches.)

• If SIS has a feature that displays the last good value on a bad value of the field sensor, this
feature should be defeated, unless the use of this feature has been considered during hazard and
risk analysis, design and configuration management.

• Feedback to alarm when a final element fails to go to its commanded state.

• Alarm if field devices change state without a command from the SIS.

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

• Use visual indicators, such as paint, tags, stamps, etc., to identify SIS devices.

• When using analytical measurements, try to provide a means to compare the analytical readings
with related basic measurements, such as pressure, temperature, etc.

N.8.2 Field device failure modes and their detection

Device failure modes should be identified during the user approval process (see ISA-TR84.00.04-1,
Annex L) and taken into account during the design process and mechanical integrity program
development (see ISA-TR84.00.03). Failure modes are discussed in detail in ISA-TR84.00.02.

N.8.3 Sensor selection criteria

Some considerations for the selection of sensors include:

Copyright International Society of Automation

• Analog devices are generally preferred to discrete devices because the use of the analog signal
allows for online detection of device faults.

• Where possible, use diverse process variables to detect the process hazard.

• Carefully review process/ambient conditions that could affect the filling/emptying of impulse lines.

• Verify seal liquids in diaphragm seal applications for resistance to amalgamation, freezing, and
polymerization, all of which can cause false readings.

• Carefully weigh the use of devices that are foreign to a plant's maintenance organization.

A minimum number of manual isolation valves should be employed between the process and the SIF
sensor. Each sensor requiring process isolation should have its own dedicated process connection and
isolation valve.

N.8.4 Final element application considerations

Some considerations in the application of valves as final elements include:

• opening/closing speeds,

• shutoff differential pressure in both directions of flow,

• actuator sizing to ensure closure under normal, abnormal, and emergency conditions,

• valve installation configuration, whereby the process flow aids the movement of the valve to the
desired trip position,

• leakage (degree of shutoff requirements),

• fire resistance —body and actuator,

• performance following long periods in the same position,

• capability to automatically test for some valve failures,

• do not compromise reliability to achieve diversity,

• materials suitability/comparability,

• carefully weigh the use of devices that are foreign to a plant's maintenance organization,

• fail position considerations, and

• valve position indication.

N.8.4.1. Solenoid valves

Some considerations in the application of solenoid valves include:

• consider temperature, voltage, area classification, loading, etc., when selecting solenoid valves,

• effects of air pressure, minimum or maximum, on the valve,

Copyright International Society of Automation

• ensure the solenoid valve is sized properly,

• adjustable flow paths provide an opportunity for defeating an SIF function if improperly adjusted,

• mounting the solenoid between the positioner and the valve,

• some solenoids are mounting position sensitive — consider installation detail requirements, and

• solenoid vents should be oriented to point downwards and have protection against plugging, dirt,
insects, freezing, etc. Bug screens should be made from a non-corrosive material (e.g. stainless
steel).

N.8.4.2. Motor starters

In general, redundant motor starters are not used. Redundancy is applied in the form of contacts in the
motor control circuit. Auxiliary contacts may be fed back to the SIS to verify starter status (position).

N.8.4.3. Input signal conditioners and output amplifiers

Input/output interface devices have failures that can be unsafe and that should be identified and
quantified. Appropriate design features should be added to handle these unsafe failures before they can
be approved for use in an 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 VAC and 24 VDC).

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

N.9 User interface

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
User interfaces to an SIS are operator interfaces and maintenance/engineering interfaces.

N.9.1 Operator interfaces

The operator interface used to communicate information between the operator and the SIS may include

• video displays;

• panels containing lamps, push buttons, indicators, and switches;

• annunciators;

• printers; and

Copyright International Society of Automation

• any combination of these.

N.9.2 Video displays

Video displays may be used to display SIS status. A BPCS, or other computer-based control system,
through its normal operator displays, may include information related to the status of the SIS. For
example, deviation alarms may be displayed on the operator interface. However, as discussed in ISA-
TR84.00.04-1, Annex B, it is recommended that safety-critical alarms, requiring that the operator take
action to prevent a process hazard, be displayed on a separate interface from the BPCS HMI.

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.

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 keystroke or touch-screen stroke, giving entry into a display hierarchy.

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.

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 should be clear,
concise, and unambiguous.

N.9.3 Panel(s)

Panels should be located to give operators easy access.

Arrange panel to ensure that the layout of the push buttons, lamps, gauges, and other information is not

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
confusing to the operator. Having 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.

N.9.4 Printer(s)

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.

An SIS connected to a BPCS may use BPCS facilities to perform its safety-related logging and reporting
functions.

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.

If printing is a buffered function (information is stored, then printed on demand or on a timed schedule),
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.

Copyright International Society of Automation

N.9.5 Maintenance/Engineering interface(s)

Maintenance/Engineering interfaces consist of means to program, test, and maintain the SIS. Interfaces
are devices used for functions, such as the following:

• System hardware configuration

• Application software development, documentation, and downloading to the SIS logic solver

• Access to application software for changes, testing, and monitoring

• Viewing SIS system resource and diagnostic information

• Changing SIS security levels and access to application software variables

Maintenance/Engineering Interfaces should have the capability to display the operating and diagnostic
status of all SIS components (such as Input/Output modules, processors, etc.) including the
communication among them.

Maintenance/Engineering Interfaces should provide means for copying application programs to storage
media.

A user-approved personal computer may be used as a Maintenance/Engineering Interface.

N.10 Security

N.10.1 General

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.

N.10.2 Exceptions

Protection against the following are beyond the scope of this annex:

• Malicious modification

• Sabotage

• Terrorism

• Modification errors

N.10.3 Additional PES considerations

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 SIS performance:

• Parameters that are appropriate for operator interaction should be accessible.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• Parameters that may be changed online with appropriate review should come under access
control.

• Parameters or functions that require validation after change should be accessible only off-line.

The ability to restrict access to the SIS program and data should be an integral feature of the SIS.

N.11 Wiring practices

Wiring practices should meet the manufacturers' recommendations and NEC requirements. Deviations
should have safety review and analysis.

Consider enhancing wiring practices by

• eliminating circuit commons for multiple circuits;

• adding circuits for better isolation;

• adding fuses to isolate faults in a way that reduces common cause;

• implementing test facilities;

• eliminating ground-loop problems; and

• separating SIS terminations from all other terminations to the extent necessary to support
administrative controls.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Additional considerations for electronic or programmable electronic SIS include:

• Twisted-pair signal wires for EMI protection

• Shield and drain wire for RFI protection, usually grounded at the power source end

• 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

• Separation of energy levels to eliminate cross-talk and radiated noise pickup

• Surge protection as appropriate

• Isolation (e.g., fiber-optic) between different ground planes

• Data communication cable specification and shielding that meets manufacturer's

recommendations

• Cabinet wiring arranged to minimize electrical noise interference and high temperature

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.

Electronic and programmable electronic logic solvers may require a more restrictive wiring approach
because inductive or capacitive coupling may falsely turn on inputs.

Copyright International Society of Automation

Use caution when using solid state inputs or outputs because leakage current may falsely actuate final
control elements.

N.12 Proof-test interval

• The following is guidance, which may be used to determine the proof-test interval:

• The frequency of proof tests should be consistent with applicable manufacturer’s

recommendations and good engineering practices.

• The frequency of proof tests should include consideration of prior operating experience.

• The proof-test interval should be selected to achieve the SIL.

• ISA-TR84.00.02 discusses various methods to verify the proof-test interval.

N.13 Power sources

Power sources include, but are not limited to, electrical power, pneumatic power (e.g., instrument air), and
hydraulic power. Grounding is also discussed in this section.

N.13.1 Electrical power source

The electrical power source should be designed to meet the safety integrity and reliability requirements of
the application.

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 de-energized-to-trip
applications. For energize-to-trip applications, electrical power source redundancy is typically provided to
meet the safety integrity requirements.

Electrical power source redundancy can be provided using an alternate source with automatic transfer, a
UPS, or battery backup. Design considerations when transferring to alternate sources include

• detection of fault prior to impacting SIS operation;

• transfer to backup source without impacting SIS operation;

• ability to maintain UPS or batteries without impacting SIS operation; and

• minimization of common-cause failures.

Consider providing power source(s) diagnostics that do not allow SIS startup unless all power sources
are available.

Electronic and PE logic solvers 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.

Electronic and PE logic solvers typically are more sensitive to electrical noise (e.g., radio frequency
interference or electromagnetic interference), consequently, shielding, good wiring practices, and proper
grounding should be utilized.

Copyright International Society of Automation

Electronic and PE logic solvers typically have a lower insulation break-over voltage rating than an
electrical SIS. Therefore, additional surge protection may be required.

PE logic solvers may require electrical power with lower total harmonic distortion than electrical or
electronic logic solvers.

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.

A checklist of AC electrical power considerations includes

• voltage and current range, including inrush current;

• frequency range;

• harmonics;

• non-linear loads;

• AC transfer time;

• overload and short-circuit protection and coordination;

• lightning protection;
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

• protection against transients, such as spikes, surges, brownouts and electrical noise;

• protection against under-voltages;

• protection against over-voltages; and

• grounding.

A checklist of DC electrical power considerations includes:

• voltage range and current range, including inrush current; and

• non-linear loads.

N.13.2 Grounding

Grounding is critical in E/E/PE technology to ensure personnel safety and proper equipment performance.

NOTE -- 1 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. For ungrounded systems, consider using ground-fault detection relays and alarms, as
appropriate.

NOTE -- 2 Electrical or electronic technologies may integrate programmable electronic into their equipment to enhance
performance through improved communication, diagnostics, human-machine interfaces, etc. In those cases, treat the grounding as
if it is programmable electronic grounding, unless manufacturer installation guidelines dictate a different approach.

Copyright International Society of Automation

The grounding system should meet the manufacturer’s recommendations. Deviations should have safety
review and analysis. A checklist of grounding considerations includes:

• corrosion protection;

• cathodic protection;

• lightning cone of protection;

• ground planes;

• raised-floor grounding;

• static electricity protection;

• shield ground;

• single-point ground;

• test ground;

• intrinsic safety barrier grounds; and

• ground terminal(s) availability.

N.13.3 Pneumatic power

Instrument air (or other gas) is typically used with final elements. The solenoid valve acts as an electrical
to instrument air relay. The instrument air 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. Instrument air checklist:

• Pressure

• Moisture

• Contaminants

• Lubrication where required

• Volume

N.13.4 Hydraulic power

Hydraulic power is typically used where high-motive force is required, such as very large valves.
Hydraulic power checklist:

• Pressure

• Volume

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• Contaminants

• Fluid properties

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Annex O – Software
NOTE -- Annex O is referenced in the following: Clause 4.3 and Annex L.7.

O.1 Purpose

The software requirements of ANSI/ISA-84.00.01-2004-1 and ANSI/ISA-84.01-1996 are similar in many

aspects, but there are some differences. The purpose of this discussion is to facilitate an understanding
of these differences. This annex is also intended to introduce important concepts related to software-type
and application software development and verification.

O.2 What are the differences

It should be noted that a number of the contributors to the ANSI/ISA-84.01-1996 development also
worked on the ANSI/ISA-84.00.01-2004-1 development, hence the similarities. Both standards discuss
the owner/operator application software used in SIS logic solvers. Neither standard addressed software
development for SIL 4 SIFs, full variability languages, or embedded software (e.g., manufacturer system
software for programmable electronic (PE) sensors, PE logic solvers, PE final elements).

The differences between ANSI/ISA-84.00.01-2004-1 and ANSI/ISA-84.01-1996 resulted in part because:

• ANSI/ISA-84.01-1996 is a national standard, and ANSI/ISA-84.00.01-2004 is an international

standard.

• IEC 61508-3 (software section) was under development when ANSI/ISA-84.01-1996 was written.

• ANSI/ISA-84.00.01-2004 was completed 7 years after ANSI/ISA-84.01-1996 (a “lifetime” in

software development).

• The various countries and safety cultures represented on the ANSI/ISA-84.00.01-2004 committee
valued the need to clearly discuss each aspect of software, even with the obvious shortcoming of
being redundant.

• Logic solvers are applied differently around the world.

• The language types adopted in ANSI/ISA-84.00.01-2004 (i.e., limited variability, full variability,
and fixed-program languages) allowed a more boundary-specific discussion of software than
available in ANSI/ISA-84.01-1996.

ANSI/ISA-84.01-1996 and ANSI/ISA-84.00.01-2004-1 list three types of software and are similar in their
definition and usage. This software is as follows:

• application software.

• utility software (i.e., the software tools used to develop and verify the application software).

• embedded software (i.e., the software supplied as part of the PE device).

--``,`,``,``,`,````,``,,`,

Copyright International Society of Automation

The major changes the owner/operator experiences when transitioning to ANSI/ISA-84.00.01-2004-1

from ANSI/ISA-84.01-1996 include:

• ANSI/ISA-84.00.01-2004-1 has normative (i.e., mandatory) software requirements, while most

ANSI/ISA-84.01-1996 software requirements are informative (i.e., non-mandatory) with the
exception of ANSI/ISA-84.01-1996 Clause 7.8;

• change in terminology;

• more detailed application requirements;

• documentation requirements included for each phase of application software development;

• addition of V-model (ANSI/ISA-84.00.01-2004-1 Figure 12);

• reference to IEC 61508 for all full variability language applications;

• reference to IEC 61508 for SIL 4 SIFs;

• reference to IEC 61508 for programmable electronic device’s embedded software; and

• expansion of safety lifecycle software elements.

Some key aspects of ANSI/ISA-84.00.01-2004-1 include:

• The V- model, a highly valued tool in Europe, was included as an informative (i.e., non-
mandatory) application option.

• When referring to software SIL, the ANSI/ISA-84.00.01-2004-1 position is as follows:

• ANSI/ISA-84.00.01-2004-1 is limited to application software developed using fixed programming

languages or limited variability languages. The ANSI/ISA-84.00.01-2004-1 requirements are
suitable for the development and modification of application software up to SIL 3. Therefore,
ANSI/ISA-84.00.01-2004-1 does not differentiate between SIL 1, 2, and 3.

• Software languages have been partitioned into three new categories,(i.e., FVL, LVL, and FPL).
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

ANSI/ISA-84.00.01-2004-1 Clause 12 uses the safety life cycle to emphasize how software should be
developed (see ANSI/ISA-84.00.01-2004-1, Figure 11). This allowed the inclusion of a comprehensive
approach to application software development. The key issue to remember is that systematic, software
errors can only be reduced through the use of the lifecycle, including specification, verification, and
validation. However, the documentation, testing, planning requirements are repeated for each life-cycle
element to assist in proper software development, not to require excessive documentation, testing, or
planning. Clause 12 also provides guidance on the use of previously developed application software
library functions

Copyright International Society of Automation

O.3 Software design considerations

O.3.1 Embedded software

Embedded software utilizes full variability programming language, ,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:

• The supplier has a software quality plan.

• The embedded software revision level is defined.

• The embedded software revision level is the same as the revision level analyzed when initially
approving the PES for use as an SIS.

• All enhancements to, or fixes of, embedded software functionality contained in new software
releases have been reviewed and analyzed.

O.3.2 Utility software

Utility software typically utilizes either limited variability software or fixed programming languages. Use of
utility software should adhere to the same criteria as embedded software. 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.

O.3.3 Application software

Application software typically utilizes limited variability language. Fixed programming languages may be
used for some peripherals (e.g., “smart” transmitters). Modular design is highly desirable in application
programs. Modular design tends to enhance design simplicity and integrity.

Limited variability languages that are mature and/or have been certified to accepted industry standards,
such as IEC 61131-3 (Programmable controllers – Part 3: Programming Languages), are preferred.

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.

To avoid unnecessary complexity and features that make the behavior of the application logic difficult to
predict, the following should be considered:

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

• If nested sequences are used, nesting should be limited to as few layers as possible.

• The application logic specification should be clearly defined using a format that is understandable
to a non-control systems specialist. The specification should be sufficiently detailed to support the
verification and validation of the program logic, including but not limited to shutdown logic,
setpoints, diagnostics, alarms, and sequencing. The specification usually consists of a
combination of documents, including a cause & effect matrix, logic narrative, functional logic
diagram, and flow charts.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• Application logic is typically implemented in one or a combination of the following programming

languages:

a. Cause-Effect Matrix

b. Function Block Diagram

c. Sequential Function Chart

d. Ladder Diagram

O.3.3.1. Peer reviews of application software

Consider performing an analysis to demonstrate that each of the requirements established in the safety
requirements specification is implemented in the design.

O.3.3.2. Peer review of designs of safety instrumented functions

Confirm that the application software meets the requirements established in the safety requirements
specification under all expected operating conditions. Consider the following:

• Tests should be developed to exercise the software beyond the normal bounds for data,
commands, keyboard inputs, and other actions.

• A bug-reporting and resolution system should be implemented.

• Application software should be tested to determine software behavior in the presence of

hardware faults.

O.3.3.3. Applications program backup

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:

• Copy to a removable medium such as magnetic tape or disk that can be copied back.

• Copy to a removable medium that can be used as a disk replacement for a corrupted PES.

• Copy to an online device (e.g., disk) used as backup.

• A communication link with another digital system.

Consider maintaining a separate backup for data that is accumulated by the application software to
generate reports, records, and trends.

O.4 Handling of software systematic errors

When PE devices are being evaluated for use in an SIF, the integrity of the software in the PE device
should be considered. Unfortunately, software failures are difficult to predict. The mathematical models
used to predict hardware failures are not easily applied to software, because software failures are not
random; they are systematic. Software errors are also difficult to identify because of the overwhelming
number of combinations of events that could lead to a fail-dangerous or fail-safe event. Unlike hardware

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

failures, there is no certification, quantitative analysis, or prior-use analysis that can be performed that
ensures the embedded software is free of systematic errors.

IEC 61508-3 addresses potential loss of PE device integrity due to embedded software errors by
requiring that the software follow its own lifecycle process. In general, software integrity is achieved by
the following:

• A software specification

• The use of various techniques and measures that increase in rigor as the SIL increases

• Increasing the verification and validation rigor as the SIL increases

• Configuration and management of change for the software

While this process may improve the performance of embedded software, the process industry has
successfully utilized many devices that are not certified for compliance with IEC 61508. FPL devices,
such as PE (“smart”) transmitters, are currently installed in thousands of applications worldwide. The risk
mitigation potential of these PE devices is well proven. Further, the IEC 61508 compliance process does
not extend to the application software that resides in LVL devices. From an owner/operator perspective,
the application software impacts the performance of the PE logic solver in a manner similar to the impact
of the process application on a field device. Bad application software yields poor PE logic solver
performance, regardless of how good the hardware and embedded software may be. Consequently, the
potential for software errors should be addressed during the selection, design, and implementation of the
PE logic solver.

There are a number of approaches to address systematic software errors. These approaches often
consider the type of software being used by the device. This section presents an approach for both FPL
and LVL devices. In accordance with ANSI/ISA-84.00.01-2004, the use of FVL devices or the
development of FVL application software should follow IEC 61508-3 to address systematic errors.

FPL devices have very limited functionality. Hence, the implementation of an FPL device involves highly
repetitive, clearly defined tasks, which minimize the potential for undetected systematic errors. An
approach to minimize systematic errors within FPL devices, such as PE-based transmitters, should take
into account all of the following:

• Use devices that have a large installed base. This allows the owner/operator to gather good prior-
use information on the FPL software.

• Use devices that allow the implementation of external diagnostics. For example, transmitter faults
can be detected by checking transmitter output signal characteristics. This may be accomplished
by comparing redundant transmitter analog signals or through comparison of the SIS transmitter
to the control transmitter. This diagnostic coverage provides protection against many systematic
errors.

• Use an FPL device without externally developed application software. This eliminates a major
contributor to systematic errors.

• Implementation of the prior-use requirements ANSI/ISA-84.00.01-2004, Clause 11.5.4, for FPL

devices that are not IEC 61508 certified by a NRTL.

LVL devices use application software written to perform a wide range of functions. PE logic solvers (e.g.,
PLCs) are commonly used LVL devices. Errors in the application software can be a major contributor to
incorrect results. Systematic errors in LVL devices are typically managed as follows:

--``,`,``,``,`,````,``,

Copyright International Society of Automation

• Prior use analysis of the LVL application software programming and validation tools.

• Prior use analysis of the embedded software in an LVL device.

NOTE -- The depth of prior use is indirectly proportional to the quality of the IEC 61508 review. For example, user approval of an
LVL device requires greater prior-use analysis than user approval of a device that has been IEC 61508 certified by an NRTL. A LVL
device that is not IEC 61508-certified by an NRTL is restricted to a maximum SIL claim limit of SIL 2.

• Implementation of ANSI/ISA-84.00.01-2004, Clause 11.5.5, requirements for LVL devices that are
not IEC 61508 certified by an NRTL.

• Implementation of application software requirements provided in the safety manual.

• Use diverse software channels or diverse technology channels with appropriate comparison
diagnostics to minimize the impact of systematic errors in the application software. This may
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

involve the use of the application software in the BPCS to emulate the SIF logic (e.g., mirroring,
shadowing), providing continuous compare of BPCS and SIF states with appropriate action (e.g.,
alarming or manual shutdown), as needed.

Copyright International Society of Automation

Annex P – Response to detection of a dangerous fault

NOTE -- Annex P is referenced in the following: Clause 4.3 and Clause 4.4.

P.1 Purpose

This annex is intended to provide application guidance regarding ANSI/ISA-84.00.01-2004-1, Clause

11.3, Requirements for system behavior on detection of a fault. This clause addresses the nature of
response associated with three separate cases:

• Fault tolerant safety instrumented systems (SIS) providing protection in either demand mode or
continuous mode (see Clause 11.3.1)

• SIS with no fault tolerance providing protection in the demand mode (see Clause 11.3.2)

NOTE -- No fault tolerance means that a single failure results in the SIF failing to function.

• SIS with no fault tolerance providing protection in the continuous mode (see Clause 11.3.3)

NOTE -- See ISA-TR84.00.04-1, Annex I, for an explanation of demand versus-continuous mode protection.

P.2 The basics

Dangerous device faults are detected in many different ways, such as:

1) Diagnostics

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
2) Proof testing

3) Inspection

4) Operator supervision of the process

5) Other means

Diagnostic fault alarms can be displayed on the BPCS interface. For the basics of alarm types, nameplate
labeling, human engineering, display characteristics, and applications, refer to ISA-18.1, ISA-RP60.3-
1985, and ISA-RP60.6-1984. These industry practices address good engineering practice for the
implementation of alarms and should be utilized, as appropriate.

When these faults are detected online, a choice is made as to whether to continue operation of the
process as it is or to take action on the process to achieve a safe state or to maintain safe operation. This
choice is related to many factors, including but not limited to the following:

• Consistency with the hazard and risk analysis

• Initiating cause frequency

• Consequence severity

• Presence of other independent protection layers

• Process safety time (i.e., the time it takes for the hazardous event to propagate)

• Mode of operation (i.e., continuous versus demand)

Copyright International Society of Automation

• Device safety manual requirements

• Fault tolerance (redundancy and voting)

Each of these factors provides information regarding the process risk of continued operation, which is the
primary concern when the intent is to continue normal operation in the presence of a known SIF fault.
Fault tolerance is a design characteristic of the SIF and is discussed in ISA-TR84.00.04-1, Annex K.

Achieving or maintaining a safe state is often thought of as “shutting down the process;” and this is given
as one of the examples found in notes included in ANSI/ISA-84.00.01-2004-1, Clause 11.3. However,
achieving or maintaining a safe state could also represent a host of other responses (or compensating
measures), such as:

• Running at reduced rates

• Implementation of reduced safe operating limits

• Suspension of use of a hazardous material

• Implementation of additional safeguards

• Provision for independent alarm with operator response

• Increasing operator staffing, e.g., continuous monitoring with alternate means of initiating
shutdown

• Limiting process operating modes, e.g., do not allow decoking to occur in Furnace-101

Because of the complexity of chemical processes, the response selection should be tailored to the
characteristics and requirements of each plant and safety function. A hazard and risk analysis defines for
each hazard scenario when action should be taken, giving the initiating causes, consequence severity,
and protection layers. The potential for common cause should also be evaluated to ensure the actions
can be implemented in the presence of the initiating cause and the SIF device fault.

When no hazard exists, continued operation of the process is generally preferable to initiating an
unnecessary shutdown. Shutdown can cause additional hazards, such as large flaring events or cascade
shutdowns of other process units, and does result in the need to restart the process unit with all of its
potential hazards. The decision to shut down versus continued operation is made by balancing the risk
posed by the potential process hazard if a process demand occurs and the risk associated with shutdown
and start-up. This decision is greatly influenced by the relative robustness of the SIS architecture and
system utilities. The path can be selected at the channel, sub card, card, or CPU level of the system. The
device safety manual may contain specific requirements that should be followed, unless a detailed
analysis of the final system architecture demonstrates that deviation from the safety manual is
acceptable.

If the choice is to continue operation, plant personnel should be notified of the fault (e.g., BPCS HMI
alarm), and any necessary compensating measures should be put in place until the fault is repaired, and
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

the device is returned to service. The diagnostic alarm that indicates a device fault may be displayed on
the BPCS HMI, but the diagnostic alarm is subject to proof testing, access security, and management of
change (MOC). Continued operation within the MTTR is restricted based on the fault tolerance and SIF
operating mode, as discussed in P.2 through P.4, so it is important that the MTTR be documented in the
safety requirements specification.

Copyright International Society of Automation

If maintenance requires longer than the MTTR assumed in the PFDavg calculation, consideration should
be given to how safe operation is maintained for the extended period. To support this concept, many
companies have adopted an internal practice that mandates that repair is completed within the MTTR. In
these companies, extensions beyond the MTTR require MOC approval. Thus, the MTTR becomes a
critical maintenance parameter for the SIF. The MOC review generally considers the following:

• What is the hazard? This should be documented in the hazard and risk analysis and in the safety
requirements specification. Care should be taken to ensure that the hazard is fully understood.

• Are there other safeguards or protection layers to prevent and/or mitigate the hazard, e.g., BPCS
interlocks, SIFs, or other non-SIS protection layers?

• What is the risk reduction provided by the SIF?

• Can this risk reduction be provided by other compensating measures for a temporary time
period?

• Are there safety manual or operating procedure requirements related to the MTTR, e.g., does it
require shutdown after a specified amount of time?

• Do the operating and maintenance procedures adequately address the potential hazards during
bypass?

The choice to continue operation as is or to take action to achieve or maintain a safe state should be
documented in the safety requirements specification so that the design is implemented to support the
choice. The instrumentation and controls used as part of a compensating measure should be subject to
periodic proof testing, access security, and management of change. It should also be understood that
ANSI/ISA-84.00.01-2004 permits operation of the process for a limited time period with a degraded or
disabled SIF when other temporary compensating measures can be put in place and are being managed
sufficiently to provide the required risk reduction. It does not mean that extended operation with a
degraded or disabled SIF is acceptable.

The actions required to maintain safe operation during degraded or disabled states should be defined for
each SIF. Refer to ISA-TR84.00.04-1, Annex B, for a discussion of operator-initiated safety functions and
ISA-TR84.00.04-1, Annex F, for a discussion of the relationship between the SIS and BPCS. Any
procedures required to continue safe operation should also be documented, followed by training of
operation and maintenance personnel.

P.3 Manual shutdown requirements

ANSI/ISA-84.00.01-2004 contains several references to the need to provide a manual shutdown backup
for the logic solver. The main reference is clause 11.2.8, which states, “Manual means (for example,
emergency stop push button), independent of the logic solver, shall be provided to actuate the SIS final
elements unless otherwise directed by the safety requirement specifications.” This clause outlines a
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

specific way a manual shutdown may be implemented, but allows the user to specify other ways to
provide a manual shutdown. Manual shutdown can be initiated by the operator using the BPCS, remote
or local pushbuttons and switches, or directly with process equipment, e.g., manual closure of valves.
Manual shutdown capability should be provided for any SIS where maintenance bypasses are used to
support online equipment repair, maintenance, and proof test.

Why is a manual shutdown needed at all? The process requirements specification defines how manual
shutdown should be executed from the process perspective. Operators are often provided with manual
pushbuttons to initiate equipment shutdown. Operators are expected to initiate trained responses to a
variety of shutdown indicators, such as process indications, process alarms, observed events, protective
alarms, emergency alarms, or procedures.

Copyright International Society of Automation

The ability to shutdown the process, independent of the BPCS controller and SIS logic, solver may be
required for some applications. The current editions of NFPA 85 and NFPA 86 require independent
means for equipment covered by these practices. The SIS logic solver has a very low failure rate, but
what will you do when it fails? Even with the very low failure rate, programmable electronic systems can
fail. Equipment safety manuals may specifically require independence, especially for SIL 3 applications.
When non-fail-safe design is used, e.g., energize to shutdown, independent shutdown facilities should be
provided that do not require the SIF support system to be operational.

Manual shutdown facilities should be defined, including the specific operator actions and physical means
of initiating the shutdown through the final elements that take action on the process. Physical means may
be located as required, such as in the field and/or control room. Field-mounted shutdowns are often
provided for mechanical equipment, such as pumps and compressors. In most cases, providing the
manual means of bringing the process to a safe state is a simple action, to actuate the final elements. But
there are cases where actuating the final elements in the wrong sequence can produce a much greater
hazard. In these cases, using a highly reliable SIS logic solver to bring the process to a safe state may be
acceptable. This is not without risk. The user will need to take extra care to ensure through program
reviews, commissioning, and validation that the SIS will function properly during an emergency.

The potential for systematic failure in the process specification, programming, and checkout of the SIS is
not considered in the safety system PFDavg calculation. That failure rate may have a significant
contribution to the potential for loss of the ability to bring the process to a safe state. When there is a
failure, whether you have redundancy or not, you need to provide a way to bring the process to a safe
state. Clause 11.3 presents requirements for system behavior when a fault is detected. The manual
shutdown does not have to be an emergency stop button, which activates the final elements of the SIS,
independent of the logic solver, but some alternate shutdown method should be provided.

For example, you have a SIL 1 SIS interlock on high level on a storage tank containing toxic chemicals.
The operator is off-loading a railcar of material to the storage tank. If the logic solver fails, the operator
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

could press the stop button on the pump and close a manual valve to stop the filling of the storage tank
and mitigate the event.

While the requirement in Clause 11.2.8 allows you to specify an alternate way to provide this protection in
your Safety Requirements Specification, just stating that you will not provide it is not an acceptable
alternative. Refer to Annex B of this technical report for a discussion of operator-initiated safety functions
and to Annex F for a discussion of the relationship between the SIS and BPCS. Any procedures required
to continue safe operation should be documented, including the training of operation and maintenance
personnel.

P.4 Fault-tolerant mode – demand and continuous mode

The first architecture addressed by Clause 11.3 is that of a fault-tolerant SIS that can perform its function
in the presence of a single dangerous fault. Continued operation within the MTTR is taken into account in
the calculation of the probability of random hardware failure. Consequently, the risk is increased slightly
due to a single period of degraded state in the life of the device. It is important to monitor the cumulative
out-of-service period or the number of failures per year because the risk is increased with each additional
out-of-service period. Compensating measures are generally not required when fault tolerance is
implemented, and repair is completed within the MTTR.

When operation is continued beyond the MTTR, the risk is greater than assumed in the calculation, so the
protection provided by the degraded SIF may not be sufficient for a period beyond the MTTR. For this
reason, the standard requires that the user examine how the risk is being managed when continuing to
operate the plant beyond the assumed MTTR.

Copyright International Society of Automation

P.5 No fault tolerance -- demand mode

The second case considered by the standard is where the SIS is not fault tolerant and is providing
protection in a demand mode. Continued operation within the MTTR is taken into account in the
calculation of the probability of random hardware failure. However, in this case, there is no protection until
the faulted device is repaired and returned to service. Therefore, when continuing operation with a
disabled SIF, compensating measures should be identified that provide risk reduction equivalent to that
provided by the SIF in the absence of the fault. These compensating measures should be documented in
the operation and maintenance procedures so that personnel are trained on their appropriate use. To
continue operation beyond the MTTR, a management of change review should be conducted to ensure
that the compensating measures identified are sufficient for extended operation and that priority has been
placed on the repair.

P.6 No fault tolerance -- continuous mode

The final case considered by the standard is where the SIF is not fault tolerant and is providing protection
in a continuous mode. In this case, the hazard is continuously or nearly continuously present, so the
failure of the SIF results in the process incident. Consequently, when a device fault is detected in a non-
fault-tolerant SIF, the standard requires that the process be shut down or compensating measures be
implemented to maintain safe operation. For the compensating measure to be effective, the total time to
detect the fault and to perform the compensating measure should be less than the process safety time
(i.e., the time it takes for the hazardous event to propagate). It is recommended that the time required to
perform the compensating measure be no more than one-half the process safety time. In continuous
mode applications, there is often not sufficient time to implement a compensating measure prior to the
hazardous event. Consequently, the response to a fault is generally to execute the safe shutdown. If
there are compensating measures that can be implemented, it is not recommended to rely on these
measures to continue operation beyond the specified MTTR.
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

P.7 Advantages and disadvantages of the diagnostic alarm response alternatives

The choice about the response to diagnostic alarms is related to risk tolerance. That being the case, at
least from a conceptual point of view, the choice should be made by the owner/operator to ensure a
consistent approach. When looking at specific processes, personnel need to provide their input along with
those who are knowledgeable about process hazards, human response, the plant safety culture, and
design issues. These decisions have a direct impact on plant cost and safety.

It is not the safety equipment manufacturer’s place to make this decision. However, the manufacturer is
responsible for providing adequate information in their safety manual to assist in this decision-making
process.

P.7.1 Immediately initiate the Safety Instrumented Function (vote channel to trip) on diagnostic
alarm

Advantages

• Reduces Risk by taking system to a safe state.

• This could send a message that improves the Safety Culture. For a site that has a poor safety
culture, the action of automatically tripping the unit could improve the safety culture by sending a
strong message to the operators that there is an expectation to run the unit in a safe manner. It
may be seen as the proper balance between production and safety.

• If this action is automated it takes the responsibility out of the hands of the operators. We should
keep in mind that most operators take pride in running the unit and don’t want to trip it unless
absolutely necessary. If it is automated, then the operator does not make the decision.

Copyright International Society of Automation

• This choice can be modeled in the SIL verification of the SIF.

• Provides a predictable system response.

• Better insures that management takes SIF failures seriously.

Disadvantages

• Increases risk of spurious trips.

• This could worsen the Safety Culture if spurious trip rate is excessive, causing personnel to view
these as nuisance trips.

• May only be justified for dangerous failures.

• May not work if final element unable to act (failed).

P.7.2 Initiate the associated Safety Instrumented Function after the Mean Time To Repair

Advantages

• Reduces spurious trip rate by providing an opportunity to repair online, thus eliminating some
unnecessary trips on safe diagnostic alarm.

• Relieves the operator of the responsibility for making the decision, removing any potential conflict
of interest.

• This choice can be modeled in the SIL verification of the SIF.

• It could convey a balance between safety and production.

• Reduces burden on operator (not last line of defense).

• Predictable system response.

• May work if final element unable to act (failed) - manual intervention possible.

Disadvantages

• SIF in degraded state for a longer period of time.

• May provide an opportunity for personnel to implement bypass if getting close to end of time
delay.

• Unpredictable Operator/Maintenance response - may take wrong action.

• Calculated risk - hoping that demand will not come during MTTR delay.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

P.7.3 Alarm only with proper operator corrective action

Advantages

• Reduces spurious trip rate by providing an opportunity to repair online.

• Provides some discretion not allowed by the previous choices.

• May work if final element unable to act (failed) -- manual intervention possible.

• Forces management to take human failures seriously (training, etc).

Disadvantages

• Calculated risk - hoping that demand will not come during delay.

•
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Provides some discretion not allowed by the previous choices.

• Safety coverage degraded relative to automated response, i.e., more detectable dangerous
failures will result in being a realized dangerous failure.

• This could send the wrong message regarding Safety Culture commitment.

• Creates conflict of interest.

• Places additional burden on operator (alarm flooding etc), which may rely on subjective judgment
under stress.

• Unpredictable Operator/Maintenance response -- may take wrong action or respond too late.

• Difficult to justify with current trend for loss of expertise as older staff retire.

P.8 Examples

These are examples of how one company has handled responses to detected failures.

P.8.1 Fault tolerant SIF – demand mode – vessel pressure

In one process using an exothermic reaction, an SIF is designed to prevent the reactor from exceeding 15
psig and releasing hazardous chemicals into the atmosphere. An SIL 2 SIF is installed on the Chemical
Reactor, using 1oo2 voting pressure transmitters to initiate the introduction of a shortstop material to
prevent an exothermic runaway reaction with a subsequent demand on the vessel relief protection. The
BPCS HMI provides the operator with a diagnostic alarm for the pressure transmitters, which indicate that
the pressure transmitter signals deviate from one another by greater than 5%.

In the event that the operator receives a deviation alarm and determines that one of the transmitters has
failed, the operator is trained to contact the maintenance department to repair the transmitter within a
specified allowable time (e.g., the MTTR). Since the SIF is designed to tolerate a single hardware fault,
the pressure transmitter may be repaired, tested, and returned to service within the specified MTTR
without bringing the process to the safe state, as defined in the operating procedure.

Copyright International Society of Automation

P.8.2 Non-fault tolerant SIF – demand mode – tank level

The process consists of two storage vessels, Tank-A and Tank-B. A flammable liquid is pumped from
Tank-A to Tank-B. When the level in Tank-B reaches 90% as detected by a level transmitter, the BPCS
stops the pump and closes the block valve. A dip pipe in Tank-B is designed to provide a siphon break.
During the PHA, a hazard was identified that, if the level transmitter in Tank-B failed, the vessel could be
overfilled resulting in a spill of flammable liquid and a possible fire. An SIL 1 SIF is implemented to
provide independent protection by closing a block valve on the transfer line, if the level in Tank-B exceeds
95% as measured by an SIF level transmitter. During normal testing the technician found that the SIF
level transmitter had failed dangerously and did not operate when the level exceeded 95%.

In this example, the failure of a single device, the SIF level transmitter, would prevent the SIF from
operating, and the rules in Clause 11.3.2 apply. The process engineers recognized this possibility and
developed compensating measures for protecting the process when there is an SIF fault. The operating
procedures allow the process to continue normal operation when an SIF level transmitter fails, if the
operator periodically verifies the tank level, using a field level gauge, and monitors the level control
transmitter for typical changes in the process signal as the transfer occurs. The alternate means of
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

protection are to remain in place until the SIF level transmitter is repaired, tested, and returned to service.

P.8.3 Non-fault tolerant SIF – demand mode – distillation column

The process uses a distillation column to separate methanol and water. During the PHA, the team
identified that failure of the level control loop in the reflux drum could cause the drum to overfill, resulting
in vessel overpressure, opening of a pressure relief valve to the atmosphere, and the liquid release of
methanol with possible fire. An SIL 1 SIF is installed to prevent the level in the reflux drum from
exceeding 95%. The SIF consists of an SIF level transmitter, a trip amp, a block valve on the steam to the
column, and a block valve on the feed to the column. The capacity of the column is such that the column
could be shut down for a short time period without affecting the production operation.

In this case, the process engineer determined that upon detection of a dangerous fault, the SIF should be
initiated. A diagnostic alarm is displayed on the BPCS HMI to alarm when the SIF level signal falls below -
5%, which indicates a failure of the SIF level transmitter. When the operator receives the alarm, the
operator manually activates the SIF per the operating procedures to bring the system to a safe state. The
hazard and risk analysis indicated that there was sufficient process safety time for the operator to
respond effectively (refer to Annex B for more information on operator alarm with response). Alternatively,
the SIF could be configured such that on detection of transmitter failure, the SIF is automatically initiated.

Copyright International Society of Automation

Annex Q – Setpoint guidance

NOTE -- Annex Q is referenced in the following: Clause 2 and Clause 4.3

Q.1 Purpose

The purpose of this annex is to provide guidance for establishing instrument setpoints for safety
instrumented functions in the process industries. The scope of ANSI/ISA-84.00.01 is “requirements for …
a safety instrumented system, so that it can be confidently entrusted to place and/or maintain the process
in a safe state.” This annex provides guidance on instrument uncertainty calculations and setpoint
determination for instruments used in an SIS to ensure that each SIF responds to achieve or maintain the
safe state of the process within one-half of the process safety time with respect to a specific hazardous
event. If measurement uncertainty is not considered in the determination of an SIS setpoint, the SIF may
not detect the presence of a valid process demand.

Q.2 Scope

This annex defines the requirements for assessing, establishing, and maintaining SIS setpoints for
instrument segments. The safe operating limit is not related to the SIS setpoint; it is a function of the
process hazard and identified protection layers. Safe operating limit is beyond the scope of this annex.

Information is required from process engineering to begin the setpoint determination process. For each
SIF, those inputs are the Process Parameter Limit, Process Lag Time, and the Safe Upper and Lower
Limits for the process. A suggested SIS setpoint or range would also be beneficial.

The scope includes process measurement setpoints that are used to achieve or maintain the safe state of
the process. The annex considers:

a) Common assumptions and practices in instrument uncertainty determinations

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
b) Equations for estimating uncertainties

c) Methodologies to calculate total segment uncertainty

d) Application of instrument uncertainty in setpoint determination

Q.3 Definitions

Definitions that are new and not previously documented in ANSI/ISA-84.00.01-2004 are indicated with (*).

Q.3.1 As-found*: the condition in which a segment, or portion of a segment, is found after a period of
operation and before recalibration or repair (if necessary).

Q.3.2 As-left*: the condition in which a segment, or portion of a segment, is left after final device
setpoint verification.

Q.3.3 As-left tolerance*: the maximum acceptable deviation from the Selected Setpoint (SSP), such that
leaving the equipment anywhere in the identified band will assure that activation occurs within the
setpoint analysis.

Q.3.4 Design basis*: the process safety and engineering information relied upon to define the
instrument segment function and activation timing.

Q.3.5 Design limit (DL)*: the extreme value of a process variable that protects the mechanical integrity
of the process equipment.

Copyright International Society of Automation

Q.3.6 Drift*: a variation in sensor or instrument segment output that may occur between calibrations and
cannot be related to changes in the process variable or environmental conditions.

Q.3.7 Error: discrepancy between a computed, observed, or measured value or condition and the true,
specified, or theoretically correct value or condition.

NOTE -- Adapted from IEV 191-05-24 by excluding the notes.

Q.3.8 Maximum (or Minimum) SIS setpoint (MSP)*: the closest approach value to the Process
Parameter Limit, allowing for process measurement uncertainty.

Q.3.9 Measurement Uncertainty*: the amount to which an instrument segment’s output is in doubt (or
the allowance made for such doubt) due to possible errors. The uncertainty is generally identified
within a probability and confidence level.

Q.3.10 Never Exceed Limit *: the closest approach value to the Design Limit, allowing for operational and
mechanical integrity uncertainties.

Q.3.11 Operating Limit Margin*: the margin between a selected SIS setpoint and the Safe Upper or
Lower Limit

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Q.3.12 Performance Acceptance Test Limits*: the maximum and minimum segment input values, within
which equipment under test should actuate, to protect the assumptions of the setpoint uncertainty
calculation.

Q.3.13 Performance test*: a test that evaluates the performance of equipment against a set of criteria.
The results of the test are used to support an operability determination.

Q.3.14 Process Lag Time: a value, either calculated or estimated, that accounts for dynamic effects after
the safety action (e.g., closure of a valve) has been completed.

Q.3.15 Process Parameter Limit: the closest approach value to the Never Exceed Limit, allowing for
process response lag time.

Q.3.16 Qualified Data*: data for which documentation exists to demonstrate its compliance with current
QA or procedural requirements.

Q.3.17 Reference accuracy*: a number or quantity that defines a limit that errors will not exceed when a
device is used under specified operating conditions.

Q.3.18 Safety Margin: a value, either calculated or estimated, that allows for operational and mechanical
integrity uncertainties.

Q.3.19 Segment*: an arrangement of components and modules as required to generate a single

protective action signal when required by a process condition

Q.3.20 Selected SIS setpoint (SSP)*: a predetermined value for actuation of a final setpoint device to
initiate a protective action

Q.3.21 Sensor: device or combination of devices that measure the process condition (for example,
transmitters, transducers, process switches, position switches)

Copyright International Society of Automation

Q.3.22 Safe Upper and Lower Limits *: the extreme values within which a process should be maintained
during normal operation

Q.3.23 Total Segment Uncertainty (TSU)*: the expected performance of the SIS process measurement
under any applicable process and environmental conditions

Additional definitions and clarifications related to instrumentation terminology and uncertainty may be
found in ISA-51.1-1979 (R1993) and ANSI/ISA-37.1-1975 (R1982).

Q.4 Establishment of setpoints

Setpoints for SIFs should be selected such that actions can be taken to achieve or maintain the safe state
of the process within the allocated process safety time.

Q.4.1 Process Parameter Limit

The Process Parameter Limit (PPL) is the least conservative value of a given process variable at which
the initiation of the SIF will reasonably protect the process equipment for each postulated event. The PPL
and its basis should be managed as process safety information.

Q.4.2 SIS setpoints

Setpoints are chosen to assure that a safety actuation occurs before the process reaches the PPL. Trip
setpoints are also chosen to assure that the plant can operate and experience expected operational
transients without unnecessary trips or safeguard actuations.

• The Maximum SIS setpoint (MSP) is the least conservative value for SIF actuation that ensures
that the PPL is not exceeded.

• The selected SIS setpoint (SSP) can be more conservative than the MSP due to plant conditions
or as a compensatory action.

• Range for Safety Setpoint - The safety setpoint for an SIS can be selected anywhere between the
Upper Operating Limit and the Maximum SIS Setpoint.

See Figure Q-1 for a graphical relationship between these values.

Q.4.3 Choosing trip setpoints

The choice of an MSP requires determining the Total Segment Uncertainty (TSU). The TSU represents
the expected performance of the SIS process measurement under any applicable process and
environmental conditions. The trip or actuation is only required to prevent or mitigate certain postulated
events, so only the process and environmental conditions that occur during those postulated events
should be considered.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Figure Q.1 — Increasing process variable, illustrating relationships of measurement terminology

Copyright International Society of Automation

Figure Q.2 shows the MSP and SSP for a trip on an increasing process:

MSP = PPL – TSU

SSP = PPL – TSU – Margin where the Margin is discretionary

NOTE -- To reduce the potential for spurious activation, SSP selection should consider an Operating
Margin at least as large as the TSU.

Figure Q.2 Setpoint Selection Relationships

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Qualified data should be used to calculate the TSU. Data sources may include any of the following:
operating experience, equipment qualification tests, equipment specifications, engineering analysis,
laboratory tests, and engineering drawings. The TSU should account for the effects of process instrument
uncertainties, considering the following:

a) Instrument calibration uncertainties caused by

1) calibration standards;

2) calibration equipment;

3) calibration method;

4) calibration environmental effects; and

5) setting tolerance.

b) Instrument uncertainties during normal operation caused by

1) reference accuracy, including conformity (linearity), hysteresis, deadband, and

repeatability;

2) power supply voltage changes;

3) power supply frequency changes;

4) temperature changes;

5) humidity changes;

6) pressure changes;

7) vibration effects;

8) process effects;

9) instrumentation transfer functions;

10) analog-to-digital conversion; and

11) digital-to-analog conversion.

c) Instrument drift

Instruments may be calibrated on different schedules. The drift used should be based on
instrument-specific calibration intervals, including allowable extensions for calibration intervals.
When the manufacturer’s specification for stability (drift) is unavailable, 50% of the instrument
calibration accuracy per year is commonly assumed.

d) Instrument uncertainties caused by operating and incident conditions

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Only uncertainties specific to the event and required period of service should be used. The use of
different uncertainty components for the same segment may be appropriate for different events.

e) Process-dependent effects

The determination of the TSU should account for uncertainties associated with the process
variable. Examples include (but are not limited to) the effect of fluid stratification on temperature
measurement, the effect of changing fluid density on level measurements, and process
oscillations or noise.

f) Calculation effects

The determination of the TSU should account for uncertainties resulting from the use of a
mathematical model to calculate a variable from measured process variables.

g) Dynamic effects

The behavior of a segment’s output as a function of the input with respect to time should be
accounted for, either in the determination of the trip setpoint or included in the hazard analyses.
The selected setpoint should ensure that the SIF responds to achieve or maintain a safe state of
the process within one-half of the process safety time with respect to a specific hazardous event.
Special attention should be paid to potential delay mechanisms, such as temperature

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
measurements through thermowells and pressure measurement through capillaries, as these
mechanisms may obscure dangerous process variations.

h) Calibration and installation bias accounting

Any bias of fixed magnitude and known direction due to equipment installation or calibration
method should be either eliminated during calibration or accounted for in the uncertainty analysis.

i) Setpoint considerations

Calculations for setpoints should consider the process range and use the following guidelines:

• Instrument Range should be 120% of the process range

• Setpoints are preferred to fall within 20% to 80% of the instrument range

• Setpoints are not to fall within the upper and lower 5% of the instrument range

• Flow setpoints, based on differential pressure measurements, should not be in the lower
20% of the instrument range.

Q.4.4 Combination of uncertainties

The uncertainty terms discussed above can be deterministic, statistical, or some combination and should
be combined using appropriate techniques. The result of the combination should be a value that
represents the performance of the SIS process measurement, either with a 95% probability, or (where
information is limited) with high probability as justified by reasonable basis.

Square-root-sum-of-squares (SRSS) and arithmetic are common techniques for combining uncertainties.
Other more complex techniques, including probabilistic modeling, stochastic modeling, or a combination
of these techniques may also be used.

Copyright International Society of Automation

Q.4.4.1. Square-root-sum-of-squares method

It is acceptable to combine uncertainties that are random, normally distributed, and independent by the
SRSS method. When two independent uncertainties, (± a) and (± b), are combined by this method, the
resulting uncertainty is (± c), where c = SQRT(a² + b²).

Q.4.4.2. Arithmetic method

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
It is acceptable to combine any uncertainties, including those that are not random, not normally
distributed, or are dependent, by the arithmetic method. In this method, the combination of two dependent
uncertainties, (+a, -b) and (+c, -d), results in a third uncertainty distribution with limits + (a+c), - (b+d).

Q.4.4.3. Test interval and scope

The time between tests and the test scope may affect the magnitudes of some of the uncertainties, such
as drift. Therefore, the uncertainty analysis should include consideration of the test scope and test
interval.

Q.4.4.4. As-left limits

The uncertainty analysis should determine an as-left band, bounding the equipment performance after
calibration. This tolerance should be included in the TSU such that leaving the equipment anywhere in the
as-left band will assure a trip before the PPL is reached.

Q.4.5 Performance test acceptance criteria

Instrumentation that implements SIS setpoints should be periodically tested to verify the equipment
performs as expected. This may consist of one or more performance tests.

The acceptance criteria for all performance tests should be based on the performance of the
measurement under the test conditions, which may differ from the operating environment. The
acceptance criteria should be tight enough to avoid masking equipment degradation. The criteria should
be developed from the same data and using the same (or more conservative) combinational techniques
as that used to determine the TSU. Only those effects expected to be present during the test should be
included in the calculation of the performance test acceptance criteria. These are typically limited to:

• setting tolerance;

• instrument uncertainties during normal operation, including drift; and

• measurement and test equipment uncertainties.

The performance test acceptance criteria may also be known as the as-found limits (or band) for the test
being performed.

Q.5 Documentation

The PPL and the basis for that limit should be identified in setpoint calculations.

The bases of the uncertainty calculation (e.g., instrument uncertainties, process effects, calculation
methods, data sources, and assumptions) should be stated in the setpoint calculation.

Copyright International Society of Automation

a) The method(s) by which setpoints are calculated should be clearly stated. The documentation
may include, as appropriate, the following:

1) The relationship between the PPL, the MSP, the SSP, the as-found limit, and the as-left
limit;

2) The uncertainty terms that are addressed;

3) The method used to combine uncertainty terms; and

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
4) Justification of complex combination methods (other than SRSS or arithmetic
combination).

b) The setpoint calculations should be controlled as process safety information. The documentation
may include, as appropriate, the following:

1) A description of the instrument segment, including the manufacturer and model number
of all devices that contribute to the segment uncertainty;

2) The relationship between instrument and process measurement units;

3) The PPL;

4) The selected values for trip setpoints;

5) The source(s) of the data used in the setpoint calculation;

6) Assumptions used to select the SIS setpoint, e.g., ambient temperature limits for
equipment, calibration, and operation and their bases;

7) Known installation and calibration bias values that could affect the setpoint;

8) Correction factors used to determine the setpoint, e.g., pressure compensation to

account for elevation difference between the trip measurement point and the sensor
physical location; and

9) Accuracy requirements for the measurement and test equipment used in the calibration
or functional testing.

c) Performance test acceptance criteria and their bases should be controlled as process safety
information.

d) Performance test data should be documented, including as-left and as-found measurements.

Q.6 Testing and maintenance of SIS setpoints

Periodic SIF tests should ensure that the SIF setpoints remain within their established limits during
operation. Formal documentation of the test results is necessary to support the investigation and
resolution of any occurrence where a limit is exceeded. Exceeding a limit in either a high or low direction
may indicate degraded performance and inability of the instrument segment to meet its intended function.

This verification should be achieved by recording as-found data to determine the setpoint in terms of the
measured or derived process variables, prior to any adjustment. As-found data should be the data taken
during the first traverse in the direction of concern during the test.

Copyright International Society of Automation

When the as-found condition is within the Performance Acceptance Test Limit, but outside the as-left
tolerance, the setpoint should be returned within the range assumed in the setpoint analysis.

If as-found data indicates that an acceptance criterion was exceeded, appropriate corrective action
should be taken. This action should include, as required, investigation to determine the cause of the
finding, evaluation of operability, interim compensating measures, trending, and appropriate corrective
action to prevent a re-occurrence. Possible actions for consideration are:

a) adjustment of testing interval;

b) setpoint revision (in the conservative direction);

c) re-evaluation of the trip setpoint or acceptance criterion (as applicable);

d) evaluation of equipment installation and environment;

e) evaluation of calibration (equipment and technique);

f) repair or replacement of the device; or

g) procedure change to implement supplemental actions

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Annex R – Key performance indicators

NOTE -- Annex R is referenced in the following: Clause 2.

The HSE study, Findings From Voluntary Reporting of Loss of Containment Incidents 2004/05, reported
that 32% of loss-of-containment events were caused by process and safety equipment failure, which
occurred due to inadequate design and maintenance. SIS equipment performance is limited by the rigor,
timeliness, and repeatability of mechanical integrity activities. Key performance indicators are
recommended as a means to ensure that the various requirements of ANSI/ISA-84.00.01-2004 are
implemented as expected. Sustainable operation is achieved by focusing on indicators that provide real-
time indication of compliance to expectations. Example indicators are provided in Table 1 for the SIS.
Additional recommended indicators have been published by CCPS in “Guidelines for Process Safety
Metrics.”

Selecting appropriate performance indicators to track can seem like an overwhelming task. It is important
to ensure that the intent of the indicator is understood rather than simply managing the indicator itself. For
example, most performance indicators focus on schedules, which are not indicative of work quality or
performance integrity. A proof-test schedule can be based on unreasonably long test intervals. Testing
can be performed on schedule but in an inadequate or incomplete manner. A schedule-based indicator
can create an illusion that the SIS is well-maintained while equipment is failing in the field. Additionally, a
focus on the percentage of success or failure of various activities can also lead to normalization of some
failures, which is unacceptable for SIS. Any piece of failed SIS equipment represents a gap in the risk
reduction strategy. Since all safety equipment is typically managed using similar indicators, a poorly
implemented indicator may negatively impact multiple layers and/or events.

The risk reduction strategy is proven by mechanical integrity data, which demonstrates that the SIS can
achieve the performance assumed during the process hazards analysis. Consideration should be given to
tracking out-of-service periods where equipment has failed and is awaiting repair or where equipment is
bypassed for maintenance and/or test. This is because the risk reduction provided by a piece of
equipment is directly related to it being able to perform as required when a process demand occurs. ISA-
TR84.00.02 provides guidance on estimating equipment performance for the purpose of the PFDavg
calculation required in ANSI/ISA-84.00.01-2004 Clause 11.9. Mechanical integrity records demonstrate
prior use history and should serve as a basis for failure rate estimates. With good record keeping, the
actual performance of specific equipment can be compared with prior assumptions in the process
hazards analysis, prior-use demonstration, and safety requirements specification.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
ISA-TR84.00.03 provides guidance on implementing a mechanical integrity plan and records-retention
program. Existing SIS performance should be periodically assessed by tracking and trending equipment
performance. Failure tracking is essential for quality assurance of SIS mechanical integrity. Repeated
failures indicate that there is a problem, which should be addressed through root-cause analysis to
determine why indicators are trending in the wrong direction. Action plans can be implemented to improve
the mechanical integrity schedule, equipment installation, maintenance procedures, and personnel
training.

Near-miss and incident investigations may identify SIS inadequacies or failures. Spurious trips and
process demands should also be tracked and compared with expectations in the hazard analysis.
Management-of-change processes should be used to improve the equipment or systems, to resolve
performance gaps.

Continued safe use of existing equipment or systems is considered “grandfathering” where the
owner/operator determines that the existing equipment is designed, maintained, inspected, tested, and
operating in a safe manner. This requires an assessment of the existing design and management
practices against current good engineering practices and process requirements. The review should
determine whether the existing SIS is operating per the safety requirements specification, and the current
management system is sufficient to yield the required risk reduction. ISA-TR84.00.04-1, Clause 3.0, and
Annex A provide more detailed discussion of the grandfather clause.
Copyright 2011 ISA. All rights reserved.

Copyright International Society of Automation

Table R.1 — Example Indicators Related to Safety Instrumented Systems (SIS)

Lifecycle Step Key Performance Indicator Formula – Deliverable

Hazard Analysis Hazard and risk analyses: Percent % KPI = 100 X (No. overdue / No. scheduled)
overdue

Hazard and risk analyses: Pareto chart listing days behind schedule
Days overdue NOTE -- This may be used to measure currently
overdue analyses and/or completed analyses for
comparison purposes
Safety Percent SIF with incomplete SRS % KPI = 100 X (No. SIF with incomplete SRS
Requirements information information / Total No. SIF)
Specification
Percent SIF with no SRS information % KPI = 100 X (No. SIF with no SRS information /
Total No. SIF)
Percent of SRS completed before %KPI = 100 X (No. SRS completed before project/MOC
project /MOC approval approval / total number of SIS projects/ MOC )
Mechanical Inspections: Percent SIF overdue % KPI = 100 X (No. overdue / No. scheduled)
Integrity
Inspections: Days overdue Pareto chart listing days behind schedule
NOTE -- This may be used to measure currently
overdue inspections and/or completed inspections for
comparison purposes

Inspections: Percent failed % KPI = 100 X (No. failed / No. performed)

Proof Tests: Percent SIF overdue % KPI = 100 X (No. overdue / No. scheduled)
Proof Tests: Days SIF overdue Pareto chart listing days behind schedule
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

NOTE -- This may be used to measure currently

overdue proof tests and/or completed proof tests for
comparison purposes
Proof Tests: Percent SIF failed % KPI = 100 X (No. failed / No. performed)
Corrective maintenance: % KPI = 100 X (No. overdue / No. scheduled)
Percent SIF overdue
Corrective maintenance: Pareto chart listing days corrective maintenance
Days SIF overdue behind schedule
NOTE -- This may be used to measure currently
overdue corrective maintenance and/or completed
corrective maintenance for comparison purposes
Corrective maintenance: % KPI = 100 X (No. failed Specification criteria / No.
Percent failed specification criteria performed)

Failure to Activate: Percent SIF failed % KPI = 100 X (No. SIF Failed to Activate / Total No.
NOTE -- Failure to Activate includes of SIF)
all cases where the SIF does not
respond to the process deviation and
an event occurs or the SIF needs to
be manually activated
Shutdowns: Percent SIF Spurious % KPI = 100 X (No. spurious SIF initiated shutdowns /
Total No. of SIF systems)
Degraded SIF out of service: Total hours Pareto chart listing hours out of service
Operation NOTE -- Out of service includes any NOTE -- This may be used to measure SIF currently
time the SIF is unavailable during an out of service and/or restored out of service SIF for
operating mode where the hazard comparison purposes
exists.

Copyright International Society of Automation

Lifecycle Step Key Performance Indicator Formula – Deliverable

SIF out of service: Percent % KPI = 100 X (No. out of service hours/Total no.
process hours)
SIF degraded: Percent % KPI = 100 X (No. hours SIF degraded/Total number
of process hours)
NOTE -- Degraded includes any time
a portion of the SIF is bypassed but is
still able to perform its function
automatically
SIF out of service: Hours beyond Pareto chart listing hours beyond specified repair time
specified repair time NOTE -- This may be used to measure SIF currently
beyond specified repair time and/or repaired SIF that
had exceeded specified repair time for comparison
purposes
SIF out of service: Percent beyond % KPI = 100 X (No. SIF beyond specified repair

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
specified repair time time/Total no. of SIF out of service during
measurement interval)
SIF out of service: Percent Not % KPI = 100 X (No. out of service & not approved by
Approved by MOC MOC / Total out of service SIF)

Operations Start-ups: Percent SIF initiated % KPI = 100 X (No. SIF initiated start-ups / Total No.
Monitoring of start-ups )
NOTE -- Total No. of start-ups includes the number of
start-ups that the SIF initiates plus the number of start-
ups where the SIF does not initiate.
Alarms: Average rate KPI = Total number of alarms within time interval / time
interval
Alarms: Flood distribution Pareto chart listing total no. of alarms annunciated
within 10 minute intervals in descending order
Alarms: 10 minute rate KPI = Total number of alarms within 10 minute time
interval / 10 minutes
Alarms: Percent suppressed KPI = Total number of suppressed alarms / Total No.
of available alarms
Alarms: Standing Pareto chart listing hours for alarms greater than 24
hours old
NOTE -- This may be used to measure current
standing alarms and/or cleared standing alarms for
comparison purposes
Shutdowns: Percent SIF response to % KPI = 100 X (No. SIF initiated shutdowns in
process deviation response to process deviation / Total No. systems)

Copyright International Society of Automation

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Annex S – Differences between 1996 and 2004 versions

NOTE -- Annex S is referenced in the following: Clause 2.

ANSI/ISA-84.01-1996 is recognized as a good engineering practice for the design, operation,

maintenance, inspection, and testing of safety instrumented systems by many owners/operators.
ANSI/ISA-84.00.01-2004-1 builds upon ANSI/ISA-84.01-1996, using an enhanced SIS lifecycle that
includes:

1) requirements for activities that were not covered due to scope limitations of ANSI/ISA-84.01-
1996;

2) new requirements necessary to address technology changes; and

3) expanded requirements that are the result of new consensus.

The following is a brief overview of requirements of ANSI/ISA-84.00.01-2004-1, highlighting some of the

significant differences between ANSI/ISA-84.01-1996 and ANSI/ISA-84.00.01-2004-1. It is important that
the reader of this clause be familiar with the content of ANSI/ISA-84.01-1996. A summary of the
differences by topic is provided in Table 4-1.

S.1 Clause 1 - Scope

This clause states that manufacturers who claim that their equipment is designed for use in SIS should
satisfy the requirements defined in IEC 61508. ANSI/ISA-84.01-1996 does not address this issue.

ANSI/ISA-84.00.01-2004-1 provides extensively detailed requirements for application software in Part 1,

Clause 12, “Requirements for application software, including selection criteria for utility software.” In
comparison, ANSI/ISA-84.01-1996 provided less definitive requirements for application software in
Clause 7.8.3, “Application logic for Programmable Electronic Systems (PES).”

ANSI/ISA-84.00.01-2004-1 identifies SIL 4 as the maximum level of performance for a Safety

Instrumented Function covered under this standard. ANSI/ISA-84.01-1996 identified SIL 3 as the
maximum level of performance for a Safety Instrumented Function.

ANSI/ISA-84.01-1996 excluded systems where the operator was the sole means of returning the process
to a safe state. ANSI/ISA-84.00.01-2004-1 did not specifically exclude this type of system, but did not
explicitly include it either. ANSI/ISA-84.00.01-2004-1 Clauses 11.3.1 through Clauses 11.3.3 provide
requirements where the operator is required to take specific action in response to safety critical alarms
and diagnostic alarms. When the Hazard and Risk Analysis (H&RA) identifies a critical alarm as a
protection layer, the detection and response may include many different components, such as sensor(s),
logic solver, operator HMI, and final element(s). It is important that all elements, including the operator, be
capable of achieving the required risk reduction. ISA-TR84.00.04-1 Annex B provides additional
discussion on this subject.

S.2 Clause 2 – References

ANSI/ISA-84.00.01-2004-1 lists four parts of IEC 61508 as normative references. ANSI/ISA-84.01-1996

lists a number of informative references in ANSI/ISA-84.01-1996, Annex C, but no normative references.

--``,`,``,``,`,````,``,,`,

Copyright International Society of Automation

S.3 Clause 3 – Abbreviations and definitions

There are a number of new abbreviations and terms in ANSI/ISA-84.00.01-2004-1. There is also
clarification or expansion of some definitions associated with terminology used in ANSI/ISA-84.01-1996.

Perhaps, the most significant new term is “Safety Instrumented Function” (SIF). In ANSI/ISA-84.01-1996,
there was very little differentiation between an SIS and SIF. ANSI/ISA-84.00.01-2004-1 spells out the
difference between the SIF (e.g., hardware & software used to mitigate a specific process risk) and the
SIS (i.e., the hardware and software used to implement multiple SIFs). For example, consider a process
furnace. If the main fuel gas pressure to the burner is too high, the flame may blow out, allowing
uncombusted gases to be introduced into the furnace with the potential for a fire within the furnace. To
prevent this hazard, an SIF is implemented in which block valves are used to isolate the main fuel gas
from the process furnace when high fuel gas pressure is detected. These same main fuel gas valves may
also be closed in response to low pilot gas pressure (i.e., a different process hazard). The SIS is the
implementation of these two SIFs in the same logic solver.

The term “prior use” is used in ANSI/ISA-84.00.01-2004-1. This term is applied when the owner/operator
is justifying the implementation of a device in an SIF application based on prior use of the device in a
similar operating profile. The standard provides specific requirements for assessing “prior use” for devices
based on the device type, safety integrity level, and, in the case of PE logic solvers, the safe failure
fraction.

ANSI/ISA-84.00.01-2004-1 introduces three types of software languages: fixed program language, limited
variability language and full variability language. The standard covers the development of application
software using fixed program language and limited variability language. Owners/operators are directed to
IEC 61508 for the development of application software using full variability language.

S.4 Clause 4 – Conformance to standard

The conformance clause in ANSI/ISA-84.00.01-2004-1 is very similar to the conformance clause in

ANSI/ISA-84.01-1996.

S.5 Clause 5 – Management of functional safety

ANSI/ISA-84.00.01-2004-1 has a number of new requirements concerning the management of functional

safety. Although a number of these new requirements are not specifically identified in ANSI/ISA-84.01-
1996, they are identified in other documents that are in widespread use in the United States, e.g., OSHA
1910.119 and the CCPS book “Guidelines for Safe Automation of Chemical Processes.”

ANSI/ISA-84.00.01-2004-1 addresses the competency requirements for individuals involved in the safety
lifecycle. Competency requirements are not addressed in ANSI/ISA-84.01-1996, because competency
was already addressed in OSHA 1910.119 for all disciplines involved in process plant design,
maintenance, and operation. Since the standard has an international scope, the competency
requirements are presented for the benefit of those owners/operators that do not have a regulatory --``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

system in place that defines these requirements. ISA-TR84.00.04-1 Annex C provides additional
guidance on the management of functional safety through effective project management and quality
control processes.

ANSI/ISA-84.00.01-2004-1 requires procedures for evaluating the performance of an SIS after the system
has been in operation for a period of time. This includes comparing the actual process demands with
what was assumed during the risk assessment and determining whether the actual failures of the SIS
components are in accordance with what was assumed during the design and verification phases.
ANSI/ISA-84.01-1996 did not have specific requirements for this evaluation.

Copyright International Society of Automation

ANSI/ISA-84.00.01-2004-1 has specific requirements for conducting functional safety assessments during
the SIS lifecycle. It also includes requirements for the composition of the assessment team. The one
mandatory assessment is at Stage 3 of the SIS lifecycle. This assessment is included in ANSI/ISA-84.01-
1996 and OSHA 1910.119, but it is called the Pre-Startup Safety Review (PSSR). The standard simply
clarifies the PSSR, as it pertains to the SIS. The major difference is that ANSI/ISA-84.00.01-2004-1
requires the inclusion of an independent, senior, competent person on the team. ISA-TR84.00.04-1,
Annex C, has additional discussion concerning this requirement.

The terms verification, validation, and functional safety assessment are used in ANSI/ISA-84.00.01-2004-
1. Each term implies that specific activities are taking place or that specific requirements are being met.
Annex D provides an overview of these three terms.

ANSI/ISA-84.00.01-2004-1 has a requirement for periodic auditing to ensure compliance with the
requirements in the standard. ANSI/ISA-84.01-1996 does not have a specific requirement for periodic
auditing. Following the ANSI/ISA-84.00.01-2004 lifecycle ensures that the intended design, operation,
maintenance, and testing of the SIS are sufficient to achieve the functional and integrity requirements.
Auditing is a means to ensure that these intentions result in actual work practices. These audits should be
considered opportunities to review the effectiveness of the management-of-change system. ISA-
TR84.00.04-1, Annex E, provides an example of how to approach and perform an audit.

S.6 Clause 6 – Safety lifecycle requirements

The ISA84 committee created ANSI/ISA-84.01-1996 to supplement OSHA 1910.119 in the areas related
to the implementation of instrumentation and controls necessary for safe operation. Rather than repeating
OSHA 1910.119 mandates, the standard references OSHA 1910.119 for some key program elements.
Specifically, ISA-84.00.01-1996 does not provide specific requirements for safety management, hazard
and risk analysis, pre-start-up safety review, or training. ISA-84.00.01-2004 provides requirements for
each of these areas.

S.7 Clause 7 – Verification

ANSI/ISA-84.00.01-2004-1 requires the development of a verification plan to define the verification

activities that are to take place. There was no specific verification clause in ANSI/ISA-84.01-1996
standard. However, most owners/operators include a number of verification steps during project
execution for project and quality management purposes.

S.8 Clause 8 – Process Hazard and Risk Analysis

ANSI/ISA-84.00.01-2004-1, Clause 8, and ANSI/ISA-84.01-1996 address the Hazard and Risk Analysis
(H&RA). Both mandate the need for H&RA, but neither defines how to specifically execute the H&RA or
to identify process risk. Rather than providing specific requirements, ANSI/ISA-84.01-1996 referred to
OSHA 1910.119 and the CCPS books, Guidelines for Hazard Evaluation Procedures, Guidelines for
Chemical Process Quantitative Risk Analysis, and Guidelines for Safe Automation of Chemical
Processes, for guidance on determining the SIS requirements. ANSI/ISA-84.01-1996, Annex A, also
provided examples of H&RA techniques commonly used in 1996.

Two major changes the owner/operator experiences when transitioning to ANSI/ISA-84.00.01-2004-1

from ANSI/ISA-84.01-1996 are:

1) the new standard has more normative (i.e., mandatory) H&RA requirements and

2) new H&RA approaches for assignment of SIL are discussed.

ANSI/ISA-84.00.01-2004-1 clearly establishes the relationship between the SIS functional and integrity
requirements and the H&RA by requiring the following:

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

• Identification of the process hazards

• Identification of the initiating cause(s) of each process hazard

• Determination of the initiating cause frequency

• ANSI/ISA-84.00.01-2004-1 limits the performance that can be assumed for the Basic Process
Control System (BPCS). ISA-TR84.00.04-1, Annex F, provides a brief discussion on this
limitation.

• Evaluation of the consequence severity associated with each process hazard

• Determination of whether process risk (i.e., initiating cause frequency and the consequence
severity) exceeds owner/operator’s risk criteria

• Identification of safety functions that reduce the process risk to the risk criteria

• Verification that each safety function is designed and managed to meet its allocated risk reduction

The differences between ANSI/ISA-84.01-1996 and ANSI/ISA-84.00.01-2004 resulted in part because:

• ANSI/ISA-84.01-1996 is a national standard, which relied on regulations and other good

engineering practices already in use in the United States.

• In the United States, the Center for Chemical Process Safety (CCPS) is primarily responsible for
establishing H&RA guidelines. CCPS developed “Guidelines for Safe Automation of Chemical
Processes,” which established criteria for the H&RA related to control and safety systems. In the
United States, the International Society of Automation (ISA) is primarily responsible for
establishing standards in the field of instrumentation and controls. The ISA SP84 committee
developed ANSI/ISA-84.01-1996.

• ANSI/ISA-84.00.01-2004 is an international standard, which should harmonize the various

approaches of multiple countries.

• The various countries and associated safety cultures represented by the ANSI/ISA-84.00.01-2004
committee valued the need to clearly discuss each other’s H&RA techniques.

• Owner/operator experience gained in applying ANSI/ISA-84.01-1996 indicated that the additional

guidance provided in ANSI/ISA-84.00.01-2004-1 was appropriate.

As a result, the ANSI/ISA-84.00.01-2004 committee was faced with a number of differing techniques and
varying H&RA terminology from the global community. Therefore, rather than mandating a specific
method, general requirements were provided, and the ANSI/ISA-84.00.01-2004 committee asked each
country delegation to submit examples of techniques for inclusion in ANSI/ISA-84.00.01-2004-3.
ANSI/ISA-84.00.01-2004-3, Annex A, was submitted by UK. ANSI/ISA-84.00.01-2004-3, Annexes B, C,
and F, were submitted by the US. ANSI/ISA-84.00.01-2004-3, Annex F, is a precursor to the CCPS book,
Layers of Protection Analysis: Simplified Process Risk Assessment. ANSI/ISA-84.00.01-2004-3, Annex
E, was submitted by Germany. ANSI/ISA-84.00.01-2004-3, Annex D, was submitted by the UK and
Finland.

NOTE -- The listing of countries above is to provide the owner/operator with the origin of each of these annexes. This listing is not
meant to imply that any specific technique is mandated by these countries. The owner/operator should determine the correct
method for the application.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

S.9 Clause 9 – Allocation of safety functions to protection layers

Safety functions are allocated to protection layers. For each safety function, the owner/operator should
evaluate potential common-cause failures that could disable multiple safety functions. Annex G provides
an additional explanation concerning common-cause failures.

When safety functions are allocated to the safety instrumented system layer, they are known as Safety
Instrumented Functions (SIF). The differences and/or relationships between safety functions, safety
instrumented functions, safety instrumented systems, interlocks, and permissives are important. Annex H
provides a discussion including important historical references to assist in the understanding of the new
terms.

Safety instrumented functions (SIF) are assigned a safety integrity level (SIL) and a mode of operation
(continuous or demand) during the H&RA. These are recent requirements and application guidance is
limited at best.

NOTE -- The SIL of an SIF is defined as a range of availability targets for the given function. SIL 1, for example, implies a range of
availability from 90 to 99%, SIL 2 from 99 to 99.9%, etc. Owners/operators may find this 10:1 ratio within a given SIL to be too wide
for practical analysis. For example, a 10:1 ratio for test intervals could mean a test interval from every 6 months to testing every 5
years. For an SIL 1 SIF, the SIF could theoretically be unavailable for as little as 3.65 days per year or as much as 36.5 days a year.
The standard requires alternative operational procedures be put in place when the SIF is unavailable. However, alternative
procedures may be effective as a compensating measure for a 3.65-day period, but would not be considered sufficient protection
during a 36.5-day period. On a project, an SIL 1 system could be installed to meet 99% availability or 90% availability. Both
solutions would be 'correct', but would be at the opposite ends of the cost and safety spectrum. Some owners/operators may find
that defining the performance requirements in terms of specific availability targets (e.g., 90, 95, 97.5, 99%, etc.) may be more
appropriate than simply specifying the required SIL.

Some of the new requirements in this clause include the following:

1) Requirements for Continuous mode of operation.

ANSI/ISA-84.00.01-2004-1 includes high demand/continuous mode of operation, as well as

demand mode. ANSI/ISA-84.01-1996 only addressed demand mode because the vast majority of
SIS operate in a demand mode. ISA-TR84.00.04-1, Annex I, discusses the differences between
demand mode and high demand/continuous mode. It also provides an example to illustrate the
importance of properly defining any high-demand/continuous-mode SIS.

2) New requirements for SIL 4 Safety Instrumented Functions.

ANSI/ISA-84.00.01-2004-1 requires that SIL 4 safety instrumented functions be designed in

compliance with IEC 61508. This requirement is due to the extensive hardware and software
verification and validation techniques that should be employed to achieve the integrity
requirements. The ISA84 committee strongly advises against the implementation of a single layer
SIL 4 SIS. ISA-TR84.00.04-1, Annex J, provides guidance on how to address process risk that
requires risk reduction equivalent to SIL 4.

3) Requirements for the BPCS when used as a protection layer.

ANSI/ISA-84.00.01-2004-1 establishes a limit on the amount of risk reduction that can be

assumed for the BPCS. This is because the BPCS is generally not designed, operated,
maintained, or tested in accordance to the requirements of the standard. ISA-TR84.00.04-1,
Annex F, provides further information on the contribution of the BPCS as an initiating cause and
as a protection layer.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

S.10 Clause 10 – SIS safety requirement specification

The requirements stated in this clause are more extensive than those found in ANSI/ISA-84.01-1996. The
new requirements include information that was typically developed by the owner/operator if necessary.
ANSI/ISA-84.01-1996, informative Annex B, identified these issues. For example, ANSI/ISA-84.00.01-
2004-1 requires that the owner/operator document the following:

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Criteria for successful operation of the SIF, e.g., whether there are any specific requirements for
tight shut-off valves.

• Requirements for the repair of an SIS fault.

• Requirement for the SIS to survive a major accident event, e.g., whether fireproofing on shutoff
valves is required.

S.11 Clause 11 – SIS design and engineering

There are a number of requirements in Clause 11 that are not addressed in the ANSI/ISA-84.01-1996.
Some of these requirements include:

• Specific requirements for when a fault is detected in the SIS.

• Minimum hardware fault tolerance for different SILs.

• Minimum hardware redundancy is required to ensure that systematic errors made in the
calculation of the frequency of failure or probability of failure on demand do not result in
inadequate protection against serious process risk. The fault tolerance refers to individual devices
or channels. ISA-TR84.00.04-1, Annex K, provides additional information concerning fault
tolerance. ISA-TR84.00.04-1, Annex L, provides a discussion of the IEC 61508 SIL claim limit.
ISA-TR84.00.04-1, Annex P, discusses various considerations when defining the response to
dangerous detected faults.

• Requirements for the selection of SIF devices.

• ISA-TR84.00.04-1 Annex L provides a discussion concerning the selection of devices based on

compliance with IEC 61508 or Prior Use.

• Requirements for Programmable Electronic (PE) logic solvers that are not designed in
compliance with IEC 61508.

• ANSI/ISA-84.00.01-2004-1 makes a distinction between general-purpose (i.e., off-the-shelf) logic

solvers and SIS logic solvers. ANSI/ISA-84.01-1996 did not make any distinction between the
two.

• ISA-TR84.00.04-1 Annex M provides a discussion of general-purpose versus safety-configured

logic solvers. The discussion includes a listing of various techniques that can be used to
implement safety-configured logic solvers.

• Requirements for design of the SIS.

• While many of the concepts in ANSI/ISA-84.01-1996, Annex B, were incorporated in ANSI/ISA-

84.00.01-2004-2, the ISA84 committee wanted to retain the good engineering practice that was

Copyright International Society of Automation

documented in ANSI/ISA-84.01-1996, Annex B. As a result, ISA-TR84.00.04-1 Annex N provides

an update of this design guidance.

• Requirement to verify quantitatively that the SIS satisfies the SIL requirements of the SIF.

• ISA-TR84.00.02 is a technical report that discusses how to perform SIL Verification calculations.

S.12 Clause 12 – Requirements for application software, including selection criteria for utility
software

ANSI/ISA-84.01-1996 requires that the application software be developed in accordance with the Safety
Requirements Specification (SRS). ANSI/ISA-84.00.01-2004-1 also requires this, but discusses the
development of the application software with relation to the safety lifecycle. Where hardware is prone to
random failures, the software is more prone to systematic failures. The safety lifecycle is important,
because it is the primary mechanism for reducing systematic failure. The inclusion of the lifecycle
discussion in the software section does result in repetition of the design process described in ANSI/ISA-
84.00.01-2004-1 Clause 11. This repetition is intended to highlight the importance of the lifecycle in the
development, verification and validation of application software. ISA-TR84.00.04-1 Annex O provides a
discussion of the evolution of application software development.

S.13 Clause 13 – Factory Acceptance Testing (FAT)

The content of this clause is informative and contains no mandatory requirements. This topic is not
discussed in ANSI/ISA-84.01-1996.

S.14 Clause 14 – SIS installation and commissioning

The content of this clause is almost an exact duplicate of what is written in ANSI/ISA-84.01-1996. There
are no new requirements.

S.15 Clause 15 - SIS safety validation

The contents of this clause are very similar to what is described in the ANSI/ISA-84.01-1996 clause on
Pre-Startup Acceptance Test (PSAT).

S.16 Clause 16 – SIS operation and maintenance

OSHA 1910.119 included many requirements for operation and maintenance. Consequently, ANSI/ISA-
84.01-1996 referenced these requirements and included only a few additional requirements specifically
related to SIS. ANSI/ISA-84.00.01-2004-1 expands the ANSI/ISA-84.01-1996 requirements for operation
and maintenance, including the following:

1) Operation procedures and associated training should address:

• How the SIF functions

• The hazard that the SIF is protecting against

• Circumstances under which bypasses switches can be activated

• When to execute a manual shutdown

• Appropriate response to diagnostic alarms

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

2) Operation management should collect information regarding process demands on the SIS and
SIF device failures.

3) Maintenance management is required to collect the results of audits and tests of SIF devices.

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Operation and maintenance management should identify any specific requirements for a visual
inspection of hardware integrity.

S.17 Clause 17 SIS modification

There are no new requirements in this clause. Requirements were previously covered by ANSI/ISA-
84.01-1996 and OSHA 1910.119.

S.18 Clause 18 – SIS decommissioning

This clause is very similar to what is in ANSI/ISA-84.01-1996 with no new requirements.

S.19 Clause 19 – Information and Documentation Requirements

There are no new requirements in this clause. Documentation requirements were previously covered by
ANSI/ISA-84.01-1996 and OSHA 1910.119.

Table S.1 – Summary of differences

ISA-84.00.01-2004 ANSI/ISA-84.01-1996

Process and its equipment/ANSI/ISA-84.01-1996

Process and its associated equipment/IEC 61508 Clause 3.1.5 makes numerous references to
Equipment Under Control(EUC)
SIF SF
SIL for SIF SIL for SIS
BPCS performance expectations are limited. Excludes BPCS in Clause 1.2.8
Validation Pre-start-up acceptance test (PSAT)
Safe Failure Fraction (fault tolerance) None
Excluded in Clause 1.2.5
Hazard and risk analysis requirements
Informative Clauses 4.2.1 – 4.2.5 and Annex A
Design requirement Less definitive
Operation and maintenance requirement Less definitive
Tracking trip/demand Less definitive
Allocation of safety functions to protection layers Not part of scope

Requirements on BPCS as a layer of protection Excludes BPCS in Clause 1.2.8

Requirements for system behavior on detection of a fault Less definitive

Prior use User-approved: Clauses 1.2.10 and 3.1.62
Requirements for interfaces Less definitive
Requirements for competency Less definitive
Requirements for application software – normative Much less definitive – informative

Copyright International Society of Automation

ISA-84.00.01-2004 ANSI/ISA-84.01-1996

Requirements calculation of SIL for SIF Informative Annex A

Grandfather clause in Clause 1.0y Grandfather clause in Clause 2.2.1
Not discussed Fire and gas excluded in Clause 1.2.14
Full variability Not discussed
Limited variability Not discussed
Fixed program Not discussed
Defines use of embedded software Requirements in Clause 3.1.58.2
Documentation requirements Less normative
Factory acceptance test (FAT) discussion Not discussed
Part 3 – global SIL selection methods US – SIL selection methods Annex A
Layer of Protection Analysis Not discussed
Example – IEC 61508 Example – Annex A and TR84.00.02
Management of functional safety requirements Less definitive
References – normative References – informative
Asset protection referenced Excluded in Clause 1.2.13
Requirements in Clauses 3.1.7.2 and 3.1.7.1 and
Common-cause failure definition
Discussed Annex B.2, B.8, B.10 and D.3
Requirements in Clause 3.1.5 and Discussed in
Diagnostics coverage definition
B.4.4.1.1, B.6.4 and B.9.3
Control system definition Requirements in Clause 3.1.5
E/E/PE E/E/PE Page 13, paragraph 1, line 2
External risk reduction requirements None
Functional safety audit details Much less
Excluded in Clause 1.2.5. Provided Guidance in
Hazard definition
Informative Clauses 4.2.1 – 4.2.5 and Annex A
Independent organization/department/person
Not discussed
requirements
Other technologies Excludes non-E/E/PE technologies

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
Safety-related system requirements IEC 61508 Part 2 -
Clause 7.4.7 Requirements for E/E/PES Implementation Discussed in Clause 7.3, but not defined as safety
related system requirements

Discussed in Clause 3.1.42 and Informative Clauses

Protection layer definition
4.2.3 and 4.2.4
Safe state definition Defined in Clause 3.1.50
Safety function (all technologies) Safety function SIS only
SIL definition (SIF) Defined SIL (SIS) in Clause 3.1.52
Both versions of ISA-84.01 utilize a safety lifecycle
process to address the assessment, design,
Safety lifecycle
operation, maintenance, testing, and management
of safety instrumented systems
Systematic failure definition Defined in Clause 3.1.60
Verification quantitative Verification qualitative or quantitative
Tolerable risk Discussed in Clause 3.2.89

Copyright International Society of Automation

ISA-84.00.01-2004 ANSI/ISA-84.01-1996

SIL 1, 2, 3, 4 SIL 1, 2, 3
Illustrates 61508 as normative reference Illustrates 61508 as draft document
Annex B.8 and B.9 pages 69-72 provide systematic
Systematic error guidance
error guidance
Includes operator action in SIS Excludes operator action (Clause 1.2.14) in SIS

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Annex T – Acronyms and abbreviations

ANSI American National Standards Institute

API American Petroleum Institute

ASME American Society of Mechanical Engineers

BPCS Basic Process Control System

CCF Common-Cause Factor

CCPS Center for Chemical Process Safety

CFR Code of Federal Regulations

CMOS Complimentary Metal Oxide Semiconductor

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

CPU Central Processing Unit

DCS Distributed Control System

DD Dangerous Detected

DTT De-energize to Trip

DU Dangerous Undetected

E/E/PES Electrical/Electronic/Programmable Electronic System

EEMUA Engineering Equipment and Material Users’ Association

EMC Electromagnetic Coupling

EMI Electromagnetic Interference

ETT Energize to Trip

FAT Factory Acceptance Text

FMEA Failure Mode Effect Analysis

FPL Fixed Program Language

FSA Functional Safety Assessment

FVL Full Variability Language

HAZOP Hazard and Operability Study

HFE Human Factors Engineering

HSE Health and Safety Executive

H&RA Hazard and Risk Analysis

HMI Human Machine Interface

Copyright International Society of Automation

HNIL High Noise Immunity Logic

IEC International Electrotechnical Commission

I/O Input/Output

IPL Independent Protection Layer

IPRDS In Plant Reliability Data System

IR Infrared

ISA International Society of Automation

KPI Key Performance Indicator

LOPA Layers of Protection Analysis

LVL Limited Variability Language

MI Mechanical Integrity

MOC Management of Change

MTTF Mean Time To Failure

MTTR Mean Time To Repair

NAMUR International User Association of Automation Technology in Process Industries

NFPA National Fire Protection Association

NRTL Nationally Recognized Testing Laboratory

OSHA Occupational Safety and Health Administration

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

OREDA Offshore Reliability Data

PE Programmable Electronic

PERD Process Equipment Reliability Database

PES Programmable Electronic Systems

PFDavg Probability of Failure on Demand

P&IDs Piping and Instrumentation Diagrams

PHA Process Hazard Analysis

PIU Proven In Use

PLC Programmable Logic Controller

PPL Process Parameter Limit

Copyright International Society of Automation

PSAT Pre-Startup Acceptance Test

PSSR Pre-Startup Safety Review

RAGAGEP Recognized and Generally Accepted Good Engineering Practice

RC Resistor-Capacitor

RRF Risk Reduction Factor

RFI Radio Frequency Interference

RTL Resistor-Transistor Logic

RTD Resistance Temperature Detector

SAT Site Acceptance Test

SD Safe Detected

SFF Safe Failure Fraction

SIF Safety Instrumented Function

SIL Safety Integrity Level

SIS Safety Instrumented System

SOE Sequence of Events

SOV Solenoid Operated Valve

SRS Safety Requirements Specification

SU Safe Undetected

THERP Technique for Human Error Rate Prediction

TI Test Interval

TSU Total Segment Uncertainty

TTL Transistor-transistor Logic

UPS Uninterruptible Power Supply

VAC Volts Alternating Current

VDC Volts Direct Current

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Copyright International Society of Automation

Annex U – References

ANSI/IEEE-845, IEEE Guide for the Evaluation of Human-System Performance in Nuclear Power
Generating Stations, The Institute of Electrical and Electronics Engineers, 1999.

ANSI/ISA-18.2-2009, Management of Alarm Systems for the Process Industries, International Society of
Automation (ISA), www.isa.org, 2009.

ANSI/ISA-84.01-1996, Application of Safety Instrumented Systems for the Process Industries,

International Society of Automation (ISA), www.isa.org, 1996, ISBN 1-55617-590-6.

ANSI/ISA-84.00.01-2004, Functional Safety: Safety Instrumented Systems for the Process Industry
Sector, Parts 1 through 3, International Society of Automation (ISA), www.isa.org, 2004.

ANSI/ISA-84.00.01-2004, Part 1, Framework, Definitions, Systems, Hardware and Software

Requirements, International Society of Automation (ISA), www.isa.org, 2004, ISBN 1-55617-979-
7.

ANSI/ISA-84.00.01-2004, Part 2, Guidelines for the Application of ANSI/ISA-84.00.01-2004 Part 1

(IEC 61511-1Mod) – Informative, International Society of Automation (ISA), www.isa.org, 2004,
ISBN 978-1-55617-920-0.

ANSI/ISA-84.00.01-2004, Part 3, Guidance for the Determination of the Required Safety Integrity
Levels – Informative, International Society of Automation (ISA), www.isa.org, 2004, ISBN 1-
55617-921-9.

API 14C (R2007) Recommended Practice for Design, Installation, and Testing of Basic Surface Safety
th
Systems for Offshore Production Platforms, American Petroleum Institute, 7 edition, 01-Mar-2001.

CCPS/AIChE “Guidelines for Chemical Process Quantitative Risk Analysis,” Second Edition, American
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Institute of Chemical Engineers, New York, 2000, ISBN No: 0-8169-0720-X.

CCPS/AIChE “Guidelines for Engineering Design for Process Safety,” American Institute of Chemical
Engineers, New York, 1993, ISBN 978-0-8169-0565-2.

CCPS/AIChE “Guidelines for Safe and Reliable Instrumented Protective Systems,” Wiley-Interscience,
New York, 2007, ISBN 978-0-471-97940-1

CCPS/AIChE “Guidelines for the Hazard Evaluation Procedures,” 3rd edition, Wiley-Interscience, New
York, 2008, ISBN 0-8169-0491-X.

CCPS/AIChE “Guidelines for the Safe Automation of Chemical Processes,” American Institute of
Chemical Engineers, New York, 1993, ISBN 0-8169-0554-1.

CCPS/AIChE “Inherently Safer Chemical Processes, A Lifecycle Approach,” 2nd edition, Wiley-
Interscience, New York, 2008, ISBN 978-0-471-77892-9.

CCPS/AIChE “Layer of Protection Analysis: Simplified Risk Assessment” Concept Series, New York,
2001. ISBN 0-8169-0811-7.

CCPS/AICHE, “Guidelines for Process Safety Metrics,” Wiley-Interscience, New York, 2009, ISBN 978-0-
470-57212-2.

Collins Concise English Dictionary, 3rd Edition, ISBN 0007162626, December 2003.

Copyright International Society of Automation

DIN V VDE 0801, Publication date: 1990-01, Principles for computers in safety-related systems, Original
language.

DIN V VDE 0801/A1, Publication date: 1994-10, Principles for computers in safety-related systems;
Amendment A1:1994-10.
nd
EEMUA 191-2007, Alarm Systems – A Guide to Design, Management and Procurement, 2 edition,
Engineering Equipment and Materials Users Association, www.eemua.co.uk, ISBN 0859311554, 2007.

Findings From Voluntary Reporting of Loss of Containment Incidents 2004/05, Health and Safety
Executive (2005).

IEC 61508 Parts 1 through 4, Functional safety of electrical/electronic/programmable electronic safety-

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

nd
related systems, International Electrotechnical Commission, www.iec.ch, 2 edition, 2010 ISBN 978-2-
88910-524-3.

IEC 61508 Part 1: General requirements, International Electrotechnical Commission, www.iec.ch,

nd
2 edition, 2010.

IEC 61508 Part 2: Requirements for electrical/electronic/programmable electronic safety-related

nd
systems, International Electrotechnical Commission, www.iec.ch, 2 edition, 2010.

IEC 61508 Part 3: Software requirements, International Electrotechnical Commission,

nd
www.iec.ch, 2 edition, 2010.

IEC 61508 Part 4: Definitions and abbreviations, International Electrotechnical Commission,

nd
www.iec.ch, 2 edition, 2010.

IEC 61511 Functional Safety – Safety Instrumented Systems for the Process Industry Sector – Part 1
Framework, definitions, system, hardware and software requirements, International Electrotechnical
st
Commission, www.iec.ch, 1 edition, 2003, ISBN 2-8318-7316-9.

IEC 61131 Programmable controllers - Part 3: Programming languages, International Electrotechnical

Commission, www.iec.ch, 2nd edition, Mar 2003.

IEEE-1023 Guide For Application Of Human Factors Engineering To Systems, Equipment, And Facilities
Of Nuclear Power Generating Stations, The Institute of Electrical and Electronics Engineers, 2004.

IEEE-1289 Guide For The Application Of Human Factors Engineering In The Design Of Computer-Based
Monitoring And Control Displays For Nuclear Power Generating Stations, The Institute of Electrical and
Electronics Engineers,1998.

ISA-18.1-1979 (R2004), Annunciator Sequences and Specifications, International Society of Automation

(ISA), www.isa.org, ISBN 0-87664-346-2.

ISA-37.1-1975 (R1982), Electrical Transducer Nomenclature and Terminology, International Society of

Automation (ISA), www.isa.org, ISBN 0-87664-113-3.

ISA-51.1-1979 (R1993), Process Instrumentation Terminology, International Society of Automation (ISA),

www.isa.org, ISBN 0-87664-390-4.

Copyright International Society of Automation

ISA-RP60.3-1985, Human Engineering for Control Centers, International Society of Automation (ISA),
www.isa.org, ISBN 0-87664-897-9.

ISA-RP60.6-1984, Nameplates, Labels, and Tags for Control Centers, International Society of Automation
(ISA), www.isa.org, ISBN 0-87664-813-8.

ISA-RP67.04.02-2010, Methodologies for the Determination of Setpoints for Nuclear Safety-Related

Instrumentation, International Society of Automation (ISA), www.isa.org, ISBN DOWN7745

ISA-TR84.00.02-2002: Parts 1-5, Safety Instrumented Functions (SIF) Safety Integrity Level (SIL)
Evaluation Techniques, International Society of Automation (ISA), www.isa.org, ISBN 1-55617-807-7.

ISA-TR84.00.03, Guidance for Testing of Process Sector Safety Instrumented Functions (SIF)
Implemented as or Within Safety Instrumented Systems (SIS), International Society of Automation (ISA),
www.isa.org, ISBN 978 1 55617 801-6.

ISO 9001:2008 Quality Management Systems – Requirements, International Standards Organization,

www.iso.org, 2008.

NFPA 85 Boiler And Combustion Systems Hazards Code, National Fire Protection Association,
www.nfpa.org, 2011.

NFPA 86 Standard for Ovens and Furnaces, National Fire Protection Association, www.nfpa.org, 2011.

NUREG-0700, Human-System Interface Design Review Guidelines, Chapter 4, U.S. Nuclear Regulatory
Commission, Rev 2, May 2002.

NUREG/CR-1278, Handbook of Human Reliability Analysis with Emphasis on Nuclear Power Plant
Applications, U.S. Nuclear Regulatory Commission, October 1983.

NUREG/CR-4772 Accident Sequence Evaluation Program (ASEP) Human Reliability Analysis Procedure,
U.S. Nuclear Regulatory Commission.

OSHA 1910.119 “Process Safety Management of Highly Hazardous Chemicals; Explosives and Blasting
Agents,” 29 CFR Part 1910, OSHA, Washington (1992).

--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---
nd
Out of Control: Why Control Systems go Wrong and How to Prevent Failure, 2 edition, HSE Books
2003, ISBN 0717621928.

Copyright International Society of Automation

Provided by IHS under license with ISA Licensee=Fermilab Research Alliance LLC/5970717001
No reproduction or networking permitted without license from IHS Not for Resale, 05/07/2014 02:47:52 MDT
Developing and promulgating sound consensus standards, recommended practices, and technical
reports is one of ISA’s primary goals. To achieve this goal, the Standards and Practices Department
relies on the technical expertise and efforts of volunteer committee members, chairmen, and reviewers.

ISA is an American National Standards Institute (ANSI) accredited organization. ISA administers United
States Technical Advisory Groups (USTAGs) and provides secretariat support for International
Electrotechnical Commission (IEC) and International Organization for Standardization (ISO) committees
that develop process measurement and control standards. To obtain additional information on the
Society’s standards program, please write:

ISA
--``,`,``,``,`,````,``,,`,,,`,`-`-`,,`,,`,`,,`---

Attn: Standards Department

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

ISBN: 978-1-937560-24-9

Copyright International Society of Automation

Provided by IHS under license with ISA Licensee=Fermilab Research Alliance LLC/5970717001
No reproduction or networking permitted without license from IHS Not for Resale, 05/07/2014 02:47:52 MDT

Common questions