Alarm Rationalisation: Why What's Written Down and What Actually Happens Are Often Very Different
- Paul Gowans
- 2 days ago
- 5 min read
Alarm rationalisation is a key activity in any alarm management programme. According to EEMUA 191, it is "a process whereby a multi-function team determines what alarm configuration (priority and settings) is required for individual parameters in the control system." In practice, it is a systematic review of every alarmable tag in a distributed control system, with the objective of optimising both the quantity and quality of alarms across a site.
The process is straightforward in principle. Each alarm is assessed against a clear standard: does it notify the operator of an abnormal situation that requires timely action? If an alarm does not protect people, the environment, the process, or equipment, and if there is no corresponding operator action, then it needs to be updated or removed. Every alarm that remains should have a defined priority, a documented cause, and a clear operator response.
A well-rationalised alarm system should mean that when an alarm occurs, the operator knows exactly what it means, why it matters, and what to do about it.
However, it is not usually that simple in practice.
The gap between documentation and reality
Alarm rationalisation produces documentation that describes how a system was understood to behave at the time it was written, and how operators respond when alarms occur in the real world.
When an alarm happens, operators use their experience, such as pattern recognition, and an understanding of the process that can go beyond what is written in procedure documentation. Sometimes the documented response is followed precisely, but often it is not. This is not because operators are ignoring procedures, but because the documented response does not always reflect reality and how the process behaves, or because the alarm occurs in a context that was not previously anticipated in the documentation.
This gap between what is written down and what actually happens is common. In data analysis carried out by Intelligent Plant across multiple industrial sites, a consistent pattern emerged. The alarms occurring most frequently were disproportionately those with no or very infrequent actual operator response at all. This is to be expected, as these are the bad actors, and these alarms are effectively broken. However, when looking at specific individual alarms, on some sites, over 90% of these have no or very infrequent response*. As EEMUA 191 makes clear, an alarm that does not prompt a response is not fulfilling its purpose. The scale of the problem suggests this is not an isolated issue but a widespread one across the industry.
*Note: It is possible that the response is outwith the control system and therefore not logged with the alarm and event data, but these sites were highly instrumented and designed to be controlled by a single control room operator, therefore it would be expected that some kind of intervention is logged.
This is not a criticism of the operators. It is a reflection of the fact that alarm documentation is often written based on engineering assumptions rather than current operational behaviour. Over time, gaps can open up between the two as processes change and experience accumulates.
Alarm rationalisation is also enormously time-consuming
Alarm rationalisation is difficult to get right, but also a highly demanding undertaking in terms of time and resource. A thorough review of every alarmable tag on a complex industrial asset can take a multidisciplinary team months to complete. Every alarm needs to be assessed individually, its priority confirmed, its cause documented, and an appropriate operator response defined.
It is a worthwhile investment, but only if the outputs are based upon how the process actually behaves.
What SEER reveals
SEER is a Sequence of Events tool built by Intelligent Plant. It ingests alarm and event data from an asset and builds a visual map of alarm sequences, showing not just that an alarm happened, but what happened before it, what happened after it, and how the sequence played out across multiple occurrences.
The starting point is often just a simple chain:
A trip occurs.
The pump stops.
Discharge flow goes low.
Discharge pressure goes low.
The discharge valve closes.
Each step follows the previous one in a predictable sequence.
But as more data is added, the picture becomes more complex. In the example below, we see a level indicator controller (10LIC0019) go in to alarm. We then see 4 interventions (blue circles) that the operator has previously taken in response to the alarm. Three of these interventions sometimes lead to further alarms. However, the most common response, indicated by the thickness of the arrows, always clears the alarm without introducing other alarms in the sequence.
What may look like a simple, linear alarm sequence can turn out to have multiple causes and multiple pathways.
SEER makes this visible. It shows which sequences occur most frequently, which paths actually lead to the alarm clearing, and importantly, what operators actually do at each step, across every recorded occurrence. That last point is where the gap between documentation and reality becomes impossible to ignore.
When you can see, across hundreds of occurrences, that operators are consistently taking a different action to the one documented, or that the documented action is only taken a fraction of the time, that is a signal that the documentation needs to be revisited.
How SEER can help with rationalisation itself
Beyond revealing the gap between documentation and practice, SEER can play a direct role in the rationalisation process itself. By showing which operator responses actually lead to alarm resolution across real historical data, SEER gives rationalisation teams a factual basis for deciding what the documented response should be, rather than relying on engineering assumptions that may never have been tested against operational reality.
This has the potential to make rationalisation both faster and more accurate. Rather than working purely from engineering knowledge and historical documentation, teams can use SEER's analysis of real operational data to inform decisions about alarm priorities, causes, and responses. The result is documentation that reflects how the process actually behaves.
What this means for alarm rationalisation
A rationalisation exercise that is based purely on engineering assumptions and historical documentation will always have blind spots. The documented alarm responses may look correct on paper but fail to reflect how the process actually behaves under varied operating conditions.
The most valuable rationalisation programmes are those that combine the structured review process with real operational data, using tools such as SEER to understand what is really happening before deciding what the documentation should say. That way, the alarm system that emerges from rationalisation is grounded in operational reality rather than theory.
If your facility has completed an alarm rationalisation exercise but you are not sure whether the documented responses reflect what actually happens in the control room, that is exactly the question SEER is designed to answer.
🔗Check out related blog posts:
Comments