ISA-TR84.00.04-2005 Part 1

TECHNICAL REPORT
ISA—TR84.00.04—2005 Part 1:
Guidelines for the

Implementation of
ANSI/ISA-84.00.01-2004
(IEC 61511 Mod)
Approved 1 December 2005
NOTICE OF COPYRIGHT
This is a copyright document and may not be copied or distributed in any
form or manner without the permission of ISA. This copy of the document
was made for the sole use of the person to whom ISA provided it and is
subject to the restrictions stated in ISA’s license to that person. It may not be
provided to any other person in print, electronic, or any other form.
Violations of ISA’s copyright will be prosecuted to the fullest extent of the
law and may result in substantial civil and criminal penalties.
ISA-TR84.00.04-2005 Part 1 --
Guidelines for the Implementation of ANSI/ISA-84.00.01-2004 (IEC 61511 Mod)
ISBN: 1-55617-979-0
Copyright © 2005 by 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
—3— ISA-TR84.00.04-2005 Part 1
Preface
This preface, as well as all footnotes and annexes, is included for information purposes and is not part of
ISA-TR84.00.04-2005 Part 1.
This document has been prepared as part of the service of 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 ADHERES TO THE POLICY OF THE AMERICAN NATIONAL STANDARDS

INSTITUTE WITH REGARD TO PATENTS. IF ISA IS INFORMED OF AN EXISTING PATENT THAT IS
REQUIRED FOR USE OF THE DOCUMENT, IT WILL REQUIRE THE OWNER OF THE PATENT TO
EITHER GRANT A ROYALTY-FREE LICENSE FOR USE OF THE PATENT BY USERS COMPLYING
WITH THE DOCUMENT OR A LICENSE ON REASONABLE TERMS AND CONDITIONS THAT ARE
FREE FROM UNFAIR DISCRIMINATION.
EVEN IF ISA IS UNAWARE OF ANY PATENT COVERING THIS DOCUMENT, THE USER IS
CAUTIONED THAT IMPLEMENTATION OF THE DOCUMENT MAY REQUIRE USE OF TECHNIQUES,
PROCESSES, OR MATERIALS COVERED BY PATENT RIGHTS. ISA TAKES NO POSITION ON THE
EXISTENCE OR VALIDITY OF ANY PATENT RIGHTS THAT MAY BE INVOLVED IN IMPLEMENTING
THE DOCUMENT. ISA IS NOT RESPONSIBLE FOR IDENTIFYING ALL PATENTS THAT MAY
REQUIRE A LICENSE BEFORE IMPLEMENTATION OF THE DOCUMENT OR FOR INVESTIGATING
THE VALIDITY OR SCOPE OF ANY PATENTS BROUGHT TO ITS ATTENTION. THE USER SHOULD
CAREFULLY INVESTIGATE RELEVANT PATENTS BEFORE USING THE DOCUMENT FOR THE
USER’S INTENDED APPLICATION.
HOWEVER, ISA ASKS 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.
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.
Copyright 2005 ISA. All rights reserved.

ISA-TR84.00.04-2005 Part 1 —4—
This ISA technical report was prepared by ISA-SP84 Working Group 2, which included the following
members:
NAME COMPANY
A. Summers, ISA-SP84 WG2 Leader SIS-TECH Solutions LLC

W. Johnson, ISA-SP84 Chair E.I. DuPont
V. Maggioli, ISA-SP84 Managing Director Feltronics Corp.
R. Dunn, ISA-SP84 Recorder DuPont Engineering
R. Adamski Premier Consulting Services
H. Bezecny Dow Deutschland
D. Bolland ExxonMobil Research & Engineering Co.
K. Bond Consultant
S. Brown Health & Safety Executive (HSE), UK
N. Cammy UOP LLC
J. Campbell ConocoPhillips
W. Cohen KBR
A. Dowell, III Rohm and Haas Co.
K. Gandhi KBR
W. Goble Exida Com LLC
D. Green Rohm & Haas Company
P. Gruhn ICS Triplex
J. Harris UOP LLC
T. Jackson Bechtel Corp.
K. Klein Solutia, Inc.
M. Lang CF Industries
T. Layer Emerson Process Management
N. McLeod Arkema
E. Marszal Kenexis
R. Nelson Celanese Corp.
D. Novak BASF Corp.
T. Ostrowski Oxychem
W. Owen Chevron Research & Technology Co.
G. Ramachandran Motiva Enterprises LLC
G. Robertson Oxy Information Technology
L. Robison BP Oil
S. Shah Exxon Mobil Chemical Co.
J. Siebert Invista
B. Smith Nova Chemicals
C. Sossman Washington Safety Management Solutions LLC
P. Stavrianidis FM Approvals
H. Storey Shell Global Solutions
R. Strube Intertek Testing Services NA, Inc.
L. Suttinger Westinghouse Savannah River Co.
K. Szafron BP
R. Szanyi ExxonMobil Research Engineering
R. Taubert BASF Corp
H. Thomas Air Products & Chemicals Inc
A. Woltman Shell Global Solutions
D. Zetterberg Chevron Energy Technology Co.

—5— ISA-TR84.00.04-2005 Part 1
This ISA technical report was approved for publication by the ISA Standards and Practices Board on 1
December 2005:
NAME COMPANY
I. Verhappen, Chair Syncrude Canada, Ltd.
F. Amir E.I. Du Pont Co.
D. Bishop Consultant
M. Coppler Ametek Inc.
B. Dumortier Schneider Electric
W. Holland Consultant
E. Icayan ACES Inc.
A. Iverson Ivy Optiks
R. Jones Consultant
K. P. Lindner Endress + Hauser Process Solutions
V. Maggioli Feltronics Corp.
T. McAvinew Jacobs Engineering Group
A. McCauley Chagrin Valley Controls Inc.
G. McFarland Emerson Process Management
R. Reimer Rockwell Automation
J. Rennie Consultant
N. Sands E I Du Pont Co.
H. Sasajima Yamatake Corp.
T. Schnaare Rosemount Inc.
A. Summers SIS-TECH Solutions LLC
J. Tatera Tatera & Associates
R. Webb Consultant
W. Weidman Parsons Energy and Chemicals
J. Weiss KEMA Inc.
M. Widmeyer Stanford Linear Accelerator Center
C. Williams Eastman Kodak Co.
M. Zielinski Emerson Process Management

This page intentionally left blank.
—7— ISA-TR84.00.04-2005 Part 1
Contents
Preface .......................................................................................................................................................... 3
1 Purpose ............................................................................................................................................... 9
2 Introduction......................................................................................................................................... 9
3 Grandfather Clause .......................................................................................................................... 10
3.1 General Considerations .......................................................................................................... 11
3.2 Management of Change Considerations............................................................................... 11
4 The Differences................................................................................................................................. 13
4.1 Clause 1 - Scope ...................................................................................................................... 13
4.2 Clause 2 – References............................................................................................................. 14
4.3 Clause 3 – Abbreviations and Definitions............................................................................. 14
4.4 Clause 4 – Conformance to Standard.................................................................................... 14
4.5 Clause 5 – Management of Functional Safety ...................................................................... 14
4.6 Clause 6 – Safety Lifecycle Requirements............................................................................ 15
4.7 Clause 7 – Verification ............................................................................................................ 15
4.8 Clause 8 – Process Hazard and Risk Analysis ..................................................................... 15
4.9 Clause 9 – Allocation of Safety Functions to Protection Layers ........................................ 17
4.10 Clause 10 – SIS Safety Requirement Specification.............................................................. 18
4.11 Clause 11 – SIS Design and Engineering.............................................................................. 18
4.12 Clause 12 – Requirements for Application Software, Including Selection Criteria for
Utility Software ...................................................................................................................................... 19
4.13 Clause 13 – Factory Acceptance Testing (FAT) ................................................................... 19
4.14 Clause 14 – SIS Installation and Commissioning ................................................................ 19
4.15 Clause 15 - SIS Safety Validation........................................................................................... 19
4.16 Clause 16 – SIS Operation and Maintenance........................................................................ 19
4. 17 Clause 17 SIS Modification................................................................................................. 20
4.18 Clause 18 – SIS Decommissioning ........................................................................................ 20
4.19 Clause 19 – Information and Documentation Requirements .............................................. 20
Annex A Example Methods for Determining Grandfather Status ............................................................... 23
Annex B Operator Action as an Independent Protection Layer (IPL) ......................................................... 41
Annex C Management of Functional Safety ............................................................................................... 51
Annex D Verification, Validation and Functional Safety Assessments ....................................................... 81
Annex E Audits.......................................................................................................................................... 103
Annex F BPCS and Its Relationship to the SIS ........................................................................................ 109
Annex G Failures - Types, Classifications, Sources and Strategy for Defense........................................ 127
Annex H SIF versus Interlocks, Permissives, and Inhibits........................................................................ 141
Annex I Continuous Mode versus Demand Mode .................................................................................... 147
Annex J SIL 4 versus Inherently Safer Design ......................................................................................... 155
Annex K Fault Tolerance Topics............................................................................................................... 157
Annex L Device Selection ......................................................................................................................... 165
Annex M General Purpose versus Safety Logic Solvers .......................................................................... 177
Annex N Design Guidance........................................................................................................................ 181
Annex O Software ..................................................................................................................................... 201
Annex P Response to Detection of a Dangerous Fault ............................................................................ 207
Annex Q Acronyms and Abbreviations ..................................................................................................... 213
Annex R References ................................................................................................................................. 215

—9— ISA-TR84.00.04-2005 Part 1
1 Purpose
ANSI/ISA-84.01-1996, Application of Safety Instrumented Systems for the Process Industries, was
replaced in 2004 by ANSI/ISA-84.00.01-2004 Parts 1-3 (IEC 61511 Modified), Functional Safety: Safety
Instrumented Systems for the Process Industry Sector. The three-part series is the United States
adoption of the international standards, IEC 61511 Parts 1-3, and includes one additional clause, a
“grandfather clause” covering existing safety instrumented systems (see ANSI/ISA-84.00.01-2004 Part 1
Clause 1.0 y).
This Part 1 technical report provides guidance related to the transition of programs developed for the
1996 standard to one compliant with the intent of the 2004 standards. This Part 1 technical report also
includes 16 informative annexes providing guidance from the ISA-SP84 committee on a wide range of
topics related to the new standards. A companion technical report, ISA-TR84.00.04-2005 Part 2, provides
an example illustrating some of the lifecycle steps in ANSI/ISA-84.00.01-2004.
This Part 1 technical report contains four main clauses. Clause 1 is the purpose. Clause 2 explains the
origins of ANSI/ISA-84.00.01-2004 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 safety instrumented systems. Clause 4 assists the owner/operator in the transition
from ANSI/ISA-84.01-1996 to ANSI/ISA-84.00.01-2004.
NOTE: Throughout this technical report, the term “ISA-84.01-2004” is used to refer to ANSI/ISA-84.00.01-2004
Parts 1-3 (IEC 61511 Modified). The term “ISA-84.01-1996” is used to refer to ANSI/ISA-84.01-1996.
See Annex R of this technical report for a list of references for all documents cited herein.
2 Introduction
In the United States of America, the Occupational Safety and Health Administration (US-OSHA)
regulation, 29 CFR 1910.119 (OSHA 1910.119), requires the identification and management of the
instrumented systems responsible for safe operation. ISA Standards Committee SP84 developed 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 ISA-SP84 committee resulted in US-OSHA
recognizing ISA-84.01-1996 as representing good engineering practice for SIS.
During its initial development, the ISA-SP84 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),
e.g., “Guidelines for the Safe Automation of Chemical Processes.” Working in parallel with the ISA-SP84
committee effort, the International Electrotechnical Commission (IEC) was developing IEC 61508,
Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems. Concepts
introduced in the international standard were incorporated into ISA-84.01-1996, resulting in ISA-84.01-
1996 being accepted as the US process sector functional safety standard by the US and IEC. Through
ISA-84.01-1996, owner/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 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.
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 ISA-SP84 committee adopted IEC 61511 as ISA-84.00.01-2004 Parts 1-3 (IEC 61511 Mod). Once the
standards were adopted by ISA, the SP84 committee immediately initiated the development of this

