Ansuisa 18.2 2009

ANSUISA-9"2-2009 Management of Alarm Systems for the Process lndustries
Approved 23 June 2009
ANSt/tSA-18.2-2009 Management of Alarm Systems for the Process lndustries

ISBN: 978-1 -936007-1 9-6
Copyright @ 2009 by the lnternational 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 ZTTO9 E-mail: [email protected]
Copyright 2009 lSA. All rights reserved.
-3Preface
ANSt/tSA-18.2-2009
This preface as well as all footnotes, annexes, and draft technical reports associated with this standard are included for information purposes only and are not part of ANSI/ISA-18.2-2009.
This standard has been prepared as part of the service of lSA, the International Society of Automation, toward a goal of uniformity in the field of instrumentation. To be of real value, this document should not be static but should be subject to periodic review. Toward this end, the Society welcomes all comments and criticisms and asks that they be addressed to the Secretary, Standards and Practices Board; lSA, 67 Alexander Drive; P.O. Box 12277; Research Triangle Park, NC 277099; Telephone (919) 549-8411; Fax (919) 549-8288; E-mail: [email protected].
This ISA Standards and Practices Department is aware of the growing need for attention to the metric system of units in general, and the lnternational System of Units (Sl) 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 Sl (and the metric system) in their business and professional dealings with other countries. Toward this end, the Department will endeavor to introduce Sl 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 lnstitute 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 all 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 lSA, or of any of the standards, recommended practices, and technical reports that ISA
develops.
This standard is structured to follow the IEC guidelines. Therefore, the first three sections
discuss the Scope of the standard, Normative References and Definitions, in that order.
ISA ADHERES TO THE POLICY OF THE AMERICAN NATIONAL STANDARDS CAUTION INSTITUTE- WITH REGARD TO PATENTS. IF ISA IS INFORMED OF AN EXISTING PATENT THAT S REQUIRED FOR USE OF THE STANDARD, 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 STANDARD OR A LICENSE ON REASONABLE TERMS AND CONDITIONS THAT ARE FREE FROM UNFAIR DISCRIMINATON. EVEN IF ISA IS UNAWARE OF ANY PATENT COVERING THIS STANDARD, THE USER IS CAUTIONED THAT IMPLEMENTATION OF THE STANDARD 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 STANDARD. ISA IS NOT RESPONSIBLE FOR IDENTIFYING ALL PATENTS THAT MAY REQUIRE A LICENSE BEFORE IMPLEMENTATION OF THE STANDARD OR FOR INVESTIGATING THE VALDITY OR SCOPE OF ANY PATENTS BROUGHT TO TS ATTENTION. THE USER SHOULD CAREFULLY INVESTIGATE RELEVANT
PATENTS BEFORE USING THE STANDARD FOR THE USER'S INTENDED APPLICATION. HOWEVER, SA ASKS THAT ANYONE REVIEWING THIS STANDARD WHO S AWARE OF ANY PATENTS THAT MAY IMPACT MPLEMENTATION OF THE STANDARD NOTIFY THE ISA STANDARDS AND PRACTICES DEPARTMENT OF THE PATENT AND ITS OWNER. ADDITIONALLY, THE USE OF THIS STANDARD MAY INVOLVE HAZARDOUS MATERIALS, OPERATONS OR EQUIPMENT. THE STANDARD CANNOT ANTICIPATE ALL POSSIBLE
Copyright 2009 SA. All rights reserved
ANSr/rSA-18.2-2009
-4-
APPLICATIONS OR ADDRESS ALL POSSIBLE SAFETY ISSUES ASSOCIATED WITH USE IN HAZARDOUS CONDITIONS. THE USER OF THIS STANDARD MUST EXERCISE SOUND PROFESSIONAL JUDGMENT CONCERNING ITS USE AND APPLICABILITY UNDER THE USER'S PARTICULAR CIRCUMSTANCES. THE USER MUST ALSO CONSIDER THE APPLICABILITY OF ANY GOVERNMENTAL REGULATORY LIMITATIONS AND ESTABLISHED SAFETY AND HEALTH PRACTICES BEFORE IMPLEMENTING THIS STANDARD.
ADDRESSED THE POTENTIAL ISSUES IN THIS VERSON.
THE USER OF THIS DOCUMENT SHOULD BE AWARE THAT THIS DOCUMENT MAY BE IMPACTED BY ELECTRONIC SECURITY ISSUES. THE COMMITTEE HAS NOT YET
Copyright 2009 lSA. All rights reserved
-5-
ANSt/rSA-18.2-2009
The following people served as voting members of lSA18 and approved this standard on 17 April 2009:
NAME Erwin E. lcayan, Managing Director
COMPANY
ACES lnc.
Donald G. Dunn, Co-chair Nicholas P. Sands, Co-chair Joseph S. Alford Stephen M. Apple Joe L. Bingham Alex D. Boquiren Alan W Bryant John R. Campbell Bridget Fitzpatrick
Max L. Hanson David Hatch BillR. Hollifield Alan Hugo Lokesh Kalra Edward M. Marszal MichaelT. Marvan Douglas P. Metzger 'lan Nimmo Patrick O'Donnell Douglas H. Rothenberg Todd R. Stauffer David Strobhar Angela E. Summers Beth E. Vail
Aramco Services Co. DuPont Consultant T|PS lnc AES Automation BechtelCorp Oxy lnc ConocoPhillips Mustang Engineering
Meyer Control Corp Exida PAS Capstone Technology Chevron Kenexis Consulting Gorp
Matrikon lnc Consultant User Centered Design Services LLC

BP D Roth lnc Siemens Energy & Automation Beville Engineering Inc. SIS-TECH Solutions LP Washington Safety Management Solutions/ URS
This published standard was approved for publication by the ISA Standards and Practices board on 12 June 2009.
NAME
J. Tatera, Vice President P. Brett M. Coppler E. Cosman B. Dumortier D. Dunn R. Dunn J. Gilsinn E. lcayan J. Jamison D. Kaufman K. Lindner V. Maggioli
GOMPANY
Tatera & Associates, Inc. Honeywell, Inc. Ametek, Inc. The Dow ChemicalCo. Schneider Electric Aramco Services Co. DuPont Engineering NIST/MEL ACES, lnc. EnCana Corporation Ltd Honeywell lnternational, lnc. Endress+Hauser Process Solutions AG Feltronics Corp. Jacobs Engineering Group Emerson Process Management Rockwell Automation E I Du Pont Yamatake Corp. Rosemount, lnc. MTL lnstrument Group ICS Secure, LLC
T. McAvinew G. McFarland
R. Reimer N. Sands H. Sasajima T. Schnaare l. Verhappen
R. Webb
ANSt/tSA-18.2-2009
W.l/\idman
J. VVeiss M. Wdmeyer M. Zielinski
-6Parsons Energy & Ghemicals Group Applied Control Solutions, LLC Consultant Emerson ProcesE Management
-7 Table of Gontents
lntroduction.......
Purpose...... Organization .............. Scope
ANSr/f
SA-18.2-2009
2 3 4 5
1.1 General Applicability ................. 1.2 The Alarm System 1.3 Exclusions
Normative References.........
2.1
References Definition of Terms and Acronyms ......
3.1 3.2 4.1 4.2
Definitions. Acronyms.. Conformance to this Standard Conformance Guidance............. Existing Systems.... Alarm System Models......
21 21
21
2"1
22 22 22 28
30
5.1 Alarm Systems 5.2 Alarm Management Lifecycle..... 5.3 Process Condition Model 5.4 Alarm States....... 5.5 Alarm Response Timeline... 5.6 Feedback Model of Operator - Process lnteraction
Alarm Philosophy 6.1 Purpose 6.2 Alarm Philosophy Contents... 6.3 Alarm Philosophy Development and Maintenance. Alarm System Requirements Specification......... 7.1 Purpose 7.2 Recommendations...... 7.3 Development.............. 7.4 Systems Evaluation 7.5 Customization and Third-Party Products 7.6 Alarm System Requirements Testing ldentification. 8.1 Purpose 8.2 Alarm ldentification Methods.... Rationalization
34 36 36 36 37 43 43
8 9
43 43 ,44 ,44 ,44 .44 .44
.45 .45 .45 .45 .45 .46 .46 .46
9.1 Purpose 9.2 Objective 9.3 Alarm Justification.................., 9.4 Alarm Setpoint Determination. 9.5 Prioritization...............
ANSI/1SA-18.2-2009
9.7 9.8 9.9

10
9.6
Removal Classification .................... Review...... Documentation.................. BasicAlarm Design
47 47 47 47 47 47 47 48 49 50 50
51 51
51
10.1 Purpose 10.2 Usage of Alarm States....... 10.3 Alarm Types........... 10.4 Alarm Attributes ..... 10.5 Programmatic Changes to Alarm Attributes..... 10.6 Review Work Product
11
Human-Machine lnterface Design for Alarm Systems
11.1 Purpose 11.2 Overview.......... 11.3 Alarm States lndications. 11.4 Alarm Priority lndications 11.5 Alarm Message lndications 11.6 Alarm Displays 11.7 Alarm Shelving 1 1.8 Out-of-service Alarms...... 11.9 Alarms Suppressed by Design 1 1 . l0Alarm Annunciators .............
11.11 Safety Alarm HMI ..........
12 Enhanced and Advanced Alarm Methods
52 54 54
54 57 59 59 60
61 61 61 61
12,1 Purpose 12.2 Basis of Enhanced and Advanced Alarming ...... 12.3 Enhanced and Advanced Alarming Categories.. 12.4 lnformation Linking 12.5 Logic-based Alarming 12.6 Model-based Alarming... 12.7 Additional Alarming Considerations.......... 12.8 Training, Testing, and Auditing Systems.. 12.9 Alarm Attribute Enforcement
13
lmplementation ..........
62 62 62 63 63 64 64 65 65 65 65 66
13.1 Purpose 13.2 lmplementation Planning ..... 13.3 lnitial Training ............ 13.4 lnitial Testing and Validation 13.5 Documentation
14
Operation..
67 68
68 68 68 69
'14.1 Purpose
14.2 Alarm Response Procedures ....,... 14.3 Alarm Shelving 14.4 Refresher Training for Operators ..
-915
Maintenance
ANSI/tSA-18.2-2009
15.1 Purpose 15.2 Periodic Testing 15.3 Out-of-service

1
5.4 Equipment Repair...............

71
71
15.5 Equipment Replacement...... 15.6 Returning Alarms to Service 15.7 Refresher Training for Maintenance
16
Monitoring and Assessment.........
72 72 72 72 72 73 73 76 76 76 77 77 77 78 78 78 78 78 79 79 79 79 79 79 79 80
16.1 Purpose 16.2 Requirements............ 16.3 Monitoring, Assessment, Audit, and Benchmark 16.4 Alarm System Measurement 16.5 Alarm System Performance Metrics 16.6 Unauthorized Alarm Suppression 16.7 Alarm Attribute Monitoring 16.8 Reporting of Alarm System Analyses 16.9 Alarm Performance Metric Summary
17
Management of Change ..............
17.1 Purpose 17.2 Changes Subject to Management of Change..... 17.3 Change Review Process Requirements.............
'17.4 Change Documentation Requirements..............
1
7.5 Change Documentation Recommendations .......
17.6 Alarm Decommissioning Recommendations........ '17.7 AlarmAttribute Modification Requirements....... 17.8 Alarm Attribute Modification Recommendations
18 Audit... 18.1 Purpose

18.2 18.3 18.4 18.5
lnitial Audit or Benchmark............ Audit lnterviews. Audit Recommendations...... Action Plans.....
ANSt/tSA-18.2-2009
-10Figures
13
Figure 1 - Alarm System Dataflow Figure 2 - Alarm Management Lifecycle
23 28
29
31
Figure 3 - Alarm Management Lifecycle Stage lnputs and Outputs Figure 4 - Process Condition Mode|........ Figure 5 - Alarm State Transition Diagram........... Figure 6 - Alarm Timeline........ Figure 7 - Feedback Model of Operator Process lnteraction Figure I - Required and Recommended Alarm Philosophy Content Figure 9 - Recommended Starting Point Deadband Based on Signal Type Figure 10 - Recommended Delay Times Based on SignalType Figure 11 - Recommended Alarm State lndications Figure 12
34 36
38
49
50
53 74
75 77
Average Alarm Rates .....
Figure 13 - Annunciated Alarm Priority Distribution Figure 14 - Alarm Performance Metric Summary..
Copyright 2009 SA. All rights reserved.
-'l'l lntroduction
Purpose
ANSt/tSA-18.2-2009
This standard addresses the development, design, installation, and management of alarm
systems in the process industries. Alarm system management includes multiple work processes throughout the alarm system lifecycle. This standard defines the terminology and models to develop an alarm system, and it defines the work processes recommended to effectively maintain the alarm system throughout the lifecycle.
This standard was written as an extension of existing ISA standards with due consideration of other guidance documents that have been developed throughout industry. lneffective alarm systems have often been cited as contributing factors in the investigation reports following major process incidents. This standard is intended to provide a methodology that will result in the improved safety of the process industries.
This standard is not the first effort to define terminology and practices for effective alarm systems. ln 1955 ISA formed a survey committee titled lnstrument Alarms and lnterlocks. The committee evolved to Standard & Practices committee 18. ln 1965 the committee completed |SA-RP18.1, Specifications and Guides forthe Use of General Purpose Annunciators. ln 1979 ISA released, as a product of the lSA18 and lSA67 committees, ISA-18.1-1979 (R2004), Annunciator Sequences and Specifications. In 1994 Amoco, Applied Training Resources, BP, Exxon, Gensym, Honeywell, Mobil, Novacor, Texaco, Shell, and others formed the Abnormal Situation Management Consortium (ASM) to develop a vision for better response to process incidents, with additional support in 1994 from the U.S. National lnstitute of Standards and Technology (NIST). ln 1999 the Engineering Equipment and Materials Users' Association (EEMUA) issued Publication 191, Alarm Sysfems; A Guide to Design, Management and Procuremenf, which was updated in 2007. ln 2003 the User Association of Process Control Technology in Chemical and Pharmaceutical lndustries (NAMUR) issued recommendation NA
1O2,
Alarm Management.
During the development of this standard every effort was made to keep terminology and practices consistent with the previous work of these respected organizations and committees. This document provides requirements for alarm management and alarm systems. lt is intended for those individuals and organizations that
a) manufacture or implement embedded alarm systems, b) manufacture or implement third-party alarm system software, c) design or install alarm systems, d) operate and/or maintain alarm systems, and e) audit or assess alarm system performance.
Organization
This standard is organized in two parts. The first part is introductory in nature, (Clauses 1-5). The main body of the standard (Clauses 6-18) presents mandatory (normative) requirements or non-mandatory (informative) recommendations as noted. lf a clause contains no mandatory requirements then it is noted as informative.
This page intentionally left blank.
-13-
ANSI/lSA-18.2-2009
Scope
General Applicability
1.1
This standard addresses alarm systems for facilities in the process industries to improve safety, quality, and productivity. The general principles and processes in this standard are intended for use in the lifecycle management of an alarm system based on programmable electronic controller and computer-based Human-Machine lnterface (HMl) technology. lmplementation of this standard should consider alarms from all systems presented to the operator, which may include basic process control systems, annunciator panels, safety instrumented systems, fire and gas systems, and emergency response systems. The practices in this standard are applicable to continuous, batch, and discrete processes. There may be differences in implementation to meet the specific needs based on process
type.
1.2
The Alarm System
The alarm system serves to notify operators of abnormal process conditions or equipment malfunctions. lt may include both the basic process control system (BPCS) and the safety instrumented system (SlS), each of which uses measurements of process conditions and logic to generate alarms (see Figure 1). The alarm system also includes an alarm log and a mechanism for communicating the alarm information to the operator via a HMl, usually a computer screen or an annunciator panel. There are other functions outside the alarm system that are important to the effectiveness of the alarm system, which many include an alarm
historian. Alarm System Advanced Alarm
Applications
srs
Sensors
Alarm
Log
External
Systems
t/o
BPCS HMI
Final Gontrol Elements
Alarm Historian
uo
Panel
Operator
Process
Control & Safety Systems
lnterface
Figure
I - Alarm System
Dataflow
ANSt/tSA-18.2-2009
-14-
1.3 Exclusions
1.3.1 Process Sensors and Final Control Elements
Process sensors and final control elements are shown in Figure 1 to indicate alarms may be implemented in these devices. The design and management of process sensors and iinal control elements are excluded from the scope of this standard. The alarms and diagnostic indications from sensors and final control elements are included in the scope of this stadard.
1.3.2 Safety lnstrumented Systems The safety instrumented system (SlS) is shown in Figure 1 to indicate alarms may be implemented in these devices. The design and management of safety instrumented sysiems are excluded from this standard (refer to ANSI/|SA-84.00.01-2004 Part 1 (lEC 6151i Mod) Functional Safety: Safety lnstrumented Sysfems for the Process tndustry Secfor - Part 1: Framework, Definitions, Sysfern, Hardware and Software Requiremenfs). The alarms and diagnostic indications from safety instrumented systems are included in the scope of this
standard.
1.3.3 Annunciator Panels The specification and design of annunciator panels is excluded from the scope of this standard. ISA-18.1-1979 (R2004), Annunciator Sequences and Specifications, provides information on alarm annunciator functions. The integration of independent alarm annunciator
panels into an alarm system is included in the scope of this standard.
1.3.4 Fire Detection and Suppression Systems and Security Systems
Fire detection and suppression systems and security systems are governed by other standards and are excluded from the scope of this standard. The alarms and diagnostics from fire detection and suppression systems or security systems that are presented t tfre process operator through the control system are included in the scope of this standard.
1.3.5 Event Data
The indication and processing of analog, discrete, and event data other than alarm indications are outside the scope of this standard. The analysis techniques using both alarm and event data are outside the scope of this standard.
1.3.6 Alarm ldentification Methods

