I continue to attempt in my blogs to define terms better for our public so that they get a clearer understanding of just what this alarm management is all about. Whether they choose our company for their needs or not, I feel compelled to clear the air on a lot of the confusing rhetoric.

A lot of papers continue to be printed on this issue of rationalization- each professing to have the answer. I guess it’s a good thing everybody did not jump on the advice of the first one. Some of this confusion seems to be deliberate obfuscation by vendors who hope to distill a sense of fear in you. Conversely, some of the confusion seems to be with the very definition of the term itself, and the prevailing assumptions made by those who hear the definition. I will try to add some light.

There are two forms of alarm rationalization. The first is the design approach, the other is the data-based approach. It seems in the process world these two worlds are continually at loggerheads. The design guy is stuck on how many theoretical trays are necessary to make a distillation tower simulation converge properly. The data guy is worried about how many real distillation trays are collapsed in his tower, and what he must now do to get the desired separation based on the current data. Each is important to the eventual result, but neither seems to understand the issues of the other- or respect them for that matter.

Let's examine the design approach first. This approach says that if an alarm system is properly designed, then it should run properly. That means that you assign only alarms that MATTER- or have a defined operator action. You design those alarms to be observant of the timing, safety, environmental consideration, and potential costs associated with each alarm. You balance these issues within the alarm configuration as a whole to assign the proper priorities to the alarms you have assigned. Incidentally- EMMUA says that you should thus end up with 80% low priority, 15% medium, and 5% high priority if you do this right.

And to do this you really don't need to know how many alarms per hour your operators are dealing with. The only dataset you need is the current alarm configuration. Some have told me that this is all that is required to rationalize the alarm system. If properly done, you will meet all of the requirements of the EEMUA 191 guidelines, and will avoid floods as best as possible without adding a layer of dynamic alarm management. After instituting this process, then if they get too many alarms, then they are operating the unit wrongly (assuming your design information is correct). This can then be adjusted for poorly-communicated design issues, and you are finished. Add the data to a configuration knowledgebase, make it available for the operator to view when trouble comes, and you are finished. This process should be supported in workflow and tools by any good alarm management tool kit.

The other approach is the activation data-based approach. Bring all alarm activation information into a database. Review this data statistically to examine what are the issues that are affecting the operator. Resolve these issues by getting rid of nuisance alarms, and rectifying the configuration to reduce those most prevalent alarms. Find out why those alarms that are occurring exist. Find paths toward replacing alarms with other methods that create the same operator "Situation Awareness" (see www.mycontrolroom.com). This can be operator graphics, communications, redirection, or a myriad of other methods. Some tell me that once the bothersome level is reduced, their job is done. In this manner they "crawl" their way into a rationalized system over time. Statistically, I guess its possible if you keep at it without ceasing.

At TiPS, we advocate a balanced mix of these two methods. The best projects include a mixture of both. They also include operator training, an alarm philosophy, a management of change procedure, and an ongoing audit and maintenance of the results.

I recommend you examine both of these methods, and use the parts of each that are able to be accomplished knowing your current management disposition, personnel availability, and other issues that come to bear. There's more to it than I've discussed here, but I think you get the general gist. The hardest to justify is the design approach, because it usually entails a large project. A "nibbling" approach can get rid of a lot of noise. However, you should recognize that if you only look after the bad actors, it is the bad actors that have not occurred that may jump up and bite you when you least expect it. The design approach allows you to anticipate the bad actors in advance of their potential damage. It's the ones we don't anticipate that always get us.

We will have a white paper coming out soon that discusses this in more detail, and with an eye to the risk associated with each method. We refer to this mixed method as a balanced approach. We don't intend to patent it, or claim intellectual property to it. It's just good logical common sense, and an approach that many of our clients use successfully. After all, good alarm management is just good common engineering sense. There's no patent on that- you either have it or you don't.

Š