What is OPC UA?

Where OPC Classic required Windows and Microsoft's COM/DCOM technology, OPC UA runs on Linux, embedded systems, cloud platforms, and Windows alike. Where OPC Classic had separate standards for real-time data (DA), alarms (A&E), and historical data (HDA), OPC UA unifies all of those capabilities under a single, coherent specification. And where OPC Classic had no built-in security, OPC UA has encryption, authentication, and role-based access control designed into the architecture from the ground up.

The result is a standard that can connect a field sensor on the plant floor all the way to an enterprise analytics platform or a cloud data pipeline, with the same protocol, the same security model, and consistent, machine-readable meaning attached to the data at every step.

OPC Classic was a significant achievement for the automation industry. It standardized how SCADA, HMI, and historian applications accessed device data, and its widespread adoption across the industry proved the value of the underlying idea. But it was built on Microsoft technology that came with structural limitations that became harder to work around as operational technology began integrating with IT networks and cloud platforms.

OPC UA was not designed to obsolete OPC Classic overnight. The OPC Foundation designed UA to supplement the existing standards and provide a migration path, not a forced cutover. Millions of deployed OPC Classic installations continue to run reliably. Products like Cogent DataHub Gateway convert between the two, allowing OPC UA clients to access data from OPC Classic servers, and vice versa, so organizations can modernize incrementally rather than all at once.

The foundational OPC UA communication model is client-server, directly analogous to OPC Classic. An OPC UA server exposes an address space, a structured representation of all the data it makes available. Clients connect to the server, browse the address space to discover available nodes, then subscribe to data changes, read values on demand, or write back to the device if authorized to do so.

The key difference from OPC Classic is that OPC UA uses standard TCP/IP over a single configurable port. There is no DCOM configuration required, no DCOM security exceptions to manage, and no Windows infrastructure dependency. An OPC UA server can sit behind a firewall and be accessed through a single inbound port rule, which is both simpler to configure and far easier to defend.

OPC UA also supports a publish-subscribe transport that decouples data producers from consumers. In pub/sub mode, an OPC UA publisher sends data to a broker or directly to subscribers using standard protocols like MQTT or UDP multicast, without requiring a persistent connection to each consumer. Multiple subscribers can receive the same data simultaneously, and new subscribers can join without any reconfiguration on the publisher side.

This model is essential for Unified Namespace architectures, where a single OPC UA data source may need to feed dozens of downstream consumers simultaneously, and for edge-to-cloud pipelines where bandwidth and connection persistence cannot be taken for granted.

One of the most important differences between OPC UA and every protocol that came before it is the ability to support industry standard and user defined information models. In Modbus, EtherNet/IP, or OPC Classic DA, you get a value, a timestamp, and a quality stamp. You do not get context. What does register 40001 mean? What is the unit of measurement? What asset does it belong to? That knowledge lives in the engineer's head or in a separate configuration file.

OPC UA defines an address space where every data point is a node with properties: a name, a description, units, data type, relationships to other nodes, and an object type that describes what kind of thing it represents. A temperature sensor node knows it is a temperature sensor, what it measures, what engineering units to apply, and what piece of equipment it is part of.

This semantic context is what makes OPC UA data immediately useful to systems that have never seen it before. An analytics platform connecting to an OPC UA server does not need a separate configuration document to understand that NodeId 1001 is the outlet temperature of Heat Exchanger HX-04 in degrees Celsius. That information is in the data itself.

You can learn more about OPC UA Information models and how OPC Router in our Putting OPC UA PubSub, Information Models, & Companion Specs to work blog post.

OPC Classic had no security of its own. It relied entirely on Windows DCOM security settings and network-layer firewalls. That approach was adequate when control networks were air-gapped, but becomes increasingly untenable as IT and OT networks converge and data needs to move across security boundaries.

OPC UA security is implemented in three coordinated layers, each addressing a distinct threat surface:

This layered model means that OPC UA can be safely deployed across DMZ boundaries and IT/OT network segments in ways that OPC Classic never could. It is one of the primary reasons IT security teams have become willing to allow OT data to traverse enterprise networks when OPC UA is the transport.

Learn more about OPC UA's layered model in our Exploring OPC UA - Key Concepts of a Layered Security Model technical blog post.

Demystify certificates in our Understanding OPC UA Certificates and Certificate Authorities technical blog post. 

Our get our full detailed OPC UA Security Concepts Guide

Engineers regularly ask how OPC UA compares to MQTT, Modbus, and EtherNet/IP. These are not competing alternatives in most architectures, they serve different layers and are often deployed together.

In a modern IIoT architecture, OPC UA and MQTT are complementary. OPC UA provides the structured, semantic data model and security framework at the device and server layer. MQTT provides the lightweight, scalable pub/sub transport that carries OPC UA data through Sparkplug B payloads up to the Unified Namespace and onward to the cloud. OPC UA over MQTT pub/sub is itself a defined transport option within the OPC UA specification.

Every major SWTB product that handles industrial data has been OPC UA certified by the OPC Foundation's compliance test lab. This is not marketing positioning, it means the implementation has passed the OPC Foundation's interoperability test suite and will work correctly with any other certified OPC UA client or server.

For engineers new to OPC UA, the most practical starting point is getting a server and client connected in a test environment and browsing the address space. The concepts become much clearer once you can see an information model hierarchy in a UA browser and watch tag values update in real time.

Software Toolbox offers free trials of TOP Server, which installs in minutes on Windows and includes a simulation driver that creates a complete address space without any hardware.

Free trial downloads are also availble for these other OPC UA products from Software Toolbox: OmniServer, OPC Router, Cogent DataHub, N3uron, OPC Data Client toolkit , and OPC Server Wizard Toolkit 

Use or solutions together and you can explore the full client-server model including subscription management, security configuration, and address space browsing without needing a PLC on the bench.

For engineers working with certificates and security configuration specifically, Software Toolbox's blog has detailed, practical guides on OPC UA certificate types, trust list management, and the difference between self-signed and CA-signed certificate deployments in production environments.