TECHNICAL REPORT

ISA-TR18.2.2-2016

Alarm Identification
and Rationalization
Approved 29 June 2016
ISA–TR18.2.2–2016, Alarm Identification and Rationalization

ISBN: 978-1-945541-00-1

Copyright © 2016 by the International Society of Automation. All rights reserved. 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

E-mail: standards@[Link]
 3 ISA-TR18.2.2-2016

Preface
This preface, as well as all footnotes and annexes, is included for information purpo ses only and
is not part of ISA-TR18.2.2-2016.

This technical report has been prepared as part of the service of ISA, the International Soc iety of
Automation, toward a goal of helping in the understanding and use of the ANSI/ISA-18.02-2009
Management of Alarm Systems for the Process Industries. 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 277099;
Telephone (919) 549-8411; Fax (919) 549-8288; E-mail: standards@[Link].

This ISA Standards and Practices Department is aware of the growing need for attention to the
metric system of units in general, and the International System of Units (SI) in particular, in the
preparation of instrumentation standards, recommended practices, and technical reports. The
Department is further aware of the benefits of USA users of ISA standards of incorporating suitable
references to the SI (and the metric system) in their business and professional dealin gs with other
countries. Toward this end, the Department will endeavor to introduce SI and acceptable metric
units in all new and revised standards to the greatest extent possible. The Metric Practice Guide,
which has been published by the Institute of Electrical and Electronics Engineers (IEEE) as
ANSI/IEEE Std. 268-1992, and future revisions, will be the reference guide for definitions, symbols,
abbreviations, and conversion factors.

It is the policy of ISA to encourage and welcome the participation of al l concerned individuals and
interests in the development of ISA standards. 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.

This technical report is structured to follow the ISA Style Guide.

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
ISA-TR18.2.2-2016 –4–

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.

The following people served as members of ISA Committee ISA18 WG 2 and contributed to this
technical report:

The following people served as voting members of ISA18 and contributed to this technical report:

NAME COMPANY

D. Dunn, ISA18 Co-Chair Phillips 66

N. Sands, ISA18 Co-Chair DuPont
B. Fitzpatrick, ISA18 Managing Director Wood Group Mustang
D. Logerot, ISA18 WG2 Co-Chair ProSys Inc.
D. Strobhar, ISA18 WG Co-Chair Beville Engineering Inc.
J. Alford Consultant
S. Apple Schneider Electric
J. Bogdan J Bogdan Consulting LLC
K. Brown Enbridge Inc.
M. Brown Matrikon Inc.
A. Bryant Oxy Inc.
J. Campbell Consultant
M. Carter Consultant
L. Dubois UReason
B. Hollifield PAS
S. Kandasamy Chevron Energy Technology Company
C. Lunty Suncor
M. Marvan Shell Canada
D. Metzger DPM Consulting
L. Myers Consultant
G. Nasby City of Guelph Water Services
G. Plowman Rockwell Automation
D. Rothenberg D Roth Inc.
T. Stauffer Exida Co.
B. Vail URS PS / AECOM
K. Van Camp Emerson Process Management
D. Visnich Burns & McDonnell
R. Weibel Tips Inc.

This published standard was approved for publication by the ISA Standards and Practices Board
on 29 June 2016.

NAME COMPANY

N. Sands, Vice President DuPont

D. Bartusiak ExxonMobil Research & Engineering
P. Brett Honeywell Inc.
E. Cosman OIT Concepts, LLC
D. Dunn Phillips 66
J. Federlein Federlein & Assoc. LLC
B. Fitzpatrick Wood Group Mustang
J. Gilsinn Kenexis Consulting
J.-P. Hauet KB Intelligence
 5 ISA-TR18.2.2-2016

J. Jamison Encana Corp.

D. Lee UCDS
K.-P. Lindner Endress+Hauser Process Solutions AG
T. McAvinew Consultant
V. Mezzano Fluor Corp.
C. Monchinski Automated Control Concepts Inc.
D. Reed Rockwell Automation
H. Sasajima Fieldcomm Group Inc. Asia-Pacific
T. Schnaare Rosemount Inc.
J. Tatera Tatera & Associates Inc.
K. Unger Consultant
I. Verhappen Industrial Automation Networks
D. Visnich Burns & McDonnell
W. Weidman Consultant
J. Weiss Applied Control Solutions LLC
M. Wilkins Yokogawa
D. Zetterberg Chevron Energy
This page intentionally left blank.
 7 ISA-TR18.2.2-2016

Contents

Foreword ............................................................................................................................ 11
1 Scope ........................................................................................................................... 13
1.1 General ............................................................................................................... 13
1.2 Applicability ......................................................................................................... 13
2 Normative references .................................................................................................... 13
3 Definition of terms and acronyms .................................................................................. 14
3.1 Definitions ........................................................................................................... 14
3.2 Acronyms ............................................................................................................ 17
4 Project scoping ............................................................................................................. 17
4.1 Approaches to identification and rationalization .................................................... 17
5 Identification ................................................................................................................. 17
5.1 Purpose ............................................................................................................... 17
5.2 Relationship between identification and rationalization ......................................... 17
5.3 Examples of identification sources ....................................................................... 18
5.4 Identification documentation ................................................................................ 20
6 Rationalization .............................................................................................................. 21
6.1 Purpose ............................................................................................................... 21
6.2 Preparation .......................................................................................................... 21
6.3 Location and facilities .......................................................................................... 24
6.4 Roles and responsibilities .................................................................................... 24
6.5 Alarm rationalization process ............................................................................... 25
7 Prioritization ................................................................................................................. 28
7.1 Consequence/allowable operator response time method ....................................... 29
7.2 Consequence-based prioritization option .............................................................. 31
7.3 Rule based prioritization ...................................................................................... 32
8 Classification ................................................................................................................ 32
8.1 General ............................................................................................................... 32
8.2 Classification procedure ....................................................................................... 32
8.3 EXAMPLE: Alarm identification and alarm classification ........................................ 32
8.4 EXAMPLE: Alarm classification and consequence severity ................................... 32
9 Master alarm database and alarm documentation .......................................................... 32
9.1 General ............................................................................................................... 32
9.2 Software .............................................................................................................. 33
9.3 Alarm documentation ........................................................................................... 33
9.4 Uses of the master alarm database ...................................................................... 34
9.5 Existing alarm systems ........................................................................................ 35
9.6 New alarm systems .............................................................................................. 35
10 Altering the alarm system to reflect the master alarm database ...................................... 35
10.1 General ............................................................................................................... 35
10.2 New alarm systems .............................................................................................. 35
10.3 Existing alarm systems ........................................................................................ 35
10.4 Training ............................................................................................................... 36
ISA-TR18.2.2-2016 –8–

11 Bibliography ................................................................................................................. 37
12 Appendix A – Potential pitfalls to success...................................................................... 37
12.1 General ............................................................................................................... 37
12.2 Project management ............................................................................................ 37
12.3 Preparation .......................................................................................................... 38
12.4 Team dynamics ................................................................................................... 38
12.5 Rationalization sessions ...................................................................................... 39
 9 ISA-TR18.2.2-2016

List of Tables

Table 1 - Example of Consequence/Operator Response Time Prioritization .......................... 30

This page intentionally left blank.
  11  ISA-TR18.2.2-2016

Foreword
In June of 2009, ANSI/ISA-18.2-2009 Management of Alarm Systems for the Process Industries,
commonly referred to as ISA-18.2 was issued. In that same year the ISA18 committee established
six working groups to develop a series of technical reports with guidance on how to implement the
practices outlined in ISA-18.2. In 2012, a seventh working group was also added. In 2016, a
revision of ISA-18.2 was published as ANSI/ISA-18.2-2016.

The technical reports are each listed below with a brief overview:

 TR1 – Alarm Philosophy – provides guidance on the alarm philosophy. TR1 is limited to the
scope of ANSI/ISA-18.2 Clause 6. The alarm philosophy provides guidance for successful
management of the alarm system. It covers the definitions, principles, and activities by
providing overall guidance on methods for alarm identification, rationalization, classification,
prioritization, monitoring, management of change, and audit.

 TR2 – Alarm Identification and Rationalization – provides guidance on alarm identification and
rationalization. TR2 is limited to the scope of ANSI/ISA-18.2 Clauses 8 and 9. Identification
and rationalization covers the processes to determine the possible need for an alarm or a
change to an alarm, systematically compare alarms to the alarm philosophy and determine the
alarm setpoint, consequence, operator action, priority, and class. Activities include, but are not
limited to, identification, justification, prioritization, classification, and documentation.

 TR3 – Basic Alarm Design – provides guidance on basic alarm design. TR3 focuses on the
scope of ANSI/ISA-18.2 Clause 10 and may include other clauses as needed (e.g., operations
and maintenance). Basic alarm design covers the selection of alarm attributes (e.g., types,
deadbands, and delay times) and may be specific to each control system.

 TR4 – Enhanced and Advanced Alarm Methods – provides guidance on advanced and
enhanced alarm methods. TR4 focuses on the scope of ANSI/ISA-18.2 Clause 12. Enhanced
alarm design covers guidance on additional logic, programming, or modeling used to modify
alarm behavior. These methods may include: dynamic alarming, state -based alarming,
adaptive alarms, logic-based alarming, predictive alarming, as well as most of the designed
suppression methods.

 TR5 – Alarm Monitoring, Assessment, and Audit – provides guidance on monitoring,