ISA-TR84.00.04-2005 Part 1 — 10 —
guideline. ANSI approved the new standards as ANSI/ISA-84.00.01-2004 Parts 1-3 (IEC 61511 Mod) in
Sept. 2004.
This guidance document facilitates transition from ISA-84.01-1996 to ISA-84.01-2004 by:
• providing grandfather clause application guidance (refer in this technical report to Clause 3.0 and
Annex A);
• highlighting the differences between ISA-84.01-1996 and ISA-84.01-2004-1 (refer in this technical
report to Clause 4.0); and
• explaining the application of new requirements in ISA-84.01-2004-1 (refer in this technical report
to Annexes B through R).
This guidance document is intended to assist owner/operators familiar with the content of ISA-84.01-1996
with the transition to ISA-84.01-2004-1. To utilize this guideline properly, the reader should be 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 (IEC61511) (for information, visit www.isa.org/standards). These differences are
presented using the ISA-84.01-2004 lifecycle with supplementary annexes for additional explanation.
NOTE 1 — Both versions of ISA-84.01 utilize a safety lifecycle. However, the scope of ISA-84.01-2004-1 differs considerably from
the scope of ISA-84.01-1996, since all elements of the lifecycle are addressed in ISA-84.01-2004-1. Refer to Clause 4.0 in this
technical report for presentation of the differences between the two versions. These additional requirements are typical when
harmonizing the standards of many countries.
NOTE 2 — There is nothing in this guideline that precludes, replaces, or makes obsolete any requirement of ISA-84.01-
1996 or ISA-84.01-2004-1. This guideline is a “how to” approach and provides informative, non-mandatory methods.
3 Grandfather Clause
The concept of the "grandfather clause” in ISA-84.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 SISs.
The grandfather clause (ISA-84.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 U.S. OSHA 29 CFR 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 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 change management 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 below in Annex A.2.

— 11 — ISA-TR84.00.04-2005 Part 1
The grandfather clause releases the owner/operator from the design and construction requirements of
ISA-84.01-2004-1 for existing installations, if the owner/operator 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.
NOTE 1 — There are many processes that are not covered under OSHA 1910.119. Some owner/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 SISs.
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 below in Annex A is intended to supplement the US-OSHA guidance and to provide examples of
methodologies that various owner/operators are using to determine whether their SIS meets the intent of the grandfather clause
(ISA-84.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 ISA-84.01-2004-1 should still be implemented, as appropriate.
Documentation, procedures, training, testing, and auditing requirements of ISA-84.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 SISs. It is the
responsibility of the owner/operator to determine that existing SISs 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. Annex A in this technical report is a collection of methods used by various
owners/operators on the ISA-SP84 committee.
3.2 Management of Change Considerations
Owner/operators of grandfathered SIS (i.e., those SIS that have been determined to meet the intent of
ISA-84.01-2004-1 Clause 1.0y) should acknowledge that this status does not provide an indefinite shield
against the full requirements of ISA-84.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 a 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 ISA-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 (PFDs) or considerably
revises the process and instrumentation diagrams (P&IDs), can be expected to have an impact on the
definition of the safety instrumented functions (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

ISA-TR84.00.04-2005 Part 1 — 12 —
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.
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 of 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.
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 a large
reduction in operations or maintenance manpower. As owner/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
problems 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,
• reduced efforts in preventative maintenance, and
• reduced documentation of problem resolution.

— 13 — ISA-TR84.00.04-2005 Part 1
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, management of change (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 ISA-84.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 The Differences
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 owner/operators. ISA-84.01-2004-1
builds upon ISA-84.01-1996 using an enhanced SIS lifecycle that includes:
1) requirements for activities that were not covered due to scope limitations of 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 ISA-84.01-2004-1, highlighting some of the significant
differences between ISA-84.01-1996 and ISA-84.01-2004-1. It is important that the reader of this Clause
be familiar with the content of ISA-84.01-1996. A summary of the differences by topic is provided in Table
4-1.
4.1 Clause 1 - Scope
This clause states that manufacturers who claim that their equipment is designed for use in Safety
Instrumented Systems (SIS) should satisfy the requirements defined in IEC 61508. ISA-84.01-1996 does
not address this issue.
ISA-84.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,
ISA-84.01-1996 provided less definitive requirements for application software in Clause 7.8.3 “Application
logic for Programmable Electronic Systems (PES).”
ISA-84.01-2004-1 identifies SIL 4 as the maximum level of performance for a Safety Instrumented
Function covered under this standard. ISA-84.01-1996 identified SIL 3 as the maximum level of
performance for a Safety Instrumented Function.
ISA-84.01-1996 excluded systems where the operator was the sole means of returning the process to a
safe state. ISA-84.01-2004-1 did not specifically exclude this type of system, but did not explicitly include
it either. ISA-84.01-2004-1 Clauses 11.3.1 through 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. Annex B of this technical report provides additional discussion on this subject.

ISA-TR84.00.04-2005 Part 1 — 14 —
4.2 Clause 2 – References
ISA-84.01-2004-1 lists four parts of IEC 61508 as normative references. ISA-84.01-1996 lists a number of
informative references in its Annex C, but no normative references.
4.3 Clause 3 – Abbreviations and Definitions
There are a number of new abbreviations and terms in ISA-84.01-2004-1. There is also clarification or
expansion of some definitions associated with terminology used in ISA-84.01-1996.
Perhaps, the most significant new term is “Safety Instrumented Function” (SIF). In ISA-84.01-1996, there
was very little differentiation between an SIS and SIF. ISA-84.01-2004-1 spells out the difference between
the SIF (e.g., hardware and 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 ISA-84.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.
ISA-84.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. Owner/operators are directed to
IEC 61508 for the development of application software using full variability language.
4.4 Clause 4 – Conformance to Standard
The conformance clause in ISA-84.01-2004-1 is very similar to the conformance clause in ISA-84.01-
1996.
4.5 Clause 5 – Management of Functional Safety
ISA-84.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 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” (see Annex R, References).
ISA-84.01-2004-1 addresses the competency requirements for individuals involved in the safety lifecycle.
Competency requirements are not addressed in 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 owner/operators that do not have a regulatory system in place that defines these
requirements. Annex C of this technical report provides additional guidance on the management of
functional safety through effective project management and quality control processes.
ISA-84.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

— 15 — ISA-TR84.00.04-2005 Part 1
components are in accordance with what was assumed during the design and verification phases. ISA-
84.01-1996 did not have specific requirements for this evaluation.
ISA-84.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 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 ISA-84.01-2004-1 requires the inclusion of an
independent, senior, competent person on the team. Annex C of this technical report has additional
discussion concerning this requirement.
The terms verification, validation, and functional safety assessment are used in ISA-84.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.
ISA-84.01-2004-1 has a requirement for periodic auditing to ensure compliance with the requirements in
the standard. ISA-84.01-1996 does not have a specific requirement for periodic auditing. Following the
ISA-84.01-2004 lifecycle ensures that the intended design, operation, maintenance, and testing of the SIS
is 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. Annex E of this technical report provides an example
of how to approach and perform an audit.
4.6 Clause 6 – Safety Lifecycle Requirements
The ISA-SP84 committee created 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.01-1996 does not provide specific requirements for safety management, hazard and
risk analysis, pre-startup safety review, or training. ISA-84.01-2004 provides requirements for each of
these areas.
4.7 Clause 7 – Verification
ISA-84.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 the ISA-84.01-1996 standard. However,
most owner/operators include a number of verification steps during project execution for project and
quality management purposes.
4.8 Clause 8 – Process Hazard and Risk Analysis
ISA-84.01-2004-1 Clause 8 and 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, 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. 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 ISA-84.01-2004-1 from 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.

ISA-TR84.00.04-2005 Part 1 — 16 —
ISA-84.01-2004-1 clearly establishes the relationship between the SIS functional and integrity
requirements and the H&RA by requiring the following:
• Identification of the process hazards,

• Identification of the initiating cause(s) of each process hazard,
• Determination of the initiating cause frequency,
ISA-84.01-2004-1 limits the performance that can be assumed for the Basic Process Control System
(BPCS). Annex F of this technical report 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, and
• Verification that each safety function is designed and managed to meet its allocated risk
reduction.
The differences between ISA-84.01-1996 and IEC 61511 resulted in part because:
• ISA-84.01-1996 was 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, ISA is primarily responsible for establishing standards in the field of
instrumentation and controls. The ISA-SP84 committee developed ISA-84.01-1996.
• IEC 61511 is an international standard, which should harmonize the various approaches of
multiple countries.
• The various countries and associated safety cultures represented by the IEC 61511 committee
valued the need to clearly discuss each other’s H&RA techniques,
• Owner/operator experience gained in applying ISA-84.01-1996 indicated that the additional

guidance provided in ISA-84.01-2004-1 was appropriate.
As a result, the IEC 61511 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 IEC 61511 committee asked each country delegation to submit
examples of techniques for inclusion in IEC 61511-3. IEC 61511-3 Annex A was submitted by the UK.
IEC 61511-3 Annexes B, C and F were submitted by the US. IEC 61511-3 Annex F is a precursor to the
CCPS book “Layers of Protection Analysis: Simplified Process Risk Assessment” (see Annex R,
References). IEC 61511-3 Annex E was submitted by Germany. IEC 61511-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.

— 17 — ISA-TR84.00.04-2005 Part 1
4.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
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. Owner/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 owner/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.
ISA-84.01-2004-1 includes high demand/continuous mode of operation, as well as demand

mode. ISA-84.01-1996 only addressed demand mode, because the vast majority of SIS operate
in a demand mode. Annex I of this technical report 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 SISs.
2) New requirements for SIL 4 Safety Instrumented Functions.
ISA-84.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 ISA-
SP84 committee strongly advises against the implementation of a single layer SIL 4 SIS. Annex J
of this technical report 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.
ISA-84.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 with the requirements of the standard. Annex F of this technical report provides
further information on the contribution of the BPCS as an initiating cause and as a protection
layer.

ISA-TR84.00.04-2005 Part 1 — 18 —
4.10 Clause 10 – SIS Safety Requirement Specification
The requirements stated in this clause are more extensive than those found in ISA-84.01-1996. The new
requirements include information that was typically developed by the owner/operator, if necessary. ISA-
84.01-1996 informative Annex B identified these issues. For example, ISA-84.01-2004-1 requires that the
owner/operator document the following:
• Criteria for successful operation of the SIF--e.g., are there any specific requirements for tight
shutoff valves.
• Requirements for the repair of an SIS fault.
• Requirement for the SIS to survive a major accident event--e.g., is fireproofing on shutoff valves
required?
4.11 Clause 11 – SIS Design and Engineering
There are a number of requirements in Clause 11 that are not addressed in 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. Annex K of this technical
report provides additional information concerning fault tolerance. Annex L of this technical report provides
a discussion of the IEC 61508 SIL Claim Limit. Annex P of this technical report discusses various
considerations when defining the response to dangerous, detected faults.
• Requirements for the selection of SIF devices.
Annex L of this technical report 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.
ISA-84.01-2004-1 makes a distinction between general-purpose (i.e., off-the-shelf) logic solvers and SIS
logic solvers. ISA-84.01-1996 did not make any distinction between the two.
Annex M of this technical report 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 ISA-84.01-1996 Annex B were incorporated in ISA-84.01-2004-2, the ISA-
SP84 committee wanted to retain the good engineering practice that was documented in ISA-84.01-1996
Annex B. As a result, Annex N of this technical report 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-2002 (visit www.isa.org/standards) is a technical report that discusses how to perform

SIL verification calculations.

— 19 — ISA-TR84.00.04-2005 Part 1
4.12 Clause 12 – Requirements for Application Software, Including Selection Criteria for Utility
Software
ISA-84.01-1996 requires that the application software be developed in accordance with the Safety
Requirements Specification (SRS). ISA-84.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 ISA-84.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. Annex O of this technical report provides a discussion of the evolution
of application software development.
4.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 ISA-84.01-1996.
4.14 Clause 14 – SIS Installation and Commissioning
The content of this clause is almost an exact duplicate of what is written in ISA-84.01-1996. There are no
new requirements.
4.15 Clause 15 - SIS Safety Validation
The contents of this clause are very similar to what is described in the ISA-84.01-1996 clause on pre-
startup acceptance test (PSAT).
4.16 Clause 16 – SIS Operation and Maintenance
OSHA 1910.119 included many requirements for operation and maintenance. Consequently, ISA-84.01-
1996 referenced these requirements and included only a few additional requirements specifically related
to SIS. ISA-84.01-2004-1 expands the ISA-84.01-1996 requirements for operation and maintenance
including the following:
1) Operation procedures and associated training should address:
o how the SIF functions.

o the hazard that the SIF is protecting against.
o circumstances under which bypass switches can be activated.
o when to execute a manual shutdown.
o appropriate response to diagnostic alarms.
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.
4) Operation and maintenance management should identify any specific requirements for a visual
inspection of hardware integrity.

ISA-TR84.00.04-2005 Part 1 — 20 —
4. 17 Clause 17 SIS Modification
There are no new requirements in this clause. Requirements were previously covered by ISA-84.01-1996
and OSHA 1910.119.
4.18 Clause 18 – SIS Decommissioning
This clause is very similar to what is in ISA-84.01-1996 with no new requirements.
4.19 Clause 19 – Information and Documentation Requirements
There are no new requirements in this clause. Documentation requirements were previously covered by
ISA-84.01-1996 and OSHA 1910.119.

— 21 — ISA-TR84.00.04-2005 Part 1
Table 4-1 – Summary of Differences
ISA-84.00.01-2004 ISA-84.01-1996
Process and its equipment/ISA-84.01-1996

Process and its associated Equipment/IEC 61508 Clause 3.1.5 makes numerous references to Equipment
Under Control(EUC)
SIF Safety function
SIL for SIF SIL for SIS
BPCS performance expectations are limited. Excludes BPCS in Clause 1.2.8
Validation Pre-startup 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
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

ISA-TR84.00.04-2005 Part 1 — 22 —
ISA-84.00.01-2004 ISA-84.01-1996
Requirements in Clauses 3.1.7.2 and 3.1.7.1 and discussed in

Common cause failure definition
Annexes B.2, B.8, B.10 and D.3
Requirements in Clause 3.1.5 and Discussed in B.4.4.1.1,

Diagnostics coverage definition
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 Informative

Hazard definition
Clauses 4.2.1 – 4.2.5 and Annex A
Independent organization/department/person requirements Not discussed
Other technologies Excludes non-E/E/PE technologies
Safety-related system requirements IEC 61508 Part 2 - Discussed in Clause 7.3, but not defined as safety-related
Clause 7.4.7 Requirements for E/E/PES Implementation system requirements
Discussed in Clause 3.1.42 and informative Clauses 4.2.3 and

Protection layer definition
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

Safety lifecycle address the assessment, design, 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
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 error

Systematic error guidance
guidance
Includes operator action in SIS Excludes operator action (Clause 1.2.14) in SIS

— 23 — ISA-TR84.00.04-2005 Part 1
Annex A Example Methods for Determining Grandfather Status
NOTE — Annex A is referenced in Clause 3.0 of this technical report.
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 (ISA-84.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.7 provide examples of methods used by some owner/operators in evaluating
existing SIS. These methods are provided as examples and should not be considered the only acceptable
approaches. Owner/operators 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, and increased testing.
A.2 Timing
The owner/operator should document the adequacy of the SIS at the cyclic process hazards analysis
(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 — Clause 3.2 of this technical report 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; or

ISA-TR84.00.04-2005 Part 1 — 24 —
• 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 Process
Hazards Analysis (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 the community,
an assessment of the protection layers is conducted to determine whether the required functionality and
integrity is 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 Safety Integrity Level (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 (PFD) for the SIF. The actual PFD is then
compared to the SIL assigned by the PHA team. If the actual PFD 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
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

— 25 — ISA-TR84.00.04-2005 Part 1
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. Owner/operators should decide and document which approach is suitable for their process
facilities.
Step 1. Define process facility grandfather clause application rules.
After reviewing Clause 3.0 of this technical report, the owner/operator establishes ground rules that are to
be implemented whenever existing SISs 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 – www.isa.org), or
• Corporate standard(s).
NOTE — Corporate standards should be verified against key requirements of ISA-84.01-2004-1 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:
a. An SIF whose design basis is not in compliance with GR-1 should be upgraded to ISA-84.01-2004-1 as soon as
possible.
b. An SIF whose design basis meets GR-1 should be upgraded to ISA-84.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.
Step 4. Analyze the SIF design basis and determine if it meets the grandfather clause ground rules.

ISA-TR84.00.04-2005 Part 1 — 26 —
A. If the SIF does not meet GR-1, then the SIF should be upgraded to meet ISA-84.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, testing, and operating according
to the design basis, the SIF should be upgraded to meet the design basis.

— 27 — ISA-TR84.00.04-2005 Part 1
Step 1
Define grandfather clause rules
Step 2
List existing SISs
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

ISA-TR84.00.04-2005 Part 1 — 28 —
A.3.3 Comparison with Key ISA-84.01-1996 Requirements
In this method, the owner/operator conducts an assessment, comparing the existing SIS to key ISA-
84.01-1996 requirements. Prior to the issuance of ISA-84.01-2004-1, ISA-84.01-1996 was used as a
good engineering practice for SIS by this owner/operator. This following questionnaire, Table A-2, was
designed for use in verifying whether existing SISs meet the intent of the requirements in 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 ISA-84.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 Safety Instrumented Systems (SIS) are defined? For example, 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 Safety Instrumented Functions (SIFs) implemented with the SIS have a
Safety Integrity Level (SIL) assigned to them?
a. 100% ____
b. 50 to 99% ____
c. 25 to 49% ____
d. < 25% ____
3. What percentage of the SISs were designed and built to meet the SIL of the SIF?
a. 100% ____
b. 50 to 99% ____
c. 25 to 49% ____
d. < 25% ____
4. What percentage of SISs 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 ____
Do current maintenance practices support the SIL of the SIFs – is the assumed Mean Time to
5. Repair (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 ____.
6. Are SIS smart sensors write protected and do they require a safety review for modification?
a. yes ____
b. no ____

— 29 — ISA-TR84.00.04-2005 Part 1
No. Question
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 ____
8. How well are maintenance procedures maintained for the SIS?
a. well maintained ____
b. adequately maintained ____
c. poorly maintained ____
d. not maintained ____
9. How well is maintenance documentation maintained?
10. How well are Operations personnel trained on the SIFs of the Safety Instrumented System (SIS)?
d. not trained ____
11. How well are operating procedures maintained for the SIS?
12. How well are the results of the SIS on-line testing documented?
a. well documented ____
b. adequately documented ____
c. poorly documented ____
d. not documented ____
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% ____
14. Are the SIS hardware, embedded software, and utility software under a formal revision and
release control program?
a. yes ____
b. no ____
15. Who on your site receives the critical problem notifications from the SIS manufacturer?
a. name ____
b. don’t know ____

ISA-TR84.00.04-2005 Part 1 — 30 —
No. Question
16. Is the SIS application logic under a formal revision and release control program?
a. yes ____
b. no ____
17. Do all SIS energize-to-trip circuits have an end-of-line current monitor?
a. yes ____
b. no ____
d. does not apply, all circuits are de-energized to trip ____
18. Are SIS Inputs or outputs forced as part of operating procedures?
a. yes ____
b. no ____
A.3.4 Comparison with Key ISA-84.01-2004-1 Requirements
Another approach to SIS evaluation is the development of a checklist based upon ISA-84.01-2004-1
requirements. The checklist should address major philosophical and technology issues defined in ISA-
84.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 in Table A-3.
Table A-3 – Checklist for Example Approach Presented in Annex A.3.4

No. Question
1. Are the Safety Instrumented Systems (SIS) defined? For example, any of the following: logic
narrative, cause and effects matrix, logic diagram.
a. yes ____
b. no ____
2. Have the Safety Instrumented Functions (SIFs) implemented with the SIS been assigned a Safety
Integrity Level (SIL)?
a. yes ____
b. no ____
3. Are SIS field devices and logic solver independent of the initiating cause?
a. yes ____
b. no ____
4. Are SIS field devices and logic solver independent of other protection layers?
a. yes ____
b. no ____

— 31 — ISA-TR84.00.04-2005 Part 1
No. Question
5. Are the SISs designed and built to meet the SIL of the SIF?
a. yes ____
b. no ____
6. Are the SISs tested frequently enough to maintain the SIL of the SIF?
a. yes ____
b. no ____
7. Are the SISs designed to meet the required fault tolerance for the SIL of the SIF?
a. yes ____
b. no ____
8. Are field devices and logic solver functionally separate from the BPCS?
a. yes ____
b. no ____
9. Do current maintenance practices support the SIL of the SIFs – is the assumed Mean Time to
Repair (MTTR) on fault detection met? This should Include analog input maintenance based on
deviation alarms.
a. yes ____
b. no ____
d. SIFs are tested at the following frequency ____.
10. Are SIS smart sensors write protected and do they require a safety review to modify?
a. yes ____
b. no ____
11. How well are the maintenance personnel or computer support personnel (whoever maintains the
SIS) trained on the SIS?
d. not trained ____
12. How well are maintenance procedures maintained for the SIS?
13. How well is maintenance documentation maintained?

ISA-TR84.00.04-2005 Part 1 — 32 —
No. Question
14. How well are Operations personnel trained on the SIFs of the Safety Instrumented System (SIS)?
d. not trained ____
15. How well are operating procedures maintained for the SIS?
16. How well are the results of the SIS on-line testing documented?
a. well documented ____
b. adequately documented ____
c. poorly documented ____
d. not documented ____
17. Are the SIS inputs and outputs shown on the P&IDs?
a. yes ____
b. no ____
18. Is the SIS hardware, embedded software, and utility software under a formal revision and release
control program?
a. yes ____
b. no ____
19. Who on your site receives the critical problem notifications from the SIS manufacturer?
a. name ____
b. don’t know ____
20. Is the SIS application logic under a formal revision and release control program?
a. yes ____
b. no ____
21. Do all SIS energize-to-trip circuits have an end-of-line current monitor?
a. yes ____
b. no ____
d. does not apply, all circuits are de-energized to trip ____
22. Are SIS Inputs or outputs forced as part of operating procedures?
a. yes ____
b. no ____
23. Historically, has the SIS performance met the operating demands?
a. yes ____
b. no ____

— 33 — ISA-TR84.00.04-2005 Part 1
No. Question
24. Historically, has the spurious activation of the SIS caused process incidents?
a. yes ____
b. no ____
A.3.5 Comparison to Accepted Prior Design Practices - A
This clause A.3.5 illustrates one company's approach to determining if an existing safety instrumented
function (SIF) meets the grandfather clause requirements. This approach involves four steps, as follows:
Step 1: Determine the required risk reduction 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
ISA-84.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 ISA-
84.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 ISA-
84.01-2004-1 is recommended.
Step 4: Verify that the SIF meets its SIL requirements by acceptable analysis method(s).

ISA-TR84.00.04-2005 Part 1 — 34 —
Table A-4 – Checklist for Example Approach Presented in Annex A.3-5

This table should not be used as a design guide for new installations. It is an example provided by
one company to evaluate existing SISs.
Independent protection layer specification credit from Risk Assessment

GENERAL SUBJECT
RRF 10 for RRF 100 for SIS RRF 1000 for SIS
CATEGORY
SIS or 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 fail safe
properties) and properties
watchdog or
Dual system (without
watchdog) 1oo2
Programmable Logic Solver Acceptable AK 4* AK 5* or higher

(PLC/SIS) with DIN 4 credits can be used for AK-6* certified
certificate systems (DIN VDE 801)
Solid state logic No System with fail safe Advanced system with fail safe logic
requirements logic
Pneumatic logic Acceptable Not acceptable Not acceptable
Relays Acceptable Acceptable if high No, unless guided contacts and prior use.
SIS system
grade commercial No jumpers. Need to review each system
hardware
quality. Need to on status.
review each system
on status.
DCS Acceptable for 1 Not acceptable Not acceptable

SIS credit or 2
credits for
BPCS and
Alarm on 1
platform if
applied into
different control
boxes - Prior
use
SIS/ BPCS logic Separate systems Acceptable Acceptable Acceptable

solver Integrated systems Acceptable Not acceptable Not acceptable unless IEC 61508
hardware unless IEC 61508 compliant
requirements
compliant
Separate systems Limited Limited variability Limited variability language (e.g., ladder
variability language (e.g., logic) or requirements of the user and/or
SIS logic solver language (e.g., ladder logic) or safety manual
software ladder logic), or requirements of the
requirements requirements of user and/or safety
the user and/or manual
safety manual

— 35 — ISA-TR84.00.04-2005 Part 1

GENERAL SUBJECT
CATEGORY
SIS or BPCS
or alarms
Integrated systems Function See user and/or See user and/or safety manual
protected safety manual requirements
against changes requirements
and override
General verification Program For verification For verification requirements from user
requirements verification requirements from and/or safety manual
performed and user and/or safety
documented manual
"Smart" Instruments Acceptable Acceptable 1oo2/ Acceptable 1oo2/ 2oo3/ 1oo2D/ 2oo2D
1oo1/1oo2/ 2oo3/ 1oo2D/ 2oo2D
2oo3/ 1oo2D/
2oo2D
Certified instruments Acceptable Acceptable Acceptable
Non-smart analog electronic Acceptable Acceptable 1oo2/ Acceptable 1oo2/ 2oo3

Instruments 1oo1/1oo2/ 2oo3
2oo3
Pneumatic analog Acceptable Acceptable 1oo2/ Requires hazard and risk analysis team
Instruments 1oo1/1oo2/ 2oo3 approval
Instrumentation 2oo3
(sensors)
Discrete measurements Acceptable Acceptable 1oo2/ Requires hazard and risk analysis team
(e.g., pressure switch) 1oo1/1oo2/ 2oo3 approval
2oo3
Pneumatic transmitter with Acceptable Acceptable 1oo2/ Requires hazard and risk analysis team
switches (behind panel) 1oo1/1oo2/ 2oo3 approval
2oo3
Pneumatic transmitter with Acceptable Acceptable 1oo2/ Acceptable 1oo2/ 2oo3

transducer (behind panel) 1oo1/1oo2/ 2oo3
2oo3
Separate sensors Acceptable Acceptable Acceptable
Sharing of Shared sensors Acceptable, Acceptable, when Acceptable, when two or more sensors are
sensors when two or two or more sensors used
more sensors are used
are used
Instrument Instrumentation according to Recommended Recommended Recommended

Installation proven practice

ISA-TR84.00.04-2005 Part 1 — 36 —

GENERAL SUBJECT
CATEGORY
SIS or BPCS
or alarms
Final elements from an Acceptable Acceptable Acceptable 1oo2

approved manufacturer 1oo1/1oo2 1oo1/1oo2
suppliers list
Control valve as final Acceptable if Acceptable as Acceptable second final element

element if: the valve is not second final element
-proof test and maintenance the only IPL
records demonstrate that it which reacts
meets the shutoff & closing within the
speed needs process safety
Final elements
-the fail safe action is time for this
NOTE: This architecture is not allowed for
defined correctly scenario (e.g.,
new or upgraded installations.
-it is not shared with another PSV or alarm
IPL for the same scenario but non-safety
-the interlock has to work related)
direct on the actuator
Analog operated block Acceptable like Acceptable like Acceptable like normal block valves
valves with direct actuation normal block normal block valves
of SIS function valves
Sensors Use proven test Use proven test Unless known use default MTTF from
interval or use interval or use publications for PFD calculations
default MTTF default MTTF from
from publications for PFD
publications for calculations
PFD
calculations
Logic solver system Use system Use system Use system manufacturer MTTF data for
manufacturer manufacturer MTTF PFD calculation
MTTF data for data for PFD
PFD calculation calculation
Test
frequencies
calculated from Final element Use proven test Use proven test Unless known use default MTTF from
PFD interval or use interval or use publications for PFD calculations
default MTTF default MTTF from
from publications for PFD
publications for calculations
PFD
calculations
Maintenance and repair Procedures Procedures required. Procedures required. Repair time as
required. Repair time as required by instrument redundancy.
Repair time as required by
required by instrument
instrument redundancy.
redundancy.

— 37 — ISA-TR84.00.04-2005 Part 1

GENERAL SUBJECT
CATEGORY
SIS or BPCS
or alarms
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 correct.
General
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 a 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, Principles for Computers in
Safety-Related Systems, which is a German standard.

ISA-TR84.00.04-2005 Part 1 — 38 —
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
SISs 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 SISs 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 determines whether
SIS functionality is achieved. If the design practice is determined acceptable, any SISs designed in
accordance with the practice can be considered for the grandfather clause.
For example, a company that is using its own classification system could map its 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 SISs 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 Acceptable Prior Design Practice Classification

to SIL Levels
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 industry organizations,
such as NFPA, API, ASME, ANSI, and ISA. 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.

— 39 — ISA-TR84.00.04-2005 Part 1
Industrial standards often define, in a prescriptive manner, the SIFs required to safely manage the
process or equipment. For existing SIFs, omission of the safety integrity level (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 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 ISA-84.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
is 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
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 safety instrumented
function (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

ISA-TR84.00.04-2005 Part 1 — 40 —
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.
• SIF logic solver requirements.
• SIF devices and required testing interval.
The operating basis documentation should cover the operation and maintenance requirements of ISA-
84.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.

— 41 — ISA-TR84.00.04-2005 Part 1
Annex B Operator Action as an Independent Protection Layer (IPL)
NOTE — Annex B is referenced in the following: Clause 4.1, Clause 4.11, Annex K.2, Annex N.9.2., 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 ISA-84.01-2004-1 Clause 8.2.1 for requirements on hazard and risk analysis.
NOTE 2 — Refer to ISA-84.01-2004-1, Clauses 11.3.1 through 11.3.3, for a discussion on the operator response to diagnostic
faults.
ISA-84.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 ISA-84.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 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 a operator action
IPL implemented in the BPCS layer when it has met the other criteria discussed in this Annex and in Annex F.

ISA-TR84.00.04-2005 Part 1 — 42 —
• All hardware involved should fully meet all requirements of ISA-84.01-2004.
• 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, ISA, The Engineered Equipment Materials and Users Association
(EEMUA), and Health & Safety Executive have developed extensive guidance on alarm
management. Design of alarm systems should consider ISA -18.1-1979 (R 2004), ISA-RP 60.3-
1985, and ISA-RP 60.6-1984; IEEE-845, IEEE-1023, and IEEE-1289; and NUREG-0700, Chapter
4 (see References, Annex R).
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 factor of less than 10, under the following conditions:
• The guidance in Annex F.2 of this technical report 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 Probability of Failure on Demand
(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) principles 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.

— 43 — ISA-TR84.00.04-2005 Part 1
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 probability of failure on demand (PFD) 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
(independent protection layer). 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 process safety time, when an operator response to an alarm is being
considered for reducing the risk of a specified hazard scenario. The 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 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 Probability of Failure on Demand (PFD) values, the owner/operator is cautioned
to do a detailed human reliability assessment to confirm the assumed PFD. The values in the table below
represent the PFD of the entire IPL. They are not to be interpreted as PFD of the human action only.
There are a number of methods for evaluating the probability of human error. Two of the more well-
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, things such as: initial training, refresher training,
procedures engineered to decrease the likelihood of human error, important human factors that have

ISA-TR84.00.04-2005 Part 1 — 44 —
been identified, potential for alarm overload, adequate time to respond to the safety alarm, and adequate
staffing.
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. They are not to be interpreted as PFD
of the human action only.
IPL Comments PFD from Suggested IPL PFD

Literature and
Industry
-1 -1
Human response to a visual Simple well-documented action with 1.0 – 1 x 10 ~1 x 10
observation of a process hazard clear and reliable indication that the (limited by
(e.g., visible vapor cloud, obvious action is required. The operator does human
loss of containment) with ≥10 not have to perform troubleshooting response)
minutes response time (not a or diagnostics to take the action.
response to instrumentation)
-2 -2
Human response to a visual Simple well-documented action with 1 x 10 1 x 10
observation of a process hazard clear and reliable indication that the (limited by
(e.g., visible vapor cloud, obvious action is required. Minor human
loss of containment) with ≥40 troubleshooting or diagnostics is response)
minutes response time (not a allowed if needed before taking
response to instrumentation) action.
-1 -1
Human response to BPCS indication Simple well-documented action with > 1 x 10 ~ 1 x 10 **
or alarm with ≥10 minutes response clear and reliable indication that the
time action is required. The operator does (limited by ISA-
84.00.01-2004)
not have to perform troubleshooting
or diagnostics to take the action.
-1 -1
Human response to BPCS indication Simple well-documented action with > 1 x 10 ~ 1 x 10 **
or alarm with ≥40 minutes response clear and reliable indication that the
(limited by ISA-
time action is required. Minor
84.00.01-2004)
troubleshooting or diagnostics is
allowed if needed before taking
action.
-1 -1
Human response to SIS indication or Simple well-documented action with 1 x 10 1 x 10
alarm with ≥10 minutes response clear and reliable indication that the
(limited by
time action is required. The operator does
not have to perform troubleshooting human
response)
or diagnostics to take the action.
-1 -1
Human response to SIS indication or Simple well-documented action with 1 x 10 – 1 x 10
alarm with ≥40 minutes response clear and reliable indication that the -2
time action is required. Minor 1 x 10 or
troubleshooting or diagnostics is (limited by
-1
1 x 10 – 1 x 10
-2
allowed if needed before taking human

action. (as determined by
response)
human reliability
assessment)

— 45 — ISA-TR84.00.04-2005 Part 1
IPL Comments PFD from Suggested IPL PFD

Literature and
Industry
-1 -2
Human response to SIS indication or Simple well-documented action with 1 x 10 – 1 x 10
alarm with more than 24 hours clear and reliable indication that the -3
1 x 10 or
response time; assumes multiple action is required. Minor
operators have an opportunity to troubleshooting or diagnostics is (limited by -1 -3
human 1 x 10 – 1 x 10
detect the alarm(s) and take action allowed if needed before taking the
response) (as determined by
action.
human reliability
assessment)
Assuming adequate documentation, training, and testing procedures, and drills for the human.
* Adapted from Layer of Protection Analysis, Simplified Process Risk Assessment (Center for Chemical Process Safety, American
Institute of Chemical Engineers, New York: 1996); Inherently Safer Chemical Processes: A Lifecycle Approach (Center for Chemical
Process Safety, American Institute of Chemical Engineers, New York: 1996); and Handbook of Human Reliability Analysis with
Emphasis on Nuclear Power Plant Applications (Swain and Guttman, NUREG/CR-1278, United States Nuclear Regulatory
Commission, Washington, DC: 1983).
-1 -1
** Rounded to 1 x 10 for ease of computation, while recognizing the ISA-84.00.01-2004-1 limit of > 1 x 10 .

ISA-TR84.00.04-2005 Part 1 — 46 —
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 SIS action?
Are operators periodically evaluated for competency in SIS 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 SIS 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 SIS 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 set points clearly identified?
Are the completions of commanded SIS actions (i.e., valve position, pump status) displayed?

— 47 — ISA-TR84.00.04-2005 Part 1
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 probability of
failure on demand (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
ISA-84.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 a 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 PFD 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 PFD 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 PFD of the example architecture.

ISA-TR84.00.04-2005 Part 1 — 48 —
Control Room
SIS
Logic PAH HS
Device
TMR
PT TMR: Tri-modular redundant
PT: Pressure transmitter
S FC: Fail closed
S: Solenoid
AS AS: Air supply
PAH: Pressure alarm high
HS: Hand switch
FC
Figure B-2 – Operator- Initiated SIF Action to Close Valve on High Pressure

— 49 — ISA-TR84.00.04-2005 Part 1
Operator Actuated
SIS Fails to Provide
Safety Function
Alarm Presentation/
Sensor TMR Logic Solver Final Element
Operator Actuation
Detection Failure Failure Failure
Failure
Sensor Fails Impulse Line to Miscalibration of Solenoid Valve SIS Shutdown Valve SIS Shutdown Valve
Dangerously Sensor Plugs Sensor Fails to Vent Fails to Close Leaks
Operator Fails to
Alarm Presentation
Take Correct
Fails
Response Action
Electrical Power
Alarm Fails Supply to Alarm
System Failure
Figure B-3 – Fault Tree Analysis of Figure B-2

— 51 — ISA-TR84.00.04-2005 Part 1
Annex C Management of Functional Safety
NOTE — Annex C is referenced in Clause 4.5.
C.1 Purpose
Management of functional safety is a new requirement in ISA-84.01-2004-1, but it has always been
considered a necessary activity by OSHA 1910.119 and 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 ISA-84.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;
and
• The personnel that 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 ISA-84.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 & 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

ISA-TR84.00.04-2005 Part 1 — 52 —
management, or plant operations, and should have the authority to prevent the project from proceeding if
deviations are not addressed.
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 failures rates, etc.) should also be developed. For further information on auditing activities, refer
to Annex E of this technical report. Table C-3 provides an example of the activities that should occur
during implementation of the ISA-84.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.

Table C-1 – Example Roles & Responsibilities Matrix
ISA-84.01-2004-1 Clause SIS Project Area Operations Maint/Elec Process/ Project Project Corporate/
Specialist Leader Supervisor Rep Rep Design ECP SIS Plant
(note 1) Engineer Contract Contract HS&E
or or
Clause 6 – Define safety lifecycle 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 L R A R R P P A

assessment (Layers of Protection
Analysis, Layered Risk Analysis, etc,)
and
Clause 9 – Allocation of safety
— 53 —
functions to protection layers
Clause 10 – SIS safety requirement L R A R R P P

specification (SRS)
Clause 11 – SIS design and L R A R R P

engineering
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 L R A R R P

(SAT)
ISA-TR84.00.04-2005 Part 1
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
ISA-TR84.00.04-2005 Part 1 — 54 —
Table C-1 – Example Roles & Responsibilities Matrix (continued)

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 reviews the final material.
Blank – No involvement
Notes
1) A quality SIS requires a number of plant personnel. 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 schedule and budget.
SIS Specialist - Keeper of technology.
Maintenance Representative - Coordinates maintenance issues.
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 answers to operational decisions, for example,
graphics design and location of manual shutdown pushbuttons.
Process Engineer - Coordinates answers to process decisions--e.g., what the trip setpoint
values are and justification for value.
4) The additional resources, as needed, include representatives from the following groups:
Maintenance
Operations
Process Engineering
Reliability
Health, Safety & Environment

— 55 — ISA-TR84.00.04-2005 Part 1
Table C-2 – Examples of experience or skills for the disciplines represented in the
example Roles & Responsibility Matrix shown in Table C-1
Discipline Experience or Skills
SIS Specialist Very knowledgeable with ISA-84-2004/ISA-84-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 SISs
Knowledgeable in the appropriate selection of integrity and reliability data
Knowledgeable on the methods for verifying SILs
Understands the roles & 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 hazards & 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 hazards & 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 on 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
Experienced/training on hazard and risk analysis methodology
Experienced/training in device common mode/common cause failures
Experienced/training in the work process for selection of devices
Experienced/training in the design, installation, and management of SISs
Experienced/training in the appropriate selection of integrity and reliability data
Experienced/training on the methods for verifying SILs
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.

ISA-TR84.00.04-2005 Part 1 — 56 —
Discipline Experience or Skills
Experience/training on process hazards
Experience/training on integrity/reliability data
Experience/training on the impact of testing on SIS performance
Experience/training on the impact of maintenance activities on plant operation
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 on process hazards
Experience/training on the impact of alarm response on safe operation
Experience/training on the impact of operational activities on safe operation
Area Supervisor Experience/training with SIS lifecycle and understands personal role and responsibility
Knowledgeable concerning operator training, responsibilities and capabilities
Knowledgeable concerning maintenance training, responsibilities and capability
Knowledgeable concerning process hazards
Experience/training on the impact of operational activities on safe operation
Experience/training on the impact of testing on SIS performance

— 57 — ISA-TR84.00.04-2005 Part 1
Table C-3 – Overview of important activities, including verification, input

information, and output deliverables associated with ISA-84.01-2004-1
Clause 6 – Define safety lifecycle 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 lifecycle activities – 6.1
2. Organize technical activities into a safety lifecycle – 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 safety lifecycle 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 lifecycle 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 occurs – 5.2.6.1.3
5. Identify functional safety assessment team leader
6. Develop roles-and-responsibilities matrix and implementation schedule

ISA-TR84.00.04-2005 Part 1 — 58 —
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&IDs & PFDs
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. 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 functions are SIFs
2. Safety functions allocated to protection layers – 9.1
3. The required SIFs determined – 9.1
4. The required SIL for each SIF determined – 9.1
Verification (Clause 7)

— 59 — ISA-TR84.00.04-2005 Part 1
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:
a) normal operation
b) start-up
c) shutdown
d) maintenance
e) process upset, and
f) 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
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)
-5
b. The dangerous failure rate of the BPCS is not assumed to be better than 10 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
reasonable 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 factor for a BPCS that does not conform with this standard when used as a protection
layer is less than 10 – 9.4.2

