A plant floor built up over twenty years rarely runs equipment from a single PLC vendor. One line runs on controllers from one manufacturer, another line was retrofitted years later with a different vendor entirely, and each speaks its own native protocol that has no reason to understand the others. OPC UA exists precisely to solve this — a vendor-neutral standard that lets equipment from any manufacturer expose its data in a common, structured way. Plants juggling a genuinely mixed-vendor floor can Book a Demo to see how iFactory connects legacy PLCs from multiple vendors through OPC UA.
Why Multi-Vendor PLC Environments Are the Norm, Not the Exception
Very few plants of any meaningful age or size run a single PLC vendor across every line. Equipment gets added, replaced, and retrofitted over years, often by different integrators with different vendor preferences or different budget constraints at the time. The result is a plant floor that runs perfectly well operationally but presents a genuine integration challenge the moment someone wants to pull data from all of it into a single system, since each vendor's controllers speak their own proprietary protocol with no native way to understand the others.
The Gateway Funnel: How Disparate Protocols Become One Standard
Rather than requiring every PLC to natively support OPC UA — an unrealistic expectation for older equipment — edge gateways sit between the legacy controllers and the rest of the plant's data infrastructure, speaking each PLC's native protocol on one side and publishing standardized OPC UA data on the other. This funnel approach means the legacy equipment itself never needs to change; only the gateway layer needs to understand each vendor's specific protocol.
Data Standardization: More Than Just a Common Protocol
Getting every PLC's data into OPC UA format is only half the standardization challenge. The other half is ensuring that equivalent data points across different vendors' equipment are named and structured consistently — a temperature reading from Vendor A's controller and the equivalent reading from Vendor C's controller need to map to the same logical data point in the unified structure, even though each vendor's internal naming convention for that value looks completely different. Without this semantic standardization layered on top of protocol standardization, a plant ends up with technically unified connectivity but still practically inconsistent data.
| Standardization Layer | What It Solves |
|---|---|
| Protocol conversion | Translates each vendor's native communication protocol into a common transport standard |
| Data structure standardization | Maps equivalent data points across vendors to the same logical naming and hierarchy |
| Access and security model | Applies consistent authentication and permission rules regardless of the originating vendor |
Extending the Life of Legacy Equipment Rather Than Replacing It
A common misconception is that connecting legacy PLCs to a modern data architecture requires eventually replacing them with newer, natively-connected equipment. In most cases this isn't necessary or economical — a PLC that is mechanically and functionally sound has no reason to be replaced just because its communication protocol predates OPC UA, provided a gateway can bridge that gap reliably. This approach preserves the investment already made in reliable equipment while still gaining the connectivity benefits of a modern, standardized data layer.
Security Considerations for Bridging Legacy Equipment
Connecting older PLCs that were never designed with modern network security in mind introduces a legitimate concern that shouldn't be an afterthought in a gateway deployment. Many legacy controllers assume they're operating on an isolated network and have no built-in authentication for the protocols they speak natively, which means the gateway itself becomes the security boundary protecting that equipment from the broader network it's now indirectly connected to. A well-designed deployment isolates legacy PLC networks behind the gateway rather than exposing them directly, and applies OPC UA's built-in security features — authentication and encryption — on the side of the gateway facing the rest of the plant's data infrastructure.
Gateway Bridging vs. Full Replacement: Comparing Total Cost
The financial case for gateway-based connectivity over full equipment replacement is usually straightforward once laid out directly, but it's worth making explicit for any stakeholder unfamiliar with the option, since replacement is often the default assumption when connectivity comes up as a requirement.
| Factor | Gateway Bridging | Full PLC Replacement |
|---|---|---|
| Upfront cost | Limited to gateway hardware and configuration | Full controller, wiring, and commissioning cost |
| Production disruption | Minimal — installed alongside running equipment | Significant — requires a planned equipment changeover |
| Time to connectivity | Typically weeks per equipment group | Often months per line, depending on scope |
Frequently Asked Questions: OPC UA Connectivity for Legacy PLC
How old can a PLC be and still be connected through an OPC UA gateway?
Age alone rarely disqualifies a PLC from gateway connectivity — what matters is whether the controller exposes its data through some accessible communication interface, even an older serial or proprietary protocol, since a gateway can typically be configured to read from most established industrial protocols regardless of how many years the equipment has been in service. Very old or unusual proprietary systems occasionally require more custom gateway configuration, but genuine hard limitations are uncommon. Teams can Book a Demo to review connectivity options for specific legacy equipment.
Does adding an edge gateway introduce any risk to the PLC's existing control function?
A properly configured gateway reads data from the PLC without writing back into its control logic, meaning the gateway's role is limited to observation and data publishing rather than interacting with the equipment's actual control function, which keeps the risk to existing operations minimal when the connection is scoped correctly to read-only access.
How much manual mapping work is required to standardize data points across different vendors?
The mapping effort scales with how many distinct vendor and controller types are present and how consistently each vendor's own naming conventions were applied during original installation, but this is generally a one-time setup effort per equipment type rather than an ongoing burden, and starting with the highest-value or most frequently needed data points first makes the initial mapping work more manageable.
Can a single edge gateway handle multiple PLC vendors simultaneously, or is one gateway needed per vendor?
Many modern edge gateways support multiple protocol drivers simultaneously, meaning a single gateway can often connect to several different vendors' PLCs at once, though the practical limit depends on the specific gateway hardware's capacity and the total volume of data being collected across all connected controllers.
Is OPC UA the right standard to target, or are there better alternatives for a multi-vendor environment?
OPC UA has become the dominant vendor-neutral standard specifically because of its broad industry adoption and built-in security model, making it a reasonable default target for most multi-vendor standardization projects, though the right choice can depend on what downstream systems and analytics platforms a plant intends to connect to afterward. Contact iFactory Support for guidance on selecting the right standardization target for a specific environment.
