Presenting alarms so the operator can act on them

Alarm management effort concentrates on the database — which alarms exist, at what threshold, at what priority. The presentation layer receives far less attention, and a well-rationalised set of alarms shown on a poorly designed summary is still difficult to use.

The presentation questions are narrow and largely settled. Most of them are answered badly by default configurations.

The summary is the primary display during an upset

Design discussions frequently treat the alarm summary as a secondary screen. In practice, during any significant abnormal event, it is where the operator spends most of their attention, and the process graphics are consulted from it.

Distributed engineering teams sometimes use remote monitoring as a supplementary management control. Further details are available through this reference.

The wider alarm-management lifecycle is described in the ISA-18 alarm management standards.

It therefore deserves the same design effort as the main overview display, and it should be permanently visible — on a dedicated screen where the console has enough of them, rather than as a window the operator has to call up.

Sort order and what it implies

The default sort in many systems is chronological with newest first. Under flood conditions this is close to useless: the top of the list is whatever happened most recently, which during a cascade is the least informative alarm.

Priority-first sorting, with time as a secondary key, is the appropriate default. The operator sees the most consequential outstanding item at the top regardless of when it arrived.

Chronological order remains valuable for diagnosis and should be one keystroke away — determining the first-out alarm in a cascade is a common and important question — but it should not be the working view.

Colour discipline

Colour is the strongest visual channel available and most control room graphics spend it on decoration.

The principle that works is that colour indicates abnormality and nothing else. Normal running is grey. Equipment states, pipe contents, vessel fills and background structure are drawn in muted greys and outlines. When something is coloured, it is because it is abnormal, and the colour indicates priority.

This is uncomfortable at first — the resulting screens look dull compared with what many sites are used to — and it is the single change that most improves the operator's ability to detect an abnormal condition peripherally, without reading anything.

Colour also has to survive colour vision deficiency, which affects a meaningful proportion of the population. Priority should be distinguishable by shape, position, text or fill pattern as well as by hue. A scheme that relies on red versus amber alone is not readable by every operator.

Audible design

The audible channel is under-used and easy to get wrong.

It should differentiate priority — a distinct tone for each level — so that an operator away from the desk knows whether to hurry. It should not be so loud or so persistent that silencing it becomes reflexive. And it should be silenceable per alarm rather than globally, because a global silence disables the channel entirely for everything that follows.

The classic failure is a single tone that repeats until acknowledged, which under flood conditions produces a continuous noise that operators silence globally within seconds, removing the audible channel exactly when it was needed.

What each line has to contain

An alarm line should tell the operator what happened, where, how bad and when, in that order of prominence.

The description is the part most often wrong. Tag-based descriptions — a tag number and an alarm type — require the operator to know the plant by tag. A description in process language, naming the equipment and the condition, is readable by someone who is covering another operator's console.

The value at the time of the alarm, and the threshold, are worth including: the difference between a level marginally over its limit and one substantially over changes the response.

Acknowledgement design

Acknowledgement should be a per-alarm action that requires a deliberate act, and bulk acknowledgement of an entire page should either be unavailable or be logged distinctly.

Where bulk acknowledgement is available and easy, it becomes the standard response to a flood, and the acknowledgement metric stops measuring anything. Where it is unavailable, operators under flood conditions cannot clear the list and the display becomes unusable in a different way.

The compromise most sites reach is per-alarm acknowledgement as the norm, with a bulk function that is available, logged separately, and reported. Its use during floods is then visible as a symptom rather than hidden.

Navigation from the alarm

An operator reading an alarm needs to reach the relevant process display quickly. A summary where selecting an alarm calls up the associated graphic, with the alarmed item highlighted, removes several seconds and several decisions from every response.

This is straightforward to configure and frequently is not, leaving the operator to navigate by memory under pressure.

Showing the response

The rationalisation exercise produced a documented expected response for every alarm. Making that available from the alarm line — a linked procedure, or the response text displayed alongside — converts a document nobody reads into an operational aid.

For infrequent alarms this is the difference between an operator who knows what to do and one who is reasoning from first principles during an upset. Infrequent alarms are, by definition, the ones nobody has practised.

Testing the display with operators

Alarm displays are usually reviewed by the engineers who built them and signed off by a supervisor. The people who will use the display under pressure are rarely asked until it is in service.

A structured review — operators working through a simulated upset on the proposed display, with someone noting every hesitation — reliably finds problems that no amount of design review does. The hesitations are the data: each one marks a place where the display did not answer the question being asked.