Alarm management in manufacturing is the discipline of making sure every alarm an operator sees is real, relevant and actionable. This guide explains why alarm floods happen, what the ISA-18.2 lifecycle asks you to do, how to set priorities and deadbands, and how to publish alarm events over MQTT so dashboards, notifications and analysis tools all see the same truth.
Why Alarm Management Matters
An alarm exists to tell an operator that something requires a response within a limited time. When that promise breaks, people learn to ignore alarms. Typical symptoms in plants without alarm management:
- Standing alarms that stay active for days because nobody can or will fix the cause.
- Chattering alarms that toggle on and off many times a minute around a limit.
- Alarm floods after an upset, where one root cause triggers dozens of consequential alarms and the important one scrolls out of view.
- Everything is high priority, so priority carries no information.
- Alarms with no defined response, configured "just in case" during commissioning.
The result is alarm fatigue. Operators acknowledge without reading, and when a genuinely critical alarm arrives it competes with noise. Investigations of several well-known industrial incidents have pointed to overwhelmed operators as a contributing factor, which is why alarm management became a formal discipline.
ISA-18.2 Basics
ANSI/ISA-18.2 (and its international counterpart IEC 62682) is the reference standard for alarm management in the process industries, and its ideas apply equally well to discrete manufacturing. Its core concept is an alarm management lifecycle:
| Stage | What happens | Output |
|---|---|---|
| Philosophy | Define what an alarm is, priorities, colors, response times, KPIs | Alarm philosophy document |
| Identification | Find candidate alarms from hazard studies, quality and maintenance needs | Candidate list |
| Rationalization | Justify each alarm: cause, consequence, response, time to respond, priority | Master alarm database |
| Detailed design | Set limits, deadbands, delays, suppression logic | Configured alarms |
| Implementation | Deploy, test, train operators | Live system |
| Operation | Operators respond; shelving and out-of-service handled by procedure | Alarm events |
| Maintenance | Repair instruments, test alarms | Maintained system |
| Monitoring and assessment | Measure alarm rates, floods, top offenders | Improvement actions |
| Management of change | Control additions, deletions and limit changes | Audit trail |
| Audit | Periodic review against the philosophy | Audit report |
The most valuable step for most plants is rationalization. For every alarm, ask: what is the cause, what happens if nobody acts, what exactly should the operator do and how much time do they have? An alarm without a clear answer to the third question is not an alarm; it is an event or a notification and belongs in a log, not on the operator's screen.
ISA-18.2 also gives commonly used benchmarks for alarm load per operator and defines an alarm flood as a burst of alarms that exceeds what an operator can handle, typically more than ten alarms in ten minutes. Use the standard's figures in your philosophy rather than inventing your own.
Alarm Management Manufacturing Teams Can Sustain: Priorities and Design
Setting Priorities
Priority should come from two factors: the severity of the consequence and the time available to respond. A simple matrix works:
| Consequence | Response needed within minutes | Response needed within an hour or more |
|---|---|---|
| Safety, environment or major equipment damage | High | Medium |
| Product loss or quality hold | Medium | Low |
| Minor efficiency loss | Low | Not an alarm (event or notification) |
Keep the high-priority share small. If more than a small minority of configured alarms are high priority, revisit the rationalization.
Deadbands and Delays
Most chattering alarms are a design issue, not a process issue:
- Deadband (hysteresis): an alarm that triggers above 80 °C clears only below, for example, 78 °C.
- On-delay: the condition must be true for a set time before the alarm activates, filtering momentary spikes.
- Off-delay: the condition must be clear for a set time before the alarm returns to normal, preventing rapid re-triggering.
Suppression and Shelving
During a planned shutdown, low-flow alarms on a stopped pump are expected and useless. State-based suppression hides alarms that are meaningless in the current machine state. Shelving lets an operator temporarily remove a nuisance alarm under a controlled procedure with an automatic time limit, so it cannot be forgotten.
Publishing Alarm Events over MQTT
Alarms usually originate in PLCs, DCS or SCADA. Publishing them over MQTT lets other consumers (andon boards, mobile notifications, maintenance systems, analysis) use the same events without separate integrations. Two topic types work well together:
acme/plant1/press/line3/press2/alarm/HYD_TEMP_HI retained: current state of this alarm
acme/plant1/press/line3/alarm-events not retained: every transition, for history
The retained per-alarm topic gives any client the current active alarm list just by subscribing to .../alarm/#. The event stream feeds a database for alarm KPIs such as alarms per hour, top ten offenders and flood periods.
The Python example below implements an alarm with deadband and on-delay on a temperature reading, and publishes both topics. It uses paho-mqtt 2.x and the free public MQTT broker for testing.
import json
import time
import uuid
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/alm-2e7b/press2"
ALARM_ID = "HYD_TEMP_HI"
HIGH, CLEAR, ON_DELAY_S, PRIORITY = 80.0, 78.0, 5.0, "HIGH"
active = False
pending_since = None
def publish_alarm(client, state, value):
event = {"alarm": ALARM_ID, "state": state, "priority": PRIORITY,
"value": value, "limit": HIGH, "ts": time.time()}
client.publish(f"{BASE}/alarm/{ALARM_ID}", json.dumps(event), qos=1, retain=True)
client.publish(f"{BASE}/alarm-events", json.dumps(event), qos=1)
print(event)
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/hydraulic/temp", qos=1)
def on_message(client, userdata, msg):
global active, pending_since
value = json.loads(msg.payload)["tempC"]
now = time.time()
if not active:
if value > HIGH:
pending_since = pending_since or now
if now - pending_since >= ON_DELAY_S:
active = True
publish_alarm(client, "ACTIVE", value)
else:
pending_since = None
elif value < CLEAR:
active, pending_since = False, None
publish_alarm(client, "CLEARED", value)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"alarm-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()
Send readings above 80 for more than five seconds and the alarm activates; it clears only below 78. Acknowledgement can be added the same way: the HMI publishes an ack event, and the alarm service updates the retained state to ACTIVE_ACKED.
Alarm Management Checklist
- Write a one-page alarm philosophy before configuring anything new.
- Export the current alarm list and rank alarms by frequency; the top ten usually generate most of the load.
- Rationalize those first: cause, consequence, response, time, priority.
- Add deadbands and delays to every chattering alarm.
- Demote alarms without an operator action to events or notifications.
- Implement state-based suppression for machines that are stopped or in changeover.
- Measure alarm rate per operator and flood periods weekly.
- Control changes to limits and priorities through management of change.
Where ConnectMQ Fits
ConnectMQ is a hosted MQTT broker that carries alarm events between controllers, dashboards and notification services, with MQTT 5, retained messages, TLS and secure WebSocket for browser-based andon screens. The portal also includes threshold alert rules and an alerts log, which are useful for simple monitoring notifications, for example a cold room or a bearing temperature crossing a fixed limit. They complement, but do not replace, rationalized process alarms and safety systems in your PLC or SCADA, which remain the place for alarms that require an operator action.
To make alarms visible on the line, combine them with a digital andon system and machine status monitoring. The smart manufacturing guide shows how alarm data fits into the full plant data architecture.
Route Your Alarm Events Through ConnectMQ
Create a free Serverless broker at app.connectmq.com with no credit card, publish your first alarm topics and watch the active alarm list update live in the topic explorer.
Frequently Asked Questions
What is an alarm flood?
An alarm flood is a period when alarms arrive faster than an operator can respond, often after a single upset triggers many consequential alarms. ISA-18.2 commonly uses more than ten alarms in ten minutes per operator as the threshold.
What is alarm rationalization?
It is the systematic review of each alarm to document its cause, consequence, required operator action, allowed response time and priority. Alarms that fail this review are removed or turned into events.
Is ISA-18.2 only for the process industry?
It was written for process industries, but its lifecycle, rationalization and performance monitoring apply to discrete manufacturing lines as well.
Can MQTT be used for safety alarms?
Safety functions belong in certified safety systems and PLCs. MQTT is well suited for distributing alarm information to dashboards, notifications and analysis, not for executing safety actions.
