SCADA upgrades: a chance to redo HMI and alarms to ISA-101 and ISA-18.2

Why do it during the upgrade

When replacing a SCADA system — FactoryTalk View SE, AVEVA System Platform, InTouch or Ignition — most of the time usually goes into "redrawing it to look like the old screens". The result is a new system running on new software that keeps all the weaknesses of the old one: screens copied from P&IDs, bright colours everywhere, hundreds of alarms per shift that operators have grown used to acknowledging without a second look.

The upgrade is the only point at which fixing these things costs almost nothing extra: the screens and the alarm list have to be redone anyway. The two standards for an orderly approach are ANSI/ISA-101.01 (HMIs for process automation) and ANSI/ISA-18.2 (alarm management).

ISA-101: documents first, screens second

ISA-101 is a standard about the HMI lifecycle — how the HMI is specified, designed, implemented, operated and changed — not a colour palette. The standard is platform-independent and applies equally to FactoryTalk View, AVEVA or Ignition.

Before the first production screen is drawn, the project needs three documents:

The philosophy and the style guide can be combined into one document. If the plant does not have them yet, the style guide and the toolkit should be the first engineering deliverables of the upgrade project — fixing things after FAT always costs more than writing the documents up front.

A display hierarchy of at most four levels is recommended: an overview of the operator's whole span of control (level 1), the main operating displays for each area (level 2), equipment detail for infrequent tasks (level 3), and diagnostics (level 4).

Habits worth leaving behind

General principle: a neutral background so the normal state looks "quiet" and abnormal conditions stand out by themselves; strong colours reserved for abnormal conditions; never use colour as the only way to distinguish states — always add shape, text or position.

ISA-18.2: alarm only when the operator must act

A signal is an alarm only when three conditions are met at the same time: (1) there is an abnormality — equipment has failed or the process has deviated; (2) the operator must do something; (3) there is still enough time for that action to have an effect. If one condition is missing, it is an event, a status or a log entry — not an alarm. The rule "no action, no alarm" on its own removes most nuisance alarms.

Every alarm that is kept needs to be rationalized and recorded in the alarm database: cause, consequence if nobody responds, the specific action, allowable response time, priority (derived from consequence and time using a fixed table in the alarm philosophy — engineers do not pick the priority of each alarm by feel), setpoint and group.

To tell whether the alarm system is "healthy", ISA-18.2 gives reference metrics per operator position, measured over at least 30 days of operation:

These are reference levels for an operating plant, not acceptance criteria unless the contract says so. If almost every alarm is "high", the rationalization is not finished.

Where the two standards meet

• A colour used for an alarm priority is not used for anything else on any screen.
• Priority is shown in three ways at once — colour, shape and a text symbol — so it can still be read by colour-blind operators or on poor screens.
• The alarm indication sits right next to the value on the process display, not only in the alarm list.
• Acknowledge, shelve and jump to the alarm source work in one single way on every screen.
• For Logix + FactoryTalk View SE systems: fix the mapping table from controller alarm severity to displayed priority in the style guide, before the first alarm is configured.

Applying it in an upgrade project

1. Survey: number of screens, number of alarms, actual alarm statistics for at least a few weeks if the old system logs them.
2. Write (or update) the HMI philosophy + style guide, and build the toolkit on the new platform.
3. Rationalize the alarm list together with operations and process engineering — this usually reduces the number of alarms considerably without losing information.
4. Build the screens following the hierarchy, run FAT against the style guide, and run in parallel with the old system before cutover.
5. Hand over the baseline (project, alarm list, style guide) and put every change after handover through the management of change process.

How far ISA-101 and ISA-18.2 are applied should be agreed with the plant at the survey stage, whether the new platform is FactoryTalk View, AVEVA System Platform / InTouch or Ignition. Small-scale screen changes or alarm additions can be done under the Small SCADA changes and extensions package.