Figure 1. Low cost and ease of implementing alarms in digital control systems have contributed to steep growth. Data reproduced with permission of PAS .
Low alarm implementation cost. Configuring an alarm has dropped dramatically in cost as the use of digital control systems has proliferated. Gone are the days when a new alarm required wiring and hardware additions to panel boards or other relay devices and several days or more to schedule the work. Now it often can be done in minutes by one person with a few simple keystrokes on a computer engineering console.
More actual alarms per operator. The rise in configured alarms per operator normally correlates to a subsequent increase in actual alarms per operator. Sometimes, the frequency of alarms exceeds what an operator can reasonably be expected to handle, as suggested by EEMUA .
Lack of sufficient guidance on how to respond to so many different alarm conditions generally exacerbates the problem.
Standard Operating Procedures (SOP) and operator manuals may exist but may not be quickly accessible when a major abnormal situation occurs on the plant floor.
Sometimes, basic documentation is missing. For instance, some project design teams fail to document both the rationale for selecting attribute values for an individual alarm and the expected operator response to abnormal situations. Again, always remember that an effective alarm should alert, inform and provide guidance to the expected response .
Multiple alarms per incident. An abnormal situation sometimes can generate many alarms, a so-called alarm flood — often confusing operators and generating information overload, rather than providing a single more intelligent conclusion for operators about what’s occurring.
Distribution of alarm logic in many parts of the system. Part of the problem with overall alarm management is that alarm functionality resides throughout the automation system (Figure 2). For example, field devices, on-line analytical systems and Safety Instrumented Systems (SIS) as well as programmable logic controllers (PLC), distributed control systems (DCS) and interfaced third-party systems (e.g., expert systems) can generate alarms. ISA Standard S-95 offers some perspective on this, defining several different levels of automation.
Figure 2. Many levels of plant automation can generate alarms.
It’s a challenge to create an environment that consolidates alarm information such that a single user interface and alarm acknowledge/response paradigm exists.
However, having alarms displayed in one place in a consistent format will help operators more effectively react to abnormal situations; having alarm records in a single database will greatly facilitate mining data for their information and knowledge content and generating batch reports.
Use of the alarm system for notification messages. At many plants, operator information overload is made worse by having the alarm system handle routine notifications (information messages). In fact, this has been blamed as a contributing factor to the severity of certain well-publicized plant disasters. Using the alarm system for routine notifications sometimes is pursued as a convenience for the automation engineers and sometimes represents a limitation of a vendor’s automation software. Regardless, notifications shouldn’t appear as alarms to operators.
Nuisance alarms. Operators at many plants are frustrated by a large number of alarms that don’t represent abnormal situations or don’t require a response. In cases where operators receive frequent nuisance alarms, they may lose respect for the alarm system and then sometimes miss real abnormal situations while responding to (or ignoring) nuisances.