Most manufacturing plants operate a mix of PLCs and sensors installed across decades of capital projects, each chosen from a different vendor and speaking a different protocol. Connecting that heterogeneous equipment to modern analytics platforms without ripping out working hardware is the central challenge of industrial IoT adoption. OPC UA was built specifically to solve this problem, but implementing it correctly on a brownfield floor requires more than installing a server and mapping a few tags. The framework below covers multi-vendor connectivity, edge gateway architecture, and information modeling essentials that determine whether your IIoT initiative delivers actionable data or just expensive noise. To see how this applies to your specific equipment mix, book a demo with our connectivity team.
Article · Legacy Systems and Data Silos
OPC UA and IIoT: PLC and Sensor Connectivity Essentials
How to connect legacy PLCs and sensors from multiple vendors to modern analytics platforms using OPC UA, edge gateways, and structured information modeling, without replacing a single piece of hardware on your brownfield plant floor.
The Legacy Connectivity Wall
Walk onto almost any plant floor running for more than ten years and you will find a connectivity landscape that looks like the one below. Each capital project added new equipment with whatever protocol was standard at the time, and none of these systems were designed to share data with each other or with cloud-based analytics platforms.
Typical Protocol Mix Found on a Single Brownfield Plant Floor
Pre-2000
Modbus RTU / TCP
Serial master-slave protocol. Still running on temperature controllers, power meters, and simple I/O blocks. No discovery, no security, no metadata.
2000-2008
Profibus DP / PA
Siemens-dominated fieldbus connecting drives, weighing systems, and process instruments. Requires dedicated hardware adapters to extract data.
2005-2012
EtherNet/IP
Rockwell/Allen-Bradley standard. Native to ControlLogix and CompactLogix platforms. Data accessible but locked behind proprietary CIP semantics.
2008-2015
Profinet IO
Siemens Ethernet-based fieldbus replacing Profibus. Fast cycle times but vendor-specific configuration tools required for data mapping.
2010-Present
OPC UA
The unified standard designed to replace all of the above. Platform-independent, secure by default, and rich with semantic data modeling capabilities.
What Makes OPC UA Different from Everything Before It
OPC UA is not simply a newer version of the classic OPC DA protocol that ran on Windows COM components. It is a fundamentally different architecture designed from the ground up for multi-vendor interoperability, platform independence, and secure internet-scale communication. Understanding these distinctions is critical before committing deployment resources.
Classic OPC DA
PlatformWindows COM only
SecurityNone built-in, relies on network isolation
Data modelFlat tag list, no relationships
ScalabilitySingle subnet, limited nodes
DiscoveryManual server configuration
TransportDCOM, firewall-unfriendly
Proprietary Protocols
PlatformVendor-specific hardware required
SecurityVaries by vendor, often minimal
Data modelVendor-defined, not interoperable
ScalabilityWithin vendor ecosystem only
DiscoveryVendor tools, no cross-vendor discovery
TransportVaries, often non-routable
OPC UA
PlatformWindows, Linux, embedded, cloud
SecurityTLS encryption, X.509 certificates, role-based access
Data modelObject-oriented, hierarchical, with relationships
ScalabilityInternet-scale, millions of nodes
DiscoveryGlobal, local, and multicast discovery
TransportTCP binary, HTTPS, WebSockets
PLC and Sensor Compatibility Matrix
The first question every plant team asks is whether their specific equipment can connect through OPC UA. The answer for virtually every PLC and sensor installed in the last 25 years is yes, but the connection path differs depending on the native protocol. The matrix below covers the most common equipment categories found on brownfield floors.
Equipment
Native Protocol
OPC UA Path
Gateway Required
Typical Latency
Siemens S7-300/400
Profibus DP
Protocol converter gateway
Yes
50-200 ms
Siemens S7-1200/1500
Profinet / S7 Comm
Built-in OPC UA server or gateway
No
10-50 ms
Allen-Bradley ControlLogix
EtherNet/IP (CIP)
Gateway with CIP-to-OPC UA translation
Yes
20-100 ms
Mitsubishi iQ-R/Q Series
SLMP / CC-Link IE
Gateway or built-in (firmware dependent)
Varies
30-150 ms
Modbus RTU Devices
Modbus Serial
Serial-to-Ethernet gateway with OPC UA server
Yes
100-500 ms
Modbus TCP Devices
Modbus TCP
Gateway with Modbus-to-OPC UA mapping
Yes
50-200 ms
Analog 4-20mA Sensors
Analog current loop
I/O module with OPC UA server interface
Yes
200-1000 ms
HART Instruments
HART protocol
HART-to-OPC UA gateway with I/O mapping
Yes
500-2000 ms
Edge Gateway Data Flow Architecture
The edge gateway is the critical bridge between legacy field protocols and the OPC UA unified layer. Its architecture determines data reliability, latency, and what happens when network connectivity between the plant floor and the analytics platform is interrupted. The flow below represents the production-proven pattern for brownfield deployments.
Layer 1
Field Protocol Drivers
Dedicated protocol drivers on the gateway maintain persistent connections to each PLC and sensor cluster. Drivers handle connection management, retry logic, and data type conversion from native formats to normalized internal representation.
Layer 2
Local Data Buffer
All incoming data is written to a local time-series buffer on the gateway before any transmission. This buffer acts as a decoupling mechanism: if the upstream connection fails, data continues to be collected locally without loss. Typical buffer depth covers 24-72 hours of high-frequency data.
Layer 3
OPC UA Information Model
Raw tag data is organized into an OPC UA information model that represents the physical equipment hierarchy. A temperature sensor becomes an object with properties for current value, engineering units, alarm thresholds, and maintenance status, not just a floating-point number at address 40001.
Layer 4
Secure Transport
OPC UA data leaves the gateway over TLS-encrypted channels with X.509 certificate mutual authentication. Payload compression reduces bandwidth consumption for high-frequency subscriptions. Pub/Sub mode enables one-to-many distribution to multiple analytics consumers without duplicating data on the wire.
Layer 5
Analytics Platform
The OPC UA client in the analytics platform subscribes to the information model, receiving structured objects with full semantic context. Analytics queries operate on machine objects and process sequences rather than raw tag arrays, dramatically reducing the time from data arrival to actionable insight.
Information Model Building Blocks
The single biggest mistake in OPC UA deployments is treating it like a protocol converter that maps flat tag lists. The real value of OPC UA lives in its information modeling capability, which turns raw data points into structured digital representations of physical equipment. The building blocks below define how a well-modeled manufacturing asset is organized.
Root Node
Production Line A
Object
CNC Milling Cell
StatusRunning / Idle / Fault
Current JobWork Order ID reference
Cycle CountCumulative parts counter
Component
Spindle Assembly
RPMVariable, 0-24000
Vibrationmm/s RMS
Bearing TempDeg C, alarm at 85
Load %0-100 percent rated
Component
Coolant System
Flow RateL/min
TemperatureDeg C inlet/outlet
LevelPercent, low alarm at 15
Object
Robot Welding Cell
StatusRunning / Idle / Fault
Wire Feed Ratem/min
Arc VoltageVolts DC
Object
Conveyor Transfer
Speedm/min setpoint/actual
LoadAmps motor current
ThroughputParts per hour
Need Help Mapping Your Equipment to OPC UA?
Our engineers will inventory your PLCs, sensors, and field protocols, then build a connectivity plan with specific gateway selections, information model designs, and a phased deployment timeline tailored to your plant floor.
Brownfield Deployment Sequence
Deploying OPC UA connectivity on an active plant floor requires a disciplined sequence that prioritizes production continuity above all else. The five-step process below has been refined through dozens of brownfield deployments and is designed to deliver measurable value at each stage rather than deferring all value to the final step.
Step 1
Protocol Inventory and Prioritization
Document every PLC, drive, instrument, and sensor cluster on the floor along with its native protocol, firmware version, network segment, and current data consumer. Rank each connection by downstream analytical value, not by ease of connection. The hardest-to-connect device might also be the one whose data closes the biggest gap in your operational visibility.
Step 2
Gateway Provisioning and Network Segmentation
Install edge gateways in the plant network DMZ with dedicated VLANs for field protocol traffic and OPC UA traffic. Each gateway should handle 8-16 protocol connections to avoid single-point-of-failure concentration. Configure firewall rules to allow only OPC UA traffic on port 4840 from gateway to analytics platform, blocking all other cross-segment traffic.
Step 3
Information Model Design
Before mapping a single tag, design the object hierarchy that represents your physical equipment. Define standard object types for common equipment categories so that every CNC machine, every pump, and every conveyor follows the same template. This standardization is what makes analytics queries portable across machines and across sites.
Step 4
Data Validation Against Source
Run the gateway in shadow mode for at least one full production shift, collecting data through OPC UA in parallel with the existing SCADA or HMI system. Compare every value, every timestamp, and every status flag. Resolve all discrepancies before cutting over any analytics workflow to the OPC UA source. This step is where most projects either build trust or lose it permanently.
Step 5
Phased Cutover and Expansion
Cutover the highest-priority data paths first, typically the ones feeding predictive maintenance or quality correlation models. Monitor for two weeks, then expand to the next priority tier. Each expansion wave is faster because the gateway infrastructure, network configuration, and information model templates are already proven from the previous wave.
Security Architecture for OPC UA Deployments
Connecting plant-floor equipment to analytics platforms intentionally creates network paths that did not exist before. Without a deliberate security architecture, those paths become attack surfaces. The layered model below represents the minimum security posture for any OPC UA deployment on a production plant floor.
Layer 5
Application Authentication
Every OPC UA client connecting to a server or gateway must present a valid X.509 certificate issued by the plant's private certificate authority. Revoked certificates are distributed via CRL or OCSP. No anonymous access is permitted on any production gateway.
Layer 4
Transport Encryption
All OPC UA communication uses TLS 1.2 or higher with strong cipher suites. The SecurityPolicy configuration on each endpoint enforces minimum encryption levels. Unencrypted OPC UA traffic is blocked at the switch port level, not just at the firewall.
Layer 3
Network Segmentation
Field protocol traffic, OPC UA traffic, and enterprise IT traffic run on separate VLANs with firewall rules that restrict cross-segment communication to explicitly permitted OPC UA sessions on port 4840. No routing exists between the field VLAN and the enterprise VLAN except through the gateway.
Layer 2
Gateway Hardening
Edge gateways run a minimal OS image with unnecessary services disabled, SSH access restricted to key-based authentication from a single bastion host, and all logs forwarded to a centralized SIEM. Gateway firmware is patched on a defined schedule with change management approval.
Layer 1
Physical Access Control
Gateway hardware is installed in locked cabinets within controlled-access plant floor areas. Physical port access is disabled on unused switch ports. Any physical connection change requires a documented work order and triggers an automated alert to the OT security team.
Frequently Asked Questions
Can OPC UA connect to very old PLCs that only have serial ports?
Yes. Serial-connected PLCs and instruments are connected through a serial-to-Ethernet converter that bridges the RS-232 or RS-485 physical layer to the plant Ethernet network. The edge gateway then runs a Modbus RTU or proprietary serial protocol driver to communicate with the device, translating the data into OPC UA objects. This two-stage path adds some latency compared to native Ethernet connections, typically 100-500 milliseconds, which is acceptable for monitoring and analytics use cases but not for closed-loop control replacement. The serial protocol driver on the gateway handles the polling timing, register mapping, and data type conversion that would otherwise require custom programming on the PLC side. For a detailed assessment of your serial device connectivity options, book a session with our team.
Does OPC UA add latency compared to reading PLCs directly from SCADA?
OPC UA adds a small but measurable latency overhead compared to proprietary SCADA protocols that are optimized for sub-millisecond communication on a single vendor platform. Typical OPC UA subscription latency through an edge gateway ranges from 10 to 200 milliseconds depending on the number of variables, network hops, and security policy configuration. For the vast majority of IIoT analytics use cases, including predictive maintenance, quality correlation, energy monitoring, and OEE calculation, this latency is entirely negligible because the analytics algorithms operate on seconds-to-minutes timescales, not milliseconds. OPC UA should not replace real-time control communication between PLCs and their native I/O or peer-to-peer safety protocols. It is designed as the data distribution layer for monitoring, analytics, and cross-system integration, not as a replacement for deterministic fieldbus control loops.
How do we manage OPC UA certificates across dozens of gateways and clients?
Certificate management is the most operationally burdensome aspect of OPC UA security if not planned from the start. The recommended approach is to establish a private certificate authority within the plant network, either using a dedicated PKI appliance or an enterprise CA with a dedicated OPC UA subtree. Each gateway and client receives a unique X.509 certificate with a defined validity period, typically one to two years. Certificate revocation is handled through a CRL distribution point or OCSP responder that all OPC UA endpoints check during session establishment. Automated certificate enrollment tools can reduce the manual workload, but the initial CA architecture and revocation workflow must be designed before deploying the first gateway. Without this, you will face a certificate management nightmare as the number of endpoints grows beyond ten to twenty.
What happens to OPC UA data flow when the plant network goes down?
A properly designed edge gateway architecture handles network interruption through local buffering. When the connection between the gateway and the analytics platform is lost, the gateway continues collecting data from field devices and writing it to its local time-series buffer. Buffer capacity typically covers 24 to 72 hours of high-frequency data at configured sampling rates. When network connectivity is restored, the gateway replays the buffered data to the analytics platform in chronological order, filling the gap in the historical record. The analytics platform must support historical data backfill through OPC UA historical read services or a bulk transfer protocol. If the buffer fills before connectivity is restored, the gateway either overwrites the oldest data or stops collection, depending on configuration. The former is appropriate for monitoring dashboards where recent data is more valuable. The latter is appropriate for compliance-critical records where no data loss is acceptable.
Can we use OPC UA Pub/Sub instead of client-server for our deployment?
OPC UA Pub/Sub is designed for scenarios where data needs to be distributed from one publisher to many subscribers simultaneously, such as broadcasting machine status to multiple dashboards, analytics engines, and historians without each consumer maintaining a separate client-server session. Pub/Sub operates over UDP multicast or brokered message transports like MQTT, which reduces per-consumer overhead on the publisher. It is particularly valuable in large-scale deployments where a single production line feeds data to five or more downstream systems. However, Pub/Sub does not replace client-server for all use cases. Command and control operations, configuration writes, and browse operations still require client-server sessions because they demand request-response semantics with guaranteed delivery. Most brownfield deployments start with client-server for initial connectivity and add Pub/Sub as the number of data consumers grows beyond two or three per source. To discuss which transport mode fits your architecture, reach out to our engineering team.
Your PLCs Have the Data. OPC UA Is How You Get It Out.
Every legacy PLC and sensor on your plant floor is generating data right now that could be feeding predictive models, quality dashboards, and energy optimization algorithms. The connectivity path is proven, the gateways are commodity hardware, and the information modeling framework is standardized. The only missing piece is the deployment plan for your specific equipment mix.
