OPC-UA as the Data Backbone for Real-Time Inference

Industrial process plants typically have between 3 and 10 distinct control systems: a DCS or PLC running each major process unit, an ESD system, a vibration monitoring network, flow computers, maybe a dedicated compressor control panel. Each of these systems has its own proprietary data interface. Getting a unified, real-time view of the process state has historically required either a purpose-built integration project for each system type, or a SCADA layer that was configured when the plant was built and has been manually maintained ever since.

OPC Unified Architecture changes this. It is not magic, and the integration work is still real, but OPC-UA provides a standardized, platform-independent, secure communication layer that has genuine traction across all the major DCS vendors (Siemens, Honeywell, ABB, Emerson, Yokogawa all have OPC-UA server implementations). When an equipment world model needs live data to generate real-time predictions, OPC-UA is the right way to get it.

What OPC-UA Actually Provides

OPC-UA defines a service-oriented architecture for process data communication. The core building blocks are: a node model (every data point is a node in an addressable namespace), a subscription mechanism (the client subscribes to nodes and receives change notifications rather than polling), a security model (signing and encryption at the transport layer, certificate-based authentication), and a structured data model (nodes can have typed attributes, methods, historical data access).

For our purposes, the most relevant features are the subscription mechanism and the structured data model. The subscription mechanism means the inference engine gets pushed a new value immediately when the sensor reading changes by more than the configured dead-band, rather than polling at a fixed rate and potentially missing rapid transients. The structured data model means that the OPC-UA server can expose not just the numeric value but also the quality code (good, bad, uncertain) and the server-side timestamp, both of which we need for proper data handling at the inference layer.

The quality code is especially important. An OPC-UA subscription delivers three-value tuples: value, quality, timestamp. A quality of Bad with a sub-status of SensorFailure tells the inference engine something different from a quality of Uncertain with a sub-status of SubNormal. Handling quality correctly means the inference engine does not blindly pass a failed sensor reading into the model input vector and produce a corrupted prediction.

The Namespace Problem in Real Deployments

In practice, the first challenge with an OPC-UA integration is almost always the namespace. Every OPC-UA server organizes its nodes in a vendor-specific or installation-specific namespace hierarchy. A Siemens S7 PLC OPC-UA server and a Honeywell Experion DCS OPC-UA server expose their data through completely different namespace structures, even if they are monitoring the same physical process. You cannot write a generic connector that reads temperature from any OPC-UA server without first knowing the specific namespace path to the temperature node on that server.

This means the first step in any OPC-UA integration is a namespace discovery and tag mapping session: connecting to the server, browsing the namespace tree, and building a mapping from semantic tag names (the names the process engineer uses, like "FIC-101 flow setpoint") to the OPC-UA node identifiers. This work is non-trivial on an old system where the namespace may not be well-documented, but it only has to be done once per server. The resulting tag map becomes the configuration file that the inference engine uses to subscribe to the right nodes.

We have found that spending time on this mapping up front pays off significantly during commissioning. A tag map that captures the full context of each node, including its engineering units, its physical range, and any interlock or calculation dependencies, makes the subsequent model training and inference debugging much faster. Undocumented tag maps create debugging situations where a model input looks wrong and it takes hours to determine whether the problem is in the model or in the tag mapping.

Latency Profile of OPC-UA Subscriptions

For a world model that makes 30-minute-horizon predictions, the latency of the data transport layer matters less than for a hard real-time control system. But it still matters. An OPC-UA subscription has three latency components: the sampling interval (how often the server checks the underlying PLC register for changes), the publishing interval (how often the server sends collected changes to the client), and network transit time. For typical Ethernet-connected plant networks, total round-trip latency for a change notification is on the order of 50 to 200 milliseconds.

That latency is fine for 30-minute-horizon predictions. It becomes relevant for shorter-horizon applications, particularly control loop tuning validation where the model needs to observe the process response to a setpoint step at sub-second granularity. In those cases, a lower sampling interval configuration on the OPC-UA server, combined with a higher-frequency subscribing client, can reduce effective observation latency at the cost of higher server load and network traffic.

The practical floor depends on the PLC scan cycle. If the PLC updates its process variables every 100 milliseconds, there is no benefit to configuring an OPC-UA sampling interval below 100 milliseconds. The server can only report changes that have occurred in the underlying hardware, and no amount of OPC-UA tuning changes the hardware scan rate.

Security on Industrial Networks

Industrial networks present a specific security context that differs from enterprise IT. The dominant concern is availability and stability of control systems, not data confidentiality (though that matters too). Anything installed on the OT network that increases the risk of control system instability or disruption is correctly treated with caution by plant operations and IT teams.

OPC-UA's security model is relevant here. Connecting to an OPC-UA server in "no security" mode (no signing or encryption) is fast to configure and acceptable on an air-gapped network segment, but it exposes the connection to manipulation by any device on the same network. Connecting in "sign and encrypt" mode with certificate authentication provides proper security but requires certificate management and a CA infrastructure that many process plants do not have in place for their OT network.

For inference applications, we typically run in read-only mode on the OPC-UA subscription: the inference engine subscribes to data nodes but never writes to them. Read-only subscriptions are lower risk from a control system integrity perspective because a misbehaving client cannot trigger a setpoint change or override a PLC register. This distinction matters when negotiating access with plant IT and operations security teams: "we read your process data to generate predictions" is a different conversation from "we write to your control system."

Where Historian Fallback Matters

Real-time OPC-UA subscriptions cover the live inference case. But a world model also needs historical data for initial training and for periodic retraining. Most OPC-UA servers support the Historical Data Access (HDA) service set, which allows querying historical values over a time range from the server's internal buffer. HDA typically provides a short rolling window, often 24 to 72 hours, depending on server configuration and storage.

For training data going back months or years, the historian (PI, Wonderware, etc.) remains the right source. This is why our integration architecture uses OPC-UA for live inference and historian export for training data, rather than trying to get everything through a single interface. The two serve different time horizons and have different access patterns, and it is cleaner to handle them separately than to force one interface to serve both roles.