ISA-TR84.00.04-2005 Part 1 — 60 —
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.

— 61 — ISA-TR84.00.04-2005 Part 1
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
Activities:
SIS safety requirements – 10.3
1. These requirements are sufficient to design the SIS and include the following: – 10.3.1
a. Description of SIFs
b. Requirements to identify and take account of common cause failures
c. Definition of safe state for each SIF
d. Concurrently occurring safe states which create a separate hazard
e. Assumed sources of demand and demand rate on the SIF
f. Requirements for proof test intervals
g. Response time requirements to bring process to safe state
h. The SIL and mode of operation (continuous/demand) for each SIF
i. SIS inputs – pre-trip alarm and trip set points
j. SIS output actions, including tight shut off when required
k. Functional relationship between inputs and outputs
l. Requirements for manual shutdown
m. Energize vs. de-energize-to-trip requirements
n. Startup permissives and sequence after a trip
o. Spurious trip rate requirements
p. Failure modes and desired response of the SIS
q. All interfaces between SIS and other systems
r. Plant modes of operation and SIFs required to operate in each mode
s. Application software requirements
t. Override/inhibits/bypass requirements
u. Response actions when SIS failure detected
v. Mean time to repair requirements
w. Dangerous combinations of output states from the SIS to avoid
x. Extremes of environmental conditions
y. ID normal and abnormal modes
z. Requirements for SIF to survive major accident–e.g., valve to remain open during fire.
2. The software SRS is derived from the SRS and the chosen architecture of the SIS – 10.3.2

ISA-TR84.00.04-2005 Part 1 — 62 —
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
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 can not affect
the higher SIL’s SIF – 11.2.3
d. 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
e. 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
f. 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 HMI interfaces follows good human factors practice
and accommodates the likely level of training – 11.2.6
g. Unless the SRS specifies otherwise, the safe state is maintained until reset initiated – 11.2.7
h. Unless the SRS specifies otherwise, the manual S/D is independent of logic solver – 11.2.8
i. 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
j. 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
k. Energize to trip requires: – 11.2.11 & 11.6.2
1) Loss of circuit integrity
2) Power supply integrity
3) Loss of power detection

— 63 — ISA-TR84.00.04-2005 Part 1

Activities (cont’d):
2. 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
3. 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
4. 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 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
5. 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
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
6. Requirements for selection of FPL & 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. Fixed Programming Language (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 PFD is acceptable
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: constraints for operation,
maintenance, and fault detection for typical configurations and the intended operational profiles – 11.5.4.5

ISA-TR84.00.04-2005 Part 1 — 64 —

7. 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
a) program sequence monitoring
b) protection of code against modification or failure detection by on-line monitoring
c) failure assertion or diverse programming
d) range check of variables or plausibility check of values
e) modular approach
f) appropriate coding standards used for embedded and utility software
g) tested in typical configuration, with test cases of intended operational profiles
h) trusted software modules and components have been used
i) system has undergone dynamic analysis and testing
j) system does not use artificial intelligence or dynamic reconfiguration
k) fault-insertion testing documented
g. Using a PE logic solver in an SIL 2 application requires a safety manual the describes 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
8. Requirements for selection of FVL programmable components and subsystems – 11.5.6

PE logic solvers programmed using Full Variable Language (FVL) are in accordance with IEC 61508-2 & 3 –
11.5.6.1
9. 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
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

— 65 — ISA-TR84.00.04-2005 Part 1

10. Operator interface requirements – 11.7.1

a. Where Operator SIS HMI interface is 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
has occurred
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 the BPCS to the SIS is managed so the safety functionality is not compromised. – 11.7.1.5
11. 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
12. 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

ISA-TR84.00.04-2005 Part 1 — 66 —

