What is OPC UA?
OPC UA, short for OPC Unified Architecture, is an open, platform-independent standard for industrial communication. Published by the OPC Foundation and standardized as IEC 62541, it defines how industrial devices, controllers, and software applications exchange data securely, reliably, and with shared meaning, regardless of operating system, hardware platform, or vendor.
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.
Software Toolbox and OPC UA: Software Toolbox has been a Charter Member of the OPC Foundation since 1996 and participated in OPC UA standards development from the earliest stages, including early adopter testing, compliance committee work, and the first public demonstration of OPC UA concepts at ISA 2005. Every major SWTB product carries OPC UA Lab Certification from the OPC Foundation.
OPC Classic vs OPC UA: what changed and why
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.
The original standard
- Built on Windows COM/DCOM technology
- Windows-only, no Linux or embedded support
- Three separate standards for data, history, alarms
- DCOM configuration notoriously difficult across firewalls and networks
- No built-in encryption or authentication
- Raw tag values only, no semantic context attached
- Client-server model only
- Still widely deployed and fully supported
The modern standard
- Standard TCP/IP transport, no COM/DCOM
- Runs on Windows, Linux, embedded, cloud
- Single unified standard covering all use cases
- Crosses firewalls and DMZs over a single TCP port
- X.509 certificates, TLS encryption, role-based access
- Rich information model with context, relationships, metadata
- Client-server and publish-subscribe transport models
- Foundation for IIoT, UNS, and Industry 4.0 architectures
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 bridge 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.
How OPC UA works: architecture and communication models
Client-server model
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.
Publish-subscribe model
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.
The OPC UA information model: why it matters
One of the most important differences between OPC UA and every protocol that came before it is the information model. 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.
OPC UA companion specifications extend the information model for specific industries and equipment types: robotics (OPC 40010), CNC machine tools (OPC 40501), food and beverage (OPC 20000), pharmaceutical (OPC 10040), and many others. When a robot and a SCADA system both implement the robotics companion specification, they share an identical understanding of the data structure with no custom integration required.
OPC UA security: built in, not bolted on
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.
Security note on certificates: OPC UA security is only as strong as how certificates are managed. Self-signed certificates are adequate for closed environments; CA-signed certificates are recommended for any deployment that spans network boundaries or includes connections from systems outside your direct control. Software Toolbox's OPC Tools product includes utilities for certificate generation and management.
OPC UA vs other industrial protocols
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.
| Feature | OPC UA | MQTT | Modbus TCP | EtherNet/IP |
|---|---|---|---|---|
| Primary purpose | Industrial interoperability framework | Lightweight pub/sub messaging | Device register access | PLC I/O and messaging |
| Information model | ✓ Yes, rich semantic context | ✗ No, payload is opaque | ✗ No, register numbers only | ~ Partial, CIP object model |
| Built-in security | ✓ Yes, X.509 + TLS + RBAC | ~ TLS only, no auth standard | ✗ No | ✗ No |
| Platform independence | ✓ Yes | ✓ Yes | ✓ Yes | ~ Primarily Windows/PLC |
| Historical data | ✓ Yes, built into spec | ✗ No | ✗ No | ✗ No |
| Alarms and events | ✓ Yes, built into spec | ✗ No | ✗ No | ~ CIP-based events only |
| Typical use in architecture | Device-to-HMI, device-to-historian, UNS feed | UNS transport, edge-to-cloud | Field device polling | Allen-Bradley PLC I/O |
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.
OPC UA in Software Toolbox products
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.
Frequently asked questions
Getting started with OPC UA
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. Pair it with any OPC UA client, including the OPC Foundation's free UA Expert tool, 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.