Required methods of alarm identification are not specified in this standard. Examples of alarm identification methods are listed.
1.3.7 Management of Ghange
specific management
requirements and recommendations to be included in a management of change procedure are included.
of change procedure is not
included
in this
standard. Some
1.3.8 Jurisdictions
city) have established process safety design, process safety management, or

reguirements, these take precedence over the requirements defined in this standard.
In jurisdictions where the governing authorities (e.9., national, federa!, state, province, county,
othr
-151.3.9 Purchase Specification
ANSt/tSA-18.2-2009
This standard is not intended to be used as an alarm system purchase specification. lt will not eliminate the need for sound engineering judgment. No particular technology is mandated.
Normative References
2.1 References
The following referenced documents are useful for the application of this standard. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ANSI/|SA-84.00.01-2004 (lEC 61511 Mod) Part 1 Functional Safety: Safety lnstrumented Sysfems for the Process lndustry Secfor - Part 1: FrameworL, Definitions, Sysfent, Hardware and Software Requirements ANS|/|SA-91.00.01-2001 ldentification of Emergency Shutdown Sysfems and Controls That Are lmportant to Maintaining Safety in Process lndustries
Definition of Terms and Acronyms
Defined terms are used in this standard. Synonymous terms, which are not used in this standard, are listed in parentheses.
3.1 Definitions
For the purposes of this standard, the following definitions apply.
3.1.1 Absolute alarm

An alarm generated when the setpoint is exceeded.
3.1.2 Acknowledge
The operator action that confirms recognition of an alarm.
3.1.3 Activate
The process of enabling an alarm function within the alarm system.
3.1.4 Adjustable alarm (Operator-set alarm)

An alarm for which the setpoint can be changed manually by the operator.
3.1.5 Advanced alarming A collection of techniques (e.9., state-based alarming, and dynamic prioritization) that can
help manage alarm rates in specific situations.
3.1.6 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.7 Alarm attributes (Alarm parameters) The settings for an alarm within the process control system (e.9., alarm setpoint, alarm
priority). Copyright 2009 lSA. All rights reserved.
ANSr/rSA-18.2-2009
-16-
3.1.8 Alarm class
A group of alarms with common alarm management requirements (e.g., testing, training,
monitoring, and audit requirements).
3.1.9 Alarm deadband (Alarm hysteresis)

The change in signal from the alarm setpoint necessary to clear the alarm.
3.1.10 Alarm flood (Alarm shower) A condition during which the alarm rate is greater than the operator can effectivety manage (e.9., more than 10 alarms per 10 minutes). 3.1.11 Alarm group A set of alarms with common association (e.9., process unit, process area, equipment set, or
service).
3.1.12 Alarm historian

The long term repository for alarm records.
3.1.13 Alarm log

The short term repository for alarm records.
3.1.14 Alarm management (Alarm system management) The processes and practices for determining, documenting, designing, operating, monitoring,
and maintaning alarm systems. 3.1.f
Alarm message A text string displayed with the alarm indication that provides additional information to the
operator (e.9., operator action).
3.1.16 Alarm off-delay (Debounce)

The time a process measurement remains in the normal state before the alarm is cleared.
3.1.17 Alarm on.delay

The time a process measurement remains in the alarm state before the alarm is annunciated.
3.1.18 Alarm overview indicator

The composite indicator of alarm status for a process unit or area.
3.1.19 Alarm philosophy A document that establishes the basic definitions, principles, and processes to design,
implement, and maintain an alarm system.
3.1.20 Alarm priority

The relative importance assigned to an alarm within the alarm system to indicate the urgency of response (e.9., seriousness of consequences and allowable response time).
3.1.21 Alarm setpoint (Alarm limit, Alarm trip point) The threshold value of a process variable or discrete state that triggers the alarm indication.
-173.1.22 Alarm summary
ANSt/tSA-18.2-2009
A display that lists alarms with selected information (e.9., date, time, priority, and alarm type).
3.1.23 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.24 Alarm system requirements specification The document which specifies the details of the alarm system design which are used in
selecting components of an alarm system.
3.1.25 Alarm type (Alarm condition) A specific alarm on a process measurement (e.9., low process variable alarm, high process
variable alarm, or discrepancy alarm).
3.1.26 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.27 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.28 Annunciator A device or group of devices that call attention to changes in process conditions.
3.1.29 Bad measurement alarm An alarm generated when the signal for a process measurement is outside the expected range (e.9., 3.8m4 or a 4-20m4 signal).
3.1.30 Bit-pattern alarm
An alarm that is generated when a pattern of digital signals matches a predetermined pattern.
3.1.31 Calculated alarm

An alarm generated from a calculated value instead of a direct process measurement.
3,1.32 Gall-out alarm An alarm that notifies and informs an operator by means other than, or in addition to,
console display (e.9., pager or telephone).
3.1.33 Chattering alarm An alarm that repeatedly transitions between the alarm state and the normal state in a short
period of time.
3.1.34 Classification The process of separating alarms into classes based on common requirements (e.9., testing,
training, monitoring, and auditing requirements).
3.1.35 Clear
An alternate description of the state of an alarm that has transitioned to the normal state. Copyright 2009 lSA. All rights reserved.
ANSt/tSA-18.2-2009
-18-
3.1.36 Console The interface for an operator to monitor and/or control the process, which may include multip displays or annunciators, and defines the boundaries of the operator's span of
control.
3.1.37 Control system A system that responds to input signals from the equipment under controt and/or from an operator and generates output signals that cause the equipment under control to operate in
the desired manner.
Systems (SlS).
NOTE The control system may include both Basic Process Control Systems (BPCS) and Safety lnstrumented
3.1.38 Decommission The change process to remove an alarm from the alarm system.
3.1.39 Deviation alarm An alarm generated when the difference between two analog values exceeds a limit (e.g., deviation between primary and redundant instruments or a deviation between process
variable and setpoint).
3.1.40 Discrepancy alarm (Mismatch alarm)

An alarm generated by error between the comparison of an expected plant or device state to its actual state (e.9., when a motor fails to start after it is commanded t the on state).
3.1,41 Dynamic alarming

The automatic modification of alarms based on process state or conditions.
3.1.42 Enforcement
An enhanced alarming technique that can verifo and restore alarm attributes in the control system to the values in the master alarm database.
3.1.43 First-out alarm (First-up atarm)

An alarm determined (i.e., by first-out logic) to be the first, in a multiple-alarm scenario.
3.1.44 Highly managed alarm An alarm belonging to a class with more requirements than general alarms (e.g., a safety
alarm).
3.1.45 lmplementation
The transition stage between design and operation during which the alarm is put into service.
3.1.46 Instrument diagnostic alarm

An alarm generated by a field device to indicate a fault (e.g., sensor failure).
3.1.47 lnterim alarm An alarm used on a temporary basis (e.g., in place of an out-of-service alarm) without
completing the management of change process.
-193.1.48 Latching alarm
ANSt/tSA-18.2-2009
An alarm that remains in alarm state after the process has returned to normal and requires an operator reset before it will clear.
3.1.49 Manual safety function alarm (Safety related alarm) An alarm that indicates an operator action is required to complete a safety function (e.9.,
operator initiated instrumented function).
3.1.50 Master alarm database

The authorized list of rationalized alarms and associated attributes.
3.1.51 Nuisance alarm An alarm that annunciates excessively, unnecessarily, or does not return to normal after the correct response is taken (e.9., chattering, fleeting, or stale alarms).
3.1.52 Operator (Controller)
The person who monitors and makes changes to the process.
3.1.53 Out-of.service The state of an alarm during which the alarm indication is suppressed, typically manually, for reasons such as maintenance.
3.1.54 Plant state (Plant mode)

A defined set of operational conditions for a process plant (e.9., shutdown, operating).
3.1.55 Prioritization
The process of assigning a level of operational importance to an alarm
3.1.56 Rate-of.change alarm

An alarm generated when the change in process variable per unit time, (dPV/dt), exceeds a defined limit.
3.1.57 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.58 Recipe.driven alarm

An alarm with limits that depend on the recipe that is currently being executed.
3.1.59 Remote alarm

An alarm from a remotely operated facility or a remote interface.
3.1.60 Reset
The operator action that unlatches a latched alarm
3.1.61 Return to normal

The indication an alarm condition has transitioned to the normal state
3.1.62 Re-alarming alarm (Re.triggering alarm)

An alarm that is automatically re-annunciated to the operator under certain conditions. Copyright 2009 lSA. All rights reserved.
ANSI/tSA-18.2-2009
-20-
3.1.63 Safety alarm

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

An alarm that indicates a demand on a safety function
3.1.65 Shelve A mechanism, typically initiated by the operator, to temporarily suppress an alarm. 3.1.66 Silence
The operator action that terminates the audible alarm indication.
3.1.67 Stale alarm

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

An alarm in an active alarm state (e.9., unack alarm, ack alarm)
3.1.69 State-based alarm (Mode-based alarms)

An alarm that is automatically modified or suppressed based on process state or conditions.
3.1.70 Station
A single human-machine interface within the operator console.
3.1.71 Statistical alarm

An alarm generated based on statistical processing of a process variable or variables.
3.1.72 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.73 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. 3.1.74 System diagnostic alarm An alarm generated by the control system to indicate a fault within the system hardware,
software or components (e.9., communication error).
3.1.75 Tag (Point) The unique identifier assigned to a process measurement, calculation, or device within the controlsystem.
3.1.76 Unacknowledged
A state in which the operator has not yet confirmed recognition of an alarm indication
-2't
3.2 Acronyms
3.2.1 Ack: Acknowledge or Acknowledged
ANSt/tSA-18.2-2009
3.2.2 ASRS: Alarm System Requirements Specification 3.2.3 BPCS: Basic Process Control System 3.2.4 cGMP: current Good Manufacturing Practice 3.2.5 EEMUA: Englneering Equipment and Materials Users'Association 3.2.6 EPA: Environmental Protection Agency (US government) 3.2.7 ERP: Enterprise Resource Planning 3.2.8 ESD: Emergency Shutdown System 3.2.9 FDA: Food and Drug Administration (US government) 3.2.10 FMEA: Failure Mode and Effects Analysis 3.2.11 HMA: Highly Managed Alarms 3.2.12 HMI: Human.Machine lnterface 3.2.13 HAZOP: Hazard and Operability Study
3.2.14 MES: Manufacturing Execution System 3.2.15 MOC: Management of Change 3.2.16 OSHA: Occupational Safety and Health Administration (US government)
3.2.17 P&lD: Piping (or Process) and lnstrumentation Diagram 3.2.18 PHA: Process Hazards Analysis 3.2.19 RTN: Return to Normal 3.2.20 SIF: Safety Instrumented Function 3.2.21 SIL: Safety Integrity Level
3.2.22 SIS: Safety lnstrumented System 3,2.23 SRS: Safety Requirements Specification 3.2.24 SOP: Standard Operating Procedure
3.2.25 UNACK: Unacknowledged
Gonformance to this Standard
4.1 ConformanceGuidance
To conform to this standard, it must be shown that each of the requirements in the normative clauses has been satisfied.
4.2 Existing Systems

For existing alarm systems designed and constructed in accordance with codes, standards, and/or practices prior to the issue of this standard, the owner/operator shall determine that the equipment is designed, maintained, inspected, tested, and operated in a safe manner. Copyright 2009 lSA. All rights reserved.
ANSr/rSA-18.2-2009
-22a
The practices and procedures of this standard shall be applied to existing systems in
reasonable time as determined by the owner/operator.
5 Alarm System Models

5.1 Alarm Systems
Alarm systems are used to communicate indications of abnormal process conditions or equipment malfunctions to the operators, the personnel monitoring and operating the process. Effective alarm systems are well designed, implemented, operated, and maintained. Alarm management is the set of practices and processes that ensures an effective system.
A foundational part of alarm management is the definition of an alarm; an audible and/or visible means of indicating to the operator an equipment malfunction, process deviation, or abnormal condition requiring a response. The essential element of this definition is the response to the alarm. This definition is reinforced in the alarm management processes
described in this standard.
5.2 Alarm Management Llfecycle

Figure 2 illustrates the relationship between the stages of the alarm management lifecycle described in this standard. The alarm management lifecycle covers alarm sysiem specification, desgn, implementation, operation, monitoring, maintenance, and cange
activities from initial conception through decommissioning.
The lifecycle model is useful in identifying the requirements and responsibilities for
implementing an alarm management system. The lifecycle is applicable for the installation of new alarm systems or managing an existing system.
-23-
ANSI/tSA-18.2-2009
Philosophy
ldentification
Rationalization
Detailed Design
Management of Change
Audit
lmplementation
Operation Monitoring & Assessment

Maintenance
Figure 2
NOTE NOTE NOTE NOTE
Alarm Management Lifecycle
The box used for stage B represents a process defined outside of this standard per 5.2.1.2. stage J represents a process that connects to all other stages per 5.2.1.10
2 The independent 3
The rounded shapes of stages A, H, and J represent entry ponts to the lifecycle per 5.2.2. The dotted lines represent the loops in the lifecycle pe 5.2.4.
5,2.1 Alarm Management Lifecycle Stages The alarm management lifecycle stages shown in Figure 2 are briefly described in the following sections. The letter label is an identifier used in the text. The requirements and
recommendations for each stage are described in Glauses 6 -18 of this standard.
ANSr/tSA-18.2-2009
-24
5.2.1.1 Alarm Philosophy (A)

Basic planning is necessary prior to designing a new alarm system or modifying an existing system. Generally the first step is the development of an alarm philosophy that documents th objectives of the alarm system and the processes to meet those objectives. For new systems the alarm philosophy serves as the basis for the alarm system requirements speciiication (ASRS) document.
The philosophy starts with the basic definitions and extends them to operational definitions. The definition of alarm priorities, classes, performance metrics, performance limits, and reporting requirements are determined based on the objectives, definitions, and principles. The schemes for presentation of alarm indications in the HMl, including use of priorities, are
also set in the alarm philosophy, which should be consistent with the overall HMI design.
The philosophy specifies the processes used for each of the lifecycle stages, such as the threshold for the management of change process and the specific requirements for change. The philosophy is maintained to ensure consistent alarm management throughout the lifecyle
of the alarm system.
The dev-elopment of the alarm system requirements specification is included in the philosophy stage of the lifecycle. Most of the specification is system independent and can be the basi for delermining which systems most closely meet the requirements. The specification typically goes into more detail than the alarm philosophy and may provide specific guidance for system
design.
5.2.1.2 ldentification (B)

The identification stage is a collection point for potential alarms proposed by any one of several methods for determining that an alarm may be necessary. These methods are defined outside of this standard so the identification stage is represented as a predefined process in the lifecycle. The methods can be formal such as process hazards analysis, safety requirements specifications, recommendations from an incident investigtion, gooit manufacturing practice, environmental permits, P&D development or operating proceure reviews. Process modifications and operating tests may also generate the need for alarms or modifications. Some alarm changes will be identified from the routine monitoring of alarm system performance. At this stage the need for an alarm has been identified and it is ready to
be rationalized.
5,2,1.3 Rationalization (C)

The rationalization stage reconciles the identified need for an alarm or alarm system change with the principles in the alarm philosophy. The steps can be completed in oe process or sequentially. The product of rationalization is clear documentation of the alarm, including any advanced alarm techniques, which can be used to complete the desgn.
Rationalization is the process of applying the requirements for an alarm and generating the supporting documentation such as the basis for the alarm setpoint, the consequence, and corrective action that can be taken by the operator.
Rationalization includes the prioritization of an alarm based on the method defined in the alarm philosophy. Often priority is based on the consequences of the alarm and the ailowable response time.
Ratonalization also includes the activity of classification during which an alarm is assigned to one or more classes to designate requirements (e.9., design, testing, training, or reporting requirements). The type of consequences of a rationalized alarm, or other ciiteria, can b used to separate the alarms into classes as defined in the alarm philosophy. Copyright 2009 lSA. All rights reserved.
-25-
ANSt/rSA-18.2-2009
The rationalization results are documented, typically in the master alarm database (i.e., an
approved document or file), which is maintained for the life of the alarm system.
5.2.1.4 Detailed Design (D)

requirements determined by rationalization. There are three areas design, HMI design, and design of advanced alarming techniques.
ln the
design stage, the alarm attributes are specified and designed based on the of design: basic alarm
The basic design for each alarm follows guidance based on the type of alarm and the specific controlsystem. The HMI design includes display and annunciation for the alarms, including the indications of alarm priority.
Advanced alarming techniques are additional functions that improve the effectiveness of the alarm system beyond the basic alarm and HMI design. These methods include state based alarming and dynamic prioritization.
5.2.1.5 lmplementation (E)

ln the implementation stage, the activities necessary to install an alarm or alarm system and bring it to operational status are completed. lmplementation of a new alarm or a new alarm system includes the physical and logical installation and functional verification of the system.
Since operators are an essential part of the alarm system, operator training is an important activity during implementation. Testing of new alarms is often an implementation requirement. The documentation for training, testing, and commissioning may vary with classification as defined in the alarm philosophy.
5.2.1.6 Operation (F)
ln the operation stage, the alarm or alarm system is active and it performs its intended function. Refresher training on both the alarm philosophy and the purpose of each alarm is included in this stage.
5.2.1.7 Maintenance (G)
ln the maintenance stage, the alarm or alarm system is not operational but is being tested or repaired. Periodic maintenance (e.9., testing of instruments) is necessary to ensure the alarm system functions as designed.
5.2.1.8 Monitoring and Assessment (H) ln the monitoring and assessment stage, the overall performance of the alarm system and individual alarms are continuously monitored against the performance goals stated in the alarm philosophy. Monitoring and assessment of the data from the operation stage may trigger maintenance work or identify the need for changes to the alarm system or operating
procedures. Monitoring and assessment of the data from the maintenance stage provides an indication of the maintenance efficiency. The overall performance of the alarm system is also monitored and assessed against the goals in the alarm philosophy. Wthout monitoring an alarm system is likely to degrade.
5.2.1.9 Management of Change (l) ln the management of change stage, modifications to the alarm system are proposed and approved. The change process should follow each of the lifecycle stages from identification to implementation.
Copyright 2009 SA. All rights reserved.
ANSr/tSA-18.2-2009
-26
5.2.1.10 Audit (J)
In the audit stage, periodic reviews are conducted to maintain the integrity of the alarm system and alarm management processes. Audits of system performance may reveal gaps not apparent from routine monitoring. Execution aganst the alarm philosophy is audited'to iq"n!!ry system improvements, such as modifications to the alarm philosophy. Audits may also identiff the need to increase the discipline of the organization to follow th larm philosohy. 5.2.2 Alarm Lifecycle Entry Points
Depending on the selected approach, there are three points of entry to the alarm management lifecycle
a) b) c)
alarm philosophy, monitoring and assessment, and

