OPC: OPC Classic vs OPC UA

Back to Blog

OPC Classic: DA, HDA, A&E and the DCOM Problem

OPC originally stood for OLE for Process Control and was built on Microsoft's COM/DCOM technology. It defined several specifications for different data types: OPC DA (Data Access) for real-time process values, OPC HDA (Historical Data Access) for stored history, and OPC A&E (Alarms and Events) for alarm streams. An OPC server (often shipped by a device or driver vendor) exposed device data, and OPC clients such as SCADA and historians consumed it - a single translation layer instead of a bespoke driver per product.

The weakness was DCOM. Because OPC Classic depended on Windows-only DCOM for communication between machines, it was notoriously difficult to configure across firewalls, painful to secure, and effectively tied to Windows. Connecting an OPC client and server on different computers - especially across network boundaries - became a recurring source of frustration for integrators, which is precisely the problem the next generation set out to solve.

OPC UA: Platform-Independent and Model-Rich

OPC UA (Unified Architecture) is a ground-up redesign. It drops COM/DCOM in favour of its own service-oriented transport that runs on any operating system and traverses firewalls cleanly, with security (authentication, encryption, and signing) built into the specification rather than bolted on. It unifies the old DA, HDA, and A&E capabilities into one framework, so a single UA connection can carry current values, history, and events.

Just as important is the OPC UA information model. Instead of a flat list of tags, UA lets a server expose a structured, self-describing address space where objects, variables, methods, and their relationships are modelled - so a client can browse and understand an asset, not just read numbers. This makes UA well suited to modern, multi-site, and cloud architectures. A cloud SCADA such as Merobix connects to controllers and OPC UA servers over OPC UA, reading tags securely and pushing them outbound to cloud dashboards, alarms, and a historian, which is why UA has become a default choice for new integrations.

Classic vs UA at a Glance

The differences compress well into a table:

Aspect	OPC Classic	OPC UA
Transport	COM/DCOM (Windows RPC)	Own binary protocol over TCP, plus web-service mappings
Platform	Windows only	Any OS, embedded device to server
Security	DCOM permissions, bolted on	Certificates, signing, and encryption in the specification
Data scope	Separate DA, HDA, and A&E servers	One session for values, history, alarms, and methods
Address space	Flat tag list	Typed object model with browsable relationships
Firewalls	Dynamic port ranges, painful	Single configurable endpoint port

The table understates the operational difference. DCOM problems tend to appear as intermittent, hard-to-diagnose connection losses after security patches or domain policy changes; UA problems tend to appear once at commissioning as certificate trust errors, then stay solved.

When Each Generation Still Wins

OPC Classic still earns its keep in one situation: client and server on the same Windows machine in an established system. Local COM without DCOM is stable and free of network security complexity, and replacing a working, isolated Classic stack carries more risk than value. Plenty of plant historians and HMIs run this way and will until the hardware is retired.

OPC UA wins everywhere a boundary is crossed: between machines, between networks, through a DMZ, into non-Windows systems, or up to cloud platforms. It is the default for new integrations, and it is the sensible bridge when an older control system must feed a modern data layer - see the guide to connecting OPC UA to cloud SCADA for what that path looks like in practice.

Migrating Without a Rip-and-Replace

Nobody migrates OPC in one weekend, and nobody needs to. The standard path is to leave working Classic servers in place and put a Classic-to-UA wrapper or gateway in front of them, exposing the same data through a UA endpoint. New clients connect over UA; old clients keep their COM connections until each one is upgraded or retired. DCOM stops crossing network boundaries early in the process, which removes most of the pain immediately.

The new operational skill is certificate management. Every UA client and server pair must trust each other's certificates, and certificates expire - so plan who issues them, where trust lists live, and who renews them before the first expiry surprises you. Many stalled UA rollouts trace back to certificate trust errors that were never understood, only worked around.

Polling, Subscriptions, and Load

Classic DA clients mostly poll, or lean on COM callbacks that behave like polling under load. UA formalizes change-based reporting: a client creates a subscription, adds monitored items with sampling intervals and deadbands, and the server publishes only changes. Configured well, this cuts network and server load substantially compared to brute-force polling of a large tag list.

Configured badly, it produces its own failure modes: subscription queues overflowing, servers hitting monitored-item limits, or clients recreating sessions in loops. Treat sampling intervals and deadbands as engineering decisions per tag class rather than defaults - fast for control-relevant points, slow for slowly moving process values - and let the server's diagnostics tell you what the load actually is.

Frequently Asked Questions