13. 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, on-line testing is performed – 11.8.1
b. Where on-line 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
14. 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 dangerous detected failure rate of each subsystem due to random hardware faults
3) estimated dangerous undetected failure rate of each subsystem due to random hardware faults
4) the susceptibility of the SIS to common cause failures
5) the diagnostics coverage of any periodic diagnostics test
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 EMC disturbances
10) Susceptibility to climatic and mechanical conditions

— 67 — ISA-TR84.00.04-2005 Part 1
Clause 12 – Requirements for application software, including selection criteria for utility software
Inputs:
1. SRS
2. Function Blocks -- prior use, else should use IEC 61508-3
Outputs:
1. Defined software safety lifecycle – 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 safety requirements specification (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 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 lifecycle –
12.7.1.2
Activities:
1. Lifecycle requirements for application software – 12.1

a. Specify an application software safety lifecycle during safety planning that satisfies the requirements –
12.1.2.1
b. For each phase of the software safety lifecycle 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 lifecycle phase to: – 12.1.2.4
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

ISA-TR84.00.04-2005 Part 1 — 68 —
Activities (cont”d):
e. For each phase of the application software safety lifecycle, the verification results are available – 12.1.2.5
f. If application software changes pertained to earlier lifecycle 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 & embedded software, and the utility software tools are under
configuration managements – 12.1.2.7
h. Application software test planning addressed: – 12.1.2.
1) policy for integrating software and hardware
2) test cases and test data
3) types of test 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 expressed and structured so they are: – 12.2.2.5
1) clear to all 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
7) software self-monitoring
8) other SIS device monitoring (sensors & final elements)
9) on-line 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 on-line 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 above functions

— 69 — ISA-TR84.00.04-2005 Part 1
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 application software design should:
1) include integrity & 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 – 12.4.2.4
d. When the application software implements SIFs of different SILs, the target SIL of the SIFs are identified.
e. The software is designed to the highest SIL unless independence between the SIF can be shown in the
design. – 12.4.2.5
f. 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 61508-3
2) for FPL compliance with Clause 11.5.4
3) for LVL compliance with Clause 11.5.5
g. The application program documentation contains: – 12.4.2.7
1) company & 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 features used for maintaining the safety integrity of all data are described and justified – 12.4.3.5

ISA-TR84.00.04-2005 Part 1 — 70 —
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
2) 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
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
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
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 are 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

— 71 — ISA-TR84.00.04-2005 Part 1
Activities (cont.):
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 lifecycle 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 sub system were subject to a
safety impact to determine: – 12.5.2.2
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
12. Application software verification – 12.7.1

a. Verification planning for each phase of application software safety lifecycle – 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 lifecycle phases
4) correctness of data

ISA-TR84.00.04-2005 Part 1 — 72 —
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

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
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 and test results
b. whether objectives and criteria 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

— 73 — ISA-TR84.00.04-2005 Part 1
Clause 14 – SIS installation and commissioning

Inputs:
1. SIS application software

2. If 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
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
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 specifications, 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

ISA-TR84.00.04-2005 Part 1 — 74 —

Activities:
1. SIS validation planning defines all activities required for validation including 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
c. manual and automated techniques
d. static and dynamic techniques
e. analytical and statistical techniques
f. 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)
g. the required environment for validation activities (i.e., calibrated tools and equipment)
h. pass-fail criteria including:
1) required process and operator input signals with their sequence and values
2) expected output signals with their sequence and values
3) other acceptance criteria--i.e., memory usage, timing, and value tolerance
4) 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 its associated SIFs validation is in accordance with the validation planning including: –
15.2.4
a. SIS performing as specified in SRS under all operating conditions
b. confirmation that adverse interactions of the BPCS and other interfaces 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
o. diagnostic alarms per SRS
p. loss of utilities actions per SRS
q. confirmation of EMC immunity

— 75 — ISA-TR84.00.04-2005 Part 1

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 lifecycle 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 lifecycle 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 (startup), the following activities are
carried out: – 15.2.8
a. all bypasses returned to normal
b. isolation valves set to startup position
c. test materials removed
d. all forces removed
9. 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
2. Operate and maintain the SIS so the designed functional safety is maintained – 16.1.1

ISA-TR84.00.04-2005 Part 1 — 76 —
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 and 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 maintenance performance
5) 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 operators 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
- 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
1) the actions taken following a system demand
2) equipment failures during routine testing or an actual demand
3) the cause of the demands
4) 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 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

— 77 — ISA-TR84.00.04-2005 Part 1
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 re-evaluated based on various factors including: – 16.3.1.5
a. historical test data
b. plant experience
c. hardware degradation
d. 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

ISA-TR84.00.04-2005 Part 1 — 78 —
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
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 which 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 lifecycle affected by modification – 17.2.3
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 insure 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

— 79 — ISA-TR84.00.04-2005 Part 1
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
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 which
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 lifecycle steps that need to re-taken.
The assessment also considers: – 18.2.3
a. functional safety during decommissioning activities
b. impact of decommissioning an SIS on adjacent operating units an facility services
4. Decommissioning activities do not begin without proper authorization. – 18.2.5

ISA-TR84.00.04-2005 Part 1 — 80 —
Clause 19 – Information and documentation requirements

Inputs: (none)
Outputs:
1. The necessary information is available and documented so that all phases of the safety lifecycle 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
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

— 81 — ISA-TR84.00.04-2005 Part 1
Annex D Verification, Validation and Functional Safety Assessments
NOTE — Annex D is referenced in Clause 4.5 and Annex E.5.
D.1 Purpose
In ISA-84.01-2004-1, verification, validation and functional safety assessment are three very distinct activities
that are carried out during the lifecycle of an SIS. It is important to understand the importance and
requirements of each of these activities.
D.2 Verification
As described in ISA-84.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 ISA-84.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 ISA-84.01-2004-1 Clause 11.9.
Some of the typical verification activities on a project include:
• 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 ISA-84.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 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.

ISA-TR84.00.04-2005 Part 1 — 82 —
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
ISA-84.01-2004-1 Clause 5.2.6 identifies five different potential stages of a project where an FSA may be
conducted. These stages are shown in Figure 8 in ISA-84.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. ISA-
84.01-2004-1 Clause 5.2.6.1.2 does require 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 Pre-Startup Safety Review (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.

— 83 — ISA-TR84.00.04-2005 Part 1
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 lifecycle 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 lifecycle phase and have the minimum effect in other areas.
If the assessment is carried out at a later stage in the lifecycle, 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 (see References, Annex R).
The following checklists are examples only. These checklists do not cover all of the detailed
requirements of ISA-84.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
ISA-84.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

ISA-TR84.00.04-2005 Part 1 — 84 —
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 ISA-84.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 assumed risk reduction for the BPCS
less than a risk reduction factor of 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 Has 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?
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 SIFs de-energize-to-trip?
(ii) Are the SIFs 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?

— 85 — ISA-TR84.00.04-2005 Part 1
Checklist No 2: Safety requirements specification

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 safety requirements specification
(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)
2.8 Are the SIFs 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 SIFs de-energize-to-trip?
(ii) Are the SIFs 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?

ISA-TR84.00.04-2005 Part 1 — 86 —

No
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?
2.19 (i) Has any special SIS logic solver requirements
been identified, such as sequencing, speed, and
accuracy?
(ii) Is it 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?
(iv) resetting the SIF after shutdown?
(v) 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:
(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?

— 87 — ISA-TR84.00.04-2005 Part 1

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 which

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?

ISA-TR84.00.04-2005 Part 1 — 88 —
Checklist No 3: Hardware specification and design

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?
(v) ensuring that aspects relevant to construction,
installation, operation, maintenance and
modification are considered?
(vi) 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?
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?

— 89 — ISA-TR84.00.04-2005 Part 1

No
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 been 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?
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 SIF device
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?

ISA-TR84.00.04-2005 Part 1 — 90 —

No
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?
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 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 communications interfaces been
defined with regard to communications 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 CCF?
3.19 Have the effects of CCF been considered in the
design?
3.20 Are design reviews carried out which include the
identification and elimination of CCF (e.g.,
components common to all systems and capable of
causing failure of the total configuration)?

— 91 — ISA-TR84.00.04-2005 Part 1

No
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, is there
available diagnostics that minimizes 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) different training, resources, tools, etc. are
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

No
4.1 Are there standards and procedures for the
development of the application software?
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?

ISA-TR84.00.04-2005 Part 1 — 92 —

No
4.5 Are design reviews carried out in the development
of the application software involving
owner/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?
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?

— 93 — ISA-TR84.00.04-2005 Part 1

No
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?
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?

ISA-TR84.00.04-2005 Part 1 — 94 —

No
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?
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?

— 95 — ISA-TR84.00.04-2005 Part 1

No
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

No
5.1 (i) Are there specifications and procedures for
quality of materials, workmanship, inspection and
testing?
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?
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? or
(ii) is SIS 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
cause 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?

ISA-TR84.00.04-2005 Part 1 — 96 —
Checklist No 5: Installation

No
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?
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 SISs 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?
Checklist No 6: SIF Validation

No
6.1 (i) Are there specifications and procedures for the
validation of each SIF?
conditions?
(iii) Is there supervision to ensure the application of
specifications and procedures during validation
test?

— 97 — ISA-TR84.00.04-2005 Part 1
Checklist No 6: SIF Validation

No
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 on-line 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

No
7.1 Are there standards and procedures for software
testing?
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
test?
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?

ISA-TR84.00.04-2005 Part 1 — 98 —
Checklist No 7: Application software validation

No
7.8 (i) Is the final test documentation checked to
ensure that all SRS requirements have been tested
and are 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?
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

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

— 99 — ISA-TR84.00.04-2005 Part 1
Checklist No 8: Operations

No
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?
8.6 Is there an acceptable user/operator manual for
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.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

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?

ISA-TR84.00.04-2005 Part 1 — 100 —
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?
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?

— 101 — ISA-TR84.00.04-2005 Part 1
Checklist No 10: Software maintenance and modifications

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?
(v) how changes are recorded and tracked?
(vi) documentation which should be updated?
10.3 Are there adequate procedures for the control of

software versions in use and the update of all
similar SISs?
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, or

(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?
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?

— 103 — ISA-TR84.00.04-2005 Part 1
Annex E Audits
NOTE — Annex E is referenced in Clause 4.5.
E.1 Purpose
Manufacturing plants should have procedures for conducting audits to ensure they are satisfying the
requirements for their Safety Instrumented Systems (SISs). ISA-84.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 to four or five
years.
E.3 Audit Participants

The individuals conducting the audit should be independent of the plant personnel where the audit is being
carried out. 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 why it is good to
have people from outside the plant to conduct these audits is that they are able provide an unbiased
observation of their findings. Besides, it is 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.

ISA-TR84.00.04-2005 Part 1 — 104 —
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 he or she wishes to interview. Once the location coordinator obtains this
list of interviewees, he or she 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 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 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. Annex D.4, Functional
Safety Assessment, in this technical report provides example checklists that could be addressed during the
audit. In addition, the Center for Chemical Process Safety book, “Revalidating Process Hazard Analyses,”
has examples of audit questions in Appendices B through G.
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. The auditors also should 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?

— 105 — ISA-TR84.00.04-2005 Part 1
• 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 answers to these questions.
E.9 Interviews
Auditors should go into the interviews with a set of questions to get 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 from 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 he or she thinks 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
the 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.
E.13 Examples of Audit Findings

The following is being shared to aid in understanding what can be found during audits and to illustrate the
value of conducting audits.

ISA-TR84.00.04-2005 Part 1 — 106 —
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.1 Operation and Accountability
• No clear ownership of the Safety Instrumented Systems--e.g., do they belong to engineering,

maintenance, operation, etc.
• 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 SISs 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 SISs 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 on-line 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.

— 107 — ISA-TR84.00.04-2005 Part 1
• 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.
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 are 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 SISs 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.

ISA-TR84.00.04-2005 Part 1 — 108 —
• The required “inspection” is not being conducted.
• 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

— 109 — ISA-TR84.00.04-2005 Part 1
Annex F BPCS and Its Relationship to the SIS
NOTE — Annex F is referenced in Clause 4.8, Clause 4.9, 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 ISA-84.01-2004-1;
NOTE 1 — ISA-84.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 ISA-84.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

ISA-84.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 ISA-84.01-2004-1.
F.2.1 BPCS as an Initiating Cause
ISA-84.01-2004-1 Clause 8 requires that an 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. ISA-
84.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 (ISA-84.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 to the SIS lifecycle. The use
of the lifecycle minimizes the potential systematic failures through the design, testing, validation, or
management processes of ISA-84.01-2004-1.

ISA-TR84.00.04-2005 Part 1 — 110 —
2) Industry-published data, as well as manufacturer data, have 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., distributed control systems,
PLCs).
NOTE — These data represent 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 ISA-84.01-2004-1 Clause 11.5.
F.2.2 BPCS as a Protection Layer
ISA-84.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 ISA-84.01-2004-1 The risk reduction must be assumed to be less than 10
(ISA-84.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, 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 ISA-84.01-2004-1 Clause 9, the risk
reduction claimed for the BPCS as a protection layer must be less than 10.
NOTE 3 — For more guidance on this topic, refer to ISA-84.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 Clause F.2.2.1 below 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 Clause F.2.2.2 below for more information);
• Functional separation of the BPCS protection layer from any SIS protection layers; and
NOTE — Physical separation is strongly recommended to avoid common mode failures
• The risk reduction assumed for the BPCS is less than 10 (ISA-84.01-2004-1 Clause 9.4.3).
NOTE — As long as a risk reduction of less than 10 is claimed for the BPCS as a protection layer, the BPCS does not need to
comply with ISA-84.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 factor 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 ISA-84.01-2004-1 has been conducted. This analysis is not trivial and
involves a detailed assessment of the overall system design, including 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

— 111 — ISA-TR84.00.04-2005 Part 1
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

ISA-TR84.00.04-2005 Part 1 — 112 —
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; and
• 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.
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; and
• 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 and effects
analysis. The design of the logic solver then incorporates external means to detect and respond to these
failures.

— 113 — ISA-TR84.00.04-2005 Part 1
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); and
NOTE — The diagnostics 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 ISA-84.01-2004-1 requirements prohibitive. Refer to Annexes L and M In this technical
report for more discussion concerning the analysis, selection, and design of SIS logic solvers (e.g., safety-
configured, general-purpose PLCs and safety PES). Annex G of this technical report 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
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 x 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 Annex I of this
technical report for a detailed explanation). As a result, the entire system should be treated as an SIS in
accordance with the requirements of ISA-84.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 ISA-84.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 PFD 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) x (PFDSIS SENSOR+ PFDSIS VALVE)