assessment and audit of alarms. TR5 focuses on the scope of ANSI/ISA-18.2 Clauses 16 and
18. Monitoring, assessment, and audit cover the continuous monitoring, periodic performance
assessment, and recurring audit of the alarm system.

 TR6 – Alarm Systems for Batch and Discrete Processes – provides guidance on the application
of ANSI/ISA-18.2 alarm life cycle activities to batch and discrete processes, expanding on
multiple clauses of ANSI/ISA-18.2.

 TR7 – Alarm Management when Utilizing Packaged Systems – provides guidance on the
application of ANSI/ISA-18.2 to plants utilizing packaged systems, expanding on multiple
clauses of ANSI/ISA-18.2.
Each technical report is written to be a standalone document. In an effort to minimize repetition,
the technical reports have cross references.

The guidance as presented in this document is general in nature, and should be applied to each
system as appropriate by personnel knowledgeable in the manufacturing process and control
systems to which it is being applied.
This page intentionally left blank.
  13  ISA-TR18.2.2-2016

1 Scope
1.1 General
This technical report was written in support of the standard ANSI/ISA-18.2-2016, Management of Alarm
Systems for the Process Industries (March 2016), commonly referred to as ISA-18.2.
This technical report provides guidance, rationale, and examples for the identification and
rationalization life cycle stages from ISA-18.2.

a) Identification - Identification is a general term for the different methods that can be used to
determine the possible need for an alarm or a change to an alarm. The identification stage
is the input point of the alarm lifecycle for recommended alarms or alarm changes. Identified
alarms are an input to rationalization.

b) Rationalization – Rationalization encompasses several significant activities, including alarm

justification, documentation, prioritization, and classification. In justification, existing or
potential alarms are systematically compared to the criteria for alarms set forth in the alarm
philosophy. If the proposed alarm meets the criteria, then the alarm type, setpoint, cause,
consequence, and operator action are documented. The alarm is prioritized and classified
according to the philosophy. Classification encompasses assig ning alarms to a group or
class defining certain administrative requirements. These activities are often combined into
a single rationalization activity. They do not need to be conducted in separate sessions.

1.2 Applicability
This technical report addresses alarm identification and rationalization for facilities in the process
industries for a variety of purposes which include, but are not restricted to, improving safety,
environmental protection, product quality, equipment protection, and plant productivity. The
methods described herein are applicable to batch and discrete processes as well as continuous
processes. There may be some further considerations needed for batch and discrete processes
(e.g., time varying setpoints and need to suppress alarms for certain batch steps). For those further
considerations see TR6. For additional guidance with respect to packaged systems see TR7 .

The application of the material in this report will vary with the type of alarm management e ffort
being undertaken.

a) New facility (unit or plant) – Alarm rationalization for a new facility can be challenging since
the team cannot draw upon alarm history or facility operating experience . Input from
operators will have to be from those who have worked on comparable processes. As such,
additional process engineering input may be needed to augment the lack of operational
experience. In some situations, some alarms may need to be rationalized a second time as
part the continuous improvement process once there is more operating experience with the
facility. A post startup audit may highlight the need for improvement to meet target metrics.

b) Control system upgrade – The lack of experience with the alarm management capabilities
of the new control system may mean that additional training could be necessary before
beginning the rationalization effort. In particular, the project team will need to understand
the options for configuration of alarms, the human machine interface, etc.

c) Existing control system – Existing systems may have issues, including: the potential for
poor or nonexistent documentation of the basis of the existing alarm configuration,
excessive or unneeded alarms, and inconsistencies in the approaches for creation of
alarms. See 9.4 for more details. However, on existing systems it is usually possible to
examine alarm performance data to identify various types of problematic alarms.

2 Normative references
ANSI/ISA–18.2–2016 Management of Alarm Systems for the Process Industries [ISA-18.2]
ISA-TR18.2.2-2016 – 14 –

ISA-84.00.01-2004 (IEC 61511 Mod) Part 1 Functional Safety: Safety Instrumented Systems for
the Process Industry Sector – Part 1: Framework, Definitions, System, Hardware and Software
Requirements [ISA-84]

IEC 62682 Management of Alarm Systems for the Process Industries, International Electrotechnical
Commission, Edition 1.0 (2014)

3 Definition of terms and acronyms

3.1 Definitions
For the purposes of this technical report, applicable terms defined in 3.1 of ISA-18.2 are used as defined in
ISA-18.2. For ease of reference, these are repeated in this section. No new definitions are needed for this
technical report.

3.1.1 Activate
The process of enabling an alarm function within the alarm system.

3.1.2 Advanced alarming

A collection of techniques (e.g., state-based alarming, and dynamic prioritization) that can help manage alarm
rates in specific situations.

3.1.3 Alarm
An audible and/or visible means of indicating to the operator an equipment malfunction, process deviation, or
abnormal condition requiring a response.

3.1.4 Alarm attributes (Alarm parameters)

The settings for an alarm within the process control system (e.g., alarm setpoint, alarm priority).

3.1.5 Alarm class

A group of alarms with common alarm management requirements (e.g., testing, training, monitoring, and audit
requirements).

3.1.6 Alarm flood (Alarm shower)

A condition during which the alarm rate is greater than the operator can effectively manage (e.g., more than 10
alarms per 10 minutes).

3.1.7 Alarm management (Alarm system management)

The processes and practices for determining, documenting, designing, operating, monitoring, and maintaining
alarm systems.

3.1.8 Alarm message

A text string displayed with the alarm indication that provides additional information to the operator (e.g., operator
action).

3.1.9 Alarm philosophy

A document that establishes the basic definitions, principles, and processes to design, implement, and maintain
an alarm system.

3.1.10 Alarm priority

The relative importance assigned to an alarm within the alarm system to indicate the urgency of response (e.g.,
seriousness of consequences and allowable response time).
  15  ISA-TR18.2.2-2016

3.1.11 Alarm setpoint (Alarm limit, Alarm trip point)

The threshold value of a process variable or discrete state that triggers the alarm indication.

3.1.12 Alarm system

The collection of hardware and software that detects an alarm state, communicates the indication of that state to
the operator, and records changes in the alarm state.

3.1.13 Alert
An audible and/or visible means of indicating to the operator an equipment or process condition that requires
awareness, that is indicated separately from alarm indications, and which does not meet the criteria for an alarm.

3.1.14 Allowable response time

The maximum time between the annunciation of the alarm and the time the operator must take corrective action
to avoid the consequence.

3.1.15 Bad measurement alarm

An alarm generated when the signal for a process measurement is outside the expected range (e.g., 3.8mA for a
4-20mA signal).

3.1.16 Call-out alarm

An alarm that notifies and informs an operator by means other than, or in addition to, a console display (e.g.,
pager or telephone).

3.1.17 Chattering alarm

An alarm that repeatedly transitions between the alarm state and the normal state in a short period of time.

3.1.18 Classification
The process of separating alarms into classes based on common requirements (e.g., testing training,
monitoring, and auditing requirements).

3.1.19 Console
The interface for an operator to monitor and/or control the process, which may include multiple displays or
annunciators, and defines the boundaries of the operator’s span of control.

3.1.20 Control system

A system that responds to input signals from the equipment under control and/or from an operator and generates
output signals that cause the equipment under control to operate in the desired manner.

NOTE The control system may include both Basic Process Control Systems (BPCS) and Safety Instrumented Systems (SIS).

3.1.21 Dynamic alarming

The automatic modification of alarms based on process state or conditions.

3.1.22 Enforcement
An enhanced alarming technique that can verify and restore alarm attributes in the control system to the values
in the master alarm database.

3.1.23 Highly managed alarm

An alarm belonging to a class with more requirements than general alarms (e.g., a safety alarm).

3.1.24 Implementation
The transition stage between design and operation during which the alarm is put into service.
ISA-TR18.2.2-2016 – 16 –

3.1.25 Instrument diagnostic alarm

An alarm generated by a field device to indicate a fault (e.g., sensor failure).

3.1.26 Master alarm database

The authorized list of rationalized alarms and associated attributes.

3.1.27 Nuisance alarm

An alarm that annunciates excessively, unnecessarily, or does not return to normal after the correct response is
taken (e.g., chattering, fleeting, or stale alarms).

3.1.28 Operator (Controller)

The person who monitors and makes changes to the process.

3.1.29 Plant state (Plant mode)

A defined set of operational conditions for a process plant (e.g., shutdown, operating).

3.1.30 Prioritization
The process of assigning a level of operational importance to an alarm.

3.1.31 Rationalization
The process to review potential alarms using the principles of the alarm philosophy, to select alarms for design,
and to document the rationale for each alarm.

3.1.32 Return to normal

The indication an alarm condition has transitioned to the normal state.

3.1.33 Safety alarm

An alarm that is classified as critical to process safety or the protection of human life.

3.1.34 Shelve
A mechanism, typically initiated by the operator, to temporarily suppress an alarm.

3.1.35 Stale alarm

An alarm that remains in the alarm state for an extended period of time (e.g., 24 hours).

3.1.36 Standing alarm

An alarm in an active alarm state (e.g., unack alarm, ack alarm)

3.1.37 State-based alarm (Mode-based alarm)

An alarm that is automatically modified or suppressed based on process state or conditions.

3.1.38 Suppress
Any mechanism to prevent the indication of the alarm to the operator when the base alarm condition is present
(i.e., shelving, suppressed by design, out-of-service).

3.1.39 Suppressed by design

A mechanism implemented within the alarm system that prevents the transmission of the alarm indication to the
operator based on plant state or other conditions.
  17  ISA-TR18.2.2-2016