audit.
These entry points are represented by rounded boxes in the diagram. As entry points these lifecycle stages are only the initial step in managing an alarm system. All itges of the lifecycle are necessary for a complete alarm managemnt system.
5.2.2.1 Start with Alarm Phitosophy (A)

The first possible starting point is the development of an alarm philosophy which establishes
the objectives of the alarm system and may be used as the basis foi the alarm system
requirements specification. This is the lifecycle entry point for new installations.
5.2.2.2 Start with Monitoring and Assessment (H)

The second possible starting point is to begin monitoring an existing alarm system and assess the performance. Problem alarms can be identified and addressed througir maintenance or management of change. The monitoring data can be used in a benchmark assessment.
5.2.2.3 Start with Audit (J) The third possible starting point is an initial audit, or benchmark, of all aspects of alarm
management against a set of documented practices, such as those listed in this standard. The results of the initial audit can be used in the development of a philosophy.
5.2.3 Simultaneous and Encompassing Stages drawn to represent sequential stages. There are several simultaneous stages which are represented at the same vertical pint in the lifecycle. Some stages encompass the activities of other stages.
The lifecycle diagram
is
The monitoring and assessment stage (H) is simultaneous to the operation and maintenance
stages.
The management of change stage (l) represents the initiation of the change process through which all appropriate stages of the lifecycle are authorized and completed.
The audit stage (J) is an overarching activity that can occur at any point in the lifecycte and includes a review of the activities of the othei stages.
5.2.4 Alarm Management Llfecycle Loops

ln addition to the lifecycle stages, there are three loops in the lifecycle. Each loop performs a function during the cycle.
-275.2.4.1 Monltoring and Maintenance Loop
ANSt/tSA-18.2-2009
The operation-monitoring and assessment-maintenance loop is the routine monitoring that identifies problem alarms for maintenance. Repaired alarms are returned to operation.
5.2.4.2 Monitoring and Management of Ghange Loop

The operation-monitoring and assessment-management of change loop is triggered when routine monitoring indicates an alarm is working per design, but is not compatible with the alarm philosophy. The design may need to be modified or an advanced alarm technique may need to be applied. The alarm may remain in operation while the management of change process is initiated and the stages of the lifecycle are repeated. 5.2.4.3 Audit and Philosophy Loop
The audit-philosophy loop is the lifecycle itself and the process of continuous improvement of the alarm system. The audit process identifies processes in the lifecycle to strengthen.
5.2.5 Alarm Management Lifecycle Stage lnputs and Outputs

The alarm lifecycle stages are connected as the outputs of one stage are often the inputs to another stage. The connections are not fully represented in the lifecycle diagram (Figure 2). Figure 3 provides more information on the relationships between the inputs and outputs of the lifecycle stages.
ANSt/rSA-18.2-2009
-28
Alarm Management
Lifecycle Stage
Stage
A
Actvteg
Clause Number
lnputs
Outputs
Ttle
Philosophy Define processes for alarm management and
ASRS.
6,7
Objectves and standards. PHA report, SRS, P&lDs, operating procedures, etc. Alarm philosophy, and list of potental alarms. Master alarm database and alarm desgn requirements. Completed alarm design and master larm database. Operational alarms and elarm response procedures. Alarm monitoring reports and alarm philosophy. Alarm dat and larm philosophy. Alarm philosophy and proposed changes. Standards, alarm phlosophy, and audt protocol.
Alarm philosophy and

ASRS,
ldentifiction
Determine potential alarms. Rationalization, classifcaton,
I
9
List of potential alarms. Master alarm database and alarm design requirements. Completed alerm design.
Retionalzation
prioritization, and
documentation.
D
Detailed Dsign
Basc alarm design, HMI design, and
10,11,12
advanced alarming design.

E
lmplementation
lnstall alarms, intial testing, and initial

training.
13
Operational alarms and alarm response procedures. Alarm data
Operation
Operator responds to alarms, refresher training. Maintenance repair and replacement, and periodc testing. Monitoring alarm date and report performance. Process to authorize additions, modifications, and deletions of alarms. Periodic audt of alarm management processes.
't4
Maintenance
15
Alarm data
Montoring & Assessment Mnagement of Change
l6
17
Alarm monitoring reports and proposed changes. Authorized alarm changes.
Audit
t8
Recommendations for improvement.
Figure 3 - Alarm Management Lifecycle Stage lnputs and Outputs
5.3 Process Condltion
Model
The process condition model, Figure 4, shows the boundaries of process conditons, from normal and target conditions to the abnormal conditions of upset and shutdown or disposal. This simple model is a useful reference in the development of alarm principles and the alarm philosophy. The warnings and indications are not to suggest alarms are required, only that under some circumstances alarms may be warranted. Every alarm is rationalized to ensure it is necessary.
-29-
ANSI/tSA-18.2-2009
Trip lndication
Upset Pre-Trip Warning
Upset lndication Pre-Upset Warning
Off-Target lndication
Figure 4
Process Condition Model
5.3.1 ProcessConditions
The process conditions illustrated in Figure 4 are described in the following sections.
5.3.1.1 Target
The target range is the set of optimal operating conditions within the normal range. These conditions may reflect highest yield, lowest cost, or target capacity operation of the process. Optimal conditions usually apply to only a subset of process variables. The target range may change with time or operating condition.
5.3.1.2 Normal
The normal range of operation is the expected operating envelope around the optimal target value. The normal range is sometimes called standard operating conditions.
5.3.1.3 Upset
The upset condition is an abnormal condition that may result in off-quality material, nonstandard product, increased emissions, or may lead to more severe consequences. 5.3.1.4 Shutdown/ Disposal The shutdown or disposal condition is the result of manual or automatic functions to avoid
u
nacceptable operatin g cond itions or unacceptable prod uct.
ANSr/tSA-18.2-2009
-30-
5.3.2 Process Gondition Warnings and lndications

The transitions between process conditions are the usual points for alarm indications. This model should not be interpreted to suggest alarms are necessary for all of the transitions, but that for different process variables different transitions may be selected for alarms.
5.3.2.1 Off-Target lndication

The off-target indication is triggered at the boundary of the target operating envelope. These indications provide the notification that a process variable is still in the normal range and is no longer in the optimal target range.
5.3.2.2 Pre-Upset Warning

The pre-upset warning provides advance notice of abnormal conditions. tMere upset or nonstandard conditions have significant consequences (e.9., equipment damage or off-quality product), there may be a warning that provides enough time to avert the upsetconditions.
5.3.2.3 Upset lndication

The upset condition indication provides notification of the upset condition. tMen a pre-upset warning is not justified, this may be the first notification of an abnormal condition. U/here reupset warnings are provided, the upset condition indication may be a confirmation of upset operation such as off-quality material or a permit violation.
5.3.2.4 Pre.Trip Warning The pre-trip warning provides an opportunity to avoid the shutdown trip or condition that requires disposition of the product. Not all process indications provide warning of trip conditions. The term trip may refer to an emergency shutdown of a plant or a loca[ process
interlock on a single piece of equipment.
5.3.2.5 Trip lndication

The trip indication provides an indication that a shutdown has occurred or a disposition limit has been violated. The disposition limit is the point of no return after which a product is unusable. Post-trip alarms may indicate the need for further action (e.g., failure of the trip function).
5.4 Alarm States

The alarm state transition diagram shown in Figure 5 represents the states and transitions for typical alarms. \Mrile there are exceptions, this diagram describes the majority of alarms and
serves as a useful reference for the development of alarm system principles and HMI functions. Note some terms used in this diagram were used in the process condition model, Figure 4.
-31
A
Normal
Process: Ol(
Alarm Occurs
ANStnSA-18.2-2009
Alm:OK
Re-Alarm
B
UnackAlarm
Process: Alarm
ProcessRTN
AlarmClears
Operator Acks Alarm
Alm:Alarm
Operator
Resets
Alarm
or
Auto Ack
c
AckAlarm
Process: Alarm
Operator
AcksAlarm
Alm:Alarm Ack
Process Alarm Occurs
RlN
ProcessRTN
D RN Unack
Process RN Process: Ol(
AlarmClears
Alm:0(
U
LatchAck
Process:Ol(
Alm: Alarm
Operator Resets Alarm Operator
E Latch Unack
Process: Ol(
Alm:Alarm
U
AcksAlarm
I
Shelve Un-shelve
Designed Suppression
Designed Un-suppression
Remove f romService
I
Returnto Service
tt Shelved
Process: N/A
Suppresse Design
Alm:N/A
Out Of
Service
Process
N
Alm:N/A
Process: N/A
Figure 5 - Alarm State Transition Diagram

NOTE NOTE
States G, H, and I can connect to any alarm state in the diagram. The dotted line ndicates an infrequently implmented option.
Copyright 2009 SA. All rights reserved
ANSr/rSA-18.2-2009
-32-
5.4.1 Alarm States

The circles in the Figure 5 represent the states of an alarm. The letter label is an identifier used in the text. The second line is a state name, often abbreviated. The third line describes process conditions, the fourth and fifth lines list the alarm status and its acknowledgement status, respectively. The possible states of alarm suppression are shown on the lower part of the diagram.
5.4.1.1 Normal (A)
he normal alarm
state is defined as the state in which the process is operating within normal specifications, the alarm is clear and past alarms have been acknowledged.
5.4.1.2 Unack Alarm (B)

The unacknowledged alarm state is the initial state upon trigger of an alarm due to off-target, upset, or shutdown process conditions. In this state the alarm is unacknowledged. Previously acknowledged alarms may be designed to re-alarm, triggering a return to this state. The alarm may be silenced in the unacknowledged alarm state.
5.4.1.3 Ack Alarm (C)

The acknowledged alarm state is reached when an alarm has not cleared, but an operator has received the alarm and acknowledged the alarm condition.
5.4.1.4 RTN Unack (D) The returned to normal unacknowledged alarm state is reached when the process returns within normal limits and the alarm clears automatically (sometimes called auto-reset) before an operator has acknowledged the alarm condition. 5.4.1.5 Latch Unack (E)
Similar to the RTN Unack state, the latched unacknowledged alarm state occurs when the process returns to normal before the operator has acknowledged the alarm. The alarm itself remains latched and requires further action by the operator to reset the alarm. The latch function is an option.
5.4.1.6 Latch Ack (F)

The latched acknowledged alarm state is the state in which the operator has acknowledged the alarm and the process has returned within normal limits but the alarm remains latchd, pending operator reset. The latch function is an option.
5.4.1.7 Shelved (G)
The shelved state is used when an alarm is temporarily suppressed using a controlled
methodology. An alarm in the shelved state is under the control of the operator. The shelving system may automatically unshelve alarms.
5.4.1.8 Suppressed by Design (H)

The suppressed by design state is used to suppress alarms based on operating conditions or plant states. An alarm in the suppressed by design state is under the control of logic that determines the relevance of the alarm.
-335.4.1.9 Out-of-Service (l)
ANSl/tSA-18.2-2009
The out-of-service alarm state is used to manually suppress alarms (e.9., use control system functionality to remove alarm from service) when they are removed from service, typically for maintenance. An alarm in the out-of-service state is under the control of maintenance.
5.4.2 Alarm Cycle Transition Paths

The arrows in the diagram represent transitions between states. For simplicity, the diagram does not illustrate effects of deadband and time delays. \Nhen the process is considered to be in alarm, the process variable has exceeded the alarm setpoint for the alarm on-delay period.
5.4.2.1 Alarm Occurs (A->B)

The process has gone out of the normal range beyond the alarm setpoint and has remained in ths state long enough to trigger the alarm.
5.4.2.2 Operator Ack (B->C)
An operator acknowledges an active alarm before taking action to return the process to
normal.
5.4.2.3 Re-Alarm (G->B) The re-alarm path shows the infrequently used option that periodically generates repetitive
alarm indications for a single alarm while the alarm remains in the alarm state.
5.4.2.4 Process RTN Alarm Clears (C->A)

This is part of a normal seguence for a non-latching alarm that does not require a separate action to reset it. The alarm moves from the acknowledged state to normal.
5.4.2.5 Process RTN (C->F)

The latched alarm remains in the alarm state when the process condition returns to normal.
5.4.2.6 Process RTN and Alarm Glears (B->D)

The process returns to normal before an operator has acknowledged the alarm and the alarm does not latch.
5.4.2.7 Operator Ack (D->A)

An alarm that has already cleared the normal state may require operator acknowledgment.
5.4.2.8 Process RTN (B->E)

The process returns to normal before an operator acknowledges the alarm but the alarm is latched.
5,4.2.9 Operator Resets (E->D)

An operator resets an alarm before acknowledging it.
5.4.2.10 Operator Ack (E->F)

An operator acknowledges a latched alarm for which the process has returned to normal.
ANSt/tSA-18.2-2009
-34-
5.4.2.11 Operator Resets (FA)

The latching alarm has been acknowledged and the process has returned to normal. When the alarm is reset, the alarm returns to the normal state.
5.4.2.12 Shelve (Any State .> G) and Un-shelve (G -> Any State)
An operator may shelve an alarm to avoid clutter in the actve alarm displays. Shelving and un-shelving are typically manual operations.
5.4.2.13 Designed Suppression (Any State Any State)
H) and Designed Un-suppression (H .>
or states may also
Process conditions or states may be used to suppress alarms by design. Process conditions
designed un-suppression are typicatly automatic operations.
un-suppress alarms when appropriate. Designed suppression and
5.4.2.14 Remove-from-Service (Any State -> l) and Return-to.Service (l .> Any State)
An operator may remove an alarm from service for maintenance or other reasons and return an alarm to service when it is available. Remove from service and return to service are typically manual operations.
5.5 Alarm Response Timeline

Figure 6 represents a process measurement that increases from a normal condition to an abnormal condition and the two possible scenarios based on whether the operator takes the corrective action or not. Using Figure 5, it is possible to map some states to this timeline to clarify the definition of terms related to tme.
Normal (A)
Unack Alarm (B)
Ack & Response
Return
(c)
process reSpODsel. without operator action \
Normal(D)
a (
(l'
threshold
measurement
'
s
o-
u,
vt Q
process
operator takes action
o (t
response o operator action
r
deadband delay
ack delay operator process deadtime
alarm setpoint alarm deadband response
Figure 6 - Alarm Timeline

-355.5.1 Normal (A)
ANSt/tSA-18.2-2009
The normal alarm state is defined as the state in which the process is operating within normal specifications, the alarm is clear and all past alarms have been acknowledged.
5.5.2 Unack Alarm (B)

The unacknowledged alarm state results when the measurement crosses the alarm setpoint. There are several factors that affect the uncertainty of the alarm trigger time such as
a) measurement
b)
accuracy, and
alarm delay time.
5.5.3 Ack and Response (C)
The acknowledged alarm state is reached when an operator acknowledges the alarm condition, after the acknowledge delay. ln this state the alarm has not cleared. There are
several factors that affect the uncertainty of the operator response time such as
a) system processing speed, b) HMI design and clarity, c) operator awareness and training, d) operator workload, e) complexity of determining the corrective action,
and
f)
complexity of the corrective action.
From the time the alarm is triggered until the operator takes the correct action is the actual response time for the alarm, or operator response delay. lt includes the detection of the alaim, the diagnosis of the situation and determination of the corrective action in response, and the executon of that response. The upper limit of the response time is the allowable response time, the point beyond which the consequence will occur even if action is taken.
5.5.4 Return to Normal (D)

The return to normal alarm state should result from the correct operator action within the allowable response time. There are several factors that affect the uncertainty of the return to
normal time. These include the following:
a) the operator response delay; b) the degree of action taken;
c)
d) e)
f)
g)
the the the the the
process deadtime in response to the corrective action; process response time to the corrective action; accuracy of the process measurement; deadband of the alarm setpoint; operational speed of the alarm system.
5.5.5 Gonsquence Threshold

The consequence results when no operator action is taken, the incorrect or insufficient action is taken, or the action is not completed within the allowable response time. The consequence begins to occur at the consequence threshold. The total time from the alarm to the cosequence threshold includes the acknowledge delay, the operator response delay, the process deadtime, and the process response delay.
ANSt/rSA-18.2-2009
-36-
5.6 Feedback Model of Operator - Process lnteraction

