OPC DA (OPC Data Access) is the classic OPC specification that lets an application read and write real-time process values from servers installed on Windows. It relies on Microsoft COM/DCOM, delivers every value with a timestamp and a quality code, and is the direct predecessor of OPC-UA.
Where OPC DA shows up on the plant floor
OPC appeared in 1996 as an interoperability layer over Windows technologies, and for two decades OPC DA was the standard way for a SCADA, a historian or a business application to read PLC values without writing one driver per brand. Alongside DA, the classic family includes HDA for historical data and A&E for alarms and events; when someone says "OPC" without qualification they usually mean DA. On the plant floor it appears wherever systems were installed between the late nineties and the 2010s: practically every SCADA of that era ships an OPC DA server, and PLC vendors distributed their drivers in that format. The typical pattern is a dedicated PC running an old Windows version that nobody touches, because data capture for a whole line hangs off it.
The data model is flat: the server exposes items in a hierarchical namespace and the client bundles them into groups, each with its own update rate and deadband. Delivery can be a direct read or an asynchronous notification when the value changes. Every value arrives with three things: the data, the timestamp and a quality code distinguishing good, bad and uncertain readings.
OPC DA versus OPC-UA
The difference is architectural rather than a matter of versions. OPC-UA drops COM/DCOM: it runs over TCP on a single known port, is cross-platform and executes on PLCs, Linux gateways or cloud servers. It builds security into the standard itself (certificates, message signing and encryption, user authentication) whereas OPC DA delegates all security to Windows configuration. And it replaces the flat item list with an information model carrying types, units, hierarchy and relationships, so consumers know what they are reading without an external mapping table. Migration is not automatic: the two protocols do not understand each other. The usual bridge is a wrapper presenting an existing DA server as a UA server, or the reverse path, so legacy applications keep working through the transition.
The practical problems with OPC DA all come from DCOM. Notifications require the server to call back into the client, so both machines have to authenticate each other: in a domain that is solved with shared accounts, and without a domain it forces replicating local users with identical passwords on both boxes. Traffic uses the endpoint mapper on port 135 plus a dynamic range of high ports, which no serious firewall leaves open and which address translation breaks. Failure detection is slow: when the link drops, DCOM timeouts are measured in minutes, not seconds. And since 14 March 2023, the DCOM hardening tied to CVE-2021-26414 enforces packet integrity as the minimum authentication level, with no registry key left to disable it: clients that do not request it stopped connecting, taking down classic OPC integrations that had run for years.
Getting OPC DA data into a data layer
The first caution is real resolution. The update rate configured on the OPC group does not speed capture up: the DA server polls the device on its own driver cycle, so asking for 100 ms over a driver that queries the PLC once a second returns the same value ten times. Before promising a resolution, look at the driver cycle and the controller cycle, not at the client configuration.
The second is the timestamp. Many DA servers stamp the value with the PC clock at read time rather than at source; with several servers whose clocks are not NTP-synchronised, correlating events across lines stops being possible. The third, and the one that does the most silent damage, is the quality code: it has to be propagated all the way to the destination. Discarding bad or uncertain values without flagging them turns a communication outage into a flat line in the history, which is later read as a stable process.
On deployment, the pattern that ages best is avoiding DCOM entirely: install the collector on the same Windows machine that hosts the DA server, so the conversation is local, and publish northbound from there over OPC-UA or MQTT. Where that is not possible, the alternative is a tunnel replacing DCOM with a single TCP connection between two agents, rather than opening a dynamic port range between plant and offices. Reading through an existing DA server touches nothing in the process and needs no line stop; the risk sits in the Windows machine, because installing software on a capture PC that has run for a decade calls for a backup image first. Write access deserves restricting too: OPC DA allows it, and the restriction belongs in the server permissions and in the network. Bridging legacy systems into a data layer is the subject of OT/IT integration.
Related terms
OPC DA is the ancestor of OPC-UA and remains the exit path from many legacy SCADA systems towards the historian. Replacing or wrapping it is part of any OT/IT convergence project, and in mixed architectures it is handled with an industrial gateway that isolates the old protocol from the rest of the system.