3.1.40 System diagnostic alarm

An alarm generated by the control system to indicate a fault within the system hardware, software or components
(e.g., communication error).

3.1.41 Tag (Point)

The unique identifier assigned to a process measurement, calculation, or device within the control system.

3.2 Acronyms
BPCS: Basic Process Control System
cGMP: current Good Manufacturing Practice
EEMUA: Engineering Equipment and Materials Users’ Association
FMEA: Failure Modes and Effects Analysis
HAZOP: Hazard and Operability Study
HMI: Human-Machine Interface
IPL: Independent Protection Layer
ISA: International Society of Automation
ISO: International Organization for Standardization
LOPA: Layer of Protection Analysis
MADB: Master Alarm Database
MOC: Management of Change
OSHA: Occupational Safety and Health Administration (US government)
P&ID: Piping (or Process) and Instrumentation Diagram
PHA: Process Hazards Analysis
PSM: Process Safety Management
SIS: Safety Instrumented System

4 Project scoping
4.1 Approaches to identification and rationalization
Identification and rationalization can be done in either a comprehensive or staged approach. In
facilities with multiple processes or units, it is a good idea to do these activities one area at a time
in order to form teams with a limited scope for both focused effort and overall time effectiveness .

For facilities where alarm management is being applied for the first time, a pilot project approach
may be beneficial so that the identification and rationalization processes can be fine-tuned before
starting on the bulk of the effort. A work plan (including needed resources) should be developed
and documented in the alarm philosophy before embarking on an identification and rationalization
effort.

5 Identification
5.1 Purpose
Identification is one of the stages of the alarm management lifecycle defined in ISA-18.2. Identification is
also a general term for the different methods that can be used to determine the possible need for an alarm
or a change to an alarm. The output of identification is a listing of proposed alarms that become the input
for the rationalization stage of the lifecycle.

Alarms may be recommended by or identified from a number of different sources. In some cases it will be
important to know the source of the alarm for the rationalization process (especially for use in setting
classification).

5.2 Relationship between identification and rationalization

In the identification life cycle stage, the conditions that likely need alarms are identified and
documented, and alarms are proposed. The rationalization stage determines if the alarm is justified
ISA-TR18.2.2-2016 – 18 –

in accordance with the alarm philosophy and, if so, documents the alarm and its attributes. This is
true for both modifications to existing and creation of proposed new alarms.

An individual or team identifying a potential alarm should be aware of the basic definition and requirements
of an alarm according to ISA-18.2 and the facility’s alarm philosophy. For example, an alarm should not be
recommended if it does not indicate an abnormal condition or does not require an operator response to
avoid a consequence.

5.3 Examples of identification sources

5.3.1 Existing alarms
For units (or process areas) that are operational, most alarms will be identified by virtue of being alarmed
currently. Most BPCS include a documentation function that allows either a printed or electronic output of
the existing alarms and their associated attributes. A facility may maintain a database of alarms separately
from the control system. The database may be an instrumentation-specific database or a more generic
system. For new units, the candidate alarms should be assembled from operational units of comparable
type. Preferably the comparable unit used to generate this list has undergone the alarm rationalization
process.

Another consideration for both existing and new units is that all available alarms should be considered in an
initial rationalization, whether or not a particular alarm actually exists. Otherwise, alarms that do not exist
but would be valuable might be missed. Most control systems have a standard list of alarms that are
configurable for any given tag type.

Many of the existing alarms may have been originally added as a result of activities such as process safety
management, review of environmental permits, incident reports, quality objectives, control system design,
and/or other processes. However, this background information may not be immediately apparent in some
existing alarm systems - as part of identification (or done later as part of rationalization) - these
documentation links may need to be identified and recorded.

5.3.2 Process safety management (PSM)

Several jurisdictions may have specific regulations with regard to process safety management. For example,
the USA has OSHA 1910.119. Activities and documentation that are prescribed by PSM regulations can
frequently be a source of recommended or required alarms for a process. Some of the typical kinds of
activities that can be found in PSM regulations are described below:

a) Process Hazards Analysis (PHA): A common PHA methodology is Hazards and Operability Study
(HAZOP) – A HAZOP studies potential process deviations, their causes and consequences, to
identify potential hazards associated with a process. Available and necessary safeguards are
identified to help protect against the identified hazards. Often, the HAZOP team might identify
operator response to an alarm as a necessary safeguard. In addition, a Layer of Protection Analysis
(LOPA) may be performed subsequent to or in conjunction with a PHA. This analysis delves into a
potential hazard scenario in more detail, to determine if the existing independent protection layers
(IPL) are sufficient to reduce the risk of a catastrophic event to very low and tolerable levels.
Operator response to specific alarms might be identified in a LOPA as a designated IPL.

b) The establishment of safe operating limits of the process is mandated by the regulation. Alarms may
be appropriate to warn operators of impending or actual breaches of safe operating limits.

c) Alarms for equipment protection may be identified through the mechanical integrity or reliability
process. Alarms may be appropriate to warn operators of impending or actual breaches of reliability
operating limits.

5.3.3 Failure modes and effects analysis (FMEA)

FMEA is typically applied to new plant and process designs, as well as plant operations, maintenance,
computer systems, etc. It is a risk reduction technique by which failure modes are identified and then
  19  ISA-TR18.2.2-2016

analyzed with respect to severity, frequency, and detectability. Alarms are a means of improving detectability
of an abnormal situation and are often implemented as a result of the FMEA analysis.

5.3.4 Environmental permits

Environmental permits may be used to identify alarms to notify the operator when the process is approaching
or exceeding allowable permit limits. For example, furnace flue gas composition and effluent water quality
analysis are two process variables where alarms may be applied. These alarms may be subject to special
requirements discussed under classification. Environmental permit alarms may necessitate calculations
performed within the control system, such as estimation of emission flow rates and time weighted averages.

5.3.5 Incident reports

Incident investigation reports may recommend the addition or modification of an alarm or alarms to prevent
the reoccurrence of the incident. The recommendations may include specific alarm sources, alarm settings
and alarm priorities. A general caution is that additional alarms are often recommended in an incident report,
even if alarm overload was one of the cited contributing factors that led to the incident.

5.3.6 Quality
There are several national and international standards and regulations (e.g, cGMPs, ISO) that address
aspects of product quality. For companies covered by such standards and regulations, it is common that
audits are conducted, both by the target company and by the issuing organization. A review of recent audits
may reveal opportunities or needs for better detection and recording of certain process deviations
(associated with product quality) via use of alarms. For example, both cGMPs and ISO standards require
that affected companies have documented evidence that their processes are "in control" particularly with
respect to those process parameters that may affect product quality. Many companies choose to utilize an
alarm system to help achieve processes that are "in control" - which includes quickly detecting and
responding to deviations. These same principles are commonly applied in non-covered processes where
product quality can be tied to significant financial consequences.

5.3.7 Control objectives

For selected process measurements, alarms may be established to provide specific operator guidance for
process performance. Care should be taken to be sure that this is truly an alarm (meeting the ISA-18.2
definition of alarm), as opposed to an alert. Most controlled variables will likely have some sort of alarm to
indicate that the controller is not able to achieve its desired function. However, not all measured or controlled
variables need to be alarmed.

5.3.8 Project documentation

During the design of a project, the project team may identify alarms that are deemed to be important to
process operation. For a licensed process, the licensor may have established required or recommended
alarms that are necessary to keep the license guarantees in force. These alarms might be shown initially on
the project process flow diagrams, piping and instrument diagrams, or other project documentation. P&ID
reviews will be conducted periodically during project development and design. The review team might
determine that particular alarms may be needed to maintain process control objectives, maintain product
quality, or for other process reasons. Alarms identified during P&ID reviews are typically associated with
direct process measurements and controls depicted thereon.

5.3.9 Operating procedure reviews

A team reviewing operating procedures for existing plants, new plants, or plant modifications might
determine that certain alarms will aid in maintaining safe and efficient operation. Alarms identified
in this fashion will typically be designed to maintain operation within established limits.

5.3.10 Packaged system manufacturer recommendations

Often, a packaged system with its own dedicated control panel intended for a specific purpose
(such as refrigeration, compression, drying, demineralization, etc.) will be included within a larger
plant or unit design. The manufacturer of the packaged syste m may recommend or require certain
ISA-TR18.2.2-2016 – 20 –

alarms to be in place in order to keep the equipment warranty in force. These alarms will usually
be designed for equipment protection, but may also impact product quality. Further details on
dealing with packaged system alarms are included in TR7.

5.3.11 Alarm philosophy

It is common for an alarm philosophy document to predetermine and specify a variety of alarms
and alarm strategies for certain conditions. This has the effect of pre -rationalizing those alarms,
eliminating the need for further individual discussion of them. The rationalization effort ensures that
those alarms will exist on the system, and are documented in the master alarm database. Examples
of such alarms include the following.

a) The philosophy may pre-determine alarms for which operator response affects personnel
safety. The philosophy could state that all safety shower/eyebath stations will alarm when
activated, and the alarm will utilize High Priority. This is because the operator’s immediate
dispatching of aid to that location is important to mitigate possibly injury. Similar situations
include the activation of any ambient toxic or flammable gas sensors, manual emergency
stop buttons on conveying systems, and similar situations.

b) The philosophy may pre-determine the alarming of instrument failure in a consistent

manner, such as by stating that all analog inputs are to have an alarm that activates when
the measurement has become invalid (e.g., loss of signal, out of range, bad quality), and
that Diagnostic Priority is used for such conditions.