A model of operator-process interaction is shown in Figure 7. ln response to a disturbance or malfunction, the process or system undergoes some change. lf that change deviates significantly from the reference or objective for the process, the operator takes action to bring the process back to the reference and continues to monitor the measurement as it returns. l
order for the action to occur, three stages of activity occur
a) b) c)
the deviation from desired normal operation is detected, the situation is diagnosed and the corrective action determined, and the action is implemented to compensate for the disturbance.
Disturbance/ Malfunction Operator Sub-System Detect Diagnose Respond Process/ System
Reference/
Measurement
Figure 7 - Feedback Model of Operator Process Interaction
5.6.1 Detect
The operator becomes aware of the deviation from the desired condition. The design of the alarm system and the operator interface impact detection of deviation.
5.6.2 Diagnose
The operator uses knowledge and skills to interpret the information and diagnose the situation and determine the corrective action to take in response.
5.6.3 Respond
The operator takes corrective action in response to the deviation.
5.6.4 Performance Shaping Factors

The ability of the operator to carry out the sub-system functions is affected by a variety of variables, including workload, short term or working memory limitations, fatigue, training, and motivation.
Alarm Philosophy
6.1 Purpose
Alarm philosophy is a separate stage of the alarm lifecycle. The alarm philosophy serves as the framework to establish the criteria, definitions and principles for the alarm lifecycle stages classification, prioritization, monitoring, management of change, and audit to be followed. An alarm philosophy document ensures that facilities can achieve Copyright 2009 lSA. All rights reserved.
by
specifying items including
the methods for alarm
identification, ratinalizatircn,
-37
ANSt/rSA-18.2-2009
a) consstency across process equlpment, b) consistency with risk management goals/objectives, c) agreement with good engineering practices, and d) design and management of the alarm system that supports an effective
response.
operator
6.2 Alarm PhilosophY Contents

This section provides the minimum and recommended content to be addressed in the alarm philosophy. Due to the wide variety of equipment used within the process industry, the betailed content of the alarm philosophy may vary between industries and from one location to another. The required and recommended contents of the alarm philosophy are listed in Figure 8.
ANSI/f SA-18.2-2009
-38-
ALARM PHILOSOPHY CONTENTS

Purpose of alarm system Defintions References Roles and responsibilities for alarm management
Y Y Y Y Y
REQUIRED
RECOMMENDED
Alarm design principles Rationalization

Alarm class definiton
Highly managed alarms (or site equvatent)

HMI design guidance Alarm setpoint determination
'(
Prioritzation method
Alarm system performance montoring Alarm system maintenance
'(
(
v
Iesting of alarms
Approved advanced alarm management techniques Alarm documentation
Y
Y
mplementeton guidance \lanagement of change Training Alarm history preservation Relted site procedures Special Alarm Design Considerations
( ( (
Figure
I-
Required and Recommended Alarm philosophy Content
For systems designed for new plants, the alarm philosophy should be drafted as part of the project planning and development, and be fully defined and approved before the system has been commissioned.
philosophy should be one of the first stages of the remediaton effort.
For existing systems which are beng remedated, and no philosophy exists, the alarm
6.2.1 Purpose of Alarm System

Defining the purpose and objectives of a process plant alarm system serves to orient particpants in design and improvement activities. Having this definition ensures that participants can implement and mantain an effective alarm system based on nformed decisions during the execution of these activities.
6.2.2 Definitions
Terms that will be encountered in the course of design and improvement of an alarm system shall be defined to ensure that all participants share a common understanding.
-396.2.3 References
ANSt/rSA-18.2-2009
A list of appropriate references for alarm management should be included. References can be internal company documents (e.9., management of change) or external published material (e.9., OSHA, ISA).
6.2.4 Roles and Responsibilities for Alarm Management

Responsibility for the activities of the alarm lifecycle shall be established in the alarm philosophy. Specific aspects to cover include the following:
a) b)
the owner of the alarm system, the philosophy, and related documents; the role responsible for management and regular maintenance of the alarm system; the role responsible for technical support to resolve problems with the alarm system; the role responsible to ensure that the requirements outlined in the alarm philosophy are followed.
c)
d)
6.2.5 Alarm Design Principles

The definition of an alarm, with examples that meet and do not meet the definition, shall be documented in the alarm philosophy. The criteria for selection and principles for design of alarms should be consistent with the definition of an alarm.
The criteria and principles should address
a) b)
c)
the role of the alarm system in identifying approaches to unsafe or sub-optimal operation, warning of malfunctions, and prompting the operator of actionable changes in the process, the methods to be used for alarm identification, and the alarm states (e.9., normal, acknowledged, latched, shelved, etc.) that the facility will
use.
6.2.6 Rationalization
actionable is done through alarm rationalization. This section of the alarm philosophy should list the criteria for alarms and the information to be captured during rationalization.
ln order to maximize the functionality of the alarm system it is important that the operator receive only those alarms that are meaningful and actionable. Ensuring that an alarm is
6.2.7 Alarm Class Definition

Alarm classes are used to set common characteristics and requirements for managing alarms. An alarm may belong to more than one class. This section should include the definition of the alarm class. lt should also include the following requirements:
a) alarm documentation; b) operator training and training documentation; c) operating procedures associated with these alarms; d) alarm maintenance; e) alarm testing;
f) i) j)
k)
alarm monitoring and assessment;
g) alarm management of change; h) alarm history retention;

alarm audit; alarm prioritization; HMI design; Copyright 2009 lSA. All rights reserved.
ANSt/tSA-18.2-2009
-40-
l)
alarm operation.
6.2.7.1 Highly Managed Alarms

Highly Managed Alarms (HMA) are classes of alarms that require more administration and documentation than others. Since the criteria may vary by process, industry or location, the alarm philosophy shall define the criteria for assigning alarms to HMA classes. The designation of alarm classes as highly managed should be based upon one or more of the following:
a) b)
alarms critical to process safety or the protection of human life (e.g., safety alarms); alarms for personnel safety or protection; alarms for environmental protection; alarms for current good manufacturing practice; alarms for product quality; alarms for process licensor requirements; alarms for company policy.
c)
d) e)
g)
Not all sites will have HMAs. lf a site does use HMAs, this section of the alarm philosophy shall be used to explicitly document the requirements for this alarm class.
6.2.8 HMI Design Guldance

Documenting the method, format, and coding (e.g., color, symbol, and alpha-numeric) for alarm presentation to the operator establishes guidelines for display and annunciation so that they are consistent throughout the plant. Specific elements that should be covered in this section include the following:
a)
b)
c)
d)
the mechanism used (e.9., panel, BPCS console screens, etc.) to communicate the alarms to the operator; recommendations for the indications on the HMI of the alarm states (e.g., normal, acknowledged, latched, shelved, etc.) that will be used at the facility; the types of displays that will be used (e.9., alarm summary, overview, first-out, etc.); the functions that will be available in the HMl, including shelving and suppression.
6.2.9 Prioritization Method

Consiste_nt priorities aid
events. Specific elements that shall be covered in this section include the following:
the operator in deciding the order of response during high alarm
a)
b)
the basis for alarm prioritization (e.9., time to respond, severity of consequence, etc.); the metrics for alarm configuration (e.9., alarm count and priority distribution); any impact of classification on prioritization.
c)
6.2.10 Alarm Setpoint Determination
This section should provide guidance on the methods used for determination of alarm
setpoints.
6.2.11 Alarm System Performance Monitoring

Metrics are used to monitor alarm system performance against the target performance levels. This section provides a basis for assessing performance to decide i f improvements are required.
-41'
ANSI/rSA-18.2-2009
Specific elements that should be covered in this section include the following:
a) the objective for monitoring and assessment; b) the monitoring metrics and target values;
c)
guidance on the approach to improve performance on the metrics'
6.2.12 Alarm System Maintenance

This section identifies the activities necessary to maintain the alarm system. Specific elements that should be covered in this section include the following:
a) b) c)
alarm maintenance record keeping; the requirements around out-of-service alarms; the policy on the use of interim alarms.
6.2.13 Testing of the Alarm SYstem This section identifies procedures to ensure consistent and adequate testing of the alarm system throughout the larm lifecycle. Decisions around applicability, criteria, methods, and
frequency should be thoroughly documented by alarm classes.
6.2.14 Approved Advanced Alarm Management Techniques

Approved advanced alarm management techniques and the conditions or criteria for their use, sttuld be identified. ldentification of approved advanced alarm techniques supports the training of personnel on these techniques. Not all sites will use the advanced/enhanced alarm management techniques (see Clause 12). lf a site does use advanced enhanced alarm management techniques, this section of the
alarm philosophy shall be used

responsibilities and work processes.
to
identify the techniques
to be used and related
6.2.15 Alarm Documentation

Appropriate documentation should be defined and retained, including the following:
a) b)
rationalization information (e.9., a master alarm database); periodic alarm performance reports.
Other documentation needs may be identified by the requirements of the different alarm
classes.
Appropriate documentation ensures that advanced techniques are implemented consistently, pidviOng expected behaviors to the operator across all modes of operation.
6.2.16 lmplementation Guidance

Defining the basic approach for commissioning and checkout of the alarm system ensures that thi is done in a'effective and consistent manner throughout the plant or company. This assures the effective deployment of the alarm system'
6.2.17 Management of Change

This section identifies the types of changes and the applicable procedures. Types of changes may include
ANSt/rSA-18.2-2009
-42-
a) b)
temporary changes to alarms (e.9., out-of-service), temporary changes to alarm attributes in conjunction with an advanced alarm system for alarm attribute enforcement, and
c)
permanent changes
suppression.
to the
master alarm database, alarm attributes,
or
designed
Permanent changes follow a management of change procedure to ensure that changes made during design, implementation, operation, or maintenance are appropriately evaluted and approved by the authorized parties and documented. This typically includes documented assessment of each change, records of system modifications, and authorization.
6.2.18 Training
This section specifies how plant personnel are to be trained on the use, management, and design of the alarm system. This is included to ensure that the instructors responsible for training are aware of the need for and their responsibility to provide appropriate trainng on the alarm system and any changes made to the alarm system. This section should lso specify the training documentation requirements.
Specific aspects of training that should be covered in the alarm philosophy or other equivalent documentation for each of the alarm classes include
a) the job roles or personnel requiring training b) an outline of the training contents, and c) when training is required.
6.2.19 Alarm History Preservation
relating to the alarm system,
This section defines what aspects of the alarm history (e.g.,
annunciations, acknowledgements, return to normal, and operator actions) should be preserved and for how long in response to specific events (e.9., incidents, violation of safe operating limits). ln some industries and regions, regulatory bodies or local statute may require preservation of this information.
6.2.20 Related Slte Procedures

To avoid inconsistencies between the alarm philosophy and other site procedures, the alarm philosophy should cite relevant procedures. The following documents may be related to the alarm philosophy:
a) standard operating procedures; b) operator training policies and guides; c) safety, health and environmental procedures; d) maintenanceprocedures; e) alarm handling policies and codes;
application programming guidelines; commissioning or qualification processes and procedures; other site procedures related to the alarm philosophy depending on the specific site.
g) h)
6.2.21 SpecialAlarm Design Considerations

The philosophy document should specify rules and methods for the design of alarms covering specific circumstances where consistency is important (e.g., bypass alarms and alarms from redundant sensors). Alarm classes may be the source of such specific design considerations.
-436.3 Atarm Philosophy Development and Maintenance
ANSt/tSA-18.2-2009
Personnel who apply the alarm philosophy should be involved in developing the alarm philosophy. Personnel involved should be equipped with detailed knowledge and understanding of design, operation, and maintenance of the process related to the site. Specific areas of expertise include
a) a)
b)
process operations,
process instrumentation, control systems,
c) process technology, d) mechanical/reliability engineering, e) safety, health and environmental,
f)
g)
alarm management, and

management of change process.
Alarm System Requirements Specification
NOTE This clause is lnformtive and does not contain mandatory requrements.
7.1
Purpose
The alarm system requirements specification (ASRS), which may also be called an alarm functional requirements specification, is part of the philosophy lifecycle stage. This clause provides guidance on the development and uses of an alarm system requirements pecificatin. The ASRS documents the alarm functionality expected of the control system. The ASRS is often a subset of the overall system requirements specification of a control
system.
The alarm system requirements specification is typically specific to a site, an individual control system, or group of similar control systems. \Nhile the ASRS is consistent with the alarm philosophy, it contains more detailed functional requirements of the alarm system than the alrm philosophy, including detailed user requirements and considering relevant site
infrastructure requirements. These requirements are used to help evaluate systems, guide the detailed system design, help determine if any system customization or use of third party products i necessary, and serve as the primary basis of alarm system function testing during implementation. lt is important to distinguish an ASRS from individual alarm activities that occur later on in the lifecycle of a system. The ASRS specifies what alarm functionality to be available when rationaliiing, desighing, implementing, visualizing and recording individual alarms, and in analyzing alarm records. The ASRS is typically generated early in the planning for a new control system. lt is updated through the implementation stage to ensure consistency with the targeted capabilities of the chosen system and, therefore, relevant in driving system design, system testing, and training activities. The ASRS is not normally updated following system implementation. Changes to
alarm system functionality can occur during the life of a system. These changes can be managed and documented via management of change.
7.2
Recommendations
Planning for new control systems and major revisions to the alarm functionality of existing control systems should include an ASRS, with the ASRS containing specifications for some or all of the following:
a) alarm attributes; b) alarm HMI; c) alarm communication
infrastructure; Copyright 2009 lSA. All rights reserved.
ANSt/tSA-18.2-2009
-44-
d) alarm record logging; e) alarm record analysis;
other capabilities that facilitate alarm lifecycle activities.

may_
There
be new control system projects in which it is determined an ASRS is not necessary to omit the ASRS and the rational supporting it should be documented.
(e.9., replicating existing systems). The decision
7.3 Development
The- alarm system
performance
requirements. The alarm philosophy may contain guidance that can be used to generate some of the alarm system requirements specification, including the following:
of the overall system may require
is only one of the functional systems within a control system and the compromise on the alarm system
a) b)
alarm priorities available;
c)
d) e)
g) h)
i) j)
k)
visualalarm indication capabilities, such as colors and symbols; audible alarm indication capabilities; alarm summary display functionality; alarm shelving functionality; alarm suppression capabilities; alarm configuration capabilities, such as deadband and time delay; alarm log capabilities, such as operator response entry and batch identification; alarm monitoring and assessment capabilities; alarm system audit functionality; advanced alarming functionality.
\p-fe Qomg alarm requirements may exist in other documents, such as in a safety requirements specification for SIS applcatons, as defined in ANS|/|SA 94.00.01-2004 part 1 (lEC 61311 Mod).
7.4 Systems Evaluation

Alarm system functionality should be evaluated against requirements during control system selection. The alarm. system functionality of process control systems variel from the very limited to the very advanced. The alarm system requirements secification provides a list of specific criteria which can contribute to the comparative evaluation of differeni systems.
7.5 Customization and Third-Party Products lf important system requirements in the specification are not met by standard commercial products, it may be necessary to develop custom solutions, which may include third-party products, or to reconsider the specification. Custom developed solutios may have nignei
req.uirements specification facilitates early recognition of the need for customized soluiions, including use of third party products, and an iniate associated cost /benefit analysis.
lifecycle costs than use of slngte supplier commercially available solutions. Thsalarm syJtem
7.6 Alarm System Requirements Testing

Each alarm system requirement should be tested prior to the operations stage of the lifecycle.
ldentification
NOTE This clause is lnformatve end does not contain mandetory requirements.
-458.1 Purpose
ANSt/tSA-18.2-2009
ldentification is a separate stage of the alarm lifecycle. ldentification is a general term for the different methods tht 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 the recommended alarms or alarm changes. ldentified alarms are an input to rationalization.
8.2 Alarm ldentification Methods

This standard does not define or require any specific method for alarm identification. Alarms may be identified by a variety of good engineering practices or regulatory requirements. Some combination of idetification meihods shbuld be used to determine potential alarms' Where appropriate, alarm identification may be done during alarm rationalization.
Some common alarm identification methods are
a) allocation of safety layers, b) process hazards analysis (PHA),
c)
d) e)
layer of protection analysis (LOPA), incident investigations, environmental permits, failure mode and effects analysis (FMEA), current good manufacturing practice (cGMP),
ISO quality reviews,
f)
g) h)
) j)
k)
P&lD reviews, operating procedure reviews, and packaged equipment manufacturer recommendations
Rationalization
9.1 Purpose
Rationalization is a separate stage in the lifecycle. During rationalization, existing or potential alarms are systematlctty compaied to the criteria for alarms set forth in the alarm philosophy. lf the proposed alarm mets te criteria, then the alarm setpoint, consequence, and operator action'ar documented, and the alarm is prioritized and classified according to the philosophy. Rationalization produces the detail design information necessary for the design stage of the alarm lifecycle.
9.2
Objective
Rationalization shall determine and document, at a minimum, the following for every alarm rationalized per the site alarm philosophy for every applicable process state:
a) alarm type; b) priority;
c)
d) e)
class; alarm setpoint value or logical condition (e.9., off-normal); operator action; conseguence of inaction or incorrect action; need for advanced alarm handling techniques if necessary.
f)
g)
Gopyright 2009 lSA. All rights reserved.
ANSr/tSA-18.2-2009
-46-
9.3
AlarmJustification
During this stage, every alarm requiring rationalization is compared to the criteria set forth in the .alarm philosophy for selection to justify that it is an alarm. lnitial training of the participants on alarm management and design may improve the effectiveness of the analysis.
9.3.1 Justification Approach

The comparison activity should
a) utilize a team approach, b) rely heavily upon operator input, and c) focus on the operator action to be prompted.
9.3.2 lndividual Alarm Justification
All alarms to be rationalized are systematically reviewed. This usually is done either
progression through engineering drawings, databases, or HMI displays. The information to be captured for each rationalized alarm should be specified in the alarm philosophy, but typically includes
by
a) verification that proposed alarm meets the criteria for an alarm stated in the philosophy, b) the response action(s) the operator may take, c) the consequence that will occur if action is not taken or is unsuccessful, and d) the time required between alarm annunciation and the occurrence of the specific
conseguence.
Those alarms for which the console operator's primary response is simply to relay the information to the appropriate person or group for action (e.g., instrument diagnostic alrms) should be reviewed to determine if an alternate method exists to transfer the information
without burdening the operator or the alarm system.
9.3.3 lmpact on Alarm System