ISA-TR84.00.04-2005 Part 1 — 114 —
• 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,
which 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 ISA-84.01-2004-1.
Implementing control and SIFs in the same logic solver should consider the following:
• Assessment of the overall system, including the main processor, input and 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 management of change (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; and
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.

— 115 — ISA-TR84.00.04-2005 Part 1
Caution for Annex F.3 of this technical report:
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

ISA-84.01-2004-1 does not require physical separation. However, many owner/operators do use physical
separation and diverse logic solvers. It is paramount to remember the primary purpose of many SISs. 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 of 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.
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 Annex K below for information regarding fault tolerance, including a treatment of separation and
diversity.

ISA-TR84.00.04-2005 Part 1 — 116 —
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 ISA-84.01-2004-1, including proof testing,
access security and management of change.
• The sensor (e.g., transmitter, analyzer, 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 on-line testing requirements for the valve or other shared device should be possible without
impairing the operation of the BPCS control function.

— 117 — ISA-TR84.00.04-2005 Part 1
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., ISA-84.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 ISA-84.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 ISA-84.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.
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 the dangerous failure rate of the SIF logic
solver.
Hazard rateLOGIC SOLVER FAILS = λLOGIC SOLVER

ISA-TR84.00.04-2005 Part 1 — 118 —
• 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 x (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 x (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 x PFDSIF
Figure F-2 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 PFD of 0.001. For an SIF with a
1oo1 sensor and 1oo1 valve, the PFD 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 PFD was calculated to be 0.007.
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 ISA-84.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 PFD, 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 proximity to the furnace. In addition, the operator is often under intense scrutiny to get the plant back
on line quickly. This stress can lead to increased probability of human error.

— 119 — ISA-TR84.00.04-2005 Part 1
Equivalent PFD
0.1
0.01
0.001
0.0001
1oo1 independent 1oo2 shared 1oo2 independent
SIF Architecture
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 PFD, installation and maintenance considerations may off-
set any advantage of sharing BPCS and SIS components. For example, on-line 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.).

ISA-TR84.00.04-2005 Part 1 — 120 —
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 were chosen simply to illustrate the
calculation. These 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 are 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
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

— 121 — ISA-TR84.00.04-2005 Part 1
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.
-5
NOTE — ISA-84.01-2004-1 Clause 8 limits the assumed dangerous failure rate to not less than 10 /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 x 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 (PFD=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 PFD of 0.05, using
the failure rates of the individual components. However, this system is not designed and maintained in
accordance with ISA-84.01-2004-1. Therefore, the BPCS loop is assumed to have a PFD of 0.1.
NOTE 1 — ISA-84.01-2004-1 Clause 9 limits the assumed risk reduction to less than 10 (PFD>0.1). For ease of calculation, LOPA
often uses a PFD of 0.1.

ISA-TR84.00.04-2005 Part 1 — 122 —
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 PFD of 0.03,
using the failure rates of the individual components. This SIF was designed and maintained in accordance
with ISA-84.01-2004-1. Therefore, the SIF is assumed to have a PFD of 0.03.
This PFD 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 PFDs 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.
Table F-1 – LOPA Table for BPCS loop as a Protection Layer
Case Initiating PL2

Cause Enabling Event PL 1 Outcome
Loss of Excess Firing BPCS Loop TT-2 Closes Vessel Fails
1 Process TT-1, TIC-1 BV-2
Flow through Closes CV-1
tubes
0.1/yr 0.1 0.1 0.03 3E-05/yr
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 PFD of 0.03, using the failure rates of the
individual components. This SIF was designed and maintained in accordance with ISA-84.01-2004-1.
Therefore, the SIF is assumed to have a PFD of 0.03.
This PFD 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 PFDs of any protection layers:
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.

— 123 — ISA-TR84.00.04-2005 Part 1
Table F-2 – LOPA Table for BPCS loop as an Initiating Cause
Case Initiating Enabling

Cause Event PL 1 PL 2 Outcome
TT-1, TC-1, CV- Excess BPCS Loop TT-2 Closes Vessel Fails
1 Fail such that Firing TT-1, TIC-1 BV-2
2 CV-1 Fails Closes CV-1
Open
0.1/yr 0.1 1* 0.03 3E-04/yr
* Uses same components as the 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.

ISA-TR84.00.04-2005 Part 1 — 124 —
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
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 the correct hazard rate.
NOTE — For more information, please refer to the Center for Chemical Process Safety 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.

— 125 — ISA-TR84.00.04-2005 Part 1
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.”
Table F-3 – Example LOPA Table Including Summary of Fault Tree Analysis of the
BPCS and Revised SIF
Case Initiating Enabling

Cause Event PL 1 PL 2 Outcome
Control Excess Firing BPCS Loop TT-2 Closes Vessel Fails
transmitter TT- TT-1, TIC-1 CV-1, BV-2
1 fails Closes CV-1
0.02 0.1 1 (Annex 0.016 3.2E-05/yr
F.6)
2A BPCS TIC-1 Excess Firing BPCS Loop TT-2 Closes Vessel Fails
(revised fails TT-1, TIC-1 CV-1, BV-2
SIS) Closes CV-1
0.04 0.1 1 (Annex 0.016 6.4E-05
F.6.2)
Control valve Excess Firing BPCS Loop TT-2 Closes Vessel Fails
CV-1 fails TT-1, TIC-1 BV-2 only
Closes CV-1
0.04 0.1 1 (Annex 0.03 1.2E-04
F.6.2)
Overall Risk due to all scenarios 2.2E-04
Control loop Excess Firing BPCS Loop TT-2 Closes Vessel Fails
fails, TT-1, TIC- TT-1, TIC-1 CV-1, BV-2
Incorrect 1, CV-1 Closes CV-1
Way! 0.05 0.1 1 (Annex 0.016 8E-05
F.6.2)

— 127 — ISA-TR84.00.04-2005 Part 1
Annex G Failures - Types, Classifications, Sources and Strategy for Defense
NOTE — Annex G is referenced in Clause 4.9, 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 Hazard and Risk Analysis (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 failure 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 ISA-84.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 ISA-84.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 ISA-84.01-2004 safety lifecycle and
functional safety management concepts into the project management process.

ISA-TR84.00.04-2005 Part 1 — 128 —
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., 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. Owner/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 Programmable Electronic (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 & Systematic Failure

Table G-1 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 No Yes
conditions
Effectively prevented by redundancy Yes No
Effectively prevented by diversity in Yes Partially
redundancy

— 129 — ISA-TR84.00.04-2005 Part 1
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 on-line, 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 on-line diagnostics is 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).
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.
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.

ISA-TR84.00.04-2005 Part 1 — 130 —
Failure Modes
Fail Safe Fail Dangerous
Safe Detected Safe Undetected Dangerous Detected Dangerous Undetected

•Fail to start •Detected by test •Effects can lead •Detected by proof test
•Spurious Trip •Detected by t
dangerous condition •Detected by failure on
inspection demand
The probability of false trips is of The probability of failure on demand is a

concern also because shutdowns fraction of all system failures and is of
and startups can create dangerous primary concern. This is the probability
conditions in addition to causing used to define the SIL. The objective
business interruption. Fault tree of proof testing is to detect a
analysis can be used to determine how dangerous undetected failure before it is
to most effectively reduce false trips. detected by a demand .
Figure G-1 – Breakdown of Failure Classifications
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

— 131 — ISA-TR84.00.04-2005 Part 1
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
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 xMTTR
PFD D = PFD DU + PFD DD
TI
PFD SU = λ SU x
2

ISA-TR84.00.04-2005 Part 1 — 132 —
PFD SD = λSD xMTTR
PFD S = PFD SU + PFD SD
βλ = λCCF ∴ βλ D = λ D
CCF
These terms and equations can be substituted into the Venn diagram as shown in Figures G-3 and G-4.
Safe Undetected Safe Detected
PFDSU PFDSD
PFD
DU
PFD DD
Spurious Trips≤ PFD + PFD

SD DD
PFD D = PFD DD + PFD DU
Figure G-3 – Venn Diagram Showing the Probability of Failure on Demand for
Each Failure Classification

— 133 — ISA-TR84.00.04-2005 Part 1
Safe Undetected Increasing Safe Detected

Coverage
PFD = λ
TI
λ × MTTR
SD SD
= ×
SU SU
PFD 2
PFD = λ
TI
×
PFD = λ
DU DU
× MTTR
DD DD
2 Increasing
Coverage
[
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
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 PFD for
dangerous, detected (DD) failures is:
PFD
DD
[
= DC × λ × MTTR
D
]
The PFD for dangerous undetected (DU) failures is:
PFD
DU
[
= (1 − DC )× λ ×
D
] TI
2
.
The probability of failure on demand is:
= + PFD
D DU DD
PFD PFD

ISA-TR84.00.04-2005 Part 1 — 134 —
Assuming that TI >> MTTR, the PFD 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 shut down, 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 2004 (see
References, Annex R), 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 been 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 failures
to properly manage technical issues are the root cause of many failures. These failures can only be
addressed through implementation of the ISA-84.01-2004 lifecycle process and its associated verification
and validation steps.
Changes after
Commissioning
20%
Specifications
44%
Operations and
Maintenance
15%
Installation and
Design and
Commissioning
Implementation
6%
15%
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

— 135 — ISA-TR84.00.04-2005 Part 1
• 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
• 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 Management of Change (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 ISA-84.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 specifications.
G.7 Common Cause Failure

The terms “common cause” and “common mode” have been used interchangeably in published literature
causing confusion. ISA-84.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).

ISA-TR84.00.04-2005 Part 1 — 136 —
• Software design errors (systematic).
• Human-machine interface design (systematic).
• Environmental--e.g., temperature extremes, humidity, corrosion, EMC, vibration, 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 mis-operation--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 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
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 ISA-84.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 ISA-84.01-2004 function safety management concepts.
The common cause failure rate for dangerous undetected is expressed as:
β ×λ DU =λ DU
CCF
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 ISA-84.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

— 137 — ISA-TR84.00.04-2005 Part 1
3) the availability.
The principles governing these three fundamentals 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.
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.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.
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 reduces the risk of random failures, as well as systematic failures.

ISA-TR84.00.04-2005 Part 1 — 138 —
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 Annex L in this
technical report for more information on prior use).
ISA-84.01-2004-1 Clauses 16.2.2 and 16.3.3 identify the data to be maintained on the SIS/SIF by
Operations and Maintenance, respectively. The IPRDS provides data to determine process demand
frequencies and devices failures, as described in ISA-84.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. ISA-84.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 mean time to repair (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, W hichever 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.

— 139 — ISA-TR84.00.04-2005 Part 1
Minimize In Plant Reliability

In Plant Reliability
DataData
System
System
λD =λ
λDUD + λ=DD,λ DU
λ DD ,rate
+ failure
dangerous dangerous failure rate
EquipmentSelected
Equipment Selected
λDD = DC×λD,dangerousdetected failure rate
withMinimum
with Minimum λ DD
= DC × λ , dangerous
D
detected failure rate
Total Failure
FailureRates
Ratesand
and λDU = (1− DC) ×λD ,dangerousundetectedfailure rate
Total
UndetectedFailure
Undetected FailureRates
Rates λ DU
= (1 − DC ) × λ , dangerous
D
undetected failure rate
DC = Diagnostic Coverage of checklists and diagnostics
C = Coverage of checklists and diagnostics
Maximize
DevelopChecklists
Develop Checklists
and Diagnostics
and Diagnosticstoto λ D = (1 − DC )× λ D + DC × λ D
MaximizePercentage
Maximize Percentage
of Detected
of DetectedFailures
Failures λ D = (1 − DC )× λ + DC × λ D
Minimize
DevelopProcedures
Develop Procedures
to Minimize
to MinimizeMTTR
MTTR
PFD= λ= λ× MTTR
× MTTR
DD DD DD DD
DetectedFailures
Detected Failures PFD
Develop
Develop andProof TestProof
Capture Procedures and define Test Intervals
Tests Substitutes
DevelopProcedures
Develop Procedures
MinimizeProof
to Minimize ProofTests
Tests
PFD= λ= λ×
TI TI
×
DU DU DU DU
by Capturing
by CapturingData
Datafrom
from PFD 2 2
Shutdowns,Startups,
Shutdowns, Startups,
andDemands
and Demands
Performance Achieved with Minimum Time To Repair, Maximum Coverage
Performance Achieved with Mean Time To Repair (MTTR), Diagnostic
Coverage (DC), and Proof
and Minimum Test
Proof Interval
Tests
DetermineProof
Determine Proof
) ×2 λ⎥⎦ +D [TI
TI ⎤
TestInterval
Intervalfor
for PFD = D(1 =− DC
1 − )DC
× λD ( +× λDC× × λ D ×] MTTR
D D
Test PFD DC MTTR
UndetectedFailures
Undetected Failures 2
to Achieve
to AchievePFD
PFDTarget
Target
= PFD+ PFD
PFD= PFD + PFD
D D DU DU DD DD
PFD
Figure G-8 – Activities and Procedures Contribution to Availability Defenses

Against Random Failures.

— 141 — ISA-TR84.00.04-2005 Part 1
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, safety instrumented systems (SIS), and safety instrumented functions (SIF).
Since many of these terms have historical references, the terminology is discussed in relation to ISA-
84.01-1996 and IEC 61508. This facilitates understanding of how these terms evolved into the current
definitions of ISA-84.01-2004-1.
H.2 Interlock
H.2.1 Definitions
(1) To join or be joined firmly as by a mutual interconnection of parts (Collins Concise English
Dictionary – Annex R).
(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 -- Annex R).
(3) Initiates or prevents a predefined action in response to a predetermined condition. (Guidelines for
Safe Automation of Chemical Processes – Annex R [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 – Annex R [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 ISA-84.01-1996 was rejected by the ISA-SP84 committee.
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 ISA-84.01-1996. Today, the term "interlock" is not
used in either IEC 61508 or ISA-84.01-2004-1.
H.2.3 ISA-84.01-1996 Analysis
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).

ISA-TR84.00.04-2005 Part 1 — 142 —
The issuance of 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 ISA-84.01-2004-1 Difference
ISA-84.01-2004-1 utilizes "safety instrumented function" (clause 5.0) in lieu of "safety interlock."
NOTE — ISA-84.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 (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.
Examples of the use of "permissives" can be found in clauses 3.1.58.1, 5.3.5, 9.4c, and B10.1.3c.
Use of the term "permissives" in ISA-84.01-2004-1 (Clauses 3.2.81.2.1 and 10.3.1-11th bullet) is identical
to that in 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 (ISA-84.01-1996 Clauses 9.7 & B 9.3.3).
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."
Example applications of the term "inhibit" used as a verb can be found in Clauses 9.7 and B 9.3.2.

— 143 — ISA-TR84.00.04-2005 Part 1
"Inhibit" has the same meaning in ISA-84.01-2004-1 as it has in ISA-84.01-1996. Example application of
"inhibit" can be found in ISA-84.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 (ISA-84.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 ISA-84.01-1996 with
IEC 61511 (or IEC 61508). It can be seen from the above definitions that ISA-84.01-2004 and IEC 61508
definitions are essentially identical. However, 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 ISA-84.01-1996 to ISA-84.01-2004.
"Safety function" is used throughout ISA-84.01-1996. The following limited sampling of clauses references
illustrates the use "safety function" throughout ISA-84.01-1996, such as Clauses 5.2.1, 5.4.1, 6.2.1, and
6.2.2.
The committee developing ISA-84.01-2004 was faced with two different definitions of "safety function"
(i.e., one definition in ISA-84.01-1996 and another in IEC 61508). The definition of "safety function" used
in IEC 61508 was adopted for ISA-84.01-2004-1. This facilitated global compatibility and recognition for
this term.
"Safety function" is primarily used in ISA-84.01-2004-1 to address the identification of safeguards that
meet the specific design, risk reduction and management requirements (ISA-84.01-2004-1 Clauses 8 and
9). To address the ISA-84.01-1996 "safety function" definition, ISA-84.01-2004-1 added the term "safety
instrumented function.”
NOTE — The IEC 61511 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 ISA-84.01-
2004 addresses.
H.6 Safety Instrumented Function (SIF)

H.6.1 Definition
Safety function with a specified safety integrity level which is necessary to achieve functional safety (ISA-
84.01-2004-1 Clause 3.2.71).
H.6.2 Overview

ISA-TR84.00.04-2005 Part 1 — 144 —
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 safety integrity level (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 Annex B of this
technical report)
ISA-84.01-1996 does not use the term "safety instrumented function.”
ISA-84.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.

— 145 — ISA-TR84.00.04-2005 Part 1
H.7 Safety Instrumented System (SIS)

H.7.1 Definition
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) (ISA-84.01-2004-1 Clause 3.2.72 -
portion of definition only).
H.7.2 Overview
No further guidance
SIS is used in ISA-84.01-1996.
NOTE — 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.
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.

— 147 — ISA-TR84.00.04-2005 Part 1
Annex I Continuous Mode versus Demand Mode
NOTE — Annex I is referenced in Clause 4.9 and Annex P.1.
I.1 Purpose
ISA-84.01-2004-1 Clause 9 requires that the owner/operator defines whether the SIF is operating in a
demand mode or high demand/continuous mode of operation. This annex provides guidance on how to
evaluate the mode of operation.
I.2 Introduction
In the process industries, the majority of demands on the SIF occur fairly infrequently (i.e. less than once
per year). Due to their prevalence, many published papers and technical reports discuss the
implementation of demand-mode SIFs only. This has led to the impression that continuous mode SIFs do
not exist in the process industry.
As the demand rate increases, there is a transition from low demand to high demand mode operation. As
a rule of thumb, ISA-84.01-2004 recommends that any SIF that is required to operate more than once a
year due to a process demand be treated as a high demand mode SIF. When the SIF operates in high
demand mode, the requirements for continuous mode SIFs may apply, including the requirements in ISA-
84.01-2004-1 Clauses 9, 11.3 and 11.9. Further, in high demand mode, the Safety Integrity Level (SIL)
should be verified by determining its probability of failure rather than its Probability to Fail on Demand
(PFD).
At the opposite extreme of low demand mode, continuous mode SIFs act continuously to prevent the
hazard. In continuous mode, the dangerous failure of the SIF results in an immediate hazard, unless
other actions (i.e., other protection layers function) are taken to prevent it. The PFD calculation generally
applied to verify the SIL is not applicable to continuous mode SIFs. Its performance is verified by
determining its probability of failure (i.e., the hazard rate). Thus, the assessment and design is more
complicated for continuous mode SIFs than it is for low demand mode SIFs.
The difficulty is defining when the transition between low demand and high demand occurs. Over the
years, many rules of thumb have been proposed to assist in this determination. The “more frequent than
once per year” guidance is intended to focus attention on those SIFs that may require additional analysis.
Another rule of thumb from IEC 61508 compares the demand interval to the proof test interval. If the
demand interval is greater than one-half the test interval, the SIF should be considered high demand
mode (e.g., if the demand interval is 1 in 10 years, a test interval longer than 1 in 5 years would suggest
high demand mode).
The important point to understand is that the low demand mode PFD math assumes that diagnostics and
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. 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 PFD math.
Fortunately, a more rigorous mathematical model can be used to determine when it is more appropriate
to consider an SIF as operating in high demand/continuous mode.
The ISA-SP84 committee 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. To better understand the complexity of
this issue, it is useful to consider examples of high demand and continuous mode SIFs.

ISA-TR84.00.04-2005 Part 1 — 148 —
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 could cause a runaway
reaction. The reaction kinetics are such that there is insufficient time 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. If the hazard
under consideration is release of the vessel contents to the atmosphere, the temperature control
loop is the primary protection, and it operates in a continuous mode.
• Tank overfill protection - A storage tank receives hazardous material continuously from several
plants. Detection of high level results in a pump being energized to automatically pump the
hazardous material to the waste sewer. The pump is shut off when a low tank level is reached.
There is no other protection layer to keep the tank from overfilling. The level control is considered
an SIF, consisting of a level switch acting on the discharge pump, and would be considered a
continuous mode of operation.
• 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.
I.4 High Demand Mode Examples
• Batch reactor initial charge cutoff (based upon total mass flow, level or weight) with a runaway
reaction potential if there is an 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).
• 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 on-line
analyzer for the by-product stopping the recycle stream when high concentration is detected
provides the only protection against this hazard and was defined as 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.
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.
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.

— 149 — ISA-TR84.00.04-2005 Part 1
I.5 Low Demand Example
• Low steam drum level safety instrumented function – 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.
I.6 Application Guidance

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 PFD 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. It is
important to recognize those cases where high demand actually exists.
ISA-84.01-2004-1 Clause 9.2.3 provides two tables for defining the SIL requirements. Table 3 provides
the SIL requirements in terms of Probability of Failure on Demand (PFD). 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. ISA-84.01-2004-1 Clause 9.2.3 states that when Table 4 is
used, neither the proof test interval nor the demand rate are used in the determination of the safety
integrity level. This means that the Table 4 requirements should not be converted into PFD 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 (ISA-84.01-
2004-1 Clause 9.2.3).
For example, for an SIL 1 continuous mode SIF, the lower bounds for the probability of failure is 10-5
failures per hour. This should not be converted into a PFD requirement by multiplying it by the expected
proof test interval (e.g., if the testing interval is 5 years, 10-5/hour x 5 years x 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 x 10
demands/year x 8760 hours/year = 0.876). While the units may cancel out yielding a unitless number, the
math is incorrect and the “PFD” 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 a simplistic 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.
As an example, the hazard rate for a low demand case can always be approximated by the equation:
Hazard Rate (HR) = Demand Rate (D) x Probability of Failure on Demand (PFDAVG)
HR = D x PFDavg (1)
And PFDAVG for a single channel system (1oo1) is given by the equation:
λDU TI
PFD avg = (2)
2

ISA-TR84.00.04-2005 Part 1 — 150 —
Where λDU is the dangerous undetected failure rate and TI is the proof test interval.
For high demand cases, the equation requires more scrutiny. For example, assume that a batch controller
has a demand interval of 14 hours and the frequency of failure for the reactor charging controls is:
λ = 0.1 per year, considered to have an SIL 1 rating with a proof test interval of one year.
Table I-1 – Hazard Rate Calculation Examples

Assumptions:
SIF Failure Rate = 0.1/year

SIF Failure Rate follows an exponential distribution:
λ = Failure Rate
D = Demand Rate
TI = Test Interval
Equations:
λTI
Simplified Equation: HR = D × PFDavg = D ×
2
= λ ⎛⎜1 − e 2 ⎞⎟
− DTI
Rigorous Equation for a 1 out of 1 protection system: HR
⎝ ⎠
Equation Reference: “Probabilistic Risk Assessment and Management for Engineers and Scientists,” 2nd
ed. Hiromitsu Kumamoto and Ernest J. Henley, IEEE Press, New York, NY, 1996.
Demand Rate Proof Test Interval Hazard Rate Hazard Rate
( per year) (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

— 151 — ISA-TR84.00.04-2005 Part 1
Demand Rate Proof Test Interval Hazard Rate Hazard Rate
( per year) (year) Simplified Equation Rigorous Equation
(per year) (per year)
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
Using the simplified equation (eq. 2), we would have the following result:
PFDavg = (0.1 x ½) = 0.05 and
HR = 600 x 0.05
HR = 30/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
demand interval should be greater than the test interval. In this case, the demand interval is 14 hours and
the test interval is 1 year, the opposite of what it should be. Dangerous failures are much more likely to 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.
Figure I-1 shows a plot of frequency of consequence (hazard rate) versus demands per year. For the
region with less than one demand per year, the slanted lines represent the bounds of the safety integrity
levels as documented in ISA-84.01-2004-1 Table 3. For example, with a demand rate of 0.1 per year, an
SIL 2 SIF would generate a hazard rate of 1E- 4 per year. For the region with a demand rate of more than
once per year, the horizontal lines represent the bounds of the safety integrity levels as documented in
ISA-84.01-2004-1 Table 4.

ISA-TR84.00.04-2005 Part 1 — 152 —
High/Low Demand
Low Demand High Demand
1.00E-01
SIL 0 SIL 1
1.00E-02
Frequency of Consequence, /yr
SIL 4
SIL 2 SIL 3
1.00E-03 SIL 2
SIL 1
SIL 3
1.00E-04 SIL 0
SIL 4
1.00E-05
1.00E-06
1.00E-07
1.00E- 1.00E- 1.00E- 1.00E- 1.00E- 1.00E+ 1.00E+ 1.00E+ 1.00E+
05 04 03 02 01 00 01 02 03
Demands per year
Figure I-1
Figure I-2 shows a plot of the three equations for estimating hazard rate from Table I-1, for an SIF with a
failure rate ( λ ) of 2.01 E-2 /yr and a test interval (TI) of once per year. As Table I-1 illustrates, the low
demand equation is applicable up to two demands per year (that is, two demands per test interval). The
high demand equation, in which the hazard rate is the SIF failure rate, is applicable above 2
demands/year. The more rigorous exponential equation for hazard rate approaches the other two
equations at very high or very low demands per year.

— 153 — ISA-TR84.00.04-2005 Part 1
High/Low Demand
Low Demand High Demand
1.00E-01
1.00E-02
SIF, Low Demand,
1.00E-03 Demand/yr * IPL PFD
SIF, High Demand,
1.00E-04 IPL Failure Rate, /yr
SIF, More Rigorous
1.00E-05
1.00E-06
0.0001 0.01 1 100
Dem ands per year
Figure I-2
Figure I-3 combines Figures I-1 and I-2, showing the hazard rate for the hypothetical SIF plotted on the
boundaries for the safety integrity levels. At low demand, the SIF is on the boundary between SIL 1 and
SIL 2. For high demand, the same architecture SIF with the same test interval now becomes an SIL 1
system. This is an artifact of the way that the safety integrity levels are defined in the standard. The
10,000 hr/yr is the result of rounding up from 8760 hrs/yr to create the "order of magnitude" ranges
depicted in Table 4. This definition yields the origin of the continuous mode being defined as more than
one demand per year.
The owner/operator is cautioned to use the appropriate equation for low demand or high demand and to
take the appropriate lifecycle steps to achieve the desired risk reduction for the process. It would seem
reasonable to apply the lifecycle requirements of the higher SIL for SIFs that may change during their
lifecycle from the high demand to the low demand region or vice versa.

ISA-TR84.00.04-2005 Part 1 — 154 —
High/Low Demand
Low Demand High Demand SIF, Low Demand,
1.00E-01 Demand/yr * IPL PFD
S IL 1
SIL 0
SIF, High Demand,
1.00E-02 IPL Failure Rate, /yr

S IL 2 SIF, More Rigorous
1.00E-03
S IL 3 SIL 4
1.00E-04
SIL 3
S IL 4
1.00E-05
SIL 2
1.00E-06
SIL 1
1.00E-07
0.00001 0.001 0.1 10 1000 SIL 0
Dem ands per year
Figure I-3
I.7 Consideration of Diagnostics in High / Continuous Demand

According to the IEC 61508 rule of thumb, if the demand frequency is more than twice the periodic proof
test frequency, the application should be considered 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 process safety
time (the time period between initiation of a demand and the hazard).
It is also important to note that, when a fault tolerant architecture is allowed to degrade to a lesser
architecture rather than automatically tripping the process, repair in a timely fashion is essential to
maintain the SIL rating 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 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 fix and return the equipment
back into service.
It should be noted that a mean time to repair is documented in the Manufacturer’s Safety Manual and the
achievement of this mean to time to repair may be a critical parameter in the SIL Claim Limit for the
device. The Safety Manual assumption should be compared to what is physically possible for the actual
process unit given its staffing and resources. The chosen mean time to repair should be included in the
mechanical integrity program, supported by procedures which detail the maximum time for restoration and
the expected operator and maintenance actions to maintain safe operation during repair.

— 155 — ISA-TR84.00.04-2005 Part 1
Annex J SIL 4 versus Inherently Safer Design
NOTE — Annex J is referenced in Clause 4.9.
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

The ISA-SP84 committee strongly advises against the implementation of a single-layer SIL 4 SIS
because of the difficulty of achieving the required PFD (probability of failure on demand) due to the
impact of common mode / common cause failures (see Annex G of this technical report). Therefore, it is
prudent to do a careful re-evaluation of the allocation of safety functions to protection layers for scenarios
that may seem to require SIL 4. The checklist in Table J-1 is suggested as a starting point.
Table J-1 – Checklist for evaluating feasibility of SIL 4 SIS
Topic Question Comment
1 Consequence and its severity Is the consequence and its severity If the consequence is less severe,
for this scenario correctly understood? then an SIF with a higher PFD may be
sufficient to meet the design
requirements (for example, SIL 1, 2,
or 3 instead of SIL 4).
2 Inherently safer principles Can the consequence severity be See discussion in J.3
reduced by applying inherently safer
principles?
3 Initiating event frequency Is the estimate for the initiating event If the initiating event frequency is
frequency correct? lower, then an SIF with a higher PFD
may be sufficient to meet the design
Can the initiating event frequency be requirements (for example, SIL 1, 2,
reduced by redesign of the process?
or 3 instead of SIL 4).
4 Other protection layers Have other protection layers been If risk reduction can be allocated to
overlooked? Do other protection other protection layers, then an SIF
layers provide more risk reduction with a higher PFD may be sufficient to
than estimated? meet the design requirements (for
example, SIL 1, 2, or 3 instead of SIL
4).
The experience of the ISA-SP84 committee strongly suggests that SIL 4 SIFs are rarely required. In
instances where it appears that an SIL 4 SIF is required, a re-evaluation of the allocation of safety
functions to protection layers frequently indicates a lower SIL SIF as appropriate. If an SIL 4 SIF is still
required, it is imperative to apply inherently safer principles to redesign the process to reduce the risk. If
an SIL 1, 2, or 3 SIF is required then it may still be valuable to reduce the risk by applying inherently safer
principles.
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 Bollinger et al, Inherently Safer Chemical Processes, A Lifecycle Approach, Center

ISA-TR84.00.04-2005 Part 1 — 156 —
for Chemical Process Safety of the American Institute of Chemical Engineers, New York: 1996 (see
References, Annex R). 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 integrity level 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.

— 157 — ISA-TR84.00.04-2005 Part 1
Annex K Fault Tolerance Topics
NOTE — Annex K is referenced in Clause 4.11, Annex F.4, Annex G.8, 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 ISA-84.01-2004-1 to determine
the adequacy of the SIF design is that owner/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-2002 provides
more information on device failure rates, including a sampling of data from five owner/operators.
ISA-84.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 ISA-84.01-2004-1 Clause 11.3
are met. Refer to Clause K.4 in this technical report 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 diagnostics 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 ISA-84.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 Annex B in this technical report 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 ISA-84.01-2004-1 Clause 3.2.4. A channel refers to a subsystem of an SIS. ISA-84.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 fourth bullet of ISA-84.01-2004-1 Clause 15.2.4.
The minimum fault tolerance requirements are documented in ISA-84.01-2004-1 Clause 11.4. Clause
11.4.2 Table 5 provides the required fault tolerance for programmable electronic (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 safety instrumented function
(SIF) and the safe failure fraction (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

ISA-TR84.00.04-2005 Part 1 — 158 —
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 ISA-84.01-2004-1
Clause 11.4 being more conservative than those in IEC 61508 for some Type A devices. As a 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.
ISA-84.01-2004 also recognizes that there are a small number of sensors, final control elements, and
non-PE logic solvers that have an SFF greater than 90% in the field application. Therefore, ISA-84.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 ISA-84.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
ISA-84.01-2004-1.
For field devices, extreme caution should be used in reducing the minimum fault tolerance from ISA-
84.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.
Owner/operators should be cautious when using manufacturers’ 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

— 159 — ISA-TR84.00.04-2005 Part 1
redundancy, and administrative diversity. Refer to Annex G in this technical report 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 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.

ISA-TR84.00.04-2005 Part 1 — 160 —
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 RTD, 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 on-line 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 ISA-84.01-2004-1 Clause 11.4.4 is increased by one, unless the dangerous
faults can be detected on-line 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 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 millions dollars and potential safety concerns that always accompany a
shutdown and resulting restart up. Consequently, it is important when designing a DTT system that power
supply redundancy and battery back-up is provided to minimize the probability of spurious trips. In
addition to implementation of reliable power supply systems, proper maintenance of the power supply
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.

— 161 — ISA-TR84.00.04-2005 Part 1
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-Vd feeds, one plant power and the other UPS with
battery back up. 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 back up. 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 output are either relays (motor controls) or solenoid operated valves
(SOV). In DTT SISs, 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 back up 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 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.

ISA-TR84.00.04-2005 Part 1 — 162 —
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 back-up 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 be 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 though
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.
• 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 PFD for the SIS.
For ETT systems the power is a direct contributor to the PFD and should be considered in the
PFD calculations.
Obviously, whether the SIF is energized or de-energized to trip, an awareness of each scheme’s unique
attributes and limitations is needed to select a design most appropriate for the SIS.

— 163 — ISA-TR84.00.04-2005 Part 1
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 back up 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 by the same person all the time, and the like.
K.4 Safe Failure Fraction

The fault tolerance requirement for programmable electronic (PE) logic solvers is based on the SIL and
the safe failure fraction (SFF). ISA-84.01-2004-1 uses the following definitions:
Safe Failure – Failure which 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.

ISA-TR84.00.04-2005 Part 1 — 164 —
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 is the dangerous detected failure, DCD 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. If a variable “%Safe” is defined as:
λS
% Safe =
λS + λD
then the SFF can be expressed as:
SFF = % Safe + (1 − % Safe ) * DC D

— 165 — ISA-TR84.00.04-2005 Part 1
Annex L Device Selection
L.1 Purpose
ISA-84.01-2004-1 defines the requirements for users of safety instrumented system (SIS) devices. It does
not define the requirements for manufacturers and suppliers of SIF devices (e.g., sensors, logic solvers
and final elements). ISA-84.01-2004-1 states that the standard applies under the following conditions:
(1b) “applies when equipment that meets the requirements of IEC 61508, or of 11.5 of ISA-84.01-2004-1,
is integrated into an overall system that is to be used for a process sector application but 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)”
(1d) “applies when application software is developed for systems having limited variability or fixed
programs but does not apply to manufacturers, safety instrumented systems designers, integrators and
users that develop embedded software (system software) or use full variability languages (see IEC
61508-3).”
ISA-84.01-2004-1 references IEC 61508 Parts 2 and 3 for the requirements for manufacturers making
claims regarding the use of their device to implement an SIF.
ISA-84.01-2004 Part 1, Clause 11.5, addresses the requirements for SIF device selection. The standard
allows two forms of evidence to be used in the selection of SIF devices:
1) Designed in accordance with IEC 61508 Parts 2 and 3
2) “Prior use” information developed in accordance with ISA-84.01-2004 Clauses 11.4 and 11.5.3
through 11.5.6
The purpose of this annex is to provide guidance on:
• The work process used to select devices;
• The relationship between the two forms of evidence noted above;
• The impact of software language on the device selection process;
• How to gather and evaluate prior use information; and
• Additional SIL Claim Limit considerations.

ISA-TR84.00.04-2005 Part 1 — 166 —
L.2 Terminology
The terminology utilized in this annex is taken from existing functional safety standards (e.g., IEC 61508,
ANSI/ISA-84.01 - 1996, ISA-84.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. It generally includes one or more
owner/operator test sites, as determined by the manufacturer. The manufacturer establishes the
scope and duration of each test and the required test documentation. If problems occur during
Alpha test(s), the equipment or installation is modified, followed by additional Alpha testing, as
necessary.
• “Beta tests” are conducted after successful completion of Alpha tests. Generally, multiple test
sites are established. The manufacturer selects owner/operators with an inherent interest and
need for the equipment under test. The feedback from these owner/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 productization). This includes product specifications, installation and operation manual,
installation details, etc.
• “IEC 61508 certification” is an analysis of a device by a nationally recognized testing laboratory

(NRTL) based on IEC 61508 Parts 2 and 3 requirements. An NRTL is approved and recognized
by US-OSHA as having the capability to assess devices for compliance with a variety of
standards, including area classification, intrinsically safe, etc. It is recommended that the
certification report be used in conjunction with operating experience to select SIF devices.
• “IEC 61508 compliant” refers to evaluation of the device based on analysis and/or testing
available from assessors other than nationally recognized testing laboratories (non-NRTL).
Typical sources of approval information are manufacturers, consultants, and operating
experience. The analysis may include FMEAs, circuit analysis, unsafe failure mode analysis,
definition of device as Type A or B, identification and understanding of embedded diagnostic
feature(s), and requirements for external diagnostics. It is recommended that IEC 61508
compliant information be used in conjunction with operating experience to select SIF devices.
• “Prior use” refers to the selection of a device based on gathering information in accordance with
the requirements defined in ISA-84.01-2004-1 Clauses 11.4 and 11.5.3 through 11.5.6.
NOTE — ISA-84.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 ISA-84.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 and its probability of failure on demand (PFD) or
frequency of failure. The safety manual places restrictions on the use of the device, which include
details related to its configuration, interfaces, installation, diagnostics, mean time to repair, fault
response, and 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

— 167 — ISA-TR84.00.04-2005 Part 1
justify the deviation. This analysis and justification is not trivial and requires expertise in IEC
61508 compliance and in the quantitative analysis of devices.
NOTE 1 — A device does not have an SIL, since SIL is a quantitative measure of the performance of the overall SIF.
When a device is advertised as “an SIL 3 device,” it may mean many different things depending on the intent of the
advertisement. It may mean that the device has been assessed for compliance with the requirements of IEC 61508 Parts
2 and 3 by an NRTL (i.e., IEC 61508 certified) or by a third party. It may mean that they have determined a frequency of
failure or probability of failure on demand. Always ask manufacturers what they mean when they use the term “SIL 3
device.”
NOTE 2 — When using “SIL Claim Limit” to infer a device PFD (i.e., no data is available) it is recommended to use the
conservative value of the SIL range for the device PFD. For example, for a “SIL 3 Claim Limit” device, the PFD falls within
-3 -4 -3
a range of 10 through 10 . The conservative value (10 ) should be used if more precise data are unavailable. Today,
many device manufacturers provide the PFD values for their products, when implemented in accordance with the safety
manual. Whatever number is chosen for the PFD, it is important that it represent the failure of the device in the operating
environment.
L.3 Device Selection Process

Device selection involves a screening process to ensure that the selected devices meet the safety
requirements. This process includes identification of the intended SIL application, the type of device
required to execute the safety function, and, when applicable, the type of programming language. The
screening process is illustrated in Figure L-1.
ISA-84.01-2004-1 has more rigorous requirements for PE logic solvers than for non-PE logic solvers and
field devices (e.g., sensors and final elements). PE logic solvers are complex and have many more
potential failure modes in their hardware and software systems. The PE logic solver requirements change
based on the programming language used for the application software. Increased rigor in the
requirements is applied as necessary to reduce the potential for systematic failures.
Device selection is limited to the following SIL claim limit (or capability limit) applications:
• Less than SIL 4 (i.e., ISA-84.01-2004-1 does not apply to SIL 4 applications. An SIL 4 SIF is
designed and managed in compliance with IEC 61508).
• SIL 3 or less for non-PE logic solvers, PE devices based on fixed program languages, and non-
PE sensors and final elements.
• Less than SIL 3 for PE logic solvers using limited variability languages (LVL).

ISA-TR84.00.04-2005 Part 1 — 168 —
Figure L-1 – Work Process for Selecting Devices

— 169 — ISA-TR84.00.04-2005 Part 1
L.4 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-specific standards and provides the essential requirements necessary
to achieve functional safety.
IEC 61511 is the process industry sector standard developed according to the IEC 61508 framework.
ISA-84.01-2004-1 is the United States implementation of IEC 61511-1. To understand the relationship of
IEC 61508 to ISA-84.01-2004-1 review ISA-84.01-2004-1 Figures 2 and 3.
IEC 61508 addresses safety-related systems, including devices used to implement SIFs. IEC 61508 Part
2 provides hardware requirements, while Part 3 provides software requirements. 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.
Manufacturers can label their products with a specific SIL claim limit (or SIL capability limit), when these
devices are evaluated for compliance to IEC 61508 by a nationally recognized testing laboratory (NRTL),
such as those listed on the US OSHA website (www.osha.gov).
L.4.1 Benefits of IEC 61508 Certified Devices
ISA-84.01-2004-1 recognizes that there are potential advantages in selecting an SIF device that has been
certified by an NRTL as designed in compliance with the requirements of IEC 61508. Using such devices
assures the owner/operator of the following:
• The assessment was done in a manner to satisfy regulatory agencies, such as US-OSHA;
• The hardware and embedded software meet the requirements documented in IEC 65108 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
systems for hardware and software
• The NRTL audits the manufacturer to verify that the product continues to be manufactured as
certified and that all changes/revisions are properly managed and evaluated; and
• The manufacturer has a management of change process.
Evaluation against IEC 61508 ensures that the device has been assessed for random hardware failures
using a failure modes and effects analysis (FMEA). The results of this analysis are documented in a
report and/or safety manual which details:
• the safe and dangerous failure modes of the device,
• specific response of the device in the detection of a fault, and
• any specific requirements such as those necessary to properly detect and respond to a fault
condition.

ISA-TR84.00.04-2005 Part 1 — 170 —
The FMEA is also used to calculate the Safe Failure Fraction (SFF) of the device and the Probability of
Failure on Demand (PFD) (or frequency of failure for continuous mode devices) based upon a specific
proof test interval and mean time to repair. This information provides a major benefit to owner/operators,
especially for programmable electronic (PE) logic solvers, where the failure modes and effects analysis
can be very complicated. It is important understand that the FMEA results include random hardware
failures only and do not include systematic errors. The device manufacturer should address systematic
errors by following IEC 61508 Parts 2 and 3, and the user should address implementation mistakes using
the ISA-84.01-2004 lifecycle.
L.4.2 Limitations of IEC 61508 Certified Devices
Owner/operators should be aware that an IEC 61508 SIL claim limit is typically not based on extensive
field operating experience. In addition, the failure modes and effects analysis often does not include
potential dangerous failure modes of the process interfaces, installation, power supplies, or
communication interfaces. These analyses may not include the full device boundary and are sometimes
restricted to the E/E/PE portion of the device. 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.
Consequently, IEC 61508 compliance is only one type of evidence for proper device selection. For field
devices, a significant question is, “will it work in the proposed process application?” This question can
only be answered by assessing the field installation and operating environment into account in the failure
modes and effects analysis. This assessment should typically include everything necessary to make the
device functional, including the process interface, installation, power supply, and communication
interface. Field application history ensures that the device performance in the operating environment is
understood, yielding proper specification of the fault tolerance and proof test intervals.
Evaluation of the device’s compliance with IEC 61508 requires numerous assumptions, including:
• the failure rate of the individual components that comprise the device;
• the degree of diagnostic coverage provided by the hardware and software;
• the degree to which the safety manual is followed by the owner/operator;
• the quality of proof testing;
• the proof test interval; and
• the potential for common mode failure.
These assumptions may not be applicable to the field application. Potential reliability issues should also
be considered, because an increased spurious trip rate is not going to make process facilities safer. Start-
ups and shutdowns are the most dangerous time for the process operation. In the best case (i.e., no
hazard), a spurious trip causes a plant shutdown, leading to production losses.
In designing the SIS, the owner/operator needs to be aware that some critical design criteria are not
addressed by IEC 61508 or ISA-84.01-2004-1. For example, the block valve is often the most critical
element in any SIF. Yet a significant design attribute for the block valve, the ratio of available actuator
power to required actuator power, is not addressed in either IEC 61508 or ISA-84.01-2004-1. Therefore,
strict adherence to the standards is not a substitute for good engineering design.
For the PE logic solver, an IEC 61508 evaluation is generally recommended due to the complexity of the
analysis of the hardware and software. The IEC 61508 compliance information should be supplemented
with a prior use evaluation.

— 171 — ISA-TR84.00.04-2005 Part 1
For field devices, IEC 61508 compliance provides some assurance with regard to the device
manufacture. The IEC 61508 lifecycle process is very detailed, covering specification, design, verification,
validation, quality control, and change management. The implementation of the IEC 61508 lifecycle by
the manufacturer should reduce the systematic failures, yielding better products. However, IEC 61508
compliance cannot determine whether the device works when exposed to the process and its associated
application conditions. Therefore, field device selection should always involve some level of prior use
evaluation to ensure that the device operates successfully in the intended application and that any
application-specific failure modes have been identified and addressed.
L.5 ISA-84.01-2004 Prior Use Assessment

The screening process in ISA-84.01-2004 Clause 11.5 is illustrated in Figure L-1. The screening process
defines when prior use information is considered sufficient to justify use of a device in an SIF application.
The prior use evaluation fulfills specific requirements in ISA-84.01-2004-1 Clauses 11.4 and 11.5.3
through 11.5.6. The methodologies and approaches taken in the evaluation 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 owner/operators’ experience with the device. If the device is PE,
additional evidence is necessary, dependent on whether the device is a Fixed Program Language (FPL)
or Limited Variability Language (LVL) device. Full Variability Language (FVL) devices cannot be selected
based on ISA-84.01-2004-1 review only; evidence of compliance to IEC 61508 Parts 2 and 3 should 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 maintenance record review. The prior
use evaluation may also include quantitative analysis of the device PFD in actual field installation. ISA-
84.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 the process
application. 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% (ISA-84.01-2004-1 Clause 11.9.2
Note).
Owner/operators and manufacturers often adopt communication 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.
NOTE 1 — A manufacturer may use an independent, competent third party, other than a nationally recognized testing laboratory,
to evaluate an SIF device based on part or all of the IEC 61508 Parts 2 and 3 criteria. The manufacturer can provide these reports
to the owner/operator as evidence to support a prior use claim (i.e., clauses L.7 and L.8). These reports should not be considered
as an “IEC 61508 certification” nor are these reports alone sufficient to meet the requirements of Clause 11.5. These reports
should not serve as a sole basis for selecting a device and should not be used as justification for labelling a device as “IEC 61508
certified.”
NOTE 2 — 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.

ISA-TR84.00.04-2005 Part 1 — 172 —
NOTE 3 — Regardless of the device selection method, there may be substantial requirements for the implementation of a device,
as documented in the device safety manual. The requirements may add substantial cost to the implementation of the device.
Consequently, the owner/operator should review:
• the device safety manual to determine the device suitability, and
• the content of the certification to identify its limitations and restrictions.
L.5.1 Benefits of ISA-84.01-2004 Prior Use Assessment
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 ISA-84.01-2004-1 prior use approach is valid for the proposed application. Operating experience
provides significant benefit for selection of field devices. Operating experience 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.
L.5.2 Limitations of ISA-84.01-2004 Prior Use Assessment
Proof test documentation and process demand event records can supply the needed information for
assessment of the probability of failure on demand (see ISA-TR84.00.02-2002). The primary challenge
for establishing operating experience is that maintenance records often do not include the detail
information required 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. 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.
L.5.3 Non-PE devices and PE devices using FPL
ISA-84.01-2004-1 allows the justification of the use 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 ISA-84.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.
ISA-84.01-2004-1 Clause 11.5.4 provides the requirements for applying prior use to the selection of these
devices. ISA-84.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 a 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.5.4 PE Devices using LVL
ISA-84.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 is not allowed).
Prior use has been successfully applied to PE logic solver for many years, relying on the following:

— 173 — ISA-TR84.00.04-2005 Part 1
• development of prior use data (ISA-84.01-2004-1 Clause 11.5),
• determination of unsafe failure modes (e.g., FMEA), and
• safety configuration (ISA-84.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” (see ISA 91.00.XX). These certifications can be considered in
the evaluation of the acceptability of the use of the PE logic solver in an SIS application. The ISA-SP84
committee discussed DIN 19250 and determined that its criteria are not sufficiently comparable to IEC
61508 requirements.
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. This is because it is:
• 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.6 A Balanced Approach – User Approved

The best methodology for the selection of SIF devices is to use a combination of evidence of “IEC 61508
compliance” and “prior use”. This approach ensures that the devices selected are designed,
manufactured, and managed for SIF service and operate successfully in the intended application (e.g.,
application-induced failures are accounted for).
ISA-84.01-1996 recognized that it was necessary for owner/operators to determine whether an SIF
device worked in the process application. 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.” ISA-84.01-2004-1 also recognizes that
owner/operators need to evaluate expected field performance when selecting SIF devices, because many
field devices are not designed in compliance with IEC 61508 Parts 2 and 3. In the 2004 standard, this
concept is referred to as “prior use.”
A typical approach used 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, diagnostic coverage, and safe failure fraction 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 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

ISA-TR84.00.04-2005 Part 1 — 174 —
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 were obtained and the boundary of the assessment. With
this background, the following guidelines can be used for selecting a device.
• IEC 61508 complaint devices should be evaluated to ensure that the device operates in its
intended applications. This may include the gathering prior use information.
• 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.
• 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”.
• IEC 61508 compliance is the preferred method for selecting PE devices using LVL.
Before addressing prior use information, it is important to recognize the overlap between IEC 61508
compliance and ISA-84.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 ISA-84.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 ISA-84.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) can be implemented.

— 175 — ISA-TR84.00.04-2005 Part 1
Figure L-2 -- Comparison of approaches without consideration of SIL Claim Limit
(Gray area in Figure L-2.B indicates that prior use may not be acceptable for some devices)

ISA-TR84.00.04-2005 Part 1 — 176 —
L.7 SIL Claim Limit Considerations

When referring to a device, it is important to remember that the term SIL refers to the PFD (or frequency
of failure, if continuous model) of an SIF. A device by itself does not have an SIL. It has a PFD. The
device implemented in an SIF contributes to the PFD of the SIF (which should achieve an SIL). When
referring to a device, the term "SIL" should always be followed by the words "claim limit."
Achieving an SIL claim limit involves substantially more than the calculation of the PFD. The SIL claim
limit is based on the hardware (Part 2) and software (Part 3) requirements of IEC 61508. These
requirements 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 PFD. 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-2002 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 PFD 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 not significant, due to the following:
• the large installed base of transmitters, which provides ample prior use information
• the ability to use external diagnostics to detect faults in the transmitter operation.
• 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.

— 177 — ISA-TR84.00.04-2005 Part 1
Annex M General Purpose versus Safety Logic Solvers
NOTE — Annex M is referenced in Clause 4.11 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. ISA-84.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 SISs, 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 programmable electronic (PE) logic solver in ISA-
84.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).
Until the late 1960s, the automotive industry utilized electromechanical relays to control its automotive
assembly lines. In the late 1960s, 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 1970s, 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 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 1980s, 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.

ISA-TR84.00.04-2005 Part 1 — 178 —
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 1980s, 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
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 1970s and 1980s.
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.
• Determine whether the logic solver manufacturer can supply safety components (e.g.,"fail-safe"
output) and use these to the extent possible.

— 179 — ISA-TR84.00.04-2005 Part 1
• Determine whether the PE logic solver meets the hardware fault tolerance required by ISA-84.01-
2004-1 Table 5.
• Implement supplemental hardwired systems (e.g., electro-mechanical relay or trip amp) to

provide an independent back-up 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 ISA-84.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 on-line 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 diagnostics 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 ISA-84.01-2004-1.
M.5 IEC 61508 Compliant PE Logic Solvers

An IEC 61508 compliant PE logic solver is the following:
• 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
serving the process sector.

— 181 — ISA-TR84.00.04-2005 Part 1
Annex N Design Guidance
NOTE — Annex N is referenced in Clause 4.11.
N.1 Purpose
This section is an updated version of ISA-84.01-1996 Annex B. It is included to ensure that the good
practices described in ISA-84.01-1996 Annex B were maintained. Some of this information is
incorporated into ISA-84.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:
a) No bus or highway communication between BPCS and SIS. This is acceptable for all SILs.
b) 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.
c) 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.
d) 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.
e) 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 change management
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
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:

