What is OPC DA?
OPC DA, short for OPC Data Access, is a Windows-based communication standard that defines how software applications request and receive real-time process data from industrial devices. It establishes a common interface so that any OPC DA client, such as a SCADA package or historian, can read data from any OPC DA server, regardless of the underlying device or vendor, without requiring custom integration code.
Before OPC DA, every application that needed access to PLC or DCS data required a custom driver written specifically for that combination of software and hardware. Change your SCADA vendor, change your PLC platform, or add a new analytics package, and someone had to write a new driver. OPC DA solved this by decoupling the device communication layer from the application layer entirely. A device vendor writes one OPC DA server. Every application that supports OPC DA can then connect to it.
OPC DA is sometimes called OPC Classic, a term that groups it with the other original OPC specifications, OPC HDA for historical data and OPC A&E for alarms and events, to distinguish the family from the newer OPC UA standard. OPC Classic and OPC UA are complementary, not mutually exclusive. Tens of thousands of OPC DA installations remain in production today and are actively supported by Software Toolbox products.
Software Toolbox history: Software Toolbox was a Charter Member of the OPC Foundation from the standard's earliest days in 1996 and has supported OPC DA in production deployments ever since. TOP Server, our flagship OPC server, implements OPC DA 1.0, 2.0, and 3.0 alongside OPC UA, HDA, and A&E in a single certified installation.
How OPC DA works
OPC DA is built on Microsoft's COM and DCOM technology. COM, the Component Object Model, is a Windows framework for inter-process communication that lets one application call methods on objects in another application running on the same machine. DCOM, Distributed COM, extends that mechanism across a network to let applications on different machines communicate using the same model.
In practical terms, an OPC DA server is a Windows process that runs on a machine connected to industrial hardware. It communicates with the hardware using the device's native protocol, whether Modbus, EtherNet/IP, S7, DNP3, or hundreds of others, and exposes the resulting data through a standardized OPC interface. Any OPC DA client can connect to that interface and request the values it needs.
The OPC DA object hierarchy: server, groups, and items
OPC DA organizes data into a three-level hierarchy. Understanding this hierarchy is fundamental to configuring and troubleshooting any OPC DA system.
How data flows: subscriptions, cache, and device reads
Once a client has created a group and added items to it, it can receive data in one of two ways: subscription-based callbacks, or on-demand reads.
Subscription callbacks are the preferred and most common method. The client subscribes to a group, and the server notifies the client via a callback whenever a value in that group changes, or at the configured update rate if no change occurs. Only changed values are sent, which reduces unnecessary network traffic between server and client. This is called the OnDataChange notification model.
On-demand reads allow the client to request current values at any time. Cache reads return the value the server last received from the device, which is fast but slightly stale depending on the polling cycle. Device reads bypass the cache and go directly to the hardware, which is slower but reflects the current device state at the moment of the read. Most applications use subscriptions for continuous monitoring and device reads only for diagnostics or critical one-off operations.
Value, quality, and timestamp: the OPC DA data triplet
Every OPC DA data item delivers three pieces of information together. This triplet is one of the most practically important aspects of the standard: it allows client applications to know not just what a value is, but whether it can be trusted and when it was last known good.
The quality field is what separates OPC DA from a simple value feed. Consider a temperature sensor that reads 0.0°C. Without quality context, there is no way to distinguish between a legitimate 0°C reading and a bad reading caused by a broken wire, network fault, or device timeout. With quality, the client application knows immediately whether to trust that zero or raise an alarm.
| Quality | Meaning | Common causes | Client action |
|---|---|---|---|
| Good | Value is current and valid | Normal operation, device responding correctly | Use the value normally |
| Bad | Value cannot be read or is known to be invalid | Device offline, network fault, driver error, item not found in device | Do not use the value; alarm, hold last good, or display a fault indication |
| Uncertain | Value may be valid but its reliability is questionable | Sensor degraded, value older than expected, sub-normal accuracy flag from device | Use with caution; display a warning indication alongside the value |
OPC DA versions: 1.0, 2.0, and 3.0
The OPC DA specification evolved through three main versions. Understanding the differences matters when you encounter version-related compatibility questions in the field, which is common in environments with a long history of OPC DA deployments.
Compatibility note: A DA 2.0 client can connect to a DA 3.0 server and use all DA 2.0 features. A DA 3.0 client can connect to a DA 2.0 server but cannot use DA 3.0-specific features like writing quality. When diagnosing unexpected behavior in an OPC DA system, the first question to ask is whether client and server support the same version, or a compatible subset.
DCOM: the most common OPC DA challenge
If you have worked with OPC DA across a network, you have almost certainly encountered DCOM configuration problems. This is the aspect of OPC DA that most engineers find frustrating, and it is worth understanding clearly.
When an OPC DA client and server are on the same machine, they communicate via local COM calls, which are fast and simple. When they are on different machines, DCOM is required, and DCOM carries significant configuration complexity.
Why DCOM is difficult in practice: DCOM uses dynamic port allocation by default, which means it randomly selects a high-numbered port for each connection. Firewalls between OT and IT networks typically block all ports except known ones, which means DCOM connections fail unless the Windows firewall is configured to allow entire dynamic port ranges (typically 49152 to 65535). Locking this down to specific ports requires additional DCOM component services configuration, identical user accounts with matching passwords on both machines, and careful management of DCOM security policies, all of which must be maintained every time Windows updates, users change passwords, or network policies are updated.
The practical implication is that many organizations avoid DCOM entirely and instead use OPC tunneling software, such as Cogent DataHub, that replaces DCOM with a standard TCP connection over a single, configurable port. The result is the same OPC DA client-server communication, but without the DCOM infrastructure overhead and with firewall-friendly, IT-acceptable network behavior.
DCOM configuration checklist for remote OPC DA
For engineers who do need to configure DCOM directly, these are the steps that account for the majority of configuration failures:
- 1Matching user accounts. Both the OPC server machine and each OPC client machine must have a Windows user account with the same username and the same password. DCOM authenticates using these accounts. A password mismatch or missing account is the most common cause of "Access denied" errors.
- 2DCOM enabled on all machines. Open Component Services (dcomcnfg), navigate to My Computer Properties, Default Properties tab, and confirm that Enable Distributed COM on this computer is checked on every machine involved in the connection.
- 3OPC server DCOM permissions. In Component Services under DCOM Config, find the OPC server application and set Launch, Activation, and Access permissions to include the OPC user account. Using "Allow Everyone" is not secure and is not recommended for production environments.
- 4OPCEnum permissions. The OPCEnum service (from the OPC Core Components package) also requires DCOM configuration. Set its Authentication Level to None on the General tab and Access Permissions to the OPC user account. Without correct OPCEnum configuration, clients cannot browse available OPC servers on the remote machine.
- 5Firewall rules. The Windows Firewall on both machines must allow DCOM. This requires allowing the DCOM service (TCP port 135 for the DCOM endpoint mapper) plus the dynamic high ports used by DCOM sessions. Restrict port ranges via Component Services if possible rather than opening the full dynamic range.
- 6OPC Core Components installed on client. The OPC Core Components Redistributable from the OPC Foundation must be installed on every client machine that connects remotely to an OPC DA server. This package includes OPCEnum and the proxy/stub DLLs required for remote COM marshaling.
OPC DA in 2026: still relevant, clearly bounded
OPC DA is not a legacy protocol waiting to be retired. It is a stable, proven standard with a deployment base measured in tens of thousands of active systems and an ecosystem of interoperable products that has been validated over nearly three decades. The argument for migrating to OPC UA is strong for new projects and for organizations building IT/OT integration layers, cloud pipelines, or Unified Namespace architectures. But the argument for replacing a functioning OPC DA system purely for the sake of modernization is much weaker.
The practical landscape in most plants is a mix of both. Here is where each belongs:
- Keep OPC DA where it is working reliably on a stable Windows network segment, where all clients are Windows-based, where there is no requirement to cross network boundaries or firewalls, and where the effort and risk of migration outweigh the benefits.
- Add OPC UA alongside DA when new IT systems, analytics platforms, or cloud integrations need to access existing OPC DA data without requiring DCOM. TOP Server can serve both protocols simultaneously from the same installation.
- Bridge DA to UA using products like Cogent DataHub when you have OPC DA servers that cannot be replaced but OPC UA clients that need their data, or when you need to cross a DMZ securely.
- Plan migration to OPC UA for new devices and new system integrations, so that over time the proportion of UA-native endpoints increases without requiring a cutover of existing DA infrastructure.
TOP Server handles both: A single TOP Server installation runs OPC DA 1.0, 2.0, and 3.0 simultaneously alongside OPC UA, HDA, and A&E. The same device driver configuration serves all protocols. Engineers do not need to choose between supporting legacy DA clients and modern UA clients; TOP Server serves both from the same instance.