Steel plants running OPC UA polling architectures hit a ceiling long before their sensor counts do. A rolling mill instrumented with 300 vibration, thermal, and current sensors polled every second creates 300 sequential request-response cycles every second, and every sensor added afterward adds proportional load to the polling server. MQTT inverts that relationship: sensors publish to a topic the instant a value changes, and any number of subscribers — CMMS work order engines, historians, dashboards — receive that value at once without ever having to ask for it. This publish/subscribe pattern is why sensor-dense steel operations move away from polling once update rates start lagging behind real equipment state. Plants that pair an MQTT broker with CMMS integration report faster alarm-to-work-order times because data arrives as a pushed event, not a polled answer. If your plant's sensor count is outgrowing a polling architecture, start a free trial with Oxmaint to test broker-based ingestion against what you run today.
Industrial IoT · MQTT Broker · CMMS Integration
MQTT for Steel Plants: The Broker Layer That Replaces Sensor Polling
MQTT is a lightweight publish/subscribe messaging protocol built for exactly the conditions a steel mill produces: thousands of sensors, unreliable network segments, and a need for data to move the instant it changes rather than on a fixed polling schedule. A broker sits between publishers and subscribers, routing messages by topic instead of by direct connection, which is what lets a single sensor feed a CMMS, a historian, and a live dashboard from one publish.
92%
Reduction in network request volume switching from OPC UA polling to MQTT publish/subscribe
3x
More sensors supported per gateway without added polling overhead
40ms
Typical publish-to-subscriber latency for a QoS 1 alarm topic on plant-floor networks
Architecture Comparison
MQTT Publish/Subscribe vs OPC UA Polling
Both protocols move sensor data from the plant floor into software. The difference is who initiates the exchange. OPC UA client-server polling asks "what is the value now?" on a timer. MQTT publish/subscribe waits for the value to change, then pushes it — and that single design choice changes bandwidth use, scalability, and how fast a CMMS can react to a failing bearing.
| Factor | OPC UA Polling | MQTT Publish/Subscribe |
|---|
| Data movement trigger | Client requests value on a fixed interval | Sensor publishes only when the value changes |
| Network load at scale | Grows linearly with sensor count and poll frequency | Grows with actual change events, not sensor count |
| New subscriber cost | Each new consumer adds a new polling client | Any number of subscribers read the same topic for free |
| Update latency | Bounded by poll interval, typically 1–5 seconds | Bounded by network transit, typically 20–100 ms |
| Behavior on disconnect | Client silently misses values until reconnect | Broker can queue and retain last known value per topic |
| Typical use case | Structured, address-space-driven equipment data | High-sensor-count telemetry and event-driven alarms |
How It Works
From Sensor to Work Order — the MQTT Data Path
Every value that reaches a CMMS through MQTT travels the same five-stage path. Understanding each stage is what makes topic design, QoS selection, and broker sizing decisions straightforward instead of guesswork.
01
Sensor Publishes to a Topic
A vibration sensor on furnace bearing 4 publishes its reading to a topic such as mill3/furnace/bearing4/vibration. The topic string is the only addressing mechanism in MQTT — there is no central tag database to configure, which is a large part of why onboarding a new sensor takes minutes instead of a change-control ticket.
02
Broker Receives and Routes the Message
The broker does not interpret the payload. It matches the topic string against every subscriber's topic filter and forwards a copy to each match. A broker handling 5,000 sensors across a mill routes messages in microseconds because topic matching is a string operation, not a database lookup.
03
Quality of Service Governs Delivery Guarantee
Each publish carries a QoS level — 0, 1, or 2 — that determines whether the message is sent once with no confirmation, delivered at least once, or delivered exactly once. Alarm topics typically use QoS 1 or 2; high-frequency vibration streams often use QoS 0 to avoid acknowledgment overhead at volume.
04
CMMS Subscribes and Evaluates Thresholds
Oxmaint subscribes to the relevant topic tree and evaluates each incoming value against the asset's configured thresholds. A value crossing the bearing-4 vibration threshold triggers a rule evaluation the same second it is published — there is no wait for the next poll cycle to notice.
05
Work Order Generates and Routes to the Technician
A threshold breach auto-generates a work order against the correct asset record, attaches the triggering sensor reading and trend context, and routes it to the technician responsible for that equipment zone — closing the loop from sensor event to assigned task without a person watching a dashboard.
The entire path — sensor to broker to CMMS to assigned technician — typically completes in well under a second on a healthy plant network, compared with the multi-second-to-minute detection windows common in polling-based monitoring setups. That speed difference is what separates a bearing caught at first temperature drift from one caught after it has already started to seize.
Topic Design
Structuring an MQTT Topic Hierarchy for a Steel Mill
A topic hierarchy is the single design decision that determines whether an MQTT deployment stays manageable at 10,000 sensors or becomes an unreadable flat namespace. A hierarchical, predictable structure lets any subscriber — human or system — filter to exactly the data it needs using wildcard subscriptions.
Level 1
Facility
The top level identifies the physical site — mill1, mill2, sinterplant — so a company running multiple facilities can subscribe to one site or all of them from a single broker connection.
Level 2
Production Area
Below facility sits the functional area — furnace, castingline, coldrolling — matching how maintenance teams are actually organized and dispatched across the plant floor.
Level 3
Asset
Each individual piece of equipment gets its own topic segment — bearing4, pumpB, drivemotor2 — matching one-to-one with the asset record inside the CMMS for direct threshold-to-asset mapping.
Level 4
Measurement
The final segment names the specific measurement — vibration, temperature, current draw — so a subscriber can filter to exactly one signal type across every asset in the plant using a single wildcard.
Delivery Guarantees
Choosing the Right QoS Level Per Sensor Type
QoS is not a single plant-wide setting — it is a per-topic decision that trades delivery guarantee against network and broker overhead. Mixing levels correctly across a sensor fleet keeps the broker efficient without ever losing an alarm.
QoS 0
Fire and Forget
No acknowledgment, no retry. Best fit for high-frequency continuous streams — raw vibration waveform samples, ambient temperature logging — where an occasional dropped sample does not change the trend and acknowledgment overhead would overwhelm the broker at that publish rate.
QoS 1
At Least Once
Guaranteed delivery with possible duplicates. The standard choice for threshold-crossing alarms and status changes, where missing the message is unacceptable but a technician or system receiving it twice causes no harm.
QoS 2
Exactly Once
Guaranteed single delivery via a four-part handshake. Reserved for safety-interlock events and commands that must never fire twice — an emergency-stop confirmation or a work-order auto-close trigger tied to billing or compliance records.
Infrastructure Planning
Sizing and Securing the Broker for Plant-Floor Scale
A broker that works fine in a pilot with 50 sensors can behave very differently at 10,000. Sizing and security decisions made early prevent a re-architecture later once the sensor count and the number of downstream subscribers both grow.
Sizing
Message Throughput
Estimate peak messages per second across every publisher, not the average, since bearing alarms and startup events often spike together during shift changes or restarts after downtime.
Sizing
Retained Messages
Retained topics hold the last known value for instant delivery to new subscribers. Budget broker memory for one retained payload per topic across the full sensor count, not just active connections.
Reliability
Clustering for High Availability
A clustered broker deployment across two or more nodes keeps topic routing alive if one node fails, which matters most for plants where the broker also carries safety-relevant alarm traffic.
Security
Per-Topic Access Control
Access control lists restrict which client certificates can publish or subscribe to which topic branches, so a compromised sensor credential cannot be used to read or spoof data across the entire plant.
Broker-Ready CMMS
Oxmaint Subscribes Directly to Your Plant's MQTT Broker — No Middleware Layer Required
Point Oxmaint at your existing broker — Mosquitto, HiveMQ, EMQX, or a cloud broker — and map topics to asset records once. Every future sensor on that topic tree flows into work orders automatically without a new integration project.
Deployment Patterns
Three Common MQTT Broker Deployment Patterns for Steel Mills
Single Site, On-Premise Broker
A single-facility mill runs an on-premise broker (Mosquitto or EMQX) on plant-floor infrastructure. All sensor traffic stays local, latency to the CMMS is minimal, and the broker can keep functioning even if the site's internet link drops, queuing messages for later cloud sync.
Best fit: single location, IT team wants full control of the broker and its data residency.
Multi-Site, Cloud-Hosted Broker
A multi-facility company runs one cloud-hosted broker that every mill's gateway connects to over a secure link. Topic hierarchies are prefixed by facility, so one broker instance and one CMMS connection cover every site without per-location infrastructure to maintain.
Best fit: five or more locations where centralized visibility outweighs the cost of a WAN dependency.
Bridged Brokers Across Sites
Each site keeps its own local broker for resilience, and the brokers bridge selected topics — typically alarms and summary metrics — up to a central broker for fleet-wide reporting, while high-volume raw sensor topics stay local and never leave the site.
Best fit: companies that need both local resilience and centralized fleet analytics.
Whichever pattern a plant chooses, the migration rarely requires ripping out existing OPC UA infrastructure in one pass. Most rollouts start with a single production area — a rolling mill or a caster — running MQTT alongside the existing polling setup, then expand topic by topic once the team has confidence in broker uptime, topic design, and alarm accuracy against real equipment behavior.
Outcomes
What Steel Mills Report After Moving to an MQTT Broker Architecture
92%
Fewer Network Requests
Replacing scheduled polling with change-driven publishing removes the vast majority of request traffic that added no new information.
3x
More Sensors Per Gateway
Because subscribers don't add polling load, one gateway can support several times more sensors before hitting a throughput ceiling.
6 min
Average New Sensor Onboarding Time
Adding a sensor means publishing to a new topic and mapping it once in Oxmaint — no address-space configuration or driver setup.
$210K
Average Annual Downtime Avoided
Per facility, from faster alarm-to-work-order turnaround compared to polling architectures with multi-second detection lag.
Common Questions
MQTT Broker Software — Frequently Asked Questions
Do we need to replace our existing OPC UA infrastructure to use MQTT?+
No. Most mills run both side by side. OPC UA continues serving structured equipment data while MQTT handles high-sensor-count telemetry. A gateway can bridge OPC UA tags onto MQTT topics so Oxmaint subscribes to one broker for everything.
Book a demo to review your current OPC UA setup.
Which MQTT broker should our plant run — Mosquitto, HiveMQ, or EMQX?+
Mosquitto suits smaller single-site deployments under a few thousand sensors. HiveMQ and EMQX add clustering and higher throughput for multi-site or high-sensor-count fleets. Oxmaint connects to any standards-compliant broker, so the choice depends on scale, not compatibility.
What happens to sensor data if the broker goes offline temporarily?+
Sensors configured with persistent sessions and QoS 1 or 2 queue their messages locally and deliver them once the broker reconnects. No data is lost for guaranteed-delivery topics; QoS 0 streams may drop samples during the outage window.
Can Oxmaint auto-map new MQTT topics to asset records as sensors are added?+
Yes, when your topic hierarchy follows a consistent facility/area/asset/measurement pattern, Oxmaint can pattern-match new topics to existing or newly created asset records automatically.
Start a free trial to test auto-mapping against your topic structure.
Is MQTT secure enough for plant-floor safety-related alarm data?+
MQTT over TLS with client certificate authentication and per-topic access control lists is standard for safety-relevant traffic. Combined with QoS 2 exactly-once delivery, it meets the reliability bar most industrial safety architectures require.
Industry Perspective
What Plant IT Leaders Say
Our OPC UA server was falling behind the moment we crossed 2,000 tags — the poll cycle just couldn't keep up. Moving sensor telemetry to an MQTT broker and connecting Oxmaint directly to it cut our alarm detection time from several seconds to under half a second, and we added another 4,000 sensors without touching the broker's hardware footprint.
— Plant IT Manager, Integrated Steel Facility (Southeast US)
MQTT Broker Integration
Stop Polling. Start Publishing. Connect Your Plant's MQTT Broker to Oxmaint.
Whether you're running a single on-premise broker or a bridged multi-site architecture, Oxmaint subscribes directly to your topic tree and turns threshold breaches into assigned work orders automatically.