ISA-TR84.00.04-2005 Part 1 — 182 —
• 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
• 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.
There are other technologies that can be used other than E/E/PE in the design of an SIS, such as
pneumatics and hydraulics. These technologies are outside the scope of ISA-84.01-2004-1.
N.4.1 Electrical technology used in SISs
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.

— 183 — ISA-TR84.00.04-2005 Part 1
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
• 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.
• 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 build-up on contacts
resulting in unreliable operation (e.g., load dropout). This is referred to as contact wetting. When utilizing

ISA-TR84.00.04-2005 Part 1 — 184 —
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 SISs

N.5.1 Solid state relays
Solid state relays are often used in high duty-cycle applications 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.
A user-approved safety crystal oscillator (e.g., quartz) timer is 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 complimentary metal oxide
semiconductor (CMOS), resistor-transistor logic (RTL), transistor-transistor logic (TTL), and high noise
immunity logic (HNIL). These components are assembled in stand-alone modules, plug-in board
modules, or in highly integrated, high-density chips. They differ from typical computer-type equipment in
that they have no central processing unit (CPU). They perform according to the logic obtained by the
direct-wiring techniques of interconnecting the various logic components, such as ANDs, ORs, and NOTs.
These systems have limitations in fail-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 SISs, 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

— 185 — ISA-TR84.00.04-2005 Part 1
Pulsed electronic logic generates pulses with a specified amplitude and period. A pulse train is
recognized as a logic "true” or "one," while all other signals (e.g., grounds, non-specified pulses, and
continuous "on" or "off") are recognized as a logic "false" or "zero."
Pulsed electronic logic can be considered in an SIS if it meets the requirements of ISA-84.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
• 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 that 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:

