In the litterature you find many articles about alarm management. One of the latest is by Nicholas Sands and Donald Dunn in November / December issue of Intech, which you can read online at the Intech web-site. Sands and Dunn headed the effort to get the ISA Alarm Management standard together. But how did we end in a situation were we need a standard for alarm management in the first place?
When I started work as a control engineer a generation ago one of the first lessons I learned was, that you don't implement an alarm to the operator console unless you also come up with guidance to the operator on what to do when that alarm comes in. I also recall, that noisy Decwriters used to print logs of alarms and other console events did not work overtime, except when a compressor or other major piece of equipment had problems. I guess I was lucky to join start at a time, when the efforts that required to implement alarms in the days before computer control had not been forgotten. It appears, that in the decades which followed control engineers discovered how easy it was to implement alarms in modern distributed control systems (DCS), and simply went to far - probably pushed along by equipment suppliers requesting equipment alarms.
Usually when people talk about alarm design, they talk about whether the alarm should just go to the DCS or it should also be displayed on the hardwired annonciator panel. That is the engineering is concentrated on how to display the process situation to the person, who is going to act on it.
However, it appears to me, that the fundamental question of alarm design, i.e. what to be alarmed about and when to be alarmed have not been addressed from an engineering perspective just like the design of other elements of the automation system such as the control loops. The available guides on alarm managements, such as the EEMUA Guide no. 191, seem to focus on the issues after you got to many alarms, and not how you got there.
It is generally recognized that alarms are used to signal to someone, that something is happening in the process, which requires an intervention beyond the capability of the automatic control system, and if you do nothing, then the automatic shutdown system will take over. This means that the ability of the process to do what is has been designed to do by the process engineers are threatened. It cannot reach the goal the designers had in mind. In other words alarms are used to indicate, that a goal cannot be reached.
On the opposite if the goal of the process can be reached then, we don't need to be alarmed. What the is the goal of the process then? Well, that depends on its current state. If the process has been down for maintenance with opening of vessels etc. then it first need to be enabled, i.e. put together again. The goal is to start up the process. Beside enablement, this also involve ensuring the process is ready for start-up, i.e. has been established by connecting the control system and putting valves, pumps etc. in proper state for startup.
If the process is producing, then the goal could be to maintain production, or to change to a different production rate, or to transition to producing a different product. The important thing to note, is that when the goal of the system changes, then what is normal and abnormal also changes, and hence the required alarms changes.
So a process is in the normal state, when it satisfying the goal it was built to accomplish, e.g producing a given amount of product of a given quality with a given time using the avaiable equipment and other resources. When this is the case, then the material and energy balances around the system are also satisfied. This means, that abnormal situations can be related back to significant deviations in material and energy balances for the plant, process unit or piece of equipment. The litterature abound with examples of disasters due to problems with these two fundamental balances, e.g. BP Texas City Refinery explosion and fire in March 2005.
So one approach to alarm design is to look for indicators of problems with material and energy balances at the equipment, process unit and plant level. Of course a necessary condition for no problems at the unit level is, the equipment balances within the unit are normal. Similarly at the plant level. A different way of stating this is, that when the goal of a process unit is satisfied, then the sub-goals of the process unit, e.g. the goals of the different pieces of equipment within the unit are satisfied. Hence the plant goal in a tree like structure may be related to the process units goals which are again related to the equipment goals.
Modelling such goal structures can be done using functional modelling. Currently work is ongoing at DTU on exactly the problem: What to be alarmed about? When to be alarmed?