Alarms Operators Can Trust: Alarm Management for Modern SCADA – White Paper

Executive summary

An alarm should tell an operator about an abnormal situation that needs a timely response. When systems raise far more alarms than people can handle, important ones are missed.
ANSI/ISA-18.2 and EEMUA 191 describe a lifecycle for managing alarms: a written philosophy, rationalisation of each alarm, good design, and continuous monitoring.¹²
Both give guidance on manageable alarm rates per operator, so alarm performance can be measured rather than argued about.
Because SCADA can change the physical process, it must also be secured as an industrial control system, following NIST SP 800-82 and IEC 62443.³⁴
We built these practices into the Inplux SCADA software from the start, instead of adding them after go-live.

1. When alarms stop working

Most plants did not design their alarm load; it accumulated. Each new instrument, each upgrade and each incident adds alarms, and few are ever removed. The result is familiar: nuisance alarms that chatter on and off, alarms that stay active for days, and floods during upsets when dozens of alarms arrive in minutes.

Operators adapt by acknowledging alarms without reading them. At that point the alarm system no longer protects the plant, and the one alarm that matters can be lost among the others.

2. The alarm management lifecycle

ISA-18.2 treats alarms as something to be managed over the whole life of a system, not configured once.¹ In simplified form, the lifecycle is:

Philosophy — agree the rules for what is and is not an alarm.
Identification and rationalisation — review every candidate alarm against those rules.
Design and implementation — set limits, priorities, deadbands and displays.
Operation and maintenance — respond, shelve with control, and keep instruments healthy.
Monitoring and assessment — measure performance and feed lessons back.
Management of change and audit — control additions and changes and review the system periodically.

3. Start with an alarm philosophy

The philosophy is a short document agreed by operations, engineering and safety. It defines:

What qualifies as an alarm: an abnormal condition that requires an operator action.
Priority levels and how they are chosen, typically from the consequence of not acting and the time available to act.
Colours, sounds and display rules used consistently across all screens.
Who may change alarm settings, and how changes are approved and recorded.
The performance targets the plant will measure itself against.

Design principle

If no operator action is required, it is not an alarm. It may still be a useful event, log entry or report — but it should not demand attention.

4. Rationalise every alarm

Rationalisation reviews each alarm with the people who operate the plant. For every alarm the team records the cause, the consequence, the required response, the time available and the resulting priority. Alarms without a clear required action are removed or reclassified; duplicate alarms for the same condition are consolidated.

Simple engineering techniques remove much of the nuisance load: deadbands and delays to stop chattering, suppression of alarms that are expected in a given operating state (for example when a unit is shut down), and grouping of consequential alarms behind the first-out cause.

5. Design for the operator

Clear priority. A small number of priority levels, used consistently, so the most important alarm is always obvious.
Context. Each alarm links to the relevant process screen and the agreed response.
Controlled shelving. Operators can temporarily shelve a nuisance alarm, but shelving is time-limited, recorded and visible to supervisors.
Calm screens. Process graphics that emphasise abnormal conditions, rather than colouring every value.

6. Measure alarm performance

EEMUA 191 and ISA-18.2 both give guidance on the alarm rate a single operator can handle in steady operation, and on how to recognise alarm floods.¹² Measuring against such targets turns alarm management into a routine improvement process. Useful measures include:

Measure	What it reveals
Alarms per operator per hour or per 10 minutes	Overall load against the guidance in the standards
Percentage of time in flood	How often operators are overwhelmed during upsets
Top 10 most frequent alarms	The few alarms that usually cause most of the load
Chattering and long-standing alarms	Settings or instruments that need attention
Shelved and suppressed alarms	Whether protection is being bypassed

7. Secure the supervisory layer

SCADA connects operators to the physical process, so a compromise can have physical consequences. NIST SP 800-82 sets out how industrial control systems differ from office IT and how to secure them;³ IEC 62443-3-3 defines system security requirements and security levels.⁴ In practice this means segmented networks, authenticated and role-based access, logging of operator actions and configuration changes, controlled remote access, and tested backups.

8. How we apply this in Inplux

Alarm priorities, deadbands and delays are configured per tag, following the site’s alarm philosophy.
Acknowledgement, shelving and configuration changes are recorded with user and time.
Alarm history is stored so the measures above can be reported per shift and per area.
Role-based access separates operators, engineers and managers.

9. Conclusion

An alarm system is only valuable if operators trust it. Following an established lifecycle — philosophy, rationalisation, good design and measurement — and securing the system as an industrial control system, makes SCADA alarms meaningful again. These principles shaped the design of the Inplux SCADA software.

References

ANSI/ISA-18.2-2016. Management of Alarm Systems for the Process Industries. International Society of Automation.
EEMUA Publication 191 (2013). Alarm Systems — A Guide to Design, Management and Procurement, 3rd edition. Engineering Equipment and Materials Users Association.
Stouffer, K., Pillitteri, V., Lightman, S., Abrams, M., Hahn, A. (2015). Guide to Industrial Control Systems (ICS) Security. NIST Special Publication 800-82 Revision 2. https://doi.org/10.6028/NIST.SP.800-82r2
IEC 62443-3-3:2013. Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels. International Electrotechnical Commission.

This white paper is provided for information. Figures labelled “Established” or “Peer-reviewed” are taken from the cited sources; figures labelled “Industry claim” have not been independently verified by LIDAVI; anything labelled “Design target” or “Hypothesis” is LIDAVI’s own and must be confirmed in a site-specific feasibility study. Nothing here is a performance guarantee.