ISA-TR84.00.04-2005 Part 1 — 186 —
Table N-1 – Fault Types
Fault Type Example
Faults that immediately disable the capability of the SIS to respond to Stuck on or stuck off of a critical output point
a demand (critical faults)
Faults that in combination with other faults disable the capability of Diagnostic of a critical output point not performed
the SIS to respond to a demand (potential critical faults)
Faults initiating a safe response of the SIS without a demand Spurious trip due to a component fault
Faults that have no impact on the capability of the SIS to respond to a Burned out, not critical LED
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)
• Using watchdog timers

— 187 — ISA-TR84.00.04-2005 Part 1
• 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 has to 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 (such as 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
Processing Voter fault Random voter test Algorithm Assertions plausibility check
Reverse computation
diversity

ISA-TR84.00.04-2005 Part 1 — 188 —
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 they 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. (For example, 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 (for example, 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
Failure mode tables shown below are based upon CCPS PERD (Process Equipment Reliability
Database) initiative taxonomies.

— 189 — ISA-TR84.00.04-2005 Part 1
Transmitter Failure Mode Table
Failure Modes Failure Cause Examples Failure Classification
Complete Failures
Signal output > 100 % Part failure Dependent on application (1)
Signal output frozen Frozen impulse line, software bug, part Dangerous
failure etc.
Signal output < 0 % Part failure Dependent on application (2)
Partial Failures
Signal output high Part failure Dependent on application (1)
Signal output low Part failure Dependent on application (2)
Signal output slow to respond Part failure Dependent on total safety time (3)
Signal output too fast Part failure Dependent on application
Signal output erratic Part failure Dangerous
Note 1: Trip on high process variable safe while trip on low process variable dangerous
Note 2: Trip on low process variable safe while trip on high process variable dangerous
Note 3: Any time it exceeds its contribution to the total safety time it is dangerous
Note 4: Safe for isolation function, dangerous when positive action (i.e., full cooling, add shortstop
material, etc.)
Note 5: Dangerous for isolation function, safe when positive action (i.e., full cooling, add shortstop
material, etc.)
Switch Failure Mode Table
Complete Failures
Switch fail to function Welded contacts, etc. Dangerous
Switch spuriously functions Vibration, corroded contacts, etc. Safe
Partial Failures
Switch function early Miscalibrated, drift, etc. Dependent on application
Switch function delayed Miscalibrated, drift, etc. Dependent on total safety time (3)
Remote-Actuated Valve Failure Mode Table
Complete Failures
Spuriously fail to closed position Component failure Depends on application (4)
Spuriously fail to open position Component failure Depends on application (5)
Fail to close on demand Component failure Dangerous
Fail to open on demand Component failure Dangerous
Frozen position (modulating service) Component failure, process fluid solidified, Dangerous
etc.

ISA-TR84.00.04-2005 Part 1 — 190 —
Valve rupture Corrosion, mechanical damage, etc. Dangerous
Seal/packing blowout Misalignment, wear-out, etc. Dangerous
Partial Failures
Reduced capacity Partial pluggage, etc. Depends on application
Seat leakage Mechanical wear of seat, etc. Depends on application
External leak Pin hole crack, etc. Depends on application
External leak - body/bonnet Pin hole crack, etc. Depends on application
External leak - packing/seal Loose fit, etc. Depends on application
Controlled variable high Component failure such as actuator, etc. Depends on application
Controlled variable low Component failure such as actuator, etc. Depends on application
Fail to hold position Component failure such as actuator, poor Depends on application
design, etc.
Unstable control (hunting) Component failure such as actuator, etc. Depends on application
Responds too quickly Component failure such as actuator, poor Depends on application
design, etc.
Responds too slowly Component failure such as actuator, poor Depends on application
design, etc.
Excessive noise Process conditions vs inherent design Depends on application
Incipient Condition
Body cracked Poor casting, corrosion, etc. Not Applicable
Body eroded High process velocity, slurry, etc. Not Applicable
Body corroded Process conditions, etc. Not Applicable
Body material – incorrect for service Poor design, etc. Not Applicable
Guide fouled Process conditions, etc. Not Applicable
Guide galled Mechanical wear, vibration, etc. Not Applicable
Guide corroded Exposure to outdoor elements, corrosive Not Applicable

process material, etc.
Guide worn Mechanical wear, etc. Not Applicable
Stem fouled Process conditions, etc. Not Applicable
Stem galled Mechanical wear, etc. Not Applicable
Stem corroded Exposure to outdoor elements, etc. Not Applicable
Stem bent Excessive force on stem, etc. Not Applicable
Stem worn Mechanical wear, etc. Not Applicable
Primary (1 out of n) seal leak by Mechanical wear, etc. Not Applicable
Secondary seal defective Mechanical wear, etc. Not Applicable
Seat fouled Process conditions, etc. Not Applicable
Seat cut Debris in process fluid, etc. Not Applicable
Seat eroded High process velocity, slurry, etc. Not Applicable
Seat corroded Corrosive process, etc. Not Applicable
Seat excessive wear Operation beyond design range, etc. Not Applicable

— 191 — ISA-TR84.00.04-2005 Part 1
Seat (soft) embedded debris Debris in process fluid, etc. Not Applicable
Seat (soft) overheat evidence Process upset conditions, etc. Not Applicable
Seat loading mechanism dysfunctional Mechanical wear, etc. Not Applicable
Spring cracked Corrosion, etc. Not Applicable
Spring corroded Exposure to outdoor elements, etc. Not Applicable
Spring fatigued Excessive cycling, etc. Not Applicable
Spring rubbing Poor construction or repair, etc. Not Applicable

Excessive vibration Inadequate support or installed location, Not Applicable
etc.
Relay Failure Mode Table

Contact fails to open when energized to Contacts stuck Dangerous

open
Contacts welded
Stuck armature
Coil inoperative
Contact fails to open when de-energized Contacts stuck Dangerous

to open
Contacts welded
Coil spring failed
Stuck armature
Contact fails to close when energized to Contacts fouled Dangerous

close
Contacts corroded
Contacts worn
Coil inoperative
Contact fails to close when de-energized Contacts stuck Dangerous

to close
Contacts fouled
Contacts corroded
Contacts worn
Coil spring failed
Alarm Failure Mode Table

Complete Failures
Alarm fail to function Welded contacts, etc. Dangerous
Alarm spuriously function Vibration, corroded contacts, etc. Safe
Partial Failures
Alarm function delayed Miscalibrated, component degraded Dependent on total safety time (3)
failure, etc.
Given these failure modes, consider selecting components with built-in features that drive the device to
one of its detectable extremes in a high percentage of its failure modes.

ISA-TR84.00.04-2005 Part 1 — 192 —
N.8.3 Sensor selection criteria
Some considerations for the selection of sensors include:
• analog devices are generally preferred to discrete devices, because the use of the analog signal
allows for on-line 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 period 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
• valve position indication.

— 193 — ISA-TR84.00.04-2005 Part 1
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
• 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
• solenoid vents should be oriented to point downward and have protection against plugging, dirt,
insects, freezing, etc. Bug screens should be made from a noncorrosive 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 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 volt AC and 24 volt DC).
Low energy signal levels are utilized in the logic system to achieve signal processing speed. High energy
signal levels are used in the field devices to ensure a high signal to noise ratio over long transmission
distances and to assure that contacts on discrete sensors used as input devices have sufficient power
(voltage and current) to provide appropriate contact-wetting. Output amplifiers receive the low energy
signal from the solid state or PES logic solver and convert it to a signal suitable for driving the final
element (e.g., solenoid valve).
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:

ISA-TR84.00.04-2005 Part 1 — 194 —
• video displays
• panels containing lamps, push buttons, indicators, and switches
• annunciators
• printers
• 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 Annex
B above, 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 pushbuttons, lamps, gauges, and other information is not
confusing to the operator. Shutdown switches for different process units or equipment that look the same
and are grouped together may result in the wrong equipment being shut down by an operator under
stress in an emergency situation. Physically separate the shutdown switches and boldly label their
function. Provide means to test all lamps.
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.

— 195 — ISA-TR84.00.04-2005 Part 1
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.
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:
• 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 is 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:

ISA-TR84.00.04-2005 Part 1 — 196 —
• Parameters that are appropriate for operator interaction should be accessible.
• Parameters that may be changed on-line 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

Wring 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 of 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 manufacturers’

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.

— 197 — ISA-TR84.00.04-2005 Part 1
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 that 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 Safety Integrity Level (SIL)
• ISA-TR84.00.02-2002 illustrates various methods to determine 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, an
uninterruptible power supply (UPS), or battery backup. Design considerations when transferring to
alternate sources include:
• detection of fault prior to impacting SIS operation;
• transfer to back-up 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.

ISA-TR84.00.04-2005 Part 1 — 198 —
Electronic and PE logic solvers typically have a lower insulation breakover 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 ensure 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, brown outs and electrical noise
• protection against undervoltages
• protection against overvoltages
• grounding.
A checklist of DC electrical power considerations includes:
• voltage range and current range including inrush current
• nonlinear 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.

— 199 — ISA-TR84.00.04-2005 Part 1
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
• 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:

ISA-TR84.00.04-2005 Part 1 — 200 —
• Pressure
• Volume
• Contaminants
• Fluid properties

— 201 — ISA-TR84.00.04-2005 Part 1
Annex O Software
NOTE — Annex O is referenced in Clause 4.12 and Annex L.7.
O.1 Purpose
The software requirements of ISA-84.01-2004-1 and 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 ISA-84.01-1996 development also worked on
the ISA-84.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 ISA-84.01-2004-1 and ISA-84.01-1996 resulted in part because:
• ISA-84.01-1996 was a US national standard and IEC 61511 is an international standard.
• IEC 61508-3 (software section) was under development when ISA-84.01-1996 was written.
• IEC 61511 was completed 7 years after ISA-84.01-1996 (a “lifetime” in software development).
• The various countries and safety cultures represented on the IEC 61511 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 IEC 61511 (i.e., limited variability, full variability, and fixed
program languages) allowed a more boundary-specific discussion of software than available in
ISA-84.01-1996.
ISA-84.01-1996 and ISA-84.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).
The major changes the owner/operator experiences when transitioning to ISA-84.01-2004-1 from ISA-
84.01-1996 include:
• ISA-84.01-2004-1 has normative (i.e., mandatory) software requirements, while most ISA-84.01-
1996 software requirements are informative (i.e., non-mandatory) with the exception of ISA-
84.01-1996 Clause 7.8

ISA-TR84.00.04-2005 Part 1 — 202 —
• change in terminology
• more detailed application requirements
• documentation requirements included for each phase of application software development
• addition of V-model (ISA-84.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
• expansion of safety lifecycle software elements.
Some key aspects of ISA-84.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 ISA-84.01-2004-1 position is as follows:
ISA-84.01-2004-1 is limited to application software developed using fixed programming

languages or limited variability languages. The ISA-84.01-2004-1 requirements are suitable
for the development and modification of application software up to SIL 3. Therefore, ISA-
84.01-2004-1 does not differentiate between SIL 1, 2, and 3.
Software languages have been partitioned into three new categories (i.e., full variability
languages (FVL), limited variability languages (LVL), and fixed program languages (FPL)).
ISA-84.01-2004-1 Clause 12 uses the safety lifecycle to emphasize how software should be developed
(see ISA-84.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, and planning requirements are repeated for each lifecycle 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.
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.

— 203 — ISA-TR84.00.04-2005 Part 1
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.
• Application logic is typically implemented in one of 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:

ISA-TR84.00.04-2005 Part 1 — 204 —
• 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 which can be copied back.
• Copy to a removable medium which can be used as a disk replacement for a corrupted PES.
• Copy to an on-line device (e.g., disk) used to backup.
• A communication link with another digital system.
Consider maintaining a separate backup for data that are 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
failures, there is no certification, quantitative analysis, or prior use analysis that can be performed that
ensures that 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; and
• Configuration and change management 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. Fixed program
language (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 limited variability
language (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

— 205 — ISA-TR84.00.04-2005 Part 1
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 that is being used by the device. This section presents an approach for both
fixed program language (FPL) and limited variability language (LVL) devices. In accordance with IEC
61511, the use of full variability language (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 minimizes the potential for undetected systematic errors. An
approach to minimize systematic errors within FPL devices, such as PE-based transmitters, should
consider 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 IEC 61511 clause 11.5.4 for FPL devices that are
not IEC 61508 certified by a nationally recognized testing laboratory (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:
• 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 IEC 61511 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 of 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.

— 207 — ISA-TR84.00.04-2005 Part 1
Annex P Response to Detection of a Dangerous Fault
NOTE — Annex P is referenced in Clause 4.11 and Annex E.1.
P.1 Purpose
This annex is intended to provide application guidance regarding ISA-84.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 safety instrumented function (SIF) failing to function.
• SIS with no fault tolerance providing protection in the continuous mode (see Clause 11.3.3).
NOTE — See Annex I of this technical report 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 alarms types,
nameplate labeling, human engineering, display characteristics, and applications, refer to ISA-18.1-1979
(R2004), ISA-RP60.3-1985, and ISA-RP60.6-1984 (see References, Annex R). These industry practices
address good engineering practice for the implementation of alarms and should be utilized as
appropriate.
When these faults are detected on-line, a choice is made 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

ISA-TR84.00.04-2005 Part 1 — 208 —
• Process safety time, (i.e., the time it takes for the hazardous event to propagate)
• Mode of operation (i.e., continuous versus demand)
• 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 Annex K of this technical report.
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 ISA-84.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 each safety function. A hazard and risk analysis
defines for each hazard scenario when action should be taken given the initiating causes, consequence
severity, and protection layers. The potential for common cause should also be evaluated to ensure that
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 mean time to repair (MTTR) is restricted based on the

— 209 — ISA-TR84.00.04-2005 Part 1
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.
If maintenance requires longer than the MTTR assumed in the PFD 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 management of change (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 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 operation 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
ISA-84.01-2004 permits operation of the process for a limited time period with a degraded or disabled
SIF, because other temporary compensating measures are 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 Annex B of this technical report for a discussion of operator-initiated safety functions
and to Annex F for a discussion of 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 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

ISA-TR84.00.04-2005 Part 1 — 210 —
reason, the standard requires that the user examine how the risk is being managed when continuing to
operate the plant beyond the assumed MTTR.
P.4 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.5 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.6 Examples
Three examples of how one company has handled responses to detected failures are presented.
P.6.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 to 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.
P.6.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

— 211 — ISA-TR84.00.04-2005 Part 1
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.6.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.

— 213 — ISA-TR84.00.04-2005 Part 1
Annex Q Acronyms and Abbreviations
BPCS Basic Process Control System

C&E Cause and Effect
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
EMC Electromagnetic Coupling
ETT Energize to Trip
FAT Factory Acceptance Text
FM Factory Mutual Global
FMEA Failure Mode Effect Analysis
FPL Fixed Program Language
FSA Functional Safety Assessment
FVL Full Variability Language
HFE Human Factors Engineering
H&RA Hazard and Risk Analysis
HMI Human Machine Interface
HNIL High Noise Immunity Logic
I/O Input/Output
IPL Independent Protection Layer
IPRDS In Plant Reliability Data System
IR Infrared
LOPA Layers of Protection Analysis
LVL Limited Variability Language
MOC Management of Change
MTTF Mean Time To Failure
MTTR Mean Time To Repair
NRTL Nationally Recognized Testing Laboratory
OSHA U.S. Occupational Safety and Health Administration
PE Programmable Electronic
PERD Process Equipment Reliability Database
PES Programmable Electronic Systems
PFD Probability of Failure on Demand
P&IDs Piping and Instrumentation Diagrams
PHA Process Hazard Analysis
PIU Proven In Use
PLC Programmable Logic Controller
PM Preventative Maintenance
PSAT Pre-Startup Acceptance Test
PSM Process Safety Management
PSSR Pre-Startup Safety Review
RAGAGEP Recognized and Generally Accepted Good Engineering Practice
RRF Risk Reduction Factor
RFI Radio Frequency Interference
RTL Resistor-Transistor Logic

ISA-TR84.00.04-2005 Part 1 — 214 —
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
STR Spurious Trip Rate
SU Safe Undetected
THERP Technique for Human Error Rate Prediction
TTL Transistor-transistor Logic
TÜV Technisher Überwachungsverein
UPS Uninterruptible Power Supply

— 215 — ISA-TR84.00.04-2005 Part 1
Annex R References
ISA – www.isa.org
ISA-TR84.00.04-2005 Part 2: Example Implementation of ANSI/ISA-84.00.01-2004 (IEC 61511 Mod).
ANSI/ISA-84.01-1996 - Application of Safety Instrumented Systems for the Process Industries. Referred
to in this technical report as ISA-84.01-1996.
ANSI/ISA-84.00.01-2004 Part 1(IEC 61511-1 Mod) - Functional Safety: Safety Instrumented Systems for
the Process Industry Sector - Part 1: Framework, Definitions, System, Hardware and Software
Requirements. Referred to in this technical report as ISA-84.01-2004-1.
ANSI/ISA-84.00.01-2004 Part 2 (IEC 61511-2 Mod) - Functional Safety: Safety Instrumented Systems for
the Process Industry Sector - Part 2: Guidelines for the Application of ANSI/ISA-84.00.01-2004 Part 1(IEC
61511-1 Mod). Referred to in this technical report as ISA-84.01-2004-2.
ANSI/ISA-84.00.01-2004 Part 3 (IEC 61511-3 Mod) - Functional Safety: Safety Instrumented Systems for
the Process Industry Sector - Part 3: Guidance for the Determination of the Required Safety Integrity
Levels – Informative. Referred to in this technical report as ISA-84.01-2004-3.
ISA-TR84.00.02-2002 - Parts 1-5 - Safety Instrumented Functions (SIF) Safety Integrity Level (SIL)
Evaluation Techniques.
ISA-TR84.00.03-2002 - Guidance for Testing of Process Sector Safety Instrumented Functions (SIF)
Implemented as or Within Safety Instrumented Systems (SIS).
ANSI/ISA-18.1-1979 - (R2004) - Annunciator Sequences and Specifications.
ISA-RP60.3-1985 - Human Engineering for Control Centers.
ISA-RP60.6-1984 - Nameplates, Labels, and Tags for Control Centers.
Fisher, Thomas G. Alarm and Interlock Systems. Research Triangle Park, NC: ISA, 1984. (ISBN 0-87664-
736-0)
AIChE -- American Institute of Chemical Engineers – Center for Chemical Process Safety (CCPS) –
www.aiche.org
Guidelines for Chemical Process Quantitative Risk Analysis. Second Edition. New York: AIChE, 2000.
(ISBN 0-8169-0720-X)
Guidelines for Hazard Evaluation Procedures. New York: AIChE, 1992. (ISBN No: 0-8169-0491-X)
Guidelines for Safe Automation of Chemical Processes. New York: AIChE, 1993. (ISBN 0-8169-0554-1)
Layer of Protection Analysis: Simplified Risk Assessment. New York: AIChE, 2001. (ISBN No: 0-8169-
0811-7)
Draft: Guidelines for Safe and Reliable Instrumented Protective Systems. New York: AIChE. Publication
expected in 2006.

ISA-TR84.00.04-2005 Part 1 — 216 —
Bollinger, Robert E., et al. Inherently Safer Chemical Processes: A Lifecycle Approach. New York:
American Institute of Chemical Engineers―Center for Chemical Process Safety, 1996. (ISBN 0-8169-
0703-X).
API – American Petroleum Institute – www.api.org
API-RP14C-2001. Recommended Practice for Analysis, Design, Installation, and Testing of Basic Surface
Safety Systems for Offshore Production Platforms. Seventh Edition.
DIN VDE – Deutsches Institut für Normung / Verband Deutscher

Elektrotechniker - www.dke.de
DIN VDE 0801 -1990. Principles for computers in safety-related systems.
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.
EEMUA -- Engineering Equipment Materials and Users’ Association – www.eemua.co.uk
Engineering Equipment Materials and Users’ Association (EEMUA), 3rd floor, 20 Long Lane, London,
EC1A 9HL, UK.
H&SE―Health and Safety Executive (UK) – www.hse.gov.uk
Health & Safety Executive (HSE), Rose Court, 2 Southwark Bridge, London, SE1 9HS, UK.
www.hse.gov.uk. (retrieved 07/06/2005 from source)
Programmable Electronic Systems Safety Related Application - PES 2: General Technical. 1987. (ISBN 0
11 883906 3)
[NOTE: PES 1 and 2 have been removed from distribution by the Health & Safety Executive.]
Out of Control: Why Control Systems Go Wrong and How to Prevent Failure. Second edition. HSE Books,
2004. (ISBN 0-7176-2192-8)
IEC ― International Electrotechnical Commission – www.iec.ch
IEC 61508-1. Ed. 1.0 b: 1998. Functional safety of electrical/electronic/programmable electronic safety-
related systems - Part 1: General requirements.
related systems - Part 2: Requirements for electrical/electronic/programmable electronic safety-related
systems.
related systems - Part 3: Software requirements.
related systems - Part 4: Definitions and abbreviations.
IEC 61511-1. Ed. 1.0: 2003. Functional Safety: Safety Instrumented Systems for the Process Industry
Sector - Part 1: Framework, Definitions, System, Hardware and Software Requirements.

— 217 — ISA-TR84.00.04-2005 Part 1
Sector - Part 2: Guidelines for the Application of IEC 61511-1.
Sector - Part 3: Guidance for the Determination of the Required Safety Integrity Levels – Informative.
IEC 61131-3. Ed. 2.0 en: 2003. Programmable controllers - Part 3: Programming languages.
IEEE ― Institute of Electrical and Electronics Engineers – www.ieee.org
IEEE-845-1999. Guide to Evaluation of Man - Machine Performance in Nuclear Power Generating

Stations, Control Rooms, and Other Peripheries.
IEEE-1023-1988. IEEE Guide for the Application Of Human Factors Engineering to Systems, Equipment,
and Facilities of Nuclear Power Generating Stations.
IEEE-1289-1998. IEEE Guide for the Application of Human Factors Engineering in the Design of
Computer-Based Monitoring and Control Displays for Nuclear Power Generating Stations.
NFPA―National Fire Protection Association – www.nfpa.org
NFPA 85: Boiler and Combustion Systems Hazards Code. 2001 Edition. (2004 Edition Available Date:
April 1, 2004).
NFPA 86: Standard for Ovens and Furnaces. 2003 Edition.
NRC ― US Nuclear Regulatory Commission – www.nrc.gov
NUREG-0700-Rev. 2, 2002. Human-System Interface Design Review Guidelines. U.S. Nuclear

Regulatory Commission.
NUREG/CR-1278-1983. Handbook of Human Reliability Analysis with Emphasis on Nuclear Power Plant
Applications. Report of the U.S. Nuclear Regulatory Commission.
NUREG/CR-4772-1987. Accident Sequence Evaluation Program (ASEP) Human Reliability Analysis

Procedure. Report of the U.S. Nuclear Regulatory Commission.
Other References
Letters of March 23, 2000 and November 29, 2005, from Mr. Richard E. Fairfax, Director, Directorate of
Compliance Programs Assistance, U.S. Department of Labor, OSHA, to ISA regarding 29 CFR 1910.119
(OSHA 1910.119).
Collins Concise English Dictionary and Thesaurus. Third edition. London: HarperCollins, 2003. (ISBN
0007162626)

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: 1-55617-979-0

ISA-TR84.00.04-2005 Part 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ISA-TR84.00.04-2005 Part 1

Uploaded by

Copyright:

Available Formats

TECHNICAL REPORT

Guidelines for the

Approved 1 December 2005

CAUTION — ISA ADHERES TO THE POLICY OF THE AMERICAN NATIONAL STANDARDS

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

Copyright 2005 ISA. All rights reserved.

A. Summers, ISA-SP84 WG2 Leader SIS-TECH Solutions LLC

Copyright 2005 ISA. All rights reserved.

Copyright 2005 ISA. All rights reserved.

Copyright 2005 ISA. All rights reserved.

Copyright 2005 ISA. All rights reserved.

This guidance document facilitates transition from ISA-84.01-1996 to ISA-84.01-2004 by:

Copyright 2005 ISA. All rights reserved.

3.1 General Considerations

3.2 Management of Change Considerations

3.2.1 Process Design

Copyright 2005 ISA. All rights reserved.

3.2.2 Safety Requirements Specification (SRS)

3.2.3 SIS Design

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

3.2.4 SIS Operation, Maintenance, Testing, and Inspection

• reduced operator diligence in diagnosing failures of SIS equipment,

Copyright 2005 ISA. All rights reserved.

3.2.5 Management of Change

4.1 Clause 1 - Scope

Copyright 2005 ISA. All rights reserved.

4.2 Clause 2 – References

4.3 Clause 3 – Abbreviations and Definitions

4.4 Clause 4 – Conformance to Standard

4.5 Clause 5 – Management of Functional Safety

Copyright 2005 ISA. All rights reserved.

4.6 Clause 6 – Safety Lifecycle Requirements

4.7 Clause 7 – Verification

4.8 Clause 8 – Process Hazard and Risk Analysis

Copyright 2005 ISA. All rights reserved.

• Identification of the process hazards,

• Evaluation of the consequence severity associated with each process hazard,

• Owner/operator experience gained in applying ISA-84.01-1996 indicated that the additional

Copyright 2005 ISA. All rights reserved.

4.9 Clause 9 – Allocation of Safety Functions to Protection Layers

Some of the new requirements in this clause include the following:

1) Requirements for continuous mode of operation.

ISA-84.01-2004-1 includes high demand/continuous mode of operation, as well as demand

2) New requirements for SIL 4 Safety Instrumented Functions.

ISA-84.01-2004-1 requires that SIL 4 safety instrumented functions be designed in compliance

3) Requirements for the BPCS when used as a protection layer.

Copyright 2005 ISA. All rights reserved.

4.10 Clause 10 – SIS Safety Requirement Specification

4.11 Clause 11 – SIS Design and Engineering

• Specific requirements for when a fault is detected in the SIS.

• Requirements for the selection of SIF devices.

• Requirements for design of the SIS.

ISA-TR84.00.02-2002 (visit www.isa.org/standards) is a technical report that discusses how to perform

Copyright 2005 ISA. All rights reserved.

4.13 Clause 13 – Factory Acceptance Testing (FAT)

4.14 Clause 14 – SIS Installation and Commissioning

4.15 Clause 15 - SIS Safety Validation

4.16 Clause 16 – SIS Operation and Maintenance

1) Operation procedures and associated training should address:

o how the SIF functions.

Copyright 2005 ISA. All rights reserved.

4. 17 Clause 17 SIS Modification

4.18 Clause 18 – SIS Decommissioning