HMI Screen Design and Alarm Management

Short answer

A useful HMI shows the operator what matters for deciding and reserves color for the abnormal. Alarms are managed as a system with a lifecycle: each one must indicate a condition that demands action, with a defined priority, cause, and response, and be reviewed with indicators. ISA 18.2, IEC 62682, and the EEMUA 191 guide frame that practice.

Short answer

An HMI (human-machine interface) lets an operator see the state of the process, detect what is abnormal, and act. Its quality is measured by how quickly and accurately it achieves that, not by graphic realism. Alarms are part of the HMI and are treated as a system with a lifecycle: design them, put them in service, measure them, and improve them. The practice references are ISA 18.2, IEC 62682, EEMUA 191, and other industry guides; this guide summarizes them and does not reproduce their figures, which are paid or restricted.

What a screen must achieve

Show the overall state at a glance.
Make the abnormal evident.
Give quick access to detail and control.
Prevent operating errors.
Be consistent across screens.

Screen hierarchy

Level	Content	Use
1. Overview	The whole process or plant with key indicators and active alarms	Continuous monitoring
2. Area or unit	Equipment of a section with its main variables	Normal operation and alarm response
3. Equipment or loop	Detail of a piece of equipment, controller, or sequence, with controls	Operation and adjustment
4. Diagnostics	Internal states, input and output signals, trends, help	Maintenance and fault analysis

The operator must be able to go from the overview to the cause of an alarm in a few steps. One screen per piece of equipment without an overview forces blind navigation.

Design principles

Discreet normal state. Neutral background, symbols in gray or soft tones. That way whatever appears in color stands out.
Color with meaning. It is reserved for alarms and abnormal states, with a consistent code throughout the HMI. It is never the only signal: it is accompanied by shape, text, or position.
Values with context. A number alone says little. Showing the value next to the normal range, the alarm limit, and a short trend helps decision-making.
Standard symbols. Equipment is represented with consistent symbols, in line with the project’s piping and instrumentation diagram or single-line diagram.
Protected controls. Dangerous controls ask for confirmation or a second step, and show the resulting state, not just the command.
Legible text. Size and contrast sufficient for the distance and lighting of the room or the field.
No decoration. Animations, shadows, and graphics that do not inform are distracting.
Consistent navigation. Navigation bar and fixed zones for alarms, time, and user.

Alarms: what they are and what they are not

An alarm is an audible or visible signal that alerts the operator to a condition that demands a response. If it does not require action, it is not an alarm: it is an event, a state, or an informational message. This distinction reduces volume more than any other measure.

Each well-defined alarm has:

Attribute	Question it answers
Cause	What condition triggers it?
Consequence	What happens if it is not handled?
Response time	How much time does the operator have?
Action	What must be done?
Priority	How urgent is it compared with the others?
Limit and delay	At what threshold and duration does it activate?

Priorities

Few priorities are used (for example, three or four), defined by the severity of the consequence and the time available. Most alarms should be low or medium priority; the highest-priority ones are few and always important. If everything is a priority, nothing is.

Typical alarm problems

Problem	Description	Remedy
Flood	Many alarms in a short time during a disturbance	State-based suppression, grouping, root-cause alarms
Nuisance alarms	They activate and clear with no possible action	Adjust threshold and delay, hysteresis, or filter
Chattering alarms	They change state repeatedly	Deadband and delay
Stale alarms	They stay active for days	Fix the condition or remove the alarm
Redundant alarms	Several signals for the same event	Keep one, the root cause
Alarms without action	The operator does not know what to do	Define a response or turn it into an event
Shelved alarms without control	Hidden by the operator and forgotten	Shelving procedure with logging and review

The public history of alarm management shows why they happen: with digital systems, adding an alarm cost almost nothing, and each incident or hazard study added more. The result was operators with more data than they can use.

Lifecycle

Alarm management standards describe a cycle with repeating stages:

Philosophy: site rules for defining, prioritizing, and handling alarms.
Identification: which signals are candidates.
Rationalization: confirming that each alarm meets the philosophy and setting its priority, limit, and response.
Detailed design: how it is presented (screen, sound, message).
Implementation and testing.
Operation: operator response and logging.
Maintenance: repair and testing of the associated instrumentation.
Monitoring and assessment: performance indicators.
Management of change: every new or modified alarm goes through the process.
Periodic audit.

Indicators to watch

Alarms per operator and per period.
The most frequent alarms.
Stale alarms and their time active.
Maximum alarms in bursts.
Distribution by priority.
Operator response time.

The target values are set by the site philosophy based on the guides; the trend over time matters as much as the figure.

Illustrative example

Illustrative. A plant has a process tank with a high-level alarm at 80% that activates and clears several times per shift because the level oscillates from agitation. The operator silences it without doing anything.

Analysis: it has no useful action, it is a nuisance alarm.
Solution 1: add a deadband and a delay so it only activates on a sustained level.
Solution 2: if the level that matters is 95%, keep that one as the alarm and leave the 80% as an on-screen indication.
Result: fewer activations, and the alarm that remains means something.

The threshold and percentages are examples; in a real project, rationalization defines them.

Alarms in substations and in SCADA

In a power SCADA, the operator HMI shares principles with the plant one, with particularities: sequence of events with time stamp, alarms from breaker states or communication failure, and controls with verification. See substation SCADA and HMI and SCADA, SAS, DCS, and HMI: differences.

Common mistakes

Creating an alarm for every available signal.
Using color across the whole screen, so the abnormal does not stand out.
Setting thresholds “out of habit” at 20% and 80% of the range.
Giving every alarm the same priority.
Not defining what the operator does for each alarm.
Silencing alarms without logging or review.
Changing alarms during startup without leaving a record.
Making screens that replicate the piping diagram without hierarchy.

Checklist

How to review an existing HMI

An HMI already in operation is reviewed with the operator beside you. They are asked, faced with a simulated or historical disturbance, to describe what they look at first, what is missing, and what is superfluous. The steps to the cause of a critical alarm are counted, and screens nobody opens and alarms that are always silenced are looked for. With that, a list of improvements is built, ordered by effect: first the alarms that repeat the most and call for no action, then navigation, and last aesthetics.

Each change is recorded and tested in a simulation environment or in a rehearsal with the operator before going to production. Changing an alarm or a color without notice can confuse at the worst moment, which is why change control matters as much as the initial design.

How we help

The design of screens and of the alarm philosophy rests on knowledge of the process and the operation. At Tiza Group we develop it within the engineering design and studies service and verify each signal, alarm, and control in testing and commissioning.

References

Wikipedia, “Alarm management” (history, causes of alarm proliferation, and existing standards).
ISA 18.2, IEC 62682, and EEMUA 191 (paid or restricted).

Frequently asked questions

How many alarms per hour is reasonable?

Alarm management guides set target values for alarms per operator and per period, but those figures come from paid or restricted documents. As a general criterion: if the operator cannot handle each alarm with a clear action, there are too many, and the most repeated ones are reviewed.

What is an alarm flood?

It is the situation where, during a disturbance, more alarms appear than the operator can handle. The system stops helping and the operator loses sight of the critical ones. It is prevented with rationalization, state-based suppression, and well-prioritized alarms.

Why not use red and green for everything?

Because color loses meaning if it is everywhere. Bright color is reserved for abnormal conditions and grays are used in the normal state. Also, some operators cannot tell red and green apart well, so color must never be the only signal.

Who decides the priority of an alarm?

It is decided in a rationalization workshop with operations, process, safety, and maintenance. For each alarm, its cause, its consequence if not handled, the time available to respond, and the expected action are defined. That information sets its priority.