c) The philosophy might predetermine limitations on the use of High -Hi/Hi and Low-Lo/Lo
alarm combinations.

d) The philosophy may specify specific and consistent methods and strategies for the alarming
of redundant sensors that input into voting interlock systems.

5.4 Identification documentation

The output of the identification work process is a list of proposed alarms that will be used as input
to the rationalization work process. For existing facilities, the list may typically consist of all of the
existing alarms plus a list of proposed additional alarms. For new facilities, the list will consist
entirely of proposed alarms for the new process area(s).

There are various methods to document the list of proposed alarms from identification. Often a
spreadsheet, database, or similar software tool is used. At a minimum, each proposed alarm should
be assigned a unique identifier (e.g., tag), a brief description of what process condition it is meant
to annunciate, and a notes field where any additional details noted during identification can be
recorded. Another field may also be added to include a drawing or document reference that
identifies the origin of the alarm idea. Often a master alarm database template with additional
fields added for identification can be used. Clause 9, master alarm database, contains additional
guidance.

Ideally, proposed alarms should be assigned unique properly-formed identifier tags, in accordance
with the facility’s tagging scheme, as part of identification. However, placeholder tags may be used
if a new facility's final tagging scheme has not yet been fully developed. If alarm tags are not yet
fully developed as part of the identification work process, this task should be done as part of
rationalization to ensure there is no confusion.

In existing facilities, existing alarms may be poorly documented. Prior to rationalization group effort,
it may be advantageous to determine the process alarm design basis , so that the rationalization
work process can proceed efficiently. This can be a time-consuming activity.
  21  ISA-TR18.2.2-2016

6 Rationalization
6.1 Purpose
Rationalization is the process by which every alarm from the identification life-cycle step is compared to the
criteria in the alarm philosophy to verify that it should be an alarm. The objective is to ensure that every
alarm is an indication of an abnormal condition requiring operator response, and that every abnormal
condition requiring operator action is appropriately alarmed (i.e., not too many or too few alarms). The
following sections describe common methods to complete an alarm rationalization.

Appendix A contains a list of common pitfalls/challenges that are often encountered in the rationalization
process.

6.2 Preparation
Alarm rationalization is typically done as a group activity; however, several tasks should be
completed prior to assembling the group.

6.2.1 Obtain alarm philosophy

Since rationalization entails comparison of an alarm to the criteria in the philosophy document, the
alarm philosophy needs to exist, be studied, and available to the group. If a philosophy has not
been created, see TR1 for guidance on the creation of an alarm philosophy document.

6.2.2 Determine rationalization approach and scope

Rationalization can be done in either a comprehensive or staged approach. The comprehensive
approach would be the application to all alarms at one time. This approach has both the greatest
benefit and greatest resource demand.

The staged approach is to apply the material to a logical subset of alarms. For example, one major
oil company chose to rationalize just their existing highest priority alarms on all process units at a
refinery before working on the lower priority alarms. This approach prolongs the r ationalization
effort for any unit, but ensures that all the highest priority alarms are addressed sooner. The major
pitfall of the staged approach is that the effort can stall at a particular stage and not be completed.
Other pitfalls include (a) the staged approach is not amenable to advanced alarms and (b) can lead
to an inefficient and possibly incomplete rationalization. In addition, the staged approach (a) may
ignore alarms that do not currently exist but might be appropriate, and (b) might delay consideration
of alarms that should be higher priority but are configured as a lower priority.

6.2.3 Identify team/personnel

Rationalization should be performed by representatives with the knowledge and skills listed below.
In some cases, one person may have the knowledge from several different areas. More specialized
personnel can attend on an as-needed basis.

[Link] Full time skill sets

Personnel with the following skill sets should be considered as full time members of the team:
a) process engineering (production engineers, operations engineers) familiar with the process
workings, economics, and with the control system;
b) operations (operators, controllers, operating technicians, trainers, operating supervisors),
preferably two operators from different shift teams with experience in use of the control
system;
c) process control (process control engineers, instrumentation engineers) ;
d) experienced alarm rationalization facilitator, knowledgeable in alarm management
principles and practices, with background in areas such as human factors, process
engineering, operations, or control systems; and without vested interest in the previous
configuration;
ISA-TR18.2.2-2016 – 22 –

e) scribe (this depends upon the database and computer skills of the other fulltime members);
f) regulatory compliance (may only be needed for certain processes in highly regulated
industries or industries with certain types of operating permits) .
[Link] As-needed skill sets
The team should be supplemented as needed by personnel with the following skill sets on an as -
needed basis:
a) safety and environmental;
b) maintenance/equipment reliability (usually when specific equipment is being discussed) ;
c) management (may only need to be involved in the kick-off meeting and MOC process);
d) instrumentation/analyzer specialists;
e) electrical and rotating equipment engineers;
f) metallurgical and other specialized disciplines;
g) knowledge of product quality requirements (e.g., cGMPs).
6.2.4 Analyze alarm system performance (for existing control system)
A history of alarm system activity and characteristics can be usefu l during the rationalization
sessions. Operator interviews / audits can also be used to establish alarm management issues.
Several months of alarm data is typically needed to capture the range of plant operations needed
to assess alarm problem areas. The data should be reviewed to identify

a) bad actors;
b) standing alarms;
c) highly correlated/duplicate alarms (alarm sequences).
More information on obtaining this information is contained in TR5.

6.2.5 Prepare master alarm database

The results of rationalization should be entered into a master alarm database (MADB). A database
of all tags in the process control system, and their possible alarms , is needed. Set-up of this
database will need to occur prior to the group sessions. The list of alarms to be rationalized comes
from the previously completed identification work process. Clause 9 contains a more detailed
discussion of the MADB.

An initial review of the master alarm database may be warranted prior to the rationalization
sessions. The purpose of the review is to identify systematic trends, deficiencies, and issues in
alarm identification. For example, if all temperature alarms have a high, hi-hi, low, and lo-lo alarm,
then the rationale behind this (if any) should be investigated prior to the group meetings. Or, if the
alarm priorities skew heavily to the highest priority category, then investigation prior to the group
sessions may be worthwhile.

6.2.6 Assemble process analyses

Different processes impose different requirements on rationalization. Operational details of the
process are needed, including normal process variables and their tolerable limits. If these vary
depending on factors such as operating mode, batch stage or recipe, then details of each variant
are needed. For batch processes, it is likely that the different phases of the batch and/or recipe
demands will need to be known.

6.2.7 Assemble reference documents

Having relevant process documentation on-hand during rationalization is critical to the process.
Some types of documentation can be more easily shared between meeting participants. Certain
documents, such as the P&IDs, should be available in multiple copies. The major pieces of
documentation that are typically used for rationalization include the following:
  23  ISA-TR18.2.2-2016

a) P&ID;

b) hazard and risk analysis (e.g., PHA, HAZOP, FMEA) reports;

c) LOPA results and safety requirements specifications;

d) safe operating limits;

e) equipment design parameters, such as temperature, pressure and capacity;

f) interlocks/cause-effect diagrams;

g) environmental/other permits;

h) production/quality targets;

i) key operating procedures;

j) complex loop documentation;

k) operating graphics (on-line or hardcopy);

l) incident reports;

m) access to process historical data;

n) task checklists;

o) process narrative or description;

p) manufacturer/licensor alarm requirements/recommendations;

q) instrument parameters such as span and response time.

6.2.8 Kick-off meeting

Since it is important for (a) management support to ensure resource availability (operators,
engineers) and (b) management understanding of the results of the rationalization, a kick-off
session is used to acquaint management and all other interested parties as to the reasons for,
method, and potential results of the rationalization process.

A review of current alarm system performance usually confirms the ne ed for improvement. A
presentation on the basis for alarm rationalization, as well as examples of past rationalizations, will
assist the group in understanding the overall intent of the effort. Requirements for participation by
specialists can be discussed as well as any concerns different plant groups might have regarding
alarm removal or addition.

The kickoff meeting can include the first part of the rationalization team training. Having the kick-
off meeting prior to the rationalization sessions enables any potentially serious issues, such as a
manager questioning the philosophy or authority of the rationalization effort, to be resolved prior to
rationalization of any alarm.

6.2.9 Train rationalization team

Prior to the commencement of the actual rationalization sessions, it may be useful to conduct a
brief training session on alarm rationalization to all likely participants. This would include full and
part time members, as well as anyone in the organization that may be impacted by the results (e.g.,
safety, instrument maintenance, operations). The course should cover the following:
ISA-TR18.2.2-2016 – 24 –

a) Objectives / Goals – These should be clearly stated such that each member of the
rationalization team has an understanding of why the effort is being undertaken and what
the results of the effort hope to achieve.
b) Methodology – The actual process to be used during the sessions should be explained to
all participants. This includes how the Alarm Philosophy is applied, how the need for alarms
is determined, how alarms are prioritized, any advanced alarm techniques to be employed,
etc.
c) Roles and Responsibilities – Each member of the team has certain responsibilities during
the rationalization effort. These should be explained and agreed upon prior to commencing
the rationalization sessions.
d) Scope – Each member of the rationalization team should have a clear understanding of
what is within the scope of rationalization sessions. This is to ensure that the meetings
focus on the alarm system and the team does not get sidetracked by trying to improve or
redesign the actual control system.
e) Progress – Expectations of daily progress and overall effort duration should be set ahead
of the rationalization sessions. Team members should be aware that progress is to be
tracked and reported back to management periodically.
f) Alarm Design – Ensuring that team members are aware of the available alarm types and
alarm attributes (e.g., setpoint, on-delay, off-delay, deadband, priority, routing, etc.) and
how they can be used to design effective alarms. Includ ing an overview of the control
system and alarm system capabilities may be worthwhile.
6.3 Location and facilities
The rationalization sessions can be intense and at times tedious. Choosing the appropriate location will help
keep members focused and on track.

