A typical cement plant runs equipment from a dozen different vendors — a kiln PLC from one supplier, a mill drive system from another, a packer and a weighbridge each speaking their own proprietary protocol, and a CEMS analyzer that only exports to a flat file once an hour. None of them were built to talk to each other, so getting a single view of the plant usually means a control room full of separate screens and a maintenance team that manually cross-references numbers between systems. OPC UA and MQTT exist specifically to solve this: one standardizes how equipment describes its own data, the other moves that data efficiently across the plant and up to a platform. Understanding where each protocol fits — and where legacy PLCs need a bridge to speak either one — is the first real step toward a plant where equipment from every vendor reports into the same system.
Digital Infrastructure · Multi-Vendor Equipment Connectivity
OPC UA and MQTT: Connecting Every Piece of Cement Plant Equipment to One System
Kiln PLCs, mill drives, packers, and lab instruments from different manufacturers rarely speak the same language out of the box. iFactory uses OPC UA for standardized data modeling and MQTT for lightweight transport, with edge computing bridging legacy PLCs that were never built to connect to anything at all.
1
Unified data model across every vendor
Legacy-Ready
Bridges PLCs with no native protocol support
Edge-First
Processes data close to the equipment itself
The Multi-Vendor Reality
Why Cement Plant Equipment Doesn't Talk to Itself
01
Every Vendor Has Its Own Protocol
A kiln control system, a mill drive, and a bagging line PLC often use three different proprietary or semi-proprietary protocols, none of which were designed with the others in mind.
02
Legacy PLCs Predate Modern Connectivity
Controllers installed ten or twenty years ago frequently have no built-in support for OPC UA or MQTT at all, and swapping them out just to get connectivity isn't realistic for most plants.
03
Point-to-Point Integrations Don't Scale
Building a custom connection from each device straight to a central system works for one or two machines, but it turns into a tangle of one-off scripts the moment a plant has forty or fifty connected assets.
04
Data Means Something Different in Every System
One system calls it "kiln speed," another calls the same value "main drive RPM," and without a standardized data model, combining them into one report means manually mapping every field by hand.
The Architecture
How Data Moves From a Legacy PLC to a Unified Platform
Layer 1
Field Devices and Legacy PLCs
Kiln, mill, packer, and lab equipment generate raw data in whatever native protocol they were built with — Modbus, proprietary serial links, or vendor-specific drivers.
Layer 2
Edge Computing and Protocol Conversion
An edge gateway sits close to the equipment, reads native protocols directly, and converts them into OPC UA so every device — old or new — exposes its data the same way.
Layer 3
MQTT Transport
Standardized OPC UA data is published over MQTT, a lightweight messaging protocol built for exactly this kind of high-frequency, many-device transport across a plant network.
Layer 4
Unified Platform
iFactory receives the standardized stream from every vendor's equipment in one place, so dashboards, reports, and alerts draw from a single consistent data model instead of a dozen disconnected sources.
Choosing the Right Layer
OPC UA vs. MQTT: What Each One Actually Does
| Aspect | OPC UA | MQTT |
|---|---|---|
| Primary role | Standardizes what the data means | Standardizes how the data moves |
| Best fit | Describing equipment structure and data models | Transporting high-frequency data efficiently |
| Typical use | Connecting to a PLC or control system directly | Publishing data across the plant network or to the cloud |
| Network load | Heavier, connection-oriented | Lightweight, built for constrained networks |
| Common pairing | Feeds data into an MQTT broker via a gateway | Carries OPC UA-modeled data to the platform |
Map Your Own Equipment List
See Which of Your PLCs Need a Bridge, and Which Connect Natively
Bring your equipment list — vendors, ages, and existing protocols included — and we'll walk through exactly what connects out of the box versus what needs an edge gateway in between.
Where This Actually Shows Up
What Unified Connectivity Changes on the Plant Floor
Legacy PLC Integration
A twenty-year-old kiln controller with no native OPC UA support connects through an edge gateway instead of being left out of the plant's digital systems entirely.
Edge Computing at the Source
Data is filtered and pre-processed near the equipment itself, so only the readings that matter get sent onward instead of flooding the network with raw noise.
Standardized Data Models
"Kiln speed" and "main drive RPM" become the same field in the same format, so a report can combine data from different vendors without manual field mapping.
One Dashboard for Every Vendor
Operators see kiln, mill, and packer data side by side on a single screen, instead of switching between separate vendor-supplied interfaces for each machine.
Getting There
How a Connectivity Rollout Typically Proceeds
1
Inventory Equipment and Protocols
2
Deploy Edge Gateways Where Needed
3
Standardize Into OPC UA Models
4
Publish Over MQTT to the Platform
5
Validate Against Known-Good Readings
A Composite Scenario
A Plant With Six Vendors and Six Separate Screens
Before
The control room ran six separate vendor interfaces for the kiln, two mill lines, the packer, the weighbridge, and the lab system. Comparing kiln output against packing rate meant an operator manually reading two screens and doing the math by hand, and a fifteen-year-old kiln PLC had no way to connect to anything newer at all.
After
An edge gateway bridged the legacy kiln PLC into OPC UA alongside the newer equipment that already supported it, and all six systems now publish standardized data over MQTT into one dashboard. The manual cross-referencing between screens is gone, and a new vendor's equipment can be added by pointing its gateway at the same standardized model instead of building a one-off integration.
Before You Start
Preparing for a Multi-Vendor Connectivity Project
List every piece of connected equipment, its vendor, its age, and whatever protocol it currently uses
Flag which controllers are legacy systems with no native OPC UA or MQTT support
Identify the handful of data points each team actually reports on today, as a starting scope
Plan to validate standardized readings against the original vendor screens before switching operators over
Common Questions
OPC UA and MQTT Connectivity — FAQ
Do we need to replace our existing PLCs to use OPC UA and MQTT?
No. Equipment that already supports OPC UA can connect directly, and legacy PLCs that don't are bridged through an edge gateway that reads their native protocol and republishes it in a standardized format. Replacing hardware is rarely necessary just to gain connectivity, which is usually the deciding factor for plants weighing this against a full controller upgrade. Our team can review your specific equipment list to confirm what's needed.
Why use both OPC UA and MQTT instead of just one?
They solve different problems. OPC UA standardizes what the data means and how equipment describes itself, while MQTT handles moving that data efficiently across the plant network and up to a platform. Using OPC UA for modeling and MQTT for transport is the combination most industrial connectivity projects settle on because each protocol is doing the part it was actually designed for.
Where does edge computing fit into this architecture?
The edge gateway is what actually talks to legacy equipment in its native protocol, converts that data into OPC UA, and filters out noise before anything gets published over MQTT. Without an edge layer, older PLCs would have no path into the standardized system at all.
How long does connecting a multi-vendor plant typically take?
It depends heavily on how many legacy versus modern controllers are involved, but most plants start with one production line as a pilot, validate the standardized data against the original vendor screens, and expand line by line rather than converting the entire plant at once. Book a demo to scope a realistic timeline against your own equipment mix.
Does standardizing the data change what operators see day to day?
Operators still see the readings they rely on, just consolidated into one dashboard instead of scattered across separate vendor interfaces. The standardization happens underneath, in how the data is modeled and moved, not in the working vocabulary the floor team already knows.
Stop Managing Six Vendor Screens Separately
Bring Every Piece of Plant Equipment Into One Standardized System
iFactory combines OPC UA data modeling, MQTT transport, and edge gateways for legacy PLCs to connect your entire equipment fleet — regardless of vendor or age — into a single platform.