Alarm justification and prioritization should also consider the functioning of the alarm, together with the alarm attributes, ensuring that
a) b)
the alarm will not become a nuisance or standing alarm, and the alarm does not duplicate another alarm that has the same operator actions.
lf either is true, then advanced alarming techniques (e.g., state based alarming or logic based alarms) may need to be specified to prevent this from occurring. Alarms on redundant equipment or redundant instrumentation are often the reasons for either of these to be true.
9.4
Alarm Setpoint Determination
Guidance for the determination of alarm setpoints stated in the alarm philosophy is a pplied. Effective methods use the allowable response time (see Figure 6), the compexity of the operator action, knowledge of the process operation and history, and other factors.
9.5
Prioritization
The method for priority assignment defined in the alarm philosophy is applied to the rationalized alarm and a priority assigned. Effective prioritization typically results in higher
priorities chosen less frequently than lower priorities. Most of the alarms should be assigned to the lowest alarm priority (least important) and the fewest to the highest alarm priority (most important), with a consistent transition between the two. The resulting priorities.shoud'have alignment with the consequence and allowable response time, such that the lowest priority
-47-
ANSt/tSA-18.2-2009
alarms have the least severe consequences and longest allowable response times and the highest priority alarms have the most severe consequences and the shortest allowable response times. Distribution metrics for priority are provided in Clause 16.
9.6
Removal
Existing alarms which fail to meet the criteria for alarming provided in the alarm philosophy shall be documented along with the basis (i.e., criterion it failed to meet) justifying removal. Those alarms should then be subject to further review per the MOC process to remove the alarm attributes from the instrument.
9.7
Classification
Classification is an activity completed in the rationalization stage of the alarm lifecycle. Alarms shall be assigned to one or more classes as defined in the alarm philosophy. Not all alarms in a class need have the same priority.
The classification may occur prior to, during, or after the alarm justification and prioritization.
9.8
Review
Upon completion of the initial justification, prioritization, and classification of all the required alarms, the results should be reviewed to ensure consistent application of the criteria throughout the process. The results should be compared to any targets for number and priority of alarms that might be set forth in the alarm philosophy.
9.9
Documentation
Rationalization shall be documented to become the basis for ensuring the integrity of the alarm system. The documentation (e.9., a master alarm database) delineates the link between each alarm and the alarm philosophy and can be used for several purposes, including:
a) input to the detailed design stage of the alarm lifecycle; b) utilization as part of the management of change; c) training of and review by operators; d) periodic auditing and reconciliation of the control system alarm settings; e) evaluation of alarm monitoring and effectiveness data.
l0
Basic Alarm Design

Purpose
l0.l
Basic alarm design is part of the detailed design stage of the lifecycle. This clause presents the essential requirements to implement the alarms defined by the rationalization process within a specific control system. lnformation in this section addresses the design considerations associated with the triggering of alarms. All design considerations related to the presentation of alarms will be contained in Clause 11.
10.2
Usage of Alarm States
The goal of this activity is to define which alarm states are used during operation of the
system. As shown in Figure 5, the possible alarm states are as follows:
a) Normal; b) unack alarm; c) ack'd alarm; d) RTN unack;

ANSt/rSA-18.2-2009
-48-
e)
latch unack (optional); latch ack'd (optional);

by design;
f) i)
g) shelved; h) suppressed
out-of-service.
The latching capability represented by latch unack and latch ack'd is optional. This function may not be available in a particular system or users may choose not to utilize these states during operation.
lf.
alarms, alarm classes, or the entire system) should be documented.
the alarm latching capability is used, then the scope of implementation (i.e., individual
10.2.1 Alarm State Triggering

The source for each alarm in the system should be documented. Changes in alarm state can be triggered from various sources within a control system as shown in Figure 1, including
a) b)
the field device (e.9., sensors and finalcontrol elements), the control and safety system, and
c)
the HMl.
Use of Alarm State lnformation
10.2.2
A clear and consistent philosophy should be documented regarding the use of alarm state information within configuration logic, such as driving interloc actios. lf alarm setpoints will be used for purposes in addition to operator notification (e.g., as an interlock setpint, then
documentation, training and management of change may bempacted. Additionally the impact of modifying alarm setpoints and attributes as well as the use of designed suppresion shuld be clearly identified, documented, and potentially restricted (e.g., extia confiiriration or higher access level required). This information should be specifically documented in the alarm philosophy under alarm design principles.
10.3 Alarm Types

Alarm types should be designed for each alarm as defined during the rationalization activity The common alarm types to be considered include the following:
a) b)
absolute alarms; deviation alarms; rate of change alarms;
c)
d) discrepancy alarms; e) calculated alarms;
recipe-driven alarms;
g) bit-pattern alarms; h) controller output alarms;

systems diagnostic alarms; instrument diagnostic alarms; adjustable alarms;
i) j)
k)
l)
adaptive alarms; m) re-alarming alarms;
n)
statisticalalarms;
-49o) frst-out alarms; p) bad measurement alarms.
ANSt/tSA-18.2-2009
The available alarm types that are included within the control system vary.
necessary to create a custom alarm type as part of the engineering scope on a project.
lt may be
Alarm types should be selected carefully based on engineering judgment. Certain types, such as rate-of-change, deviation, bad measurement, and controller output alarms, are common they are not applied sources of nuisance alarms during process upset conditions appropriately.
if
10.4 Alarm Attributes

During the basic design process the default alarm attributes should be configured for each alarm that has been identified during rationalization and set according to the master alarm database or based on engineering judgment. Attributes such as setpoint (e.9., limit), deadband or on and off delays, may be different depending upon the specific alarm type that will be implemented. Defining appropriate values can help minimize the number of nuisance alarms that are generated during operation. Recommendations for the design of specific alarm attributes are provided in the following sections.
10.4.1 Alarm Setpoints

Alarm setpoints should be configured based on the information documented in the master alarm database.
10.4.2 Alarm Deadbands

Alarm deadbands are an alarm attribute within the process control system that requires the process variable to cross the alarm setpoint into the normal operating range by some percentage of the range (see Figure 6). Deadbands are typically set based on the normal operating range of the process variable, measurement noise, and the type of process variable. Application of deadbands can be very effective in eliminating nuisance alarms. 10.4.2.1 Alarm Deadband Requirements
The control system shall provide the capability for implementing deadband functionality
10.4.2.2 Alarm Deadband Recommendations
The engineering basis for setting of deadbands should be documented in the alarm philosophy. Figure 9 provides recommendations which represent a good starting point for common processes. Proper engineering judgment should be employed when setting deadbands in order to minimize nuisance alarms while maintaining process vigilance and plant / personnel safety. Excessive deadband, such as what might be calculated for an instrument with a large scale (e.9., flow of 0 - 100,000) can act as a latch, creating stale
alarms. Settings should be documented and then reviewed during commissioning and after significant operating experience.
Signa! Type
Deadband
(Percent of Operating Range)

Flow Rte Level Pressure Temperature
-5o/o -5o/o -2o/o -1o/o
Figure 9 - Recommended Starting Point Deadband Based on Signal Type

ANSt/tSA-18.2-2009
-50-
Reference: ML Bransby, "The Management ofAlerm systems", HSE Books, 1998, pp. 193-1gs
10.4.3 Alarm On-Delay and Off.Delay

The attributes on-delay and off-delay (i.e., filter timer and debounce timer) can be used to eliminate nuisance alarms. The on-delay is used to avoid unnecessary alarms when a signal temporarily overshoots its limit, thus preventing the alarm from being tiiggered until the signal remains in the alarm state continuously for a specified length of time. The off-delay is use to reduce chattering alarms by locking in the alarm indication for a certain holding period after it
has cleared.
10.4.3.1 Alarm On-Delay and Off.Delay Requirements

functionality
The control system shall provide the capability for implementing on-delay and off-delay
10.4.3.2 Alarm On-Delay and Off-Delay Recommendations
Figure 10 provides recommendations which represent a good starting point for common processes. Proper engineering judgment should be employed when setting on and off delays
in order to minimize nuisance alarms while maintaining process vigilnce and plant
-or
and whether PV filtering is being applied to reduce signal noise. On-Oetay times should be applied only after careful evaluation and potential control system operational effects. Settings should be reviewed during commissioning and after significant operating experience.
Signal Type
Flow Rate Level Pressure Tempereture Delay Time (On or Off)
personnel safety. Delay times should consider residence time during al modes of oeration
-15 Seconds -60 seconds

-'15 seconds
-60 seconds
Figure l0
Recommended Delay Times Based on Signal Type
Reference: ML Bransby, "The Management of Alarm systems", HSE Books, 1999, pp. 193-19s
10.5 Programmatic Changes to Alarm Attributes

Some sites modify alarm attributes based on conditions such as product type or grade. Alarm attributes can typically be modified from one or more of the following sourCes:
a) operator interface (e.9., manual changes during operation); b) engineering interface (e.9., design changes under management of change);
c)
d)
control logic (e.9., sequences, phases);
external to the control system (e.9., Manufacturing Execution System (MES), Enterprise Resource Planning (ERP) system, or advanced alarming program).
The alarm philosophy should detail the use and limitations of this technology. For each alarm the user should identiff and clearly document which sources of the control system will have programmatic access to modify attributes during operation and which sources will be subject
to management of change
10.6
attributes are covered in Clause 12. Review Work Product
procedures. More advanced techniques
for modifying alrm
A typical control system provides the user with the ability to implement numerous different alarm types for a single process variable. To minimize alarm loading on the operator, the Copyright 2009 lSA. All rights reserved.
- 51 -
ANSI/|SA-18.2-2009
basic alarm design results should be reviewed against the master alarm database to ensure thn only requird alarms are being activated. The methods for activation and deactivation may be fernt based on the specific functionality provided in the control system.
11 Human-Machine lnterface Design for Alarm Systems

11.1 Purpose
The HMI design for alarm systems is part of the detailed design -lifecycle 9ta.9e. This section ouines the fu-nctionality to irovide alarm indications and related functions to the operator and other HMI users. The indiation and display of alarms is only one component of the HMI design, and contributes to effective operator-process interaction (see Figure 7). Guidance on genral HMI design for control systems is outside the scope of this standard. The capabilities of control systems vary widely. Some features described in this section are not available in all systems.
11.2 Overview
The HMI design for alarms follows the alarm philosophy, is consistent with the overall HMI design philosohy, and is within the capabilities of the control system.
11.2.1 HMI lnformation Requirements

The interface shall clearly indicate
a) tags in alarm, b) alarm states, c) alarm priorities, d) alarm types.
and
11.2.2 HMI Functional Requirements

The interface shall provide the ability for the operator to
a) b)
silence audible alarm indications (i.e., without acknowledging the alarm), acknowledge alarms,
c)
d)
place alarms out-of-service through access controlled methods as allowed

philosophy, and modify alarm attributes through access controlled methods only.
in
the
11.2.3 HMI Display Requirements

The interface shall provide the capability for the following:
a) at least one alarm summary display; b) alarm indications on process displays; c) alarm indications on tag detail display; d) assignment of alarms to operator stations.
11.2.4 HMI Functional Recommendations
The interface should provide
a) an alarm shelving function, b) A designed suppression function,
and
ANSt/SA-18.2-2009
-52-
c)
display of alarm messages.
11.3 Alarm States lndications

The alarm state transition diagram (see Figure 5) defines the states of alarm in the HMl.
ll.3.l
Required Alarm State lndications
A combination of visual indications, audible indications, or both, shall be used to distinguish

the following alarm states:
a) normal; b) unacknowledged alarm; c) acknowledged alarm.

11.3.2 Recommended Alarm State Indications
The following recommended alarm state indications are common industry practice.
11.3.2.1 Normal State lndication The normal state should not use an audible indication. The normal state visual indication
should be the same as indications without alarms.
11.3.2.2 Unacknowledged Alarm State lndication The unacknowledged alarm state should use an audible and visual indication. The audible indication should be silenced with a silence action or acknowledge action by the operator. The visual indication should be clearly distinguishable from the normal state ndication by using colors.and symbols (e.9., shape or text). The visual indication for an unacknowledge alarr should include a blinking element. There are some environments in which a audible
indication is not an effective indicator of unacknowledged alarms.
11.3.2.3 Acknowledged Atarm State lndication

The acknowledged alarm state should not use an audible indication. The acknowledged alarm
state visual indication.should be clearly distinguishable from the normal state indlcation by using symbols (e.9., .s!ap.e or text), and should be identical in color to the unacknowledgeit alarm indication. A blinking element should not be used in the visual indication for an acknowledged alarm.
11.3.2.4 Return to Normal Unacknowtedged State lndication

The return to normal unacknowledged state should not use an audible indication. The return to normal unacknowledged state visual indication may be the same as the normal state or it may indicate an unacknowledged status with a blinking element.
11,3.2.5 Latched Unacknowledged Atarm State tndication

The.unacknowledged latched alarm state should use an audible indication, usually the same as the unacknowledged alarm indication. The audible indication should be silen-ced with a silence action or acknowledge action by the operator. The unacknowledged latched alarm state visual indication may be the same as the unacknowledged alarm indiction, or it may be different to indicate the latched status.
11.3.2.6 Latched Acknowledged Alarm State lndication The acknowledged latched alarm state should not use an audible indication. The latched acknowledged alarm state visual indication should be similar to the acknowledged state
53
ANSI/|SA-18.2-2009
indication, but it should be different to indicate the need for operator reset of the latch' The visual indication for a latched acknowledged alarm should not include a blinking element'
11.3.2.7 Shelved Alarm State lndication
a shelved alarm should not include a blinking element. The shelved alarm state indication should be distinct from the unacknowledged nd acknowledged state indications. No audible indication should be used to identify shelved alarms.
Shelved alarms should be visually indicated in the HMl. The visual indication for
11.3.2.8 Suppressed by Design Alarm State lndication

Alarms suppressed by design should be visually indicated in the HMl. The visual indication for 'slppresseri by dsign should not include a blinking element. The suppressed by an alarm 'state indiction hould be distinct from the unacknowledged and acknowledged design alarni design.
state indications. No audible indication should be used to identify alarms suppressed by 11.3.2.9 Out-of-Service Alarm State lndication
Out-of-service alarms should be visually indicated in the HMl. The visual indication for an outof-service alarm should not include a blinking element. The out-of-service alarm state indication should be distinct from the unacknowledged and acknowledged state indications. No audible indication should be used to identify out-of-service alarms.
11.3.2.10 Summary of Alarm State lndications
The recommended audible and visual alarm state indications for typical alarms
summarized in Figure 11.
Alarm State Audble
lndcaton
are
Visual lndications Color

No
Symbol No Yes Yes
Blinking
No
Normal Unacknowledged Alarm Acknowledged Alarm Return to Normal State Unacknowledged Alarm Latched Unacknowledged Alarm Latched Acknowledged Alarm Shelved Alarm Suppressed by Design Alarm Out-of-Service Alarm
No Yes
No No
Yes Yes
Yes
No
Optional
Yes Yes
Optional
Yes Yes
Optional
Yes
No
Yes
No No
Optional Optional Optional
Optional Optional Optional
No
No
No No
No
Figure 1l
NOTE
Recommended Alarm State lndications
Yes signifies an indication that is different from the normal stte ndcation.
11.3.3 Audible Alarm State lndications The audible alarm indication for unacknowledged alarms may be also used to indicate the priority, the process area, or the alarm group, depending on the alarm philosophy.
environments where an audble indication of an unacknowledged alarm is not effectve (e.g., high ambient noise level environments), a clear visual indication of an unacknowledged laim tnat is always within view of the operator should be used (e.9., a light or series of lights).
ln
ANS/SA-18.2-2009
-54-
11.4 Alarm Priority lndications

The alarm philosophy provides a set of alarm priorities used in the HMI to assist the operator in selecting the sequence of alarm response actions.
11.4.1 Alarm Priority Indication Requirements
A unique combination of visual indications, audible indications, or both, shall be used

distinguish the alarm priorities within the alarm system.
to
11.4.2 Recommended Alarm Priority Indications

The following recommended alarm priority indications are common industry practice.
11.4.2.1 Color Alarm Priority lndications
A separate color indication should be used for each alarm priority. The alarm priority colors should be reserved and should not be used for other elements oi the HMl. Th'ere are some
environments in which colors cannot be reserved for priority indication.
11.4.2.2 Symbol Alarm Priority tndications
A.unique symbol (e.9. shape or text) should be used to indicate each alarm priority to
reinforce color coding.
',1.4.2.3 Audible Alarm Priority lndications
An audible indication should be used for each alarm priority. ln environments where an audible indication is not used as a priority indication, a visul priority indication should be
used.
11.5 Alarm Message lndications

The alarm message provides further clarification of the alarm beyond the state and priority indication. lt may also include part of the alarm response action r a reference to the alarm response procedure.
11.5.1 Recommended Alarm Message lndications

The following recommended alarm message indications are common industry practice.
11.5.1.1 Visual Alarm Message lndications
A text message should be generated for each alarm and displayed on the alarm summary.
The alarm text message is usually not direcily displayed on proces displays.
11.5.1.2 Vocalized Alarm Message lndications
A vocalized alarm message, using a voice synthesizer, is infrequently used. The vocalized
message should be structured and brief. The vocalized message snoutd be silenced with a silence action or acknowledge action by the operator. A visuallndication should be used in conjunction with a vocalized alarm message.
11.6 Alarm Displays