a) The location should not be somewhere where the participants can be frequently interrupted
(e.g., control room).
b) The location should be one which is designated for the sole use of the rationalization team
for the duration of the effort. It is very disrupti ve to have to pack up all materials to move
to another location because the meeting room is booked for another meeting.
Like the location, the facility needs to be conducive to group discussions of technical issues.

a) Large center table with chairs surrounding it – not a classroom style layout.
b) A computer for access (remote if required) to the process and alarm historical data and if
possible, process control HMI screens (with live process data or screenshots). It is not
necessary for everyone in the room to be sitting in front of a computer. Have this computer
hooked up to a projector to allow everyone to see what is being shown.
c) A single computer hooked up to a projector for the facilitator (or scribe). This computer
should have the master alarm database and will be used as the primary interface for
recording all results from the rationalization discussions.
d) Large white board or flip chart (with appropriate markers, erasers, etc.) to sketch systems,
capture thoughts and ideas.
6.4 Roles and responsibilities
6.4.1 Facilitator
Success of the rationalization depends heavily upon the capability of the facilitator. Their key role
in the activity includes the following.

a) Keep the rationalization moving – Since a rationalization can be expected to cover anywhere
from 1000 to 5000 alarms, it is imperative to keep the process moving. It is the facilitator
who maintains the balance between adequate discussion on alarms and progress toward
  25  ISA-TR18.2.2-2016

addressing all the alarms. Sometimes ancillary discussions are both needed and lengthy;
however, it can often degrade into “story telling”.

b) Enforce/Interpret alarm philosophy – The foundation of the rationalization is the alarm

philosophy or selection criteria. Although this should have been accepted and read at the
beginning of the rationalization, it is the facilitator who must enforce and interpret the
philosophy. Although everyone agreed to the philosophy, the group can often stray and the
facilitator may need to re-review the philosophy. Sometimes, exceptions to the philosophy
are needed and should be documented as such.

c) Suggest better ways to handle alarms – The facilitator needs to be sensitive to alternate
methods to achieve both operational and alarm objectives. Plant personnel often overly
accept the alarm system as it is currently designed.

d) Capture generic issues – The facilitator also needs to be sensitive to issues that apply
beyond a particular alarm. In discussing a particular alarm, general classes of problems will
become apparent and need to be captured. A comprehensive alarm philosophy will cover
many such situations, but not anticipate all of them.

e) Ensure consistency – The facilitator is present to ensure consistency, both during the
rationalization and after. During the course of the rationalization, the facilitator needs to
point out if related alarms are not being handled in the same fashion or if the alarm
guidelines are not being consistently applied.

f) Challenge team decisions – If the necessary expertise is not present to truly assess the
required alarm or alarm characteristics, the facilitator should note the need to call in the
needed discipline.

6.4.2 Core team members

In addition to their expertise on the process and/or control system, the core team members can be
given additional responsibilities, including:

a) Check documentation – One team member could be assigned to determine if the alarm is
referenced in relevant documentation (e.g., PHA, cause-and-effect, etc.) and access any
information related to it.

b) Track progress – Since the rationalization will initially be done addressing all the tags on a
drawing, one team member could keep track of what has been covered and what remains
to be addressed. While marking alarms rationalized on each P&ID or BPCS screen -print is
useful, numerous alarms may be present that are not on a drawing. A separate list of
identified alarms can be useful to ensure that all related alarms are addressed at the same
time. See Clause 9 on MADB for more information.

c) Mark drawing changes – It is common to find drawing errors during the course of the
rationalization. One member could keep a red-lined drawing to capture errors.

d) Maintains action item list –This would cover additional research needed to properly
determine alarm settings, or questions requiring technical expertise that is not currently
present in the meeting. One team member could track these for assignment or review.

6.5 Alarm rationalization process

The first task of the rationalization session is for the team to read the site’s alarm philosophy. This
ensures that all team members understand the goal in alarm management, part icularly how alarms
are to be selected and prioritized. It is also beneficial to study the alarm configuration data and
alarm options.
ISA-TR18.2.2-2016 – 26 –

It is a generally effective rationalization approach to work through the process from the flow of the
P&IDs or graphic displays, rationalizing all instruments and controls in a given area together. (Note
that rarely are all alarms on the P&ID; the control system configuration is the reliable source data
for configured alarms.) If the process has identical or redundant equip ment/systems (e.g., parallel
trains, multiple compressors), then one can be done in the group session with the alarms copied to
the duplicates outside the group session.

Each identified alarm is evaluated according to the following steps and results docum ented for
every applicable process state. Note that for batch applications there are typically several such
states.

6.5.1 Justify alarm

Every existing and proposed alarm is reviewed to ensure that it meets the basic requirements for
an alarm in the alarm philosophy, such as:

a) The alarm indicates a malfunction, deviation, or abnormal situation .

b) The alarm represents a situation requiring timely operator action in order to avoid defined
consequences.

c) The alarm is the best indicator of the cause of the abnormal situation (i.e., multiple alarms
from the same condition should be avoided).
When the validity check indicates an existing alarm is not needed, the rationale for deletion is
documented. In some cases, an alarm may fail to meet the above requirements, yet be required to
exist by pre-existing methodologies such as PHAs or HAZOPs. Removal of such alarms may require
several administrative steps.

There may be resistance from a team member to alarm removal due to a desire to still have the
status condition visible. This can usually be accomplished by ensuring the condition is indicated
in the HMI, rather than via the alarm system. Other options can include status indicators on HMI
screens, operator alert systems, and creation of log-only events that can be used for later
troubleshooting.

6.5.2 Determine consequence of inaction

Document the immediate and proximate consequences of insufficient operator response (or
ineffective response) to the alarm. The consequences should assume the condition alarmed
continues or gets worse. This essentially defines the purpose of the alarm. For example, the
consequence of a high level alarm at 80% should be evaluated as if the level were to c ontinue to
increase, filling the vessel. Check whether the consequence will result in another alarm or SIS
action. If the consequence is less than the minimum threshold defined in the alarm philosophy
document, then the alarm should be marked for removal and document the basis.

The alarm rationalization is neither a PHA nor a probabilistic risk assessment. Different from a
PHA, the consequence defined during a rationalization is that which the operator can directly
prevent (the mitigated consequence) as opposed to the ultimate (unmitigated) consequence. The
assumption should be that no failures other than what may have caused the alarm are present.
Safety instrumented systems and relief valves should be assumed to function in identifying the
consequences.

6.5.3 Estimate allowable response time

Document the time allowed for the operator to respond to the alarm. This is the duration available
for the operator to take successful action, from when the alarm occurs to when the consequence is
no longer avoidable. This may play a role in priority determination. If there is not sufficient time for
the operator to respond, the alarm should be redesigned if possible. This could be as simple as
changing the alarm setpoint to allow for more response time. If this is not an op tion, perhaps another
process measurement would provide a more timely warning against the consequence in question.
  27  ISA-TR18.2.2-2016

If this is for an existing alarm, then mark for modification and document the basis. If no redesign
options are available, then it may be appropriate to remove the alarm.

Estimating allowable response time can be challenging. Operators often confuse the allowable
response time with how long they should wait to respond. Their answer to the latte r is that they
should respond right away. Another issue is that most alarms reflect passing a threshold and not
how fast the variable is changing. So allowable response time can be based upon a worst-case
rate of change, a typical rate of change, or a rate of change related to the probable cause of the
alarm.

Allowable response time can seldom be calculated precisely. For that reason, it is usually best to
use operations experience rather than engineering principles for this determination. Also, allowable
response time is usually documented as a range rather than a fixed number. Usually, this is one of
the ranges used for prioritization (see 7.1).

6.5.4 Document the alarm’s root cause(s)

Document the likely root causes of the process condition that would result in the alarm. The list of
events should either be the likely events that this alarm is to identify or something that is unique
about this alarm versus all others. While an alarm for a trip of minor electric pump could be caused
by a loss of power to the unit, it is unlikely that the purpose o f such an alarm would be to alert the
operator to a unit-wide power failure. Not every cause needs to be documented, so lengthy
investigations into low probability causes should be avoided. Documenting the cause of an alarm
can be helpful for determining the appropriate operator response.

6.5.5 Document the operator corrective action(s)

Document the operator actions to take in response to the alarm. The actions should be objective,
using action verbs such as start/stop or raise/lower. The actions can either be through the control
system, through action in the field accomplished by the operator receiving the alarm, through
instruction to field personnel, or through consultation with others. It is useful to look down the list
of causes to help identify potential actions, although there will rarely be a one-to-one
correspondence. Some events require multiple actions while in other cases multiple events result
in the same action. It is often necessary to distinguish between confirming/verifying actions (i.e.,
what the operator might check to determine the alarm condition is true, such as local or other
control system indications) and corrective actions. It is the latter that satisfy the criterion of the
alarm prompting an action. Sometimes the underlying events are so complex (e.g., major equipment
trip) or the alarm is so general (e.g., common trouble) that “troubleshoot to determine exact cause
and solution” is a reasonable corrective action response.

