What is OPC DA?
OPC DA (OPC Data Access) is the original OPC specification that lets Windows applications read and write current process data (value, timestamp and quality) from industrial devices through Microsoft COM/DCOM, regardless of the vendor. The OPC Foundation published Data Access 1.0 in 1996 to solve the driver problem in industrial automation: instead of a separate interface for every PLC and every SCADA package, there was now one standard interface. OPC DA is the best-known member of OPC Classic and still runs in countless legacy systems in OT environments, although OPC UA is increasingly taking over that role.
Within OT convergence, OPC DA is often the layer where process data first becomes available in a vendor-neutral form, which makes it a natural starting point for connections to historians, MES and modern data platforms.
🧠 Where does OPC DA come from and which versions exist?
In the mid-1990s almost every HMI and SCADA package ran on Windows. A group of vendors therefore chose Microsoft’s OLE/COM technology as the foundation, and OPC originally stood for OLE for Process Control. Since 2011 OPC officially means Open Platform Communications. Data Access was the first and by far the most widely used specification; OPC HDA (historical data) and OPC A&E (alarms and events) followed later.
| Version | Year | Main additions |
|---|---|---|
| DA 1.0 / 1.0a | 1996 / 1997 | Custom COM interface, synchronous reads and writes; asynchronous traffic through the older IDataObject/IAdviseSink mechanism |
| DA 2.0 - 2.05a | from 1998 | Automation interface (e.g. for Visual Basic), new asynchronous interface with connection points and OnDataChange callbacks, better browsing |
| DA 3.0 | 2003 | Writing value, quality and timestamp together, reads with MaxAge, keep-alive per group, improved deadband handling and error reporting |
A DA 2.0 client works with a DA 3.0 server but then only uses the 2.0 features. The other way round, a DA 3.0 client does not always work with an old DA 1.0 server, because that server lacks the version 2.0 callback interfaces (IOPCDataCallback). In practice most servers and clients support DA 2.05a and 3.0 side by side.
🔧 How is OPC DA structured?
OPC DA follows a client-server architecture. The chain typically looks like this: PLC or field device → OPC DA server → (COM locally or DCOM across the network) → OPC DA client such as SCADA or a historian.
| Component | Function | Example |
|---|---|---|
| Device driver | Speaks the device’s own protocol | S7 Comm driver for a Siemens PLC |
| OPC DA server | Translates device data into the standard OPC interface and keeps a cache | Kepware KEPServerEX, SIMATIC NET |
| Group | Set of items with its own update rate, deadband and active/inactive state | Group “Line3_Fast” at 500 ms |
| Item | Connection to one data point via an Item ID | Line3.Motor.Speed |
| OPC DA client | Reads, writes or subscribes | SCADA, HMI, Historian |
Each server registers itself in Windows with a ProgID and a CLSID, and the OpcEnum service gives clients a list of installed servers. A client then browses the server’s address space and adds the tags it needs as items to one or more groups. An important detail: an item is not the data itself but a connection to the data source.
When client and server run on the same computer, everything goes through COM and there is no network traffic. When they run on different computers, OPC DA uses DCOM: first TCP port 135 for the RPC Endpoint Mapper, then a dynamic port (by default 49152-65535 since Windows Vista and Server 2008). With subscriptions the server also calls back into the client, so traffic flows in both directions.
🔄 How does OPC DA exchange data?
OPC DA offers three ways to read data, plus synchronous or asynchronous writes. The choice determines the load on the network and on the PLC.
| Method | How it works | When to use it |
|---|---|---|
| Synchronous read from cache | The client immediately gets the last known value from the server cache | Fast requests where a slightly older value is acceptable |
| Synchronous or asynchronous device read | The server fetches the value directly from the device | Checks before a critical action; heavy with many items |
| Subscription (OnDataChange) | The server sends only changed values per group via a callback | Continuous monitoring and trending; the default for SCADA |
| Write | Synchronous or asynchronous write of a value to the item | Setpoints and commands |
With subscriptions two group settings control the behaviour:
- Update rate - the fastest interval in milliseconds at which the server reports changes for that group. Common values are 250-1,000 ms for operator screens and 1-10 seconds for reporting or historian data.
- Percent deadband - applies to analogue items with an engineering range: a change is only reported when it exceeds that percentage of the range. With a range of 0-200 °C and a deadband of 0.5%, a temperature change is only passed on from 1 °C upwards.
DA 3.0 added MaxAge: the client states how old a value may be at most. A MaxAge of 0 means always read from the device, the maximum value means always read from the cache. With keep-alive a DA 3.0 server also reports in when nothing changes, so a client can tell a quiet connection from a broken one.
🧠 What do value, timestamp and quality mean?
Every OPC DA item delivers three fields, often abbreviated to VQT: value (a Windows VARIANT, so an integer, float, boolean, string or array), quality and timestamp (in UTC). The quality field in particular makes OPC DA suitable for real-time process monitoring: an operator sees not just a number but also whether that number can be trusted.
The quality is a byte laid out as QQSSSSLL: two bits for the main status, four for the substatus and two for limit information.
| Code (hex) | Meaning | Typical cause |
|---|---|---|
| 0xC0 | Good | Value is current and reliable |
| 0xD8 | Good - local override | Value manually overridden |
| 0x40 | Uncertain | Quality is questionable |
| 0x44 | Uncertain - last usable value | Source no longer delivers updates |
| 0x00 | Bad | Unspecified error |
| 0x08 | Bad - not connected | Item not configured or connected |
| 0x18 | Bad - comm failure | Communication with the PLC or IO lost |
| 0x1C | Bad - out of service | Item or group inactive |
A good SCADA or historian configuration shows bad quality clearly to the operator and stores the quality alongside the value, so later analyses do not treat invalid values as real measurements.
🏭 Where is OPC DA used?
OPC DA became the standard interface between controllers and Windows software. The server handles the protocol translation to the underlying network:
| Underlying protocol | Typical application |
|---|---|
| Modbus and Modbus TCP | PLCs, energy meters, variable frequency drives |
| Profibus and ProfiNET | Siemens-based installations |
| Ethernet IP | Allen-Bradley controllers |
| S7 Comm | Siemens S7 PLCs |
| BACnet | Building Automation and HVAC |
Well-known server products include KEPServerEX from Kepware (a multi-protocol server with a large driver library), SIMATIC NET from Siemens, OPC Factory Server from Schneider Electric, the MatrikonOPC servers and RSLinx Classic from Rockwell Automation. On the client side, virtually every SCADA package of that generation supports OPC DA, such as WinCC.
Typical applications:
- Process industry and manufacturing - SCADA screens, alarm management and data collection for the historian
- Energy and water - pumping stations, substations and telemetry through a central SCADA
- Connection to IT - MES and ERP systems usually obtain production data indirectly through a historian or gateway that reads OPC DA itself
- Edge and cloud - gateways on an edge computer read OPC DA and publish to MQTT or a Unified Namespace
- Labs and simulation - OPC DA simulation servers are still widely used for training and client testing
In the Purdue Model, OPC DA servers and clients usually sit at levels 2 and 3, inside the process network.
🔐 What risks and limitations does OPC DA have?
OPC DA was designed for closed networks and has no security model of its own. Everything depends on Windows and DCOM, which leaves the cybersecurity of many installations weak:
- Difficult firewalls - port 135 plus a large dynamic range, and callbacks towards the client
- Weak configurations - vendor manuals long advised authentication level None and permissions for Everyone, letting anyone on the network operate the server
- No encryption in practice - DCOM can encrypt with Packet Privacy, but OPC installations rarely set the level that high
- Outdated hosts - OPC servers often run on Windows versions without updates, which complicates patch management
- Targeted abuse - the Havex malware (2013-2014) actively searched networks for OPC servers, and Industroyer (Ukraine, 2016) included an OPC DA component
With the DCOM hardening KB5004442 (CVE-2021-26414), Microsoft requires at least Packet Integrity for activation: optional since June 2021, enabled by default since 14 June 2022 and impossible to disable since 14 March 2023. OPC DA clients on unpatched or outdated Windows versions therefore lose their connection to an updated remote server.
🛠️ How do you manage and migrate OPC DA in practice?
A realistic approach combines hardening of what is running with a gradual transition:
- Inventory every OPC DA server, client and network flow in your asset inventory, including the DA version and Windows version.
- Keep DCOM local - put client and server on the same machine, or use an OPC tunneller that replaces DCOM with a single fixed, preferably encrypted TCP connection.
- Restrict DCOM - narrow the dynamic port range, remove anonymous access and use dedicated service accounts with minimal privileges.
- Segment - place OPC traffic in its own zone with conduits according to IEC 62443, apply network segmentation with an industrial firewall and route data to IT through a DMZ or a data diode.
- Monitor DCOM traffic with logging and security monitoring; unexpected connections to port 135 can indicate lateral movement.
- Migrate to native OPC UA when SCADA or the historian is replaced, and use a DA-to-UA wrapper or gateway in the meantime.
For Dutch organisations covered by the Cyberbeveiligingswet (in force since 15 August 2026), this approach helps demonstrate that the known risks of legacy OT connections are adequately managed. NIST SP 800-82 and the NIST CSF provide further guidance, and ISA-95 helps position the integration between process control and business systems.
📡 What is the difference between OPC DA and OPC UA?
OPC UA (IEC 62541) is the platform-independent successor and combines the functions of DA, HDA and A&E in a single architecture.
| Property | OPC DA | OPC UA |
|---|---|---|
| Technology | COM/DCOM | Own protocol stack, independent of COM |
| Platform | Windows only | Windows, Linux, embedded and cloud |
| Network | TCP 135 plus dynamic ports | One port (4840 by default), also HTTPS and PubSub |
| Security | Depends on Windows/DCOM settings | Certificates, encryption and user authentication built in |
| Data model | Tags in a namespace with VQT, no type model | Object-oriented information model |
| Status | Legacy, no new development | Active standard |
❓ Frequently asked questions
What does OPC DA stand for?
OPC DA stands for OPC Data Access, where OPC originally meant OLE for Process Control and since 2011 Open Platform Communications. OPC DA is the specification for reading and writing current process data. Historical data and alarms are covered by the separate OPC HDA and OPC A&E specifications.
Is OPC DA still used?
OPC DA is still widely used in existing SCADA, historian and HMI installations, especially in the process industry, energy and water. The OPC Foundation no longer develops the specification and new projects choose OPC UA. Existing OPC DA connections keep working as long as the Windows hosts and DCOM settings are properly managed.
Does OPC DA work on Linux?
OPC DA does not run natively on Linux, because the specification is built on Microsoft COM/DCOM; an OPC DA server always runs on Windows. To use OPC DA data on Linux, you usually place a gateway or wrapper on a Windows machine that exposes the data through OPC UA or MQTT. For new Linux applications, OPC UA is the logical choice.
What is the update rate in OPC DA?
The update rate in OPC DA is the interval in milliseconds at which an OPC DA server reports changes in a group of items to the client. A lower update rate gives faster screens but puts more load on the server, the network and the PLC. Combine the update rate with a deadband to avoid unnecessary notifications for small fluctuations.
What does bad quality mean in OPC DA?
Bad quality in OPC DA means that the value of an item is not reliable, for example because communication with the PLC has been lost (0x18) or the item is not connected (0x08). The server often still delivers a number, but it must not be used as a real measurement. SCADA and historian systems should make bad quality visible and store it with the value.
How do I connect OPC DA to OPC UA?
You connect OPC DA to OPC UA with a wrapper, which exposes an existing OPC DA server as an OPC UA server, or with a proxy, which lets an old OPC DA client read data from an OPC UA server. Many multi-protocol servers and edge gateways offer both functions. This lets you migrate step by step without replacing every system at once.
📌 In summary
OPC DA is the COM/DCOM-based OPC specification that since 1996 has made current process data with value, timestamp and quality available to Windows software in a vendor-neutral way.
OPC DA solved the driver problem between PLCs and SCADA and still forms the backbone of many OT installations. Groups, update rates, deadbands and quality codes make it a mature real-time interface, but its Windows dependency, difficult DCOM configuration and lack of built-in security make it a legacy technology. Manage existing connections with segmentation, tunnels and hardening, and plan the move to OPC UA.