Within a control system there are several types of displays that are effective as part of the alarm system. These include the following:
a)
alarm summary display; Copyright 2009 lSA. All rights reserved.
-55b)
alarm status display; alarm log display;
ANSt/tSA-18.2-2009
c)
d) overview display; e) process display;
f)
tag detail display;
g) first-out display; h) shelved alarm display;
i) out-of-service alarm display; j) suppressed by design alarm display. ll.6.l Alarm Summary Display
At least one alarm summary display is required for each alarm system. The alarm summary provides a list of active alarms within the alarm system. There are several required and
recommended functions for alarm summary displays. I 1.6.1.1 lnformation Requirements
The alarm summary display shall list only alarm information. The display shall provide the
following information for each alarm:
a) the name and description of the tag in alarm; b) the alarm state (including acknowledged status);
c)
d) e)
the alarm priority; the time/date the alarm became active; the alarm type.
11.6.1.2 lnformation Recommendations

The alarm summary display should provide the following information for each alarm:
a) b)
c)
d) e)
the process value; the alarm setpoint; the process area;

the alarm group; the alarm message.
11.6.1.3 Additional lnformation Recommendations

In addition to the information for each alarm, the header for the alarm summary should display
a) b)
the number of alarms in the summary list, and the number of unacknowledged alarms in the summary list.
11.6.1.4 Functional Requirements

The alarm summary display shall provide the following functions:
a) b)
sorting of alarms by chronological order; sorting of alarms by Priority; individual acknowledgment of each alarm.
I
c)
11.6.1.5 Functional Recommendations

The alarm summary display should provide the following functions: Copyright 2009 lSA. All rights reserved.
ANSr/tSA-18.2-2009
-56-
a)
b)
navgatonal link to the appropriate process display;
c) d) e)
filtering of alarms by time of alarm; filtering of alarms by priority; filtering of alarms by alarm type; filtering of alarms by alarm group; filtering of alarms by process area; time limits for filters.
g)
\Mere alarm summary filters are used, the display should clearly indicate when a filter is in
use.
11.6.2 Alarm Status Display An alarm status display is recommended. The alarm status display provides an indication of the number of alarms by priority for each process area, usually in a process flow
arrangement.

The alarm status display should provide the following information for each process area or other grouping:
a) b)
the number of alarms in each alarm priority; the number of unacknowledged alarms in each priority; an indication if all alarms in a priority are acknowledged.
c)

The alarm status display should provide the following functions:
a) b)
c)
navigational link to the appropriate alarm status display; navigational link to the appropriate process display; navigational link to the appropriate overview display.
11.6.3 Alarm Log Displays

An alarm log display should be provided. The alarm log display provides access to the alarm log, which contains an alarm record for each alarm state change (e.g., acknowledgment, return to normal, etc.).

The alarm log display should provide the following information for alarm records:
a) b)
c)
d) e)
the name and description of the tag; the alarm state (including acknowledged status); the alarm priority; the date and time of the alarm; the date and time of acknowledgment; the alarm type.

The alarm log display should provide the following functions: Copyright 2009 lSA. All rights reserved.
-57a) b) c) d) e)
filtering of alarms by tag; filtering of alarms by time of alarm; filtering of alarms by priority; filtering of alarms by alarm type; filtering of alarms by alarm group; filtering of alarms by process area.
ANSflSA-18.2-2009
f)
11.6.4 Overview Displays

The overview display provides a higher level view of the process than shown on individual process displays. The overview display can assist the operator by providing alarm overview indicators (e.g., show the highest active alarm priority or alarm counts by all priority) for process areas as part of the process overview display.
11.6.5 Process Displays

The process displays provide a process context for the alarms. The process displays should provide the following information:
a) the tag identity (through text or other access methods); b) the alarm state, including acknowledge status; c) the alarm priority; d) the alarm suppression status; e) the alarm type.
11.6.6 Tag Detail Displays
The detail displays provide a detail for the tag in alarm. A detail display should provide the following information:
a) b)
the alarm state (including acknowledge status); the alarm priority; the alarm group; the alarm type; the alarm setpoint; the alarm suppression status; the current value of the tag.
c)
d) e)
g)
11.6.7 First-out Displays The first-out display provides the status for a group of alarms and indicates which of the group triggered first. A first-out display should provide the followlng information:
a) b) c)
a unique indication of the first-out alarm;
all alarms in the first-out group; the state of all the alarms in the first-out group.
11.6.8 Other Display Elements

Other display elements may be used to indicate alarm states, including alarm banners.
11.7 Alarm Shelving

The temporary shelving of alarms by the operator is a common practice to keep nuisance alarms and other alarm from interfering with the effectiveness of the alarm system. Shelving Copyright 2009 lSA. All rights reserved'
ANSr/rSA-18.2-2009
-58-
includes a set of functions to ensure the integrity of the alarm system is maintained. Where alarm shelving is provided, the requirements of this clause shall be met.
11.7.1 Alarm Shelving Functional Requirements

The alarm shelving function shall provide the following:
a) b)
displays of shelved alarms or equivalent list capabilities, to indicate all alarm shelved; a time limit for shelving; access control for shelving of highly managed alarms, if allowed; the ability to unshelve alarms;
c)
d) e)
a record of each alarm shelved.
11.7.2 Alarm Shelving Functional Recommendations The alarm shelving function should be designed to prevent alarm floods when alarms are
automatically un-shelved.
11.7.3 Shelved Alarm Displays

functionality have several required and recommended functions.
Shelved alarm displays, or equivalent list capabilities, for an alarm system with shelving
11.7.3.1 lnformation Requirements

Shelved alarm displays shall provide the following information:
a) b)
the tag name and description; alarm type;
c)
d) e)
1
the unsuppressed alarm state; the alarm priority; the time and date the alarm was shelved or the shelved time remaining.
1.7.3.2 Functional Requirements
Shelved alarm displays shall provide the following functions:
a) b)
sorting of alarms by chronological order of shelving or shetved time remaining; sorting of alarms by priority;
c) individual unshelving of alarms.

11.7.3.3. Functional Recommendations Shelved alarms displays should provide the following functions:
a) sorting of alarms by chronological order for active atarms; b) operator entry of the reason the alarm was shelved; c) filtering of alarms by priority; d) filtering of alarms by alarm state; e) filtering of alarms by process area;
g)
navigational link to a process display; navigationa! link to the tag display.
-5911.8 Out-of-service Alarms
ANSt/tSA-18.2-2009
The suppression of alarms by placing an alarm out of service is common practice to remove alarms from service to allow maintenance. There are several required and recommended HMI functions related to out-of-service alarms.
ll.8.l
Out-of-service Alarm Functional Requirements
The out-of-service alarm function shall provide the following:
a) a method to individually remove each alarm from service; b) a method to individually return each alarm to service; c) displays of out-of-service alarms or equivalent list capabilities,
service;
to indicate all alarm out-of-
d) e)
access control to place highly managed alarms out-of-service if allowed; a record of each alarm placed out-of-service.
11.8.2 Out-of-servlce Alarm Displays

Out-of-service alarm display, or equivalent list capabilities, shall be provided for the alarm system. Out-of-service alarm displays have several required and recommended functions. The out-of-service alarm displays may be combined with the shelved alarm displays.

Out-of-service alarm displays shall provide the following informtion:
a) the tag name and description; b) alarm type; c) the unsuppressed alarm state; d) the alarm priority; e) the time and date the alarm was placed out-of-service.
Out-of-service alarm displays should provide an indication of the suppression method (e.9., out-of-service).

Out-of-service alarm displays should provide the following functions:
a) b)
c)
d) e)
sorting of alarms by chronological order of suppression; operator entry of the reason the alarm was suppressed; sorting of alarms by priority; sorting of alarms by alarm state; sorting of alarms by process area; individual return-to-service of alarms.
11.9 Alarms Suppressed by Design

The designed suppression of alarms is common practice to prevent alarms that are not needed due to intended or actual operating conditions. Where alarm designed suppression is
provided, the requirements of this clause shall be met.
ANSt/rSA-18.2-2009
-60-
11.9.1 Designed Suppression Functionat Requirements

The designed suppression function shall provide the following:
a)
b)
alarms suppressed by design; a record of each alarm suppressed by design.
displays of alarms suppressed by design or equivalent list capabilities, to indicate all
11.9.2 Designed Suppression Displays

Designed suppression displays, or equivalent list capabilities, shall be provided for the alarm system. Designed suppression displays have several required and recommended functions. The designed suppression displays may be combined with the shelved alarm displays or outof-service alarm displays.

Designed suppression displays shall provide the following information:
a) the tag name and description; b) alarm type; c) the unsuppressed alarm state; d) the alarm priority; e) the time and date the alarm was suppressed.
Designed suppression displays should provide an indication of the suppression method (e.g., designed suppression).

Designed suppression displays should provide the following functions:
a) b) c) d)
sorting of alarms by chronological order of suppression; sorting of alarms by priority; sorting of alarms by alarm state; sorting of alarms by process area.
11.10 Alarm Annunciators

Alarm systems may include separate alarm annunciation devices. Alarm annunciators should be integrated into the alarm system. The specification of alarm annunciators is outside the scope of this standard.
NOTE For further guidance see ISA-18.1-1979 (R2004).
11.10.1 Alarm Annunciator Functional Recommendations

Alarm annunciators should be designed to provide the following functions:
a) b)
communicate alarm state information to the alarm log; prevent redundant alarms in the control system; prevent the need for redundant acknowledgement in the control system
c)
-61
ANSt/tSA-18.2-2009
11.10.2 Alarm Annunciator Display Recommendations Alarm annunciators should be designed so that the alarm layout on the annunciator follows a consistent methodology.
11.11 Safety Alarm HMI

An independent HMI may be required for some safety alarms. The identification methods for safety alarms are outside the scope of this standard. 11.11.1 lndependent Safety Alarm HMI
An HMI independent from the BPGS may be required for the following safety alarms: manual safety function alarms, depending on considerations (e.9., the risk reduction
factor);
a)
b)
system diagnostic alarms from the SIS that indicate dangerous faults, depending on considerations (e.9., the operator response);
NOTE For further guidance see ANSI/ISA 84.00.01-2004 Part 1 (lEC 61511 Mod).
12
Enhanced and Advanced Alarm Methods
NOTE This clause is lnformative and does not contain mandatory requirements.
12.1 Purpose
Enhanced and advanced alarming is part of the detailed design lifecycle stage. This section provides guidance and consideration for additional alarm management techniques beyond itrose wfrch are normally employed in control systems. They generally provide added functionality over the basic alarm system design and may be particularly useful to guide operator action during plant upsets or other multiple alarm situations.
of logic, programming, or modeling used to modify alarm attributes. They methods include dynamic alarming, statebased alarming (i.e., mode-based alarming), adaptive alarms, logc based alarming, and predictive alarming. Most designed suppression methods are included in advanced alarming.
Enhanced and advanced alarming methods are additional layers
ln addition to advanced alarming techniques, enhancements to the alarm system may also
provide enhanced information to the operations personnel. This type of information is usually onsidered necessary to either avoid or mitigate operational problems which may lead to incidents.
The basic alarm design methods may not be sufficient to reduce alarm floods, or mitigate their effect and enhancednd advanced techniques may be necessary. Methods described in this clause can reduce or eliminate flood.
12.2 Basis of Enhanced and Advanced Alarming

Enhanced and advanced alarming methods are often used if the basic alarm design does not achieve the performance goals stated in the alarm philosophy. The alarm philosophy or alarm system requirements specfication should include a list of acceptable enhanced and advanced alarming methods.
12.2.1 Effort, Manpower Requirements and Complexity

The additional complexities of enhanced and advanced alarming techniques need additional resources for design, implementation, and maintenance. The management of change process
ANSt/tSA-18.2-2009
-62-
techniques.
should include a review of the impact of changes on the enhanced and advanced alarming
The cost of additional alarm system complexity should be compared to the additional benefits of improved alarm system performance.
The consequence failure scenarios for enhanced and advanced alarming techniques should be considered before approval and during design.
12.3 Enhanced and Advanced Alarming Categories

Enhanced and advanced alarming techniques can be categorized by complexity.
12.3.1 Category 1: lnformation Linking fnformation linking techniques, category

information related to the alarm available to the operator.
1,
includes techniques that make additional
12.3.2 Category 2: Logic-based Alarming

Logic-based alarming, category
conditions to modify alarm attributes.
2,
includes techniques that use logic based
on
plant
12.3.3 Category 3: Model.based Alarming

Model-based alarming, category 3, includes techniques that use process data and process models to provide the operator with information that may include alarms based on anlysis or detailed guidance.
12.3.4 Category 4: Additional Alarming Considerations

Additional alarming consideration category 4, includes those techniques that utilize auxiliary or remote alarm systems.
12.4 lnformation Linking

Alarm systems can be enhanced by linking information in the master alarm database (e.g., operator action or consequence). lnformation can also be linked from other sources including: operating procedures, operator logs, maintenance history, or design documents. These lins should be easy to manage and maintain.
12.5 Logic.basedAlarming
Logic-based alarming is accomplished using Boolean logic or decision trees to determine the modifications to be made to alarm systems. This technique is usually implemented direcfly in the control system.
12.5.1 AlarmAttributeModification
The functional capability to modify some alarm attributes (e.g., alarm setpoints or priorities) is necessary for some enhanced and advanced alarming techniques. Some systems may not have this functionality and supplementary or externally enabled systems may be considered.
12.5.2 Externally Enabled Systems

Externally enabled systems capture alarm and process data from the control system and use the information to determine plant operating conditions and the corresponding modifications to alarm attributes. Copyright 2009 lSA. All rights reserved.
63
ANSI/|SA-18.2-2009
12.5.3 Logical Alarm Suppression/ Attribute Modification

Logical alarm suppression techniques use alarm state conditions from some alarms to modify the alarm attributes of other alarms (e.9., first-out alarms).
12.5.4 State-based Alarming

State-based alarming is an advanced alarm technique that modifies alarm setpoint, priority, or suppression status bsed on defined operating states for equipment or processes. States are often determined through
a)
b)
status of a logical variable, a defined process variable which reaches a specific limit, logic that looks at many variables and indicators, and operator selection.
c)
d)
The state determination and alarm modification can be manual, semi-automated (e.9., some combination of manual and automated), or fully-automated.
12.6 Model-based Alarming

Model-based alarming can be used in areas where a more complex system of annunciating an alarm is desired, where complex process parameters may produce a result based on multiple data points, or where an estimation of plant state can be derived from a model.
Predictive alarms may sometimes be accomplished through the use of process models. Predictive alarms can be used to replace basic alarms and provide additional time to respond.
Model-based alarm systems should not be used as a replacement for the basic alarm system without thorough analysis.
12.7 Additional Alarming Considerations

Some additional enhancements may add value to the alarm system. These enhancements may or may not be normally available in the basic alarm system.
12.7.1 Non-control Room Gonsiderations

\A/here
the operating personnel are expected to respond to alarms while completing noncontrol room based tasks, consideration may be given to remote alarm display and
acknowledgement. Procedures to provide back up to the operator may be necessary. improve reliability. An alarm escalation procedure should be considered.
The use of remote alarm notification practices should include periodic test messages to
12.7.1.1 Paging, e-maiting and Remote Alerting Systems
Several situations can potentially exist in which the person who most needs to know about an abnormal situation and take action on it is not an operator in a control room. Such situations can benefit from the availability of a remote alerting system (e.9., paging, email, etc.).
The reliability of the message delivery is a significant issue in such systems and should be dealt with in the design. Acceptable, if not optimum, results should be achievable even if delivery does fail. lt may be necessary to also provide remote acknowledgement.
ANSr/tSA-18.2-2009
-64-
12.7.2 Supplementary Alarm Systems

Supplementary alarm systems may replace the control system alarm notification system or make use of the existing graphics environment to provide a common interface. Alteinatively, system may be used in addition to the existing alarm system to provide additional r alternative alarm information. Special care should be taken to ensure that the additional information provides value. When these systems are employed to present alarms in place of control system notification techniques, users should design the system to ensure alarm availability nd reliability are acceptable.
12.7.3 Batch Process Gonsiderations
The process conditions, states, and phases may be used to modify alarms in
processes. This is often implemented as state based alarming.
batch
12.7.3,1 Continuously Variable Alarm Thresholds

Alarms for batch processes are often applicable only to specific steps of the process, or associated with changing control loop setpoints, or time varying process data trends. Unless special care is taken, batch processes are especially prone to the generation of nuisance alarms. Advanced alarm methodologies may provide a structure for addressing these types of batch-related alarm problems.
12.7.3.2 Relative Time versus Absolute Time

Data and alarm record time stamps are normally accomplished in computer systems using calendar time. For batch information, relative time (i.e., the time since the beginning of th batch or process step) is more relevant. A feature of advanced alarming is ttreoitity to take calendar time stamps and electronic records indicating when the batch step or phase started and compute and display alarms in relative time.
12.7.3.3 lnclusion of Lot Number and other ldentifying Marks

Some sites may specify the functionality to associate identification numbers with alarms. Being able to sort records by the selected identification is also useful in generating official b-atch records of a production run and in comparing records of differenf productin runs. Methods of extracting and attaching such identifying marks should be proven nd reliable.
12.8 Training, Testing, and Auditing Systems

The alarm philosophy should specify steps to ensure advanced alarm functions continue to operate, including training, testing, and auditing. For enhanced and advanced alarming systems, it may be necessary that training, testing, and auditing procedures include the enhanced features of such a system.
12.9 Alarm Attribute Enforcement

