AlarmIQ Engineering Guide • March 28, 2026 • 9 min read

MQTT Alarm Monitoring for Industrial Equipment

Traditional alarm monitoring is trapped inside the SCADA network. MQTT breaks that boundary — delivering alarm state changes to any subscriber, anywhere, in milliseconds.

The Problem with Polling-Based Alarm Systems

Most industrial alarm monitoring systems work by polling. A SCADA server or HMI reads PLC tags on a fixed interval — typically every 500ms to 5 seconds — checks for alarm conditions, and logs any changes. This approach has worked for decades within the confines of a single control network, but it has fundamental limitations.

Polling creates a latency floor equal to the poll interval. If you poll every 2 seconds, you can miss an alarm that activates and clears within that window. More importantly, polling does not scale well across plants. If you want a central monitoring system across 50 machines in 3 buildings, you need the SCADA server to maintain persistent connections and poll cycles for every machine — a configuration nightmare that grows linearly with machine count.

Then there is the network boundary problem. SCADA systems typically run on isolated OT networks with no internet access. Getting alarm data to a cloud dashboard, a mobile phone, or an enterprise historian means building complex DMZ architectures with data diodes, relay servers, and custom middleware.

Why MQTT Is Better for Alarm Delivery

MQTT is a publish-subscribe messaging protocol designed for constrained networks. Instead of polling, devices publish messages when state changes occur. Subscribers receive those messages immediately. The fundamental difference is event-driven delivery vs. scheduled reads.

For alarm monitoring, this means:

Zero-poll latency — alarm state changes are published the instant they occur, not at the next poll cycle
Report by exception — only changes are transmitted, reducing network traffic by 90%+ compared to cyclic polling
Decoupled architecture — publishers and subscribers do not need to know about each other. Adding a new alarm consumer requires zero changes to the PLC or edge gateway.
Built-in QoS — MQTT supports three quality-of-service levels. QoS 1 (at-least-once delivery) guarantees alarm messages survive network interruptions with automatic retry.
Retained messages — the broker stores the last message on each topic. When a new subscriber connects, it immediately receives the current alarm state without waiting for the next change.
Lightweight protocol — MQTT runs on minimal bandwidth. A complete alarm state change message is typically under 200 bytes. This makes it viable over cellular networks for remote facilities.

Sparkplug B: The Industrial MQTT Standard

Raw MQTT defines a transport mechanism but not a data format. Sparkplug B, now an Eclipse Foundation specification, adds the structure that industrial applications need:

Topic Namespace

Sparkplug B defines a hierarchical topic structure: spBv1.0/GroupId/MessageType/EdgeNodeId/DeviceId. For alarm monitoring, a typical alarm topic might be:

spBv1.0/Plant1/DDATA/Line3/Mixer01

The DDATA message type indicates device data — a report-by-exception payload containing only the metrics (tags) that changed since the last publish.

Alarm Payloads in Sparkplug B

Sparkplug B uses Google Protocol Buffers (protobuf) for efficient binary encoding. Each metric in a payload includes:

Name — the tag path (e.g., Alarms/TempHH)
Datatype — Boolean for digital alarms, Int32 or Float for analog alarm values
Value — the current state
Timestamp — millisecond-resolution UTC timestamp from the edge node
Quality — good, bad, or stale indicator

This structure means every alarm state change arrives with a precise timestamp from the edge, not from the receiving server. For root cause analysis across multiple machines, having accurate edge timestamps is critical for determining event sequence.

Birth and Death Certificates

Sparkplug B includes birth (NBIRTH/DBIRTH) and death (NDEATH/DDEATH) messages. When an edge node connects, it publishes a birth certificate containing every metric it will report, including all alarm tags with their current values. When it disconnects unexpectedly, the broker publishes a pre-registered death certificate.

For alarm monitoring, this means:

A monitoring system always knows the complete set of alarms available from each machine
Connection loss is itself an alarm event, delivered automatically by the broker
No alarm state is unknown — birth certificates provide initial state, DDATA provides changes, death certificates signal loss of visibility

OPC-UA Subscriptions vs. MQTT Pub/Sub

OPC-UA also supports event-driven communication through its subscription model. A client creates a subscription, adds monitored items (tags), and receives notifications when values change. So why choose MQTT over OPC-UA for alarm monitoring?

Connection model — OPC-UA subscriptions are point-to-point. Each consumer needs its own session and subscription to the OPC-UA server. MQTT is one-to-many: a single publish reaches all subscribers.
Network traversal — OPC-UA requires bidirectional TCP connections, which are difficult to route through firewalls and NAT. MQTT uses outbound-only connections from the edge, passing through firewalls naturally.
Broker persistence — the MQTT broker stores messages for disconnected subscribers (with QoS 1/2 and persistent sessions). OPC-UA subscriptions have a lifetime — if the client disconnects for too long, the subscription is dropped and data is lost.
Scalability — an OPC-UA server has practical limits on concurrent sessions (typically 20-50). An MQTT broker can handle thousands of concurrent subscribers.

The pragmatic approach: Use OPC-UA at the edge to read PLC tags, and MQTT to transport them to monitoring systems. An OPC-UA-to-MQTT edge gateway combines the best of both: reliable PLC communication via OPC-UA, efficient fan-out via MQTT.

Setting Up Alarm Monitoring Without SCADA

You do not need a full SCADA system to monitor alarms. A minimal MQTT-based alarm monitoring setup requires three components:

1. Edge Gateway

A small industrial PC or gateway appliance running an OPC-UA client and MQTT publisher. Common options include:

Ignition Edge with MQTT Transmission module
Kepware with IoT Gateway plugin
Open-source solutions like Node-RED with OPC-UA and MQTT nodes
Dedicated hardware like HMS Ewon or Moxa gateways

The edge gateway connects to the PLC via OPC-UA (or EtherNet/IP for Allen-Bradley, S7 for Siemens), reads alarm tags, and publishes state changes to the MQTT broker.

2. MQTT Broker

The broker can run on-premise, in the cloud, or as a managed service. For industrial alarm monitoring:

On-premise: Mosquitto (open source) or HiveMQ for higher availability
Cloud: AWS IoT Core, Azure IoT Hub, or HiveMQ Cloud

For alarm reliability, use QoS 1 at minimum. QoS 0 (fire-and-forget) risks losing alarm messages during network glitches.

3. Alarm Consumer

Any MQTT subscriber can consume alarm data. This could be a cloud application, a mobile notification service, an enterprise historian, or a dedicated alarm management platform.

Edge Deployment Considerations

Deploying MQTT alarm monitoring at the edge introduces practical considerations:

Store and forward — the edge gateway must buffer alarm messages during internet outages and forward them when connectivity returns. Most commercial gateways support this natively.
Local alarm processing — for time-critical alarms, process them at the edge rather than waiting for a cloud round-trip. Edge logic can send SMS or trigger local outputs directly.
Bandwidth — MQTT alarm messages are small, but if you publish every tag change (not just alarms), bandwidth can add up on cellular connections. Configure the edge gateway to filter alarm-relevant tags only.
Security — use TLS encryption and certificate-based authentication for all MQTT connections. Never expose an MQTT broker to the internet without authentication.

MQTT-Native Alarm Intelligence

AlarmIQ connects to your MQTT broker or OPC-UA server and monitors every alarm in real time. Combine live alarm data with PLC program analysis for instant root-cause tracing — no SCADA required.

Learn About AlarmIQ