OT
OPC UA security: modes, certificates and trust lists
Do not leave an OPC UA connection at “it works”. Treat security mode, certificate trust and user authentication as separate decisions.
What is the difference between OPC DA and OPC UA?
Short answer
OPC DA (Classic) is built on Microsoft COM and DCOM and is tied to Windows. OPC UA is platform-independent, uses its own binary TCP or HTTPS transport, and has security built in: certificates, signing and encryption. It also offers typed information models, subscriptions, method calls and historical access.
Two architectures
OPC DA (Classic) rests on Microsoft's COM and DCOM technologies. Clients and servers therefore usually run on Windows, and DCOM's dynamic port use makes firewall rules hard to write and maintain.
OPC UA is not tied to one operating system. It runs over its own binary TCP transport or over HTTPS. Security is part of the core rather than an add-on: application certificates, message signing and encryption are defined in the standard. Its information model is typed, so a pump can be one object with speed, status and methods.
On top of reading and writing, UA provides subscriptions for change notifications, method calls, historical access and a PubSub option for publish-subscribe messaging.
Worked example: moving pump tags
Hypothetical plant: 120 OPC DA tags are defined, and 36 of them no longer appear on any screen or report. The migration therefore starts with 120 − 36 = 84 tags.
Each remaining tag is mapped to a UA node. For example, the DA item 'PumpA.Speed' becomes a variable at Line1/PumpA/Speed in the UA address space. The data type, such as Double, and the engineering unit are checked against the DA server documentation and written into the UA model.
Change notifications come from a subscription. The publishing interval depends on process needs; 1000 ms here is only a starting value for a test, not a rule.
Common mistakes
The first mistake is assuming OPC UA is secure by default. A deployment that uses security mode None, or accepts any certificate, gives up most of the protection the standard offers. Policies and certificate management must be configured on purpose.
The second mistake is copying DA tags one-to-one. UA is meant to model objects, types and relationships; a flat list of tags uses none of that.
The third mistake is treating OPC UA as real-time. Subscription intervals, network load and server load determine timing. Control loops still belong in the controller; the OPC UA layer is for supervision and data exchange.
Follow-up questions
Do I have to move from OPC DA to OPC UA?
Not always. If the existing system works and its network is isolated, the move can wait. For new integrations, or for data flows that must cross firewalls, OPC UA is usually the better fit. The decision depends on maintenance, security and support plans.
Can DA and UA work side by side?
Yes. A DA-to-UA bridge, sometimes called a wrapper or proxy, can expose an existing DA server to UA clients. The bridge translates connections and data, but it does not remove the Windows and DCOM dependency inside the DA server.
Sources
Example numbers are hypothetical, not measured field results.
Read the full guide.
Full library
DataOps
Prepare OPC UA data for AI
Turn a tag value into a usable observation with units, quality, timestamps and asset context.