To maintain designed alarm attribute settings (e.g., alarm setpoints, alarm priorities and mode-based designed suppression) at authorized values, there should 6e a regular qomparison of the rationalized values with the settings in effect in the control system. Enforcement, the automatic verification and restoration of alarm attributes, is an enhanced alarm technique that performs functions associated with monitoring, assessment, and audit. Enforcement can be initiated on a scheduled basis or on requesi and should differentiate
changes resulting from state-based or alarm shelving methodologies as acceptable so as not to produce false mismatches.
-65-
ANSr/f
SA-18.2-2009
l3
lmplementation
13.1 Purpose
lmplementation is a separate stage of the alarm lifecycle which is the transition from design to operation. This section covers general requirements to install an alarm, an alarm system, or implement a modification to an existing alarm or alarm system, and bring it to operational status. lmplementation is the transition from design to operation.
13.2 lmplementation Planning The scope of the project or change will determine the extent of the work
lmplementation planning should include the following considerations:
necessary.
a) disruption to operation; b) availability of resources; c) functional testing or validation; d) verification of documentation; e) operator training.
13.3 lnitia! Training
The training requirements for new alarms and modifications to existing alarms are determined by the classification of the alarm and the class requirements as detailed in the alarm philosophy.
13.3.1 lnitial Training for Highly Managed Alarms

Operators shall be trained on the response to all new or modified highly manged alarms prior to the operator assuming responsibility for responding to the new or modified alarms.
13.3.1.1 lnitial Training Requirements

The training shall include
a)
b)
c)
the technical basis of the alarm (e.9. consequence of inaction, determination of setpoint value, causes for alarm, corrective action, tags used for confirmation, etc), the response or corrective action to the alarm, and the audible and visual indications for the alarm.
13.3.1.2 Documentation Requirements

Documentation of the training shall include
a) the persons trained, b) the method of training, c) the date of the training, and d) the last time when the personnelwere trained.
The minimum retention period is specified in the alarm philosophy document or per company
policy.
13.3.2 lnitial Training for New or Modified Alarms

Operators should be trained on all new or modified alarms.
ANSr/tSA-18.2-2009 13.3.2.1 Training Recommendations

The training should include
-66-
a) the technical basis of the alarm, b) the response or corrective action to the alarm, and c) the audible and visual indications for the alarm.
13.3.2.2 Documentation Recommendations
Documentation of the training should include
a) b) c)
the persons trained, the method of training, and the date of the training.
13.3.3 lnitial Training Requirements for New or Modified Alarm Systems

Operators shall be trained on all new or modified alarm systems.
13.3.3.1 Initial Training Recommendations for New or Modified Alarm Systems

The training requirements for the modified alarm system should be appropriate for the nature of the change. The training requirements of new alarm system should inclde
a) b) c) d) e)
the audible and visual indications for alarms, the distinction of alarm priorities,
the use of the alarm HMI features (e.g., alarm summary sorting and fittering), the proper methods for shelving and suppression, and the proper methods for removing an alarm from service.
13,4 lnitial Testing and Validation lnitial testing requirements for new alarms and modifications to existing alarms are determined by the classification of the alarm and the class requirements as etailed in the alarm philosophy.
13.4.1 lntal Testing Requirements for Highly Managed Alarms
The alarm.philosophy shall identify the testing requirements for highly managed alarms prior to putting the alarms in operation. The initialtesting shall be documented including
a) b) c) d) e)
the alarm setpoint or logical conditions, the alarm priority, the audible and visual indications for the alarm, any other functional requirement for the alarm as specified, the persons conducting the testing,
f)
g) h)
i)
the method of testing and acceptance criteria, the results of the testing and resolution of any failures or non-compliance, the date of the testing, and the date the alarm was put into service.
13.4.2 lnitial Testing Recommendations for New or Modified Alarms

Alarms should be tested during implementation. The testing should include verification of Copyright 2009 lSA. All rights reserved.
-67
ANSt/tSA-18.2-2009
a) the alarm setpoint or logical conditions, b) the alarm priority, c) the audible and visual indications for the alarm, and d) any other functional requirement for the alarm as specified.
13.4.3 lnitial Testing Requirements for New or Modified Alarm Systems
Alarm systems shall be tested during implementation to ensure that appropriate items in the alarm piritosophy and ASRS have been met. The testing of modified alarm system shall be appropriate to ttie nature of the change, as determined by site MOC procedures. The testing of new alarm system shall include
a) b)
the audible and visual indications for each alarm priority, the HMI features, such as alarm messages displayed in the alarm summary or equivalent,
and
c)
the methods for removing an alarm from service.
13.4.3.1 lnitial Testing Recommendations

Initial testing recommendations should include
a) b)
c) d)
the methods for shelving, the methods for alarm suppression, any additional functions of enhanced or advanced alarming techniques, and method of alarm filtering, sorting, linking of alarms to process displays.
13.5 Documentation
There are several documentation requirements and recommendations for alarm system
implementation.
13.5.1 Documentation Requirements

The following documentation shall be provided:
a) b)
c) d)
I
alarm lists from the master alarm database shall be available prior to the implementation of new or modified alarms; individuals performing alarm testing shall have current and sufficient information to perform the test; alarm response procedures shall be provided to the operators as a part of placing a new or modified alarm in service; upon completion of alarm system implementation, the master alarm database shall be updated in accordance with the site MOC procedure.
3.5.2 Documentation Recommendations
The reporting method, documentation format and structure should be in accordance with the project documentation procedures and owners documentation requirements. The testing methodology and documentation should be appropriate to the nature of change, as determined by site MOC procedures or alarm philosophy'
lnformation about new and modified alarms that would be useful to both testers and operators can include some of the following:
a) b)
basic process control system alarm source tag; alarm type; Copyright 2009 lSA. All rights reserved'
ANSr/rSA-18.2-2009
-68-
c)
d) e)
priority; alarm setpoint value or logical condition; operator action; consequence of inaction;
g) initial of persons involved; h) the date of testing and change;

the method of testing and acceptance criteria; the results of the testing and resolution of any failures or non-compliance.
i) j)
14 Operation
14.1 Purpose
Operation is a separate stage of the lifecycle. This section covers requirements for alarms to remain in and return to the operational state. The operational state is when an alarm is on-line and able to indicate an abnormal condition to the operator. This section also describes appropriate use of tools for alarm handling within the operational state. Operation is the lifecycle stage following implementation and when returning from maintenance. Out-of-service alarms are discussed in the maintenance clause.
14.2 Alarm Response Procedures

Alarm response procedures shall be readily accessible to the operator.
14.2.1 Alarm Response Procedure Recommendations

The form of alarm documentation that is deemed most accessible by operating staff should be readily accessible.
used. The alarm information recorded during alarm rationalization should also be made
Unless otherwise specified in the alarm philosophy, the alarm response procedures should include
a) b)
the alarm type, alarm setpoint,
c)
d) e)
potentialcauses,
consequence of deviation, corrective action, allowable response time, and alarm class.
g)
14.3 Alarm Shelving

Alarm shelving requirements shall be determined by the classification of the alarm and the class requirements as detailed in the alarm philosophy.
14.3.1 Alarm Shelving Requirements

Shelved alarms shall be reviewed at the beginning of each shift.
14.3.2 Alarm Shelving for Highty Managed Alarms
lf a highly managed alarm class is used then shelving highly managed alarms shall follow authorization and reauthorization requirements as detailed in the alarrn philosophy. Copyright 2009 lSA. All rights reserved.
-69reauthorization details.
ANSt/tSA-18.2-2009
An audit trail shall be maintained recording approval, interim alarms and procedures, and
14.3.3 Alarm Shelving Recommendations
The operator should be permitted to shelve alarms to prevent unnecessary distraction due to unforeseen alarm system malfunctioning alarms. Shelved alarms extending beyond a single operating shift shoud be reauthorized. Approval requirements for shelving alarms should be recorded in the site alarm philosophy.
14.3.4 Alarm Shelving Record Recommendations

The following information shall be recorded for each shelved alarm extending beyond a single operating shift:
a) b)
alarm name;
the reason for shelving.
14.4 Refresher Training for Operators

The training requirements for alarms shall be determined by the classification of the alarm and the class requirements as detailed in the alarm philosophy.
14.4.1 Refresher Training Documentation for Highly Managed Alarms
lf a highly managed alarm class is used then the

documented:
following training information shall be
a) b)
c)
the persons trained; the method of training; the date of the training.
The frequency of training shall be specified in the alarm philosophy. The documentation of the training shall be retained for the period specified in the alarm philosophy or per company
policy.
14.4.2 Refresher Training Content for Highly Managed Alarms
lf a highly managed alarm class is used then operators shall be periodically trained on the characleristics of each highly managed alarm. The content of the refresher training shall
include
a) b)
c)
the technical basis of the alarm, the response or corrective action to the alarm, and the audible and visual indications for the alarm.
14.4.3 Refresher Training Recommendations for Alarms

Operators should receive periodic training that involves alarm response evaluation. The trining should cover a broad range of process scenarios. The training should include
a) b) c)
the technical basis of the alarm, the response or corrective action to the alarm, and
the audible and visual indications for the alarm.
A record of refresher training should be kept indicating who received the training and the time it was received.
ANSt/f SA-18.2-2009
-70-
15 Maintenance
l5.l
Purpose
operational state to the out-of-service state and then returning to the operational state. Maintenance also reguires refresher training for personnel maintaiing the alarm system.
Maintenance is a separate stage of the lifecycle. This section covers requirements for alarm system testing, replacement-in-kind, and repair. lt describes the transition of alarms from the
15.2 Periodic Testing

Periodic testing requirements for alarms shall be determined by the classification of the alarm and the class requirements as detailed in the alarm philosophy.
15.2.1 Periodic Testing Requirements
fMen tests are performed, a record shall be kept for a period specified in the
philosophy and shall contain the following:
alarm
a) b) c) d)
date(s) of testing; name(s) of the person(s) who performed the test or inspection; unique identifier of equipment (e.9., loop number, tag number, and equipment number); result of tests.
!f the.alarm ph.ilosophy requires that some alarms be periodically tested then it shall provide guidelines on the frequency and manner of testing.
15.2.2 Periodic Testing for Highly Managed Atarms
lf a
periodically tested to ensure performance.
highly managed alarm class is used then alarms belonging to this class shall be
Any deficiencies found during functional testing of highly managed alarms shall be repaired or else an interim alarm or procedure shall be put in place in a timely manner.
15.2.3 Periodic Test Procedure Recommendations

Test procedures should be provided for alarms requiring testing. Procedures should contain
a)
b)
steps for taking the alarm out-of-service prior to the test and returning the alarm to service after the test, appropriate warnings regarding control loops or final elements that mght be affected by the test, and steps to address advanced alarming techniques if applicable.
c)
15.2.4 Periodic Testing Recommendations

Test records should contain the following:
a) b)
method of testing; planned interval before next test.
Any deficiencies found during functional testing should be repaired in a safe and timely
manner.
-7115.3 Out-of-service
ANSr/rSA-18.2-2009
Out-of-service requirements for alarms shall be determined by the classification of the alarm and the class requirements as detailed in the alarm philosophy.
15.3.1 Out-of-service Process Requirements

Alarms that will be compromised for extended durations (e.9., days, weeks, or months) shall be examined to determine whether an alternative alarm is necessary. lf an interim alarm is necessary then it shall adhere to management of change requirements'
An authorization and documentation process (e.9., permit process) shall be used to take an alarm out-of -service. A list of out-of-service alarms shall be available for review on-demand
with their corresponding replacements where applicable. The following information shall be recorded for each out-of-service alarm:
a) b)
c)
d) e)
the name of the tag in alarm; the alarm type; approval details; details concerning interim alarms or procedures if required; the reason for taking the alarm out-of-service.
15.3.2 Out-of-service for Highly Managed Alarms

lf a highly managed alarm is taken out-of-service for longer than one shift, appropriate interim alarm r procedures shall be identified unless the process is in a state where the
consequence has been eliminated.
15.3.3 Out-of-service Process Recommendations

Approval requirements for taking alarms out-of-service should be specified in the site alarm philosophy. The duration of record retention should be defined in the site alarm philosophy.
15,4 Equipment Repair

lnformation related to an alarm malfunction should be available to the operator. Alarms affected by non-functioning equipment (e.9., equipment that is taken out-of-service for repair or preventative maintenance) should be placed out-of-service if the condition will not be resolved within a reasonable time as specified in the alarm philosophy.
15.5 Equipment Replacement

replacement equipment (e.g., measurement devices, valves, process equipment) will change operating conditions or alarm attributes, then site management of change procedures should be followed. Replacements that do not result in such changes do not require management of change. lf a replacement is made then alarm validation may be required depending on the class of the alarm as specified in the alarm philosophy.
lf
15.6 Returning Alarms to Service

Prior to returning out-of-service alarms to the operational state, operators shall be notified to ensure they are aware of the returning alarm and the removal of the interim methods.
15.6.1 Recommendations for Returning Alarms to Service lnterim alarms and procedures should be removed, where applicable, when the original
alarms are returned to service. Copyright 2009 lSA. All rights reserved.
ANSr/tSA-18.2-2009
-72
of alarms shall be
15.7 Refresher Training for Maintenance

Te training requirements for the maintenance
classification of the alarm and the class requirements as detailed in the alarm philosophy.
determined
by
the
15.7.1 Refresher Training Requirements for Highly Managed Alarms
lf a highly managed alarm class is used then the appropriate personnel shall be periodically trained on the maintenance requirements for all highly managed alarms. The frequency ot training shall be specified in the alarm philosophy. Documentation of the training strall incuOe the persons trained, the method of training, and the date of the training. The rcord shall be retained for the period specified in the alarm philosophy document or per company policy.
15.7.2 Refresher Training Recommendations for Alarms
Maintenance personnel should receive periodic training on the maintenance requirements of alarms. A record of refresher training should be kept indicating who received the training and the time it was received. Evaluations should be conducted to ensure site mainteance procedures are clearly understood.
l6
Monitoring and Assessment
16.1 Purpose
Monitoring and assessment is a separate stage of the lifecycle. This stage verifies that design, implementation, rationalization, operation, and maintenance are satisfactory. This clause provides g,uidance on the use of alarm system analysis for both ongoing moitoring and periodic performance assessment. These activities use many of the same types oi measures. This clause recommends several performance measures that should be considered for inclusion in the alarm philosophy.
the lifecycle (e.9:, design, maintenance, or management-of-change) depending uion the

nature of the problem.
Problems identified via alarm system monitoring may be resolved in several different parts of
16.2 Requirements
Alarm system performance shall be monitored. Monitoring and assessment of the alarm
system performance shall be made against the goals in the alarm philosophy.
16.3 Monitoring, Assessment, Audit, and Benchmark

The usage of these terms is in the following context.
o . o .
Monitoring is the measurement and reporting of quantitative (objective) aspects of alarm system performance.
Assessment is the comparison of information from monitoring and additional qualitative (subjective) measurements, against stated goals and defined performance metrics. Audit is a comprehensive assessment that additionally includes the evaluation of the effectiveness of the work practices used to administer the alarm system. Benchmark is an initial audit of an alarm system designed to specifically identify problematic areas for the purpose of formulating improvement plans.
Monitoring- typically occurs at a higher frequency than assessment. The monitoring of some aspects of the alarm system performance is based upon continuous measurement. he intent of monitoring is to identify problems and take corrective actions to fix them.
-73relative to the alarm system is covered in the audit section.
ANSr/SA-18.2-2009
The focus of the assessment process is to apply engineering judgment and review to determine whether the system is performing properly. The evaluation of work processes
16.4 Alarm System Measurement

Performance measurement is fundamental to control and improvement. An alarm system will likely experience performance deterioration over time, as sensors age and process conditions change, or if an alarm change management policy is not in place. Ongoing performance measurement can determine when corrective action is needed.
When alarms have been properly rationalized and designed, and nuisance alarms (e.9., chattering alarms) eliminated, the resulting alarm rate reflects the control system's ability to keep the process within bounds without requiring manual operator intervention. The solutions to high alarm rates may include improvements to the control system or to the process rather than adjustments to the alarm system. Enhanced or advanced alarm techniques may be
necessary.
16.5 Alarm System Performance Metrics

Various types of alarm system analyses, key performance indicators, and methods are possible. Both initial alarm system assessment and ongoing monitoring should include the measures in this section. The entire list of chosen analyses should reflect decisions made in
the alarm philosophy.
The two categories of data in a typical control system alarm system are alarm records (i.e., dynamic or real-time data) and alarm attributes (i.e., alarm settings or configuration data). Both categories are valuable in alarm system performance measurement and are subject to different analyses.
. .
Alarm records contain alarm-related information and are produced by the system when alarms occur. Alarm attributes make up the underlying structure which is necessary in order that alarm records are produced, including the decisions about alarm types, alarm setpoints, priorities, deadbands, and similar items.
ln general, at least 30 days of data is desirable for calculating the metrics in this section. For batch operations, data corresponding to several similar batches is more applicable. The target metrics in the following sections are approximate and depend upon many factors, (e.9., process type, operator skill, HMl, degree of automation, operating environment, types and significance of the alarms produced). Maximum acceptable numbers could be significantly lower or perhaps slightly higher depending upon these factors. Alarm rate alone is not an indicator of acceptability.
16.5.1 Average Annunciated Alarm
Rate per Operating Position
Analysis of annunciated alarm rates is a good indicator of the overall health of the alarm system. Recommended targets for the average annunciated alarm rate per operating position (i.e., the span of control and alarm responsibility of a single operator) based upon one month of data are shown in Figure 12. These rates are based upon the ability of an operator and the time necessary to detect an alarm, navigate within the control system to the relevant data, analyze the situation, determine and perform proper corrective action(s), and monitor the situation to ensure the alarmed condition is successfully handled.
ANSr/tSA-18.2-2009
-74-
Very Likely to b Acceptablo
Maximum Manageable
-150 Alarms per day
-300 Alarms per day
-6 Alarms per hour (average) -1 Alarm per