The corrective actions can be made available for operator reference in an alarm response
procedure. See the discussion on information linking and dynamic cause analysis in TR4 for a more
detailed discussion of how this is done.

6.5.6 Assign alarm priority

Alarm priority is a tool for the operator to differentiate relative levels of urgency in active alarms.
There are a variety of logical methods for designating alarm priority. The details of the methodology
chosen should be documented in the alarm philosophy document (for additional guidance see TR1).
A more detailed discussion of how to assign alarm priorities is provided in Clause 7.

6.5.7 Determine the alarm setpoint or logical condition

The alarm setpoint should be (a) far enough away from the consequence threshold such that the
operator has sufficient time to act and (b) not so close to the normal process value as to cause
nuisance alarm annunciations as a result of normal process variations. Examination of process
history is highly valuable for this determination.

Be careful about selecting an alarm setpoint at or near the range limit of the instrument, as some
instruments are often less accurate at the extremes and the alarm may not occur when needed. If
ISA-TR18.2.2-2016 – 28 –

the desired alarm setpoint is near, at or beyond the instrument range, then an instrument re -range
is usually preferable to compromising on alarm setpoint.

Assigning the correct logical condition for a digital or discrete alarm is an important consideration.
The rationalization team is responsible for this determination as well.

The core rationalization team may not be able to select an alarm setpoint or logical condition with
confidence. Those setpoints that need further input from a specialist should be identified and
forwarded to the correct individuals to determine/validate the alarm s etpoint. There are a number
of special cases for which additional factors need to be considered in setting alarm setpoints. See
TR4 and TR6 for more information on these special cases

6.5.8 Assess need for special handling

Some alarms may require special handling to meet the criteria in the alarm philosophy and should
be identified at this time. This may include for different plant states (start -up, shutdown, or
equipment trip) changing the alarm parameters (setpoint and priority) and/or suppression of alarms.
For example, if the alarm would remain in the “Active” state for a long period (a standing alarm) in
violation of the alarm philosophy, then logic required to prevent this from occurring should be
identified at this point, for detailed specification in the d etailed design stage. A more detailed
discussion of these advanced alarming techniques is discussed in TR4.

6.5.9 Alarm shelving

Alarm shelving is an example of where special handling may be required. For some alarms, it may be
determined that as part of rationalization that the ability to shelve these alarms may need to be restricted or
enhanced. The ability to shelve an alarm can also be determined by the alarm's classification - see Clause
8 for further information about alarm classification.

6.5.10 Assign alarms to class

Based on the alarm’s identification and consequence of inaction, assign the alarm to a class
following the class criteria in the alarm philosophy. A more detailed discussion is provided in Clause
8 of this technical report.

6.5.11 Review results

Because the rationalization will occur over several days/weeks and not all alarms will be on
drawings/displays, a review step will be needed. The purpose is to ensure consistency in how
alarms are handled and flag any alarms not justified. Creation of alar m reports showing priorities
and/or consequences for alarms will allow inconsistencies and omissions to be spotted and
corrected.

7 Prioritization
Alarm rationalization includes the task of prioritization. Alarm priority helps the operator to know
which alarm to address first, enabling operators to focus on more urgent alarms before the less
urgent. If only one alarm ever actuated at a time, priorities would not be needed. However, when
multiple alarms annunciate in a short period of time, alarm priorities become an essential tool.

The greatest number of alarms should be of the lowest priority, with successively fewer in each
higher level of priority. A well-tested and proven approach to priority selection involves some
combination of

a) The severity of the consequence that will occur if the operator response is late or
inadequate;

b) The time available for the operator to make a correct response before the consequence
becomes unavoidable.
  29  ISA-TR18.2.2-2016

The method for assigning alarm priorities should be documented in the alarm philosophy (see TR1
for guidance on the creation of an alarm philosophy document). The intent is that alarm priorities
are assigned in a consistent manner. Two commonly used methods for assigning alarm priorities
are described in the following two sections. Other methods exist and can be used if consistent
results are produced.

7.1 Consequence/allowable operator response time method

A commonly used prioritization method is a matrix based on (a) the consequence of the alarm if it
receives inadequate or no corrective action and (b) the amount of time that an operator has to
respond to avoid the consequence. An example of one such matrix is shown in Table 1. The matrix
is used by first selecting the main type of consequence of inaction or incorrect action
(Personnel/Safety, Public/Environmental/Safety, or Asset/Damage/Cost/etc.), then selecting the
severity of the likely consequence (Minor, Major, Severe). Having selected the severity, the
corresponding time to respond determines the recommended alarm priority. It is important that the
matrix reflect company criteria and business importance so that priority indicates which alarm is
more important from the business’s perspective.

The example shown in Table 1 is just one example of how to do prioritization. Different variations
of this table can be developed that use either qualitative or quantitative criteria. Further examples
of prioritization methods can be found in the Bibliography under EEMUA191, Hollifield and Habibi,
and Rothenberg.
ISA-TR18.2.2-2016 – 30 –

Table 1  Example of consequence/operator response time prioritization

Proximate Consequence of Inaction or Incorrect Action
Type of
Consequence
MINOR MAJOR SEVERE

Personnel Any alarm for which operator action is the means by which harm to a person is
Safety avoided will utilize High Priority. For a listing of such alarms, see the Alarm
Philosophy.

Public, Local environmental Non-permanent damage Uncontained release of

Environ- effect, contained from contamination, hazardous materials with
mental, Safety release, minor cleanup single exceedance of significant environmental
statutory or prescribed and/or 3rd party impact
Internal or routine limit or publicity
reporting requirements
only Reporting required at the Extensive cleanup
local or state agency measures and financial
Fault with safety level consequences
related systems
Low level gas release Immediate danger to life
and health

Asset Event or lost Event or lost production

Event or lost production
Damage, production costing costing $10,000 to
costing >$100,000
Cost, <$10,000. $100,000
Efficiency,
Extensive outage,
Downtime, Minor efficiency impact Significant efficiency
potential equipment
Lost or quality excursion. loss, multiple unit impact
damage
Production,
Quality, Reporting required only Reporting required at the
Destruction of assets
at the department level site level

Allowable
Event has only minor Event has major Event has severe
Response
consequence consequence consequence
Time

Immediate (0-
Medium Priority High Priority High Priority
5 min)

Rapid
Low Priority Medium Priority Medium Priority
(5-15 min)

Prompt
Low Priority Low Priority Medium Priority
(15-30 Min)

Not Urgent Low Priority or Re- Low Priority or Re- Medium Priority or Re-
(>30 Min) engineer engineer engineer

Following are a few clarifications concerning some of the entries in Table 1:

  31  ISA-TR18.2.2-2016

a) Personnel safety  Typically, these are alarms associated with such things as ambient
asphyxiation, toxic or flammable gas detection, safety shower/eyebath or deluge system
actuation alarms, field “emergency stop” or “help” switches, and similar items. In such
cases, the operator response of investigation and sending help minimizes further harm to a
person.

At most facilities, more reliable automated actions rather than operator responses are used
to protect personnel safety from process-related sources. Any exceptions to this principle
should be documented.

b) Alarms lacking urgency  All alarms should convey a sense of urgency. It is not desirable
to have alarms for which there is no operator action for a long period of time . Such alarms
should be re-engineered to manifest urgency, removed as an alarm, or documented as a
needed exception.

For non-urgent notifications, an option may be to implement such messages in a separate

notification system, such as the maintenance system, or as alerts, or using some other non-
urgent notification system that is separate from the alarm system .

c) Diagnostic alarms  Alarms indicating sensor malfunction are usually available on most
control system inputs, outputs, or other tags. If immediate and simple troubleshooting fails,
there are limited possibilities for further operator action. Generally , such action is limited to
calling the maintenance function, either by writing a routine work request, or the immediate
call-out of overtime resources (depending upon the importance of the sensor.) If call -out of
maintenance personnel during off-hours is required, then those alarms should have a higher
priority than those for which maintenance call-out is not required, thus aiding in the proper
operator response.

The use of a fourth (lowest) “diagnostic priority” for alarms to identify alarms for which the
proper operator response is the writing of a routine repair request is also a good practice.
In such a case the call-out alarms can utilize Low.

d) Similarity with prioritization table in TR1  There is a similar table in TR1. It is not exactly
the same as this one, but is included in TR1 as yet another example of a way to accomplish
the prioritization task.

7.2 Consequence-based prioritization option

For companies whose alarm philosophy defines that alarm priority is largely dictated by
consequence and not by allowable response time, a consequence-based approach can be utilized.
The advantage is a faster prioritization, with a disadvantage in the quality of the results being highly
dependent upon the alarm skills of the rationalization team.

The consequence-based prioritization uses criteria similar to the following :

a) High Priority – Operator action required due to imminent threat to personnel safety,
environment, or corporate assets (drop everything);

b) Medium Priority – Operator action required due to imminent potential for safety system
actuation, unit shutdown, contamination of tank/batch, or equipment damage;

c) Low Priority – Operator action required due to imminent potential for production/economic
loss (off-spec), minor unit upset, and/or equipment faults.
ISA-TR18.2.2-2016 – 32 –

7.3 Rule based prioritization

The priority of some alarms may be defined in the alarm philosophy. For example, a rule is often used to
define the priority of alarm types such as bad measurement or command disagree, as well as for specific
scenarios such as safety shower activation, fire and gas detectors, etc.

8 Classification

