Too much information can be a bad thing, especially when it comes in the form of hundreds of alarms bombarding the control room. Considering that operators can’t adequately respond to that many alarms and notifications going off at once, problems—all too often—go unnoticed. As time goes on, they can fester to the point that they degrade quality, damage equipment, or even injure people.
Recognizing the negative ramifications of receiving too many alarms, industries have been talking—for the last decade or two—about alarm-management programs. In an attempt to reduce control room clutter, many automation professionals have begun to eliminate nuisance alarms and consolidate those that are repetitive. Some have gone so far as to find ways to prevent alarms through continuous improvement in process control.
“For some, reducing alarms to zero has become the ultimate goal of alarm management,” notes Tyron Vardy, product director for alarm-management solutions at Honeywell Process Solutions.
Goals like these may sound great, but how frequently are they successful? Is industry really adopting the best practices necessary for managing all those alarms? Looking for answers to these questions, Automation World asked users of alarm technology for their observations in an informal, unscientific survey, and also sought the perspective of vendors.
To allow our readers to speak freely, the survey was anonymous. The only data collected was on the size of their company and the corresponding industry. Responses came from small, medium, and large companies. Half of them came from process industries—like chemical, petroleum, and utilities—a quarter came from discrete manufacturing—such as automotive, aerospace, machinery, and equipment—and 15 percent from hybrid industries—like pharmaceuticals and food and beverage. The remaining nine percent were consultants and other professionals.
The survey yielded some encouraging results, especially when compared to results from a survey Automation World initially conducted seven years ago. In the earlier survey, nearly 70 percent of respondents said alarm overloads affected their ability to operate their processes properly. Yet only 50 percent indicated that they were not following any best practices for alarm management. However, based on the current survey, the situation seems slightly better: More than 60 percent say that overloads are causing problems, though—compared to the last survey—more users are implementing best practices. For example, almost 3/4 of the respondents indicated that their companies have been taking steps to limit the number of alarms that they are tracking.
Investments in software
Another sign that more industrial facilities are adopting best practices for alarm management is an investment in the necessary software. Although, nearly 20 percent of respondents are using alarm-management software more than 10 years old, over half have updated their software within the past five years.
An interesting fact about software acquisitions over the past five years is that 44% were part of a human-machine interface (HMI) or supervisory control and data acquisition (SCADA) upgrade. This connection may be due to a few reasons. The first is a matter of perception, according to John Krajewski, director of product management at Aveva. “Even if the alarm logic is in the controller, operations teams most commonly interact with those alarms in their HMI and SCADA applications,” says Krajewski. “Because that is often the place where people see alarms, that is generally what they consider to be their alarm system.”
He, and others, point to a desire to benefit from the latest in information technology as another reason that many users see alarm management as part of an HMI upgrade. These users want to benefit from the connectivity made possible by mobile devices, the Industrial Internet of Things (IIoT), and ever-increasing digitalization.
Consider a tank-overflow alarm built directly into the control application. “When users build the control module to handle that tank overflow, they build the alarm instruction or tag condition,” says Michael Anthony, product manager for controls and visualization at Rockwell Automation. “That alarm, without any engineering by an HMI design engineer, is consumed by built-in software within the HMI. From there, that alarm history can be ingested into a data lake for orchestration with other analytics.” The result is greater real-time visibility that can drive decisions and behaviors.
As part of their investment in alarm software upgrades, 29% of the respondents indicate they are making use of a related best practice: the use of simple grayscale screens that reserve color and flashing icons for drawing attention to abnormalities. This technology is often referred to as high-performance HMI.
Though it may be tempting to view the survey results on this aspect of HMI upgrades in a negative light (as the majority of users are not using advanced HMI technology), Krajewski is encouraged by the fact that nearly one-third of respondents have moved toward grayscale HMIs. “It’s very difficult for users to switch because of the inertia that their existing systems have,” he explains. “If an organization has, say, 1,000 people on its operations teams, that means 1,000 people already know how the existing system works and what the colors mean. Justifying the expense and effort to reengineer the solutions, change all those systems, and retrain all those people is difficult.” Consequently, some users have chosen to ease into the technology by metering it in slowly as they make revisions and add new screens.
A matter of priorities
Another important best practice being adopted is the use of software to prioritize alarms. About 65% of all respondents report that their alarm systems clearly differentiate critical alarms from those of a lower priority.
Even so, vendors find it worrisome that almost one third say their alarm systems still treat all notifications equally and rely on the operator to decide which to prioritize. This practice can be dangerous, especially in situations when the operators receive a lot of alarms. “Operators become accustomed to just ignoring things on the screen,” explains Anthony. “When a chemical vent is blocked, and a pressure alarm is flashing with the same priority as a panel door alarm, the building pressure can be missed. That can lead an explosion.”
Automation vendors suspect that software does not assign priority because the necessary information was lacking at the configuration stage. “There is no practical methodology for prioritization, and these users don’t have the manpower to determine priorities,” says Dr. Hiroaki Tanaka, manager of the Advanced Solutions Division at Yokogawa Electric Corporation. “Software can only import a determined alarm database that includes alarm prioritization.”
Though an HMI can ultimately help in monitoring alarm systems, issues can manifest if parameters are not set. “A systems integrator building an HMI is often simply given a functional specification, and no key operational data for knowing which alarms are important and which are not,” adds Krajewski. “So, the integrator just turns on all the alarms and gives them equal status, leaving the development of a priority hierarchy for later.” In too many cases, the hierarchy is left for the operators to discover.
The missing component here is an alarm-management philosophy for establishing alarms and reacting to them appropriately. Although half of the respondents reported having such a philosophy, their responses suggest that this best practice may not be well entrenched. Only 34% say that employees follow it all of the time. While 52% say that the document is followed most of the time, 14% admit to following it only some of the time.
This laxity over creating and following an alarm philosophy may be, in part, a vestige of simpler days when there were fewer alarms to track. “When many systems were installed initially, the primary alarm response was a single alarm or warning indicator,” recounts Ramey Miller, HMI product manager at Siemens. “In turn, there was no need for a philosophy.” The complexity of today’s systems has changed things, however. “An alarm-management philosophy is now a necessity,” Miller adds.
Priorities for an orderly plan
Indeed, developing an alarm strategy should be the first step in any alarm-management program. It should come before the use of software to group alarms, prioritize them, and identify the bad actors. Starting with software can certainly deliver some quick wins, but it can take you only so far without a clear strategy, according to Vardy. “Use the software to deliver your plan, rather than letting the software drive the way that you think about alarm management,” he says, adding that the third step can be either alarm rationalization or boundary management. “Some would argue that rationalization should be next, but I think that the third step should really depend on the state of your alarm system,” says Vardy. “If you have a lot of alarms that are in a bit of a mess, then you’ve got to clean them up before you do the rationalization. Limit the alarms, and then do the rationalization on what’s left. There’s no point in rationalizing all those alarms.”
Half of the survey respondents admit that their companies have not implemented safeguards against control-system adjustments, which could cause a process to drift from its rationalized state. “Often, the time needed to do the rationalization work isn’t prioritized,” explains Rockwell’s Anthony. He recommends taking the necessary time because, once you discover that a process has drifted from a set point, the work to ensure that your product still meets quality-control specifications can be enormous.
Rationalization is linked to yet another best practice, namely operator involvement. After all, the operators are the ones who work with the system every day. “One objective for alarm rationalization is to reflect operator knowledge into the alarm database, knowledge such as possible root cause and corrective action,” says Tanaka.
Automation vendors also advocate for giving operators a role in developing the company’s alarm philosophy and specifying the software. “Today’s systems can have hundreds of physical sensors and many more logically programmed alarms,” says Miller. “The task of categorizing and prioritizing them is typically easier when development engineers, management, and operators all work together to creating the alarm philosophy.” Right now, about 55% of all respondents say that operators help with alarm management and system specification.
To keep alarm-management programs on track and to help users stay current on best practices, Vardy suggests lifecycle management as the fifth and final step. “It’s just a matter of making sure people don’t stray from the program.
