Definition
OPC DA (OPC Data Access) is a data access specification developed by the OPC Foundation. It is based on Windows COM/DCOM and enables real-time data exchange between industrial control devices and upper-level systems, SCADA, DCS. Due to its dependence on Windows and DCOM configuration, cross-platform operation and firewall traversal are relatively complex. Nowadays, it is largely replaced by OPC UA, but it is still widely used in legacy systems.
Technical Features
OPC DA uses a client/server architecture. The server connects to devices such as PLCs and instruments, while clients (HMI, SCADA, data acquisition software) subscribe or poll data through the OPC interface. It supports synchronous read/write, asynchronous read/write, subscriptions, and other modes. Data items are identified by ItemID and include value, quality, and timestamp. DCOM requires configuration of Windows Firewall and DCOM permissions, making cross-machine access complex; it only supports the Windows platform.
Migration to OPC UA
OPC UA is the successor to OPC DA, supporting cross-platform, secure encryption, information modeling, PubSub, and more. New projects are recommended to use OPC UA. Older DCS or SCADA that only support OPC DA can convert data to OPC UA for cloud platforms and MES collection through an OPC DA to OPC UA bridging gateway.
Component Identity and Subscription Quality
The server maps device points to items
In the data-access specification, the server stands between the devices and the client. It reads a PLC or an instrument with the vendor driver, then registers the result as a data item. The client does not care which bus is underneath. It reads value, quality, and timestamp by item identifier. The quality code says whether the value can be used. When communication is down, a sensor is over range, or the server has just started and has not refreshed, the value field may still hold an old number. Only the quality code tells the display "do not trust this."
There are three rhythms. A synchronous read or write returns only when that call finishes, and a large item list freezes the screen. An asynchronous read or write delivers the result later. A subscription has the server push changes on an agreed refresh period, which suits a display. The subscription period is not the device's own scan. A point may already have changed in the controller while the screen still waits for the next callback. Set the subscription slower than the process changes, and alarms arrive late.
Suited only to Windows hosts in the same domain
This technology is built on the component object model. Server and client usually both have to run on Windows, and they have to be able to start objects for each other under the same identity. It suits an older system that already has configuration software in the control room, a point list that has not changed for years, and no chance yet to modify the controller program. For new cross-platform collection, for traffic that must cross a firewall, or for a gateway that is not Windows, do not keep this remote component call as the only path. Evaluate a bridge to a newer protocol.
Before remote access, settle three things: which Windows account is allowed to start the server, whether the firewall permits the ports the components use, and whether the server process still runs when nobody is logged in. Many sites work while an engineer is logged in and go blank after logoff, because the server was set to start only inside an interactive session. Change the domain policy and that configuration fails across the board.
Permissions, the firewall, and quality codes
The most common fault is permissions, not the point list. The client can ping the server and still fail to browse the item list, usually because the identity that starts the server and the identity that accesses it are not the same. Opening it temporarily as an administrator and running it long term as an ordinary service account produce different results. Second, the firewall allows only a fixed port while dynamic ports stay blocked. The local connection works, and a subscription across machines times out at random. Third, quality is ignored. Communication is already down, the screen keeps showing the last pressure and temperature, and the operator adjusts from that.
Item identifiers follow the server project. Replace the server or upgrade the driver and the identifier strings may change. Every client has to be rebound. Do not treat browse order as a stable address. Restrict write commands even more tightly, or any program that can reach the component can change a setpoint. If the data must be handed to a non-Windows Modbus collector, use a purpose-built bridge and check quality again at the bridge. Do not write bad quality into a register that looks normal.
The server process should also stay at a lower priority than the control task. Refreshing thousands of items, if it preempts the configuration runtime on the same industrial PC, makes the display and the collection slow each other down. The operator reads that delay as a slow field device. Limit the number of subscribed items and the refresh period, and put the server on its own host so it does not compete with the operator station for the same processor.