8.1 General
Assigning alarms to classes facilitates management of the alarm system. Certain classes of alarms
may have special testing, training, MOC, reporting or reliability requirements. Classification
provides a way to consistently assign requirements and then sup port verification that the
requirements have been met. The criteria for each alarm class is defined in the alarm philosophy,
including which alarm classes are highly managed. Assigning recommended alarm classes is
usually undertaken as part of the rationalization process.

8.2 Classification procedure

Each alarm should be designated as a member of at least one alarm class, though an alarm may
be assigned to multiple classes. The classification is usually based on the consequence, regulatory
or policy requirements, the identification method, or other criteria as defined in the philosophy ( see
TR1). The classification activity takes place during the rationalization stage of the lifecycle and
may be done during rationalization meetings or separately.

8.3 EXAMPLE: Alarm identification and alarm classification

The operator response to an alarm has been identified as a n independent protection layer (IPL) for
a hazardous event using Layer of Protection Analysis (LOPA). The IPL alarm class defined in the
alarm philosophy includes all alarms/responses listed as IPLs.

During rationalization, the alarm is approved by the team. The identification docume nt is a LOPA
report. The alarm is assigned to the IPL class because it meets the requirements of the class
definition in the alarm philosophy.

Alarm identification is often a factor in alarm classification. In this example, because the alarm and
response was identified as an IPL in a LOPA, it was also assigned to the IPL alarm class.

8.4 EXAMPLE: Alarm classification and consequence severity

An alarm being rationalized has a consequence of a release of a toxic chemical with the potential
to do harm to people or the environment. The consequence severity is severe. The alarm
philosophy states that when the response to an alarm is necessary to avoid a severe safety or
environmental consequence, the alarm should be classified as critical to process safety, a hig hly
managed alarm class according to the site’s alarm philosophy.

During rationalization, the alarm is approved by the team. With a consequence of release of toxic
chemicals and a severity of severe, the alarm is classified as process safety critical.

Consequence severity is often a factor in alarm classification. Though it is rare to have only an
alarm to protect against such a high severity consequence, it can happen. When the consequences
are high, the alarm should be subject to more stringent require ments of the highly managed alarm
classes.

9 Master alarm database and alarm documentation

9.1 General
A typical control system can have thousands of instruments and thousands of alarms. The tracking of
alarms, including their documentation, their justification, and current status is facilitated by the use of a
master alarm database (MADB). ISA-18.2 defines the MADB as the authorized list of rationalized alarms
  33  ISA-TR18.2.2-2016

and associated attributes. The MADB typically includes some alarm attributes whose values may be
determined in the detailed design stage. The master alarm database is subject to management of change
control and maintained for the life of the alarm system.

This clause covers issues associated with the creation and maintenance of the MADB for both existing alarm
systems that have not yet accomplished the rationalization life cycle stage, and for new alarm systems.

9.2 Software
A controlled electronic database is a versatile and desirable format for the alarm information. There
are a variety of commercial applications available in the marketplace for creation of a master alarm
database, or one can be created in-house. Some desirable characteristics and capabilities of a
master alarm database are listed below.

a) The database should be capable of easy and automatic update when the control system
itself is changed (e.g., addition, deletion, or modification of tags).
b) Capability for the connection of the database via an active connection to the control system
should be considered, but with potential security and management of change issues
addressed. Such connectivity enables other desirable functionality discussed in later
sections.
c) Rich database sorting, filtering, and copying capabilities are desirable and can increase the
productivity of many rationalization tasks.
d) The database should include all of the relevant alarm attributes contained in the control
system.
e) Alarm attribute changes should be possible according to rules. This is useful when applying
changes to many attributes at once based on an established rule in the alarm philosophy
(for example, a rule stating that all instrument diagnostic alarms of a certain type shall be
designated as a particular alarm classification or priority).
f) The database should provide a method of summarizing changes, in a forma t suitable for
generation of MOC documentation.
g) The database should provide customizable fields for recording a variety of tag related and
alarm related documentation or linkages to documents.
h) The database should keep track of the progress of the rationali zation tasks.
i) The ability of the database to update the control system directly with rationalized alarm
settings should be considered. Alternately, it should be able to output an alarm attributes
listing file suitable for use in bulk change methodologies.
j) Once the alarm system has been rationalized, it is useful to have an easy and ongoing
method to compare the actual alarm-related settings in effect on the control system to the
values contained in the MADB. This should be done in a way that does not allow for
uncontrolled change to the MADB. It is common for alarm settings to be changed on the
control system in ways that may not follow MOC procedures.
k) The MADB should provide for change tracking and revision control of its contents.
9.3 Alarm documentation
Rationalization ensures that alarms meet the requirements set forth in the alarm philosophy, and includes
the tasks of documentation, settings determination, prioritization, and classification. Several information
items are collected for each alarm during rationalization. These include the following which should be part
of the MADB:

a) the control system tag;

b) the alarm type;

ISA-TR18.2.2-2016 – 34 –

c) the alarm setpoint or logical condition;

d) potential causes of the alarm;

e) the nature and severity of the consequences associated with failing to respond to the alarm;

f) potential corrective actions or responses to the alarm, or reference to an available response

procedure;

g) the time available for the operator to respond to the alarm;

h) the alarm priority;

i) the alarm message, if applicable;

j) the alarm classification;

k) values or settings of alarm attributes such as deadband and delay times;

l) any special considerations for the alarm (e.g., design factors, HMI depiction, special or applicable
handling techniques or advanced methods being applied to the alarm);

m) If the process or equipment has different states that should utilize different alarm settings (e.g.,
differing products, feedstocks, quality parameters, or conditions such as startup or idle), those
multiple state-based alarm conditions and settings are also determined and documented. A more
detailed discussion of state-based alarming is covered in TR4. TR6 discusses these as recipe-
based alarms in batch processes.

9.4 Uses of the master alarm database

The master alarm database documents each alarm per the alarm philosophy and can be used for
several purposes, including the following.

a) Input to the detailed design stage of the alarm lifecycle  This ensures the alarms are set
properly. ISA-18.2 requires that alarm lists from the master alarm database sha ll be
available prior to the implementation of new or modified alarms.

b) Use by both system owners and system integrators  For new projects and modifications,
the database may be used by system owners or integrators responsible for the configuration
of the BPCS and SIS systems.

c) Use by operators  The database contains valuable training and operational information.
Alarm systems can be enhanced by linking information from the master alarm database
(e.g., possible alarm causes, consequences, and responses) into the operator’s human-
machine interface (HMI). Such methods can be superior to their collection in reference
books. Information can also be linked from other sources including: operating procedures,
operator logs, maintenance history, or design documents. For additional information, see
the discussion of information linking in TR4.

d) Utilization as part of the management of change process  ISA-18.2 requires that

unauthorized changes to the alarm system shall be detected and resolved. Many facilities
use automated methods to periodically check the online settings of alarms in the control
system against their proper settings in the master alarm database. Any discrepancies are
reported. In some cases, automated mechanisms restore the proper settings. For additi onal
information, see the discussion of alarm audit in TR5 and alarm enforcement in TR4.
  35  ISA-TR18.2.2-2016

9.5 Existing alarm systems

Many facilities will be implementing the principles of alarm management on existing alarm systems.
The alarm configuration on such systems often results from an initial configuration accomplished
via rules of thumb with no guiding alarm philosophy, followed by years of uncontrolled modifications
and additions. Documentation of some specific alarm settings and attributes may be contained in
procedures or lists, but full documentation of all alarms is usually lacking.

In beginning a rationalization effort on an existing system, it is useful to prepare a starting point

initial master alarm database reflecting all of the current alarm settings and attr ibutes. The database
should contain both the existing alarms and the potential alarms that can be setup on each tag if
the control system has such a default capability (e.g., Process Hi, Process Hi-Hi, Rate-of-Change,
etc.). The rationalization stage activities of justification, prioritization, documentation, and
classification can use this database to collect the results. Each existing and potential alarm is
evaluated according to the principles in the alarm philosophy as well as the output of the
identification life cycle stage.

In dealing with the initial list, the rationalization process may confirm or modify existing alarms, add
new alarms, or delete existing alarms. The resulting documentation should also indicate that while
the control system may have the standard capability for many different alarms on a tag, the
rationalization process is not only selecting alarms to be activated in the alarm system, but is also
indicating that other potential alarms should not be activated. The methods for alarm activation and
deactivation may be different based on the specific functionality provided in the control system.

The completion of the rationalization stage results in the maste r alarm database. This reflects the
desired configuration of all alarms, which is then used as an input to the implementation life cycle
stage.

9.6 New alarm systems

For new systems, an initial alarm database can be prepared similarly to 9.5, except it can be
assumed there are no existing alarms. The same activities are accomplished and a master alarm
database results, which is then used as an input to the implementation life cycle stage.

10 Altering the alarm system to reflect the master alarm database

10.1 General
The master alarm database content incorporates the output of the rationalization activities and also
attributes that may be determined in the basic alarm design stage. It is then necessary for the
actual alarm system to be either implemented or altered to be in alignment with the MADB, either
initially for new systems or as a change to existing systems.

10.2 New alarm systems

Implementation of the basic alarm design into a new control system is a straightforward task. The
specific techniques for the control system are used to ensure the alarms are set up with the proper
attributes and conditions as contained in the MADB.

Commissioning of the control system and of the alarm functionality is generally accomplished in
accordance with normal project procedures. ISA-18.2 details desired activities in commissioning,
documentation, testing, and training regarding the alarm system.

10.3 Existing alarm systems