10 minutes (average)
-12 Alarms per hour (average)
-2
Alarms per 10 mnutes (average)
Figure 12
Average Alarm Rates
Sustained operation above the maximum manageable guidelines indcates an alarm system that is annunciating more alarms than an operator may be abe to handle, and the likeihood of missing alarms increases.
The use of averages can be misleading. Any period of time that produces more alarms than can be handled, presents the likelihood of missed alarms, even if the average for that interval seems acceptable.
16.5.2
Peak Annunciated Alarm Rates per Operating position
Alarm rates of 10 alarms or more in a l0 minute time period may exceed the operator -Rates capability for effective alarm response, or result in missed alarms. approaching 10 alarms in 10 minutes may not be reliably sustainable by an operator for tong peiiOs.
For peak alarm rate analysis, annunciated alarms are counted in regular 1O-minute intervals (e.9., 1:00 pm through 1:09 pm). The recommended target corresponding to one month of data is that less than -1olo of the lO-minute intervals should contain more thn 10 alarms.
Both the peak and average alarm rates should be taken into account simultaneously because either measurement individually could be misleading. The quantity of intervals exceding 10 alarms, and the magnitude of the highest peaks strould be reported.
16.5.3 Alarm Floods

Alarm floods are variable-duration periods of alarm activity with annunciation rates likely to exceed the operator response capability. ln an alarm flood, the alarm system is likely to be ineffective in assisting the operator. Alarm flood calculations involve the determination of adjacent time periods where the alarm generation rate is high, thus producing an overall flood event. The start of an alarm flood is indicated by the first regular 10 minute interval with an alarm rate that exceeds 10 alarms per 10 minutes. The end of an alarm flood is indicated by the first regular 10 minute interval with an alarm rate of less than 5 alarms per 10 minuts. Alarm floods should be of short duration and low total alarm count. As a recommended target, an alarm system should be in flood for less than -1olo of the reporting period.
16.5.3.1 Alarm Flood Analysis

lmprovements to the alarm system and process operation may be indicated by the analysis of alarm floods. No targets are provided for these metrics. Alarm flood analysis should nclde
a) number of alarm floods per reporting period, b) duration of each alarm flood, c) alarm count in each alarm flood, and d) peak alarm rate for each alarm flood.
Copyright 2009 1SA. All rights reserved
-75-
ANSt/tSA-18.2-2009
Alarm floods may require advanced methodologies to address. Some methods are described in Clause 12.
16.5.4 FrequentlyOccurring Alarms

Relatively few individual alarms (e.9., l0 to 20 alarms) often produce a large percentage of the total alarm system load (e.9., 200lo to 80%). The most frequent alarms should be reviewed at regular intervals (e.9., daily, weekly, or monthly). Substantial performance improvement can be made by addressing the most frequent alarms.
The analysis methodology is to use at least several weeks of data and rank alarm records from most to least frequent. The most frequent alarms are likely not working properly or as designed. High frequency alarms often have major skewing effects on other performance
measurements.
The top 10 most frequent alarms should comprise a small percentage of the overall system foad (e.9., 1o/o to 5%). Action steps based on this analysis include review for proper functioning and design.
16.5.5 Chattering and Fleeting Alarms

A chattering alarm repeatedly transitions between the alarm state and the normal state in a
short period of time. Fleeting alarms are similar shorduration alarms that do not immediately repeat. ln both cases, the transition is not due to the result of operator action.
A threshold for chattering of an alarm that repeats three or more times in one minute is often used as a first pass identification of the worst chattering alarms. Other values may be used.
It is possible for a chattering alarm to generate hundreds or thousands of records in a few hours. This results in a significant distraction for the operators. Chattering alarms are often
high in the listing of the most frequent alarms. Chattering and fleeting alarm behaviors should be eliminated. There is no long-term acceptable quantity of chattering or fleeting alarms.
16.5.6 Stale Alarms

Alarms that remain in effect continuously for more lhan 24 hours may be considered as stale. Some alarms remain in the alarm state continuously for days, weeks, or months. Such alarms provide little valuable information to the operators. They clutter the alarm displays and often represent conditions that are not truly abnormal. Stale alarms should be examined to ensure that they were properly rationalized. Logic, programmatic, state-based, or similar methods can be used to eliminate stale alarms.
There should be less than five stale alarms on any given day, with action plans to address them. No alarm should be intentionally designed to become stale and there is no long-term acceptable number of stale alarms.
16.5.7 Annunciated Alarm Priority Distribution

Effective use of alarm priority can enhance the ability of the operator to manage alarms and provide proper response. The effectiveness of alarm priority is related to the distribution of the alarm priorities: higher priorities should be used less frequently.
Priority Designation
3 priorities: Low, Medium, High
Percentage Distribution
-807o Low, -15% Medium, -5olo High
-80o/o Low,
4 priortes: Low, Medlum, Hgh, Hghest
-15% Medium, -57o High, -<10lo Highest
Figure l3
- Annunciated Alarm Priority Distribution
ANSt/tSA-18.2-2009
-76-
alarms.
Four priority systems often include an additional highest priority for a very few selected
Additional special-purpose priorities may be useful, such as a lowest priority for instrument malfunction or diagnostic alarms with very limited and prescribed operaior action. There is no recommended frequency or percentage distribution for such diagnostic alarms, since there is no recommended frequency for instrument failure. Low numbers are better.
Various priorities with limited annunciation (e.g., silent alarms) are sometimes used for special circumstances. There is no recommended distribution for limited annunciation
priorities. Distributions at wide variance to these percentages can compromise the value of prioritization and generally indicate alarm priority settings that did not result from a consistent alarm rationalization methodology. Effective rationalization is the usual solution.
16.5.8 Alarm Attributes Priority Distribution An effective alarm rationalization effort will produce annunciated alarm record priority distributions similar to Figure 13. lt is useful to measure the priority distribution'of th underlying alarm attribute structure. The distribution of alarm priority attributes should be similar to Figure 13. Annunciated alarm record distributions will not match alarm attribute distributions since all alarms are not equally likely to occur. Diagnostic-type alarms are el-cluded from the priority attribute distribution percentage calculations due i their skewing
effect.
16.6 Unauthorized Alarm Suppression

The alarm states of shelved, suppressed by design, and out-of-service are all intended as controlled methodologies. lt is possible for alarms to be suppressed outside of these methodologies. lt is necessary to detect and report any such atarms; the potential for mistakes and the resulting risk are high. Analysis methods should be used to detect and report any alarms suppressed outside of proper methods. There should be no alarms that are improperly suppressed.
16.7 Alarm Attribute Monitoring

Unauthorized alarm attribute changes shall be detected and resolved. Periodic monitoring at the frequency specified in the alarm philosophy shall be made of the actual alarm attributel in
effect on the control system, compared to the rationalized attributes in a master alarm database or to allowable alarm attribute changes specified in the alarm philosophy. Discrepancies shall be identified and resolved quickly. The target value for'improieriy
changed alarms is zero.
16.8 Reporting of Alarm System Analyses

Alarm system analyses should be properly reported. Reporting should
a)
b)
and
include personnel (e.9., operators, staff and managers) concerned with the alarm system,
be at a frequency appropriate to the nature of the data contained and the needs of the recipients.
At-,various phases of an improvement effort, different analyses should be performed at different frequencies. (9.g., providing weekly reports at the start ot an effort and monthly reports later on). Weekly analyses may still cover the prior 30 days of data to produc
meaningful trends. The alarm philosophy should specify analysis and reporting frequencies. Copyright 2009 lSA. Att rights reserved.
-77 -
ANSt/tSA-18.2-2009
Action should be taken on problems identified by the alarm analyses. Progress and status of actions should be regularly reported.
16.9 Alarm Performance Metric Summary

The alarm performance metrics and example target values previously described, with the same qualifications, are summarized in the Figure 14.
Alarm Performance Metrics Based upon at least 30 days of data
[l/letrc Annunciated Alarms per Time Annunciated Alarms per Day per Operating Position Annunciated Alarms per Hour per Operating Position Annunciated Alarms per 10 Minutes per Operating Position
Target Value
Target Value: Very Likely to be Acceptable Target Value: Maximum Manageable
-150 alarms per day
-300 alarms per day
-6 -1
(average) (average)
-12 (average)
-2
(average)
Metric
Percentge of hours containing more than 30 alarms Percentage of 10-minute perods contanng moro than 10 alarms Maximum number of alarms n a 10 mnute period Percentage of time the elarm system is in a flood condition Percentage contribution of the top 10 most frequent alarms to the overall alarm load Quantty of chattering and fleeting elrms Stale Alarms Annunciated Priority Dstrbution
-<1o/o -<1o/o
Target Value
s10
-<1o/o
-<1o/olo 5olo maxmum, wth action plans to address deficiencies. Zero, acton plans to correct any that occur Less than 5 present on any day, wth action plans to address' 3 priorities: -80o/o Low, -15% Medium, -570 High or 4 riorities: -800/o Low, -150lo Medium, -5% Hgh, -<l7o 'highest' Other special-purpose priorities sxcludd from the calculation Zero alarms suppressed outside of controlled or approved methodologies.
Unauthorized Alarm Suppression Unauthorzed Alarm Attrbute Changes
Zeo alarm attrbute changes outsde of approved methodologies or

MOC.
Figure 14
Alarm Performance Metric Summary
17
Management of Change
17.1 Purpose
for alarm system changes
Management of change is a separate stage of the lifecycle. This section covers requirements pertainng to the addition of new alarms, alarm attribute modification, authorization, and documentation. The purpose of management of change is to ensure that changes are authorized and subjected to the evaluation crteria described in the alarm philosophy. The management of change process ensures that the appropriate stages of the alarm management lifecycle are apped to alarm system changes.
ANSt/lSA-18.2-2009
-78-
17.2 Changes Subject to Management of Change

Alarm addition and removal shall require authorization through MOC. Permanent changes that result in a difference from the designed values of the alarm setpoint, class, priority, consequence, basis, suppression logic, or response time shall require evaluation through
MOC.
17.3 Change Review Process Requirements

The Moc process shall ensure the following considerations are addressed:
a) the technical basis for the proposed change; b) impact of change on health, safety and the environment;
c)
d) e)
modifications are in accordance with the alarm philosophy; modifications for operating procedures; time period for which change is valid; authorization requirements for the proposed change; the degree of safety is maintained if the alarm is implemented for safety reasons; personnel from appropriate disciplines are included in the review;
g) h)
i) j)
changes to the alarm system follow all appropriate subsequent alarm management lifecycle stages; implementation of all changes adhere to procedures specified in the alarm philosophy.
17.4 Change Documentation Requirements

Documentation requirements shall be determined by the classification of the alarm and the class requirements as detailed in the alarm philosophy. The following information shall be recorded for approved changes:
a)
b)
reason for the change; date the change was made; the name of the person implementing the change; the name of the person authorizing the change; nature ofthe change;
c)
d)
e)
f)
g)
training requirements; testing requirements.
17.5 Ghange Documentation Recommendations

alarm changes should be recorded as part of the change record. Records should
Changes required to related system components and documentation as a consequence of
a) be protected against unauthorized modification, destruction, or loss, b) be revised, amended, reviewed, and approved under the control of an appropriate
document control procedure,
c)
d)
be stored for a duration determined by the site record retention policy, and be maintained per the alarm philosophy class requirements.
17.6 Alarm Decommissioning Recommendations
lf an alarm is no longer needed then it should be decommissioned from the alarm

Displays and related documentation should be modified within a reasonable time. Copyright 2009 lSA. All rights reserved.
system.
-7917.7 Alarm Attribute Modification Requirements
ANSr/tSA-18.2-2009
\Men changes to alarm attributes are necessary then the proposed modifications, including the addition and deletion of alarms, shall follow the MOC process specified in the alarm
philosophy.
17.8 Alarm Attribute Modification Recommendations

A list of referencing materials (e.9., graphics, control logic, P&lD, operating procedures, and
making changes to alarms. This prevents introducing incorrect information into documentation and helps prevent interim automation logic and graphic errors.
HAZOP) should be generated and maintained. This reference list should be reviewed prior to
l8
Audit
18.1 Purpose
Audit is a separate stage of the lifecycle which is conducted periodically to maintain the integrity of the alarm system and alarm management processes. Audit of system performance may reveal gaps not apparent from monitoring. Execution against the alarm philosophy is audited to identify any requirements for system improvements, such as modifications to the
alarm philosophy or the work process defined therein.
An audit reviews the managerial and work practices associated with the alarm system. lt determines whether those practices are sufficient to adequately administer the system by reviewing practices vs. procedures and procedures vs. policy or requirements. Audit also
includes comparison of the alarm management practices against industry guidelines. The frequency of the audit process is lower than monitoring and assessment
18.2 lnitial Audit or Benchmark

All aspects of alarm management should be audited at the start of an improvement effort. An initial audit or benchmark should be made against a set of documented practices (e.9., the practices listed in this standard). A benchmark includes an initial iteration of the audit process, in order to capture any work practice concerns. The results of the initial audit can be used in the development of a philosophy.
18.2.1 lnitial Audit or Benchmark Requirements

The audit frequency and the specific audit requirements stated in the alarm philosophy shall be followed for highly managed alarms.
18.3 Audit lnterviews

Personnel interviews or questionnaires should be conducted as part of the audit to identify performance and usability issues. lnterview topics may include
a) alarms occur only on events that require operator action, b) alarm priority is consistently applied and meaningful, c) alarms occur in time for effective action to be taken, d) roles and responsibilities for the alarm system users and support personnel are clear, and e) training regarding the proper use and functioning of the alarm system is effective.
18.4 Audit Recommendations
The alarm philosophy should be audited against industry guidelines and the requirements and recommendations of this standard. The work processes and procedures that ensure Copyright 2009 lSA. All rights reserved.
ANSI/rSA-18.2-2009
-80a
periodic
compliance with the alarm philosophy should be evaluated for effectiveness on basis. The audit should review work practice documentation which may include
a) b)
verification that alarms require operator action to avoid a defined consequences, documentation of alarm attributes and rationalization,
MOC documentation of modifications to alarm attributes in the master alarm database,
c)
d) e) a)
alarm performance monitoring reports, documentation of repairs to malfunctioning alarms, and documentation for out-of-service alarms.
18.5 Action Plans

Action plans should be developed for problems identified during the audit processes. When defining an action plan, timelines, accountabilities, and review of results obtained should be assigned to each item.

Ansuisa 18.2 2009

Uploaded by

Ansuisa 18.2 2009

Uploaded by

ANSUISA-9"2-2009 Management of Alarm Systems for the Process lndustries

Approved 23 June 2009

ANSt/tSA-18.2-2009 Management of Alarm Systems for the Process lndustries

Copyright 2009 lSA. All rights reserved.

Copyright 2009 SA. All rights reserved

ADDRESSED THE POTENTIAL ISSUES IN THIS VERSON.

Copyright 2009 lSA. All rights reserved

Matrikon lnc Consultant User Centered Design Services LLC

Copyright 2009 lSA. All rights reserved

Copyright 2009 lSA. All rights reserved.

References Definition of Terms and Acronyms ......

3.1 3.2 4.1 4.2

43 43 ,44 ,44 ,44 .44 .44

.45 .45 .45 .45 .45 .46 .46 .46

9.7 9.8 9.9

Removal Classification .................... Review...... Documentation.................. BasicAlarm Design

Human-Machine lnterface Design for Alarm Systems

15.1 Purpose 15.2 Periodic Testing 15.3 Out-of-service

5.4 Equipment Repair...............

Monitoring and Assessment.........

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

7.5 Change Documentation Recommendations .......

18 Audit... 18.1 Purpose

Copyright 2009 lSA. All rights reserved.

Figure 1 - Alarm System Dataflow Figure 2 - Alarm Management Lifecycle

Average Alarm Rates .....

Copyright 2009 SA. All rights reserved.

Copyright 2009 lSA. All rights reserved.

This page intentionally left blank.

Copyright 2009 lSA. All rights reserved

The Alarm System

Final Gontrol Elements

Control & Safety Systems

Copyright 2009 lSA. All rights reserved

1.3.4 Fire Detection and Suppression Systems and Security Systems

1.3.6 Alarm ldentification Methods

1.3.7 Management of Ghange

requirements and recommendations to be included in a management of change procedure are included.

of change procedure is not

city) have established process safety design, process safety management, or

Copyright 2009 lSA. All rights reserved.

-151.3.9 Purchase Specification

Definition of Terms and Acronyms

3.1.1 Absolute alarm

3.1.4 Adjustable alarm (Operator-set alarm)

3.1.8 Alarm class

3.1.9 Alarm deadband (Alarm hysteresis)

3.1.12 Alarm historian

3.1.13 Alarm log

3.1.16 Alarm off-delay (Debounce)

3.1.17 Alarm on.delay

3.1.18 Alarm overview indicator

3.1.20 Alarm priority

Copyright 2009 lSA. All rights reserved.

-173.1.22 Alarm summary

3.1.31 Calculated alarm

3.1.40 Discrepancy alarm (Mismatch alarm)

3.1,41 Dynamic alarming

3.1.43 First-out alarm (First-up atarm)

3.1.46 Instrument diagnostic alarm

Copyright 2009 lSA. All rights reserved.

-193.1.48 Latching alarm

3.1.50 Master alarm database

3.1.54 Plant state (Plant mode)

3.1.56 Rate-of.change alarm

3.1.58 Recipe.driven alarm

3.1.59 Remote alarm

3.1.61 Return to normal

3.1.62 Re-alarming alarm (Re.triggering alarm)

3.1.63 Safety alarm

3.1.64 Safety function alarm

3.1.67 Stale alarm

3.1.68 Standing alarm

3.1.69 State-based alarm (Mode-based alarms)

3.1.71 Statistical alarm

Copyright 2009 lSA. All rights reserved.