Very frequently I run into situations where alarm rationalizations conflict with the results of other risk studies. Many studies such as HAZOP and LOPA will add new alarms to address potentially hazardous conditions while the alarm rationalization studies tend to remove alarms to make the system more usable by the operator. These objectives tend to conflict with each other and result in one study taking away what the first added. Which one is right? Usually the HAZOP or LOPA, but the reality is that none of these studies can be done in a vacuum. All of the studies are very interdependent and the results of one must be considered when performing another. Unfortunately, many pure-play companies that can only perform a single type of study put their blinders on and do what they think is correct while simultaneously wrecking the results of other studies and putting the plant and personnel at risk.
Many alarm rationalization guides will recommend that when multiple transmitters measure a single process parameter only one of those alarms should be annunciated, and the one that should be selected (according to pure-play alarm rationalization firms with little or no overall process safety expertise) is the SIS transmitter. This choice is almost always the wrong one! This is why I joined the ISA 18 committee, because alarms cannot be analyzed in a vacuum without considering how they impact other instrumented safeguards and risk systems. I did my best to impart this knowledge into the standard and into the committee members – but the counseling was not accepted in all cases, usually because it would make the job of alarm rationalization more difficult if other risk studies must also be considered.
The rationale behind the minimization of alarm annunciations makes sense. Ultimately, for any single incident that can occur in a process plant there should be a single alarm indicating the problem. This helps to prevent the operator from getting overloaded with multiple indications of the same event both from the same type of measurement (e.g., multiple level alarms) and from multiple measurements indicating the same problem (e.g., loss of level then generates low flow alarm, pump vibration alarm, etc.). When a single event causes a “flood” of alarms it becomes much more difficult for the operator to know what the root cause of the problem is. Consider the case of a low level event in a separator. If five level alarms, one low flow alarm, a pump vibration alarm, a pump over-current alarm, and possibly some BADPV / Deviation alarms all occur simultaneously, the operator becomes overloaded with information and has a hard time determining what the root cause of the problem is so that he can take an action. In a perfect world, only one alarm would be generated for this event – making it very easy for the operator to diagnose. Unfortunately, this level of perfection is unattainable as it would require an unrealistically sophisticated artificial intelligence system to determine when an alarm should be annunciated and when they should be suppressed. For instance, in the example above it would make sense to suppress the vibration alarm of the pump because the root problem is low level – but does that mean that the vibration alarm has no value and should be removed? No.
While we can’t prevent some of the flooding issues while still annunciating the required situations, it is relatively easy to prevent multiple annunciations of a problem in the same process variable. For instance, a separator might have an alarm on its control transmitter, a dedicated alarm transmitter, and 2oo3 voting transmitters for shutdown. In this case it is quite common for all five transmitters to annunciate a problem if the level goes low. This would be excessive. There are a two different ways that this excessive flooding can be prevented. The first, and more common approach, is to pick one of the five transmitters as the alarm point. The second is to employ logic to the alarm system.
If the selected route for alarm minimization is selected, determining which of the transmitters should be used as the annunciation point is somewhat complex, and requires consideration of all the scenarios under which an alarm may be required and what the other risk studies and equipment design basis studies have taken credit for. When an alarm rationalization removes an alarm point (and when you only annunciate one of the five alarms here, you’re removing the other four) you need to go back to the HAZOP, the LOPA, the SIS design basis, and every other risk study that considers alarms and ensure that the removal of these alarms does not impact the results of those other studies. This is a step that most pure-play alarm rationalization companies do not do, but is absolutely essential to maintaining a safe plant. If any of the other risk studies reference the alarms that are being removed, those studies will need to be updated and the results will need to be revalidated. For instance, if ALL of these alarms are reference in the HAZOP, those references – at a minimum – will need to be removed. You may need to re-rank the likelihood of the event considering that some of the safeguards have been removed, but that will probably not be an issue. Of more importance is when alarms that are credited as IPL are removed, the entire LOPA of that scenario becomes invalid, and it is likely that tolerable risk is no longer achieved.
In general, a LOPA study will take credit for operator intervention based on alarms as a protection layer. This protection layer needs to be independent of the initiating cause and independent of the other protection layers. If it is not independent, no credit can be taken. As a result, using the SIS transmitter as the basis for operator intervention is virtually never done, because the SIS transmitter is part of a different protection layer. In this case, the operator intervention protection layer is not “independent” of your SIS protection layer, so credit for both can not be taken. The only device that is independent of both the initiating event and the SIS (in the case of the separator example) is the dedicated alarm transmitter. If only one alarm is annunciated in this situation, it will necessarily be the dedicated alarm transmitter. While this logic is pretty airtight and well understood by risk analysts, for some reason the pure-play alarm rationalization guys don’t seem to get it. The rationale they promote is that an alarm generated by SIS equipment will be more reliable because safety equipment is better and more rigorously maintained. This rationale is not true (unless you choose to maintain your plant that way) and completely ignores the concept of independent protection layer. As such, I firmly stand by the concept that whichever transmitter is identified as part of an independent protection layer (which should be clearly documented in the LOPA) must be the device that actually generates the alarm. Usually, this will NOT be the SIS transmitter.
There is another option with superior reliability characteristics and optimal alarm flood prevention, but it requires a significant amount of additional work. The best option is to utilize all of the redundant hardware at your disposal for alarm generation, but use logic to only generate one alarm. This is similar to the “common trouble alarm” concept for major pieces of equipment. In the separator example, you could have all five of the transmitters set to journal (which will not cause a flood to the operator), and then use DCS logic to generate an audible alarm (of appropriate priority) to the operator. Using this scheme the reliability of using five redundant transmitters is incorporated into the alarm, but only one annunciation is generated, preventing the operator being overloaded by redundant information.