Rationalization activities are often performed as an improvement effort on existing alarm systems.
Such systems may have been determined or developed in the absence of an alarm philosophy,
alarm documentation, or management of change requirements. Rationalization is typically
accomplished as an off-line exercise, in that few changes (usually by exception) are made to t he
in-service alarm system until the entire rationalization effort is complete.
ISA-TR18.2.2-2016 – 36 –

The result of rationalization and detailed alarm design on such systems is often a need to
accomplish many hundreds of alterations in the existing alarm system. A list of such typical
alterations includes:

a) the addition of new alarms;

b) the deletion of existing alarms;
c) the modification of existing alarms (e.g., setpoints, priorities, deadbands, logical
conditions);
d) the alteration of HMI displays related to alarm functionality or depiction;
e) the implementation of new procedural requirements for handling alarms (e.g. alarm shelving
procedures, new management of change requirements, new security setups and limitations
on operator or staff alterations of alarms);
f) the implementation of advanced alarm handling methodologies (see TR4), such as state -
based alarming and alarm flood suppression.
The accomplishment of such significant change in an alarm system is an undertaking that needs
planning. For many operators and staff, the changed alarm system may involve a major shift in
operating methodology. Compared to the pre-rationalized condition, the basic meaning of the alarm
system itself may be changed.

It is generally desirable to accomplish the changes in a minimum amount of time. Mos t control
systems have the ability to accomplish many alarm changes (e.g. , setpoints, priorities) in bulk and
online, given a properly formatted input file.

On many control systems, not every desired alarm change (e.g., addition of a new alarm,
modification of a logic-based alarm) can be accomplished in bulk or in an online fashion. In some
cases, a tag may have to be taken off-line to accomplish the change, and then reactivated. Care
must be taken so the process is not disturbed during these changes.

Special management of change procedures could be necessary for changes of a significant

quantity. Obviously the use of individual forms or authorization procedures for hundreds of changes
is an impractical approach. A special procedure for a one-time implementation of the needed
changes is often used. After such an implementation, the new MOC requirements for modifying
alarms are used.

10.4 Training
Implementation of rationalization and the resulting basic alarm design, in the form of either a new
installation or revision of an existing alarm system, needs operator and staff training. The training
may include such elements as the following:

a) a review of the alarm performance conditions that led to the decision to implement an alarm
philosophy and perform rationalization;
b) a general overview of the alarm philosophy;
c) the use and designation of alarm priority;
d) procedures regarding the handling and reporting of nuisance alarms ;
e) features of the control system’s alarm presentation, annunciation and management ;
f) permissible and non-permissible changes to the alarm system by operations ;
g) the management of change process for alarms;
h) proper use of all alarm handling strategies (e.g., shelving, state-based, flood suppression);
i) instructions for accessing on-line master alarm database information, such as alarm
consequences and operator response to alarms;
j) alarm system performance reporting;
  37  ISA-TR18.2.2-2016

k) access methods for retrieving alarm documentation;

l) the review of significant alarm changes and access to a list of the changes ;
m) the specific review of alarms designated as higher priorities, e.g., High and Medium
priorities;
n) any specific training required by the alarm philosophy such as training regarding alarms in
certain classifications;
o) training related to changes in alarm response procedures .

11 Bibliography
The following referenced documents may be useful for the application of this technical report.

EEMUA 191: Alarm Systems - A Guide to Design, Management and Procurement, Edition 3.
“Engineering Equipment and Material Users Association, London, 2013.
Hollifield, B. and Habibi, E. “Alarm Management: A Comprehensive Guide”, 2 nd Edition, ISA, 2011.
Rothenberg, D.H. “Alarm Management for Process Control”, Momentum Press, 2009.
ISA-dTR18.2.1, Alarm Philosophy (also known as TR1, to be published).
ISA-TR18.2.3, Basic Alarm Design (also known as TR3).
ISA-TR18.2.4, Enhanced and Advanced Alarm Methods (also known as TR4).
ISA-TR18.2.5, Alarm System Monitoring, Assessment, and Auditing (also known as TR5).
ISA-TR18.2.6, Alarm Systems for Batch and Discrete Processes (also known as TR6).
ISA-dTR18.2.7, Alarm Management with Packaged Systems (also known as TR7, to be published).
OSHA 1910.119, Process Safety Management of Highly Hazardous Chemicals , United States
Occupational Safety and Health Administration.

12 Appendix A – Potential pitfalls to success

12.1 General
This appendix lists some of the common pitfalls and challenges that can be encountered when undertaking
an alarm identification and rationalization projects. Being aware of these potential pitfalls can help project
teams anticipate and plan strategies to avoid these common problems that can make undertaking alarm
management difficult when present.

12.2 Project management

Managing alarm identification and rationalization projects can be more challenging when any of the following
occur:

a) failure to hold a kickoff meeting;

b) implementing only part of the rationalization on a console, resulting in alarm inconsistencies for the
same operator (e.g., bad measurement on all tags in one part of console and on only High and
Medium alarms in another part);

c) failure to move beyond resolution of bad actor alarms;

d) failure to have enough operations support/personnel;

ISA-TR18.2.2-2016 – 38 –

e) failure to train teams (particularly on definition of an alarm) and educate management on

rationalization goals and process;

f) failure to budget for alarm rationalization activities (therefore resources unavailable);

g) poorly timed alarm rationalization too late in new project execution where detailed alarm design has
already occurred (alarm rationalization as an after-thought).

12.3 Preparation
Preparing for any rationalization effort can be more difficult when the following are encountered:

a) failure to have available limits of operation (trip, safety, reliability, mechanical, design);

b) failure (especially on greenfield projects) to have all needed information on packaged systems prior
to rationalization. See TR7 for more details regarding alarms from packaged systems.

c) failure to have a complete instrument database, resulting in tags added later that are difficult to
identify;

d) failure to have accurate drawings resulting in BPCS tags that do not show on drawing and/or are
shown inaccurately;

e) failure to identify problem alarms such as standing alarms and bad actors prior to the rationalization;

f) failure to understand limitations of the BPCS, particularly if rationalization is on an older system that
does not have the functionality of more modern systems;

g) existing alarms that have no other documentation other than the alarm tag, and no one in the facility
knows the purpose or function of the alarm;

h) non-standard alarm tagging that does not provide any indication as to purpose or function of the
alarm.

12.4 Team dynamics

Team dynamics for alarm rationalization efforts can be challenging when any of the following are
encountered:

a) failure to align the expectations from safety reviews (PHA) and functional safety studies (LOPA
verification IPL lists) with alarm rationalization resulting in unrestricted acceptance of alarms from
those studies that do not meet criteria of alarm philosophy;

b) failure to address redundant instrumentation, such as SIS multiple voting and/or multiple
temperatures on same piece of equipment (reactors, compressors);

c) failure to understand limitation of instrumentation for alarming, such as: inability to support different
priorities for different alarm types; instrument indicates the demand for a state change but not the
feedback of the actual indication of the state (e.g., thinking the hand switch that stops a pump
actually shows the pump status);

d) failure to understand all the potential alarms in the control system, such as rate of change,
discrepancy, change of state, etc.;

e) failure to develop ground rules for workflow during rationalization sessions, particularly handling
non-process related alarms;
  39  ISA-TR18.2.2-2016

f) allowing the team to get stalled by attempting to reach consensus concerning numerical values of
alarm setpoint, deadband, delay times or other parameters. This is better handled by assigning a
knowledgeable team member to establish recommended values of these parameters offline for
presentation to the team.

12.5 Rationalization sessions

Rationalization sessions can be challenging when any of the following difficulties are encountered:

a) failure to document operator actions/response in sufficient detail;

b) failure to document that a point was reviewed even if no alarm was deemed necessary, leaving it
unclear if the lack of alarm was oversight or intentional;

c) failure to use appropriate software to capture/document results. For example, many installations
attempt to use a word processor or spreadsheet as a database. A database is much more versatile
than a spreadsheet or word processor, and provides for more easily generated reports.

d) failure to realize that the energy of the team has been exhausted and a break is needed;

e) failure to manage personalities and group dynamics such that one individual dominates;

f) failure to keep the team focused leading to off-topic discussions, side conversations, or attempting
to re-design the process;

g) having a team that is not engaged, using “check a box” mentality, or rushing through with little
thought to the responses, consequences, etc. Failure to examine descriptors and messages for
understandability as part of the rationalization.

h) failure to examine all applicable plant states, particularly upset modes of operation;

i) failure to identify sections of the process to be covered that might need participation by an individual
with specific expertise;

j) failure to take advantage of copying rationalization results to identical systems in the process, such
as redundant trains, machines;

k) having an existing alarm list in which what process condition each alarm is annunciating is not
clearly defined;

l) not having a complete list of existing and potential alarms be fore starting rationalization.
This page intentionally left blank.
1
Developing and promulgating technically sound consensus standards, recommended
practices, and technical reports is one of ISA’s primary goals. To achieve this goal, the
Standards and Practices Department relies on the technical expertise and efforts of
volunteer committee members, chairmen, and reviewers.

ISA is an American National Standards Institute (ANSI) accredited organization. ISA

administers United States Technical Advisory Groups (USTAGs) and provides secretariat
support for International Electrotechnical Commission (IEC) and International
Organization for Standardization (ISO) committees that develop process measurement
and control standards. To obtain additional information on the Society’s standards
program, please write:

ISA
Attn: Standards Department
67 Alexander Drive
P.O. Box 12277
Research Triangle Park, NC 27709

ISBN: 978-1-945541-00-1