“Woe is me! There are too many safety-related alarms” is a common lament related to control room management. Companies are devoting attention to modifying their definition of “safety-related.” The occurrences of safety-related alarms prompt the need to review those occurrences on at least a monthly basis. There are discussions about how to reduce the number of alarms that are classified as “safety-related” in order to reduce the amount of time used for monthly and annual reviews. There are companies who have changed what might have once been alarms to alerts in order to reduce the number of alarms. One philosophy is that alarms require a response and alerts do not require a response. Another philosophy is that alerts do require action, but not immediate action. People who are taking these steps are convinced they are doing the right things for the right reasons and that pipeline safety will not be affected by these changes related to alarm management. How we define and classify things can have consequences for good or for ill.
Definitions express the general nature of a thing and a philosophical pipeliner like me tends to expend time and energy pondering definitions and considering their importance. The purpose of this article is to provide information that you can ponder during your lamentations about the burdens of alarm management. Think about what your company considers “safety-related” operations. Consider how that pertains to alarms. Ponder the differences between alarms and alerts for the controller.
One of the CRM Frequently Asked Questions (FAQ) (A-16) provides this from PHMSA: For purposes of Control Room Management, PHMSA considers safety-related to mean any operational factor that is necessary to maintain pipeline integrity or that could lead to the recognition of a condition that could impact the integrity of the pipeline, or a developing abnormal or emergency situation. I believe that provides an adequate starting point that companies could apply to defining “safety-related” as it applies to SCADA-related processes, alarm management, and the other CRM elements. Look at your company’s abnormal and emergency operating procedures. Those should be designed to address safety-related operational factors related to pressures, tank levels, temperatures, odorization, leak detection, data communication, and/or safety-related conditions. Haven’t you been addressing safety-related operations prior to CRM? What is different now? What devices provide adequate information to controllers about safety-related operational factors? It is likely that those devices should have safety-related points associated with them and some of those safety-related points will have alarms.
Another CRM FAQ (E-04) states: “PHMSA expects operators to designate safety-related alarms, and to train its controllers to understand which alarms are safety-related along with their individual implications to safety. In general, “safety-related” alarms include operating parameters and do not include items such as equipment efficiency alarms and related measurements. Refer to FAQ’s in section A for more information about the term “safety-related.” What alarms are associated with devices that provide controllers adequate information so they can take actions to maintain pipeline integrity or address a developing abnormal or emergency condition? It is likely that an alarm indicating operating limits are being approached or have been exceeded should be safety-related.
PHMSA has issued Notices of Amendment (NOA) to some companies because they failed to define either “safety-related” points or “safety-related alarms” or both. This is from a NOA dated 10-10-2012: The definition section of the Alarm Management Plan was not specific enough to ensure all appropriate personnel understand the difference between the following terms; notification, alert, CSE- Critical Safety Equipment, SSCR, tags, OIMS, PV Filtering, inaccurate, false, stale data (noted as old data or white data), suppress versus inhibit and other utilized abbreviations in the definitions.
This is from another NOA dated 11-20-2012: Section 603 of the CRM Plan and the Alarm Management plan need to clearly define the alarms in the SCADA system, provide adequate definitions, establish priorities for effective controller response, and what is visible to the controller.
What are the definitions that your company uses in its written alarm management plan? Is your approach to defining “safety-related” and “alarm” and “alert” based in providing for effective controller response to alarms or on reducing the number of occurrences that have to be reviewed monthly?
What is your philosophy for alarm management so that it satisfies the CRM regulatory requirement in 192,631(e) and 195.446(e) “Alarm management. Each operator using a SCADA system must have a written alarm management plan to provide for effective controller response to alarms.”
I did some research into definitions that are relevant to alarm management in control rooms, including from a NTSB Accident Report where alarms and alerts were relevant. Are these definitions similar to the ones your company is using?
The PHMSA CRM regulations has this definition of an alarm: An audible or visible means of indicating to the Controller that equipment or processes are outside operator-defined, safety-related parameters. There is not a definition of an alert in the PHMSA CRM regulations. Why is that? This statement is from a NOA dated 07062012: PHMSA has identified that “Alerts” are a form of alarm if controller action is required. If the controller is expected to respond to “alerts” including acknowledgements, then the “alerts” should be considered regarding other provisions of this section of the rule. Karen Butler from PHMSA said companies use various terms such as alerts, notifications, informational indications, interim alarms, cautions, warnings, emergency alarms and alarms.
The AGA Alarm Management White Paper (2009) has these definitions of alarms and alerts: Alarm: An audible or visible means of indicating to the Gas Controller that an equipment or process is outside operator defined safety-related parameters. Alert: A notification or event that does not require immediate action. Alerts are always of lower priority than alarms and should never be safety-related.
The ANSI/ISA–18.2–2009 Management of Alarm Systems for the Process Industries (23 June 2009) Alarm: An audible and/or visible means of indicating to the operator an equipment malfunction, process deviation, or abnormal condition requiring a response. 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.
Honeywell published a white paper in 2011 titled “Alarm Management for Pipelines” Alarm: An audible or visible means of indicating to the controller an equipment or process malfunction or abnormal condition requiring a response. An alarm has three basic functions: 1. Notifying the controller of an abnormal change; 2. Communicating to the controller the nature of the change and possible causes; 3. Directing the controller to take appropriate corrective action. Keep in mind, as we look at best practices, that an alarm must not be expected and must require a controller action.
API Recommended Practice 1167 (2010) has this definition of an alarm: Alarm – A visible and/or audible means of indicating to the controller an equipment malfunction, an analog or accumulation process deviation, or other condition requiring a controller’s response. The Recommended Practice does not have a definition of an alert, but does provide an explanation of alerts, their purpose, and appropriate responses to alerts by a Controller. Based on the information in the Recommended Practice, I use the definition below for an alert: Alert – a notification, reminder, and/or warning that is configurable and controllable by the controller and that prompts the controller to perform an action or to follow up on a task.
Columbia Gas Transmission had a pipeline accident in 2012. The NTSB accident report (February 2014) evaluated the ways alarms and alerts were classified and handled in the control center. The definitions used by Columbia Gas, as stated in the report, are: Alarm: An audible or visible means of indicating to the Controller that equipment or processes are outside operator-defined, safety-related parameters. Alert: an audible or visible means of indicating to the controller or monitoring center analyst that conditions have changed, equipment or other monitoring variables are outside of operator defined controlling parameters or which indicate that equipment, devices or processes are not functioning as intended but which are not integral to a safety-related parameter. (NiSource 2012)
Do alerts in your company require controller action or do they merely provide information? If alerts require controller action, when is action required? Has your system always had alerts or did you add alerts after the CRM regulations were implemented? How are alerts presented to the controller: on a separate display or intermingled with alarms? Are there different colors for alerts than for alarms?
In my simplistic view, an alarm is anything that requires a controller or operator to take action. Remember the purpose of the alarm management requirements is to provide for effective controller response to alarms. A company should take a risk-based approach to classifying alarms as safety-related or not. The process should be documented and a structured method used for risk analysis. The hazards and the consequences should be considered during alarm rationalization. There should be conservative decision making about the priorities of alarms. It is better to err on the side of caution and provide guidance to the controllers so that they respond effectively to all alarms, no matter their priority or how often they occur. If there are too many occurrences of alarms, address the root causes that triggered the alarm.
Use this information as your company ponders the connections between pipeline safety and alarm management. If you desire more information, I recommend reading The Alarm Management Handbook: A Comprehensive Guide Second Edition (2010) by Bill Hollified and Eddie Habibi and/or Human Factors in Alarm Design (1994) by Neville Stanton. The textbook from 1994 changed my viewpoint about the importance of effective alarm design so that alarms were a tool for controllers and operators instead of the burdens imposed by engineers and system designers. It decreased my woes and reduced my lamentations.
Charles Alday © 2015 Please Distribute to Others.
