SEP-OCT 2017

Issue link:

Contents of this Issue


Page 15 of 57

16 INTECH SEPTEMBER/OCTOBER 2017 WWW.ISA.ORG PROCESS AUTOMATION ing. But to whom? The control room op- erators? Maintenance personnel? Natu- rally, the answer is, "It depends." One of the most basic qualifications of a legitimate alarm is that the opera- tor must be able to do something to fix or mitigate the situation. So, if that pressure transmitter is providing a very critical reading, it probably merits a control room alarm, even though the operators are not likely to be the ones going out there to fix it. It might cause them, however, to implement a backup solution or compensate for the loss of information while the device is being replaced by maintenance. Now, multiply this scenario by all the smart instruments and actuators in the plant or process unit. If every one of the potentially hundreds or thousands of devices that can cause an alarm is configured to do so, there could be major ramifications. The easy solution is to direct those diagnostic messages to maintenance, but this so - lution is shortsighted if something is truly critical. Returning to our exam - ple, say the pressure transmitter does fail. A process upset may result, which would trigger other alarms, but the sit - uation would have advanced well past where it could have been avoided by earlier action. To further complicate the situation, the degree of criticality of the pres - sure transmitter may vary depending on what is happening with the pro - cess. During a procedure or particu- larly critical time in a batch process, the threat of lost or questionable data from the device might be very impor - tant to the operators. At other times, they may not care as much. Dynamic alarming This brings us to an important realiza - tion: many alarms are more useful or critical at some times than at others. The objective is making those critical alarms active at the times when they are most needed, and suppressed when they are not. Here is another example: a com- pressor provides pressurized air to a variety of devices around a process unit, such as valve actuators (figure 3). incident instead of defusing it. Running counter to the less-is-better idea is the proliferation of new tools that result in even more alarms. Many vendors provide code libraries that enhance (increase) alarm generation through built-in diagnostic features. Many of these alarms can be identi- fied as the root cause for more gener- alized undesirable process events, and as such should not just be eliminated during rationalization. Instead, these valuable warnings can and should be added to the alarm pool. These alarms can be early warnings of developing critical conditions, and therefore serve a valuable purpose. But their timing is also indiscriminate, because their trigger condition is gen - erally narrow in scope, such as a sud- den loss of signal reported by an ana- log input instruction used to monitor cooling flow. For this reason, proper application requires some type of context-based filtering to restrict their occurrence under wrong or unhelpful circumstances. The use of diagnostic alarming func- tions has been controversial for some time. If a pressure transmitter is showing signs of degradation in its electronics, it can detect the problem and send a warn- the idea of only creating alarms where the process and safety considerations call for them. The 10-step life cycle has a few start- ing points, with one of the most com- mon being establishing a foundational philosophy, and it continues through all the other steps needed to properly manage alarms—from identification to maintenance (figure 2). While other ar- ticles on the topic can provide broader detail and a more general description of ANSI/ISA-18.2, this article will focus on the practical side of alarm manage- ment: design and implementation. Too many, too few, or just right The ultimate objective for a process fa- cility or individual unit is not to have a specific, fixed number of alarms, but rather the right number for the current circumstances. The concept is simple, but implementation is more complex. The underlying concern about having a liberal number of alarms is that too many will activate at the same time and overwhelm operators. During this "alarm flood," they will not be able to discern important alarms from duplicate or irrel- evant ones. As a result, situational aware- ness is compromised, and operators can make bad decisions or even escalate an Philosophy Identification Rationalization Detailed design Implementation Operation Maintenance Management of change Monitoring & assessment Audit Figure 2. ANSI/ISA-18.2 established a framework for developing and working with alarms using a systematic approach.

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - SEP-OCT 2017