HomeResourcesWhat is OPC UA?
OPC Standards Explained

What is OPC UA?

OPC UA, OPC Unified Architecture, is the open, platform-independent industrial communication standard published by the OPC Foundation as IEC 62541. It defines how devices, controllers, and software exchange data securely, reliably, and with shared meaning, regardless of operating system, hardware, or vendor.

Last reviewed: 2026Reading time: ~10 minTopics: OPC UA, IEC 62541, information model, pub/sub, security, X.509, IIoT, UNS

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.

OPC Classic (DA, HDA, A&E)

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
OPC UA (IEC 62541)

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.

OPC UA communication: client-server and pub/sub paths
FIELD DEVICESPLC / RTUDCSSensorsEmbeddedOPC UA serverEdge deviceLinux / containerOPC UA SERVERTOP ServerAddress spaceInformation modelSecurity layer140+ device driversDA + UA + HDA + A&EHMI / SCADA clientHistorian clientMQTT broker / UNSpub/sub transportCloud / analyticsMES / ERPclient-serverpub/subTLS + X.509

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:

Transport
Network and port security
OPC UA communicates over a single configurable TCP port, eliminating the wide range of dynamic DCOM ports that made OPC Classic difficult to firewall. TLS provides transport-level encryption when configured. Firewalls only need a single inbound rule per OPC UA server endpoint.
Application
X.509 certificates and secure channels
Every OPC UA client and server application has an X.509 certificate that acts as its identity. During connection establishment, both sides exchange and verify certificates, then establish an encrypted secure channel using asymmetric cryptography for key exchange and symmetric AES encryption for ongoing data transfer. Messages are signed to detect tampering and sequenced to prevent replay attacks.
User
Authentication and role-based access
Individual users authenticate with username/password, X.509 user certificates, or anonymous access (not recommended for production). Each user is assigned a role, and each node in the address space can have individual read, write, and browse permissions per role. A maintenance engineer's client can read all nodes but write only to maintenance parameters. An operator client can write setpoints but cannot browse the configuration namespace.

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.

FeatureOPC UAMQTTModbus TCPEtherNet/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.

🖥️
TOP Server
OPC UA Lab Certified server with 140+ device drivers. Exposes any connected device as an OPC UA endpoint. Supports DA, UA, HDA, and A&E simultaneously on the same installation.
🛡️
OPC Tools
Utilities for OPC UA certificate management, trust list administration, security configuration testing, and endpoint discovery. Purpose-built for the tasks OPC UA deployments require at scale.
🔗
Cogent DataHub
OPC UA gateway, bridge, and tunneling middleware. Connects OPC UA endpoints to OPC DA clients, tunnels OPC Classic across networks securely, and bridges between OPC UA servers and MQTT brokers.
🔀
OPC Router
Visual workflow middleware for routing OPC UA data to databases, cloud platforms, MQTT brokers, SAP, REST APIs, and other systems. Handles OPC UA pub/sub alongside classic polling workflows.
📡
OmniServer
OPC UA certified server for non-standard and custom protocol devices. Uses a script-based driver development environment so any device with a documented protocol can be exposed as an OPC UA data source.
🐧
Kepware Edge
Containerized OPC UA connectivity for Linux-based edge hardware. Brings TOP Server's driver library and OPC UA endpoint to Docker environments, Raspberry Pi, industrial PCs, and cloud VMs.

Frequently asked questions

Can OPC UA clients connect to OPC Classic (DA) servers?+

Not directly, since they use fundamentally different transport mechanisms. OPC Classic uses COM/DCOM and is Windows-only. OPC UA uses TCP/IP and works cross-platform.

However, OPC gateway or wrapper products solve this cleanly. A DA-to-UA wrapper exposes an existing OPC DA server's data through an OPC UA endpoint, allowing modern UA clients to access legacy DA servers without any changes to the DA server itself. Cogent DataHub provides exactly this capability, as does TOP Server's built-in UA server functionality which can expose DA data as UA. This allows organizations to migrate client applications to OPC UA incrementally, without replacing existing OPC DA infrastructure all at once.

Does OPC UA require a Windows server to run?+

No. This is one of the most important improvements over OPC Classic. OPC UA runs natively on Linux, embedded operating systems (VxWorks, QNX, and others), macOS, and cloud infrastructure, as well as Windows. The OPC Foundation publishes open-source OPC UA stack implementations in C, C++, Java, Python, and .NET, so OPC UA can be implemented on almost any platform that has a TCP/IP stack.

Software Toolbox's Kepware Edge product specifically packages OPC UA connectivity for Linux environments, enabling deployment on containerized edge hardware, Raspberry Pi, and cloud VMs running Ubuntu or other Linux distributions.

Is OPC UA suitable for real-time control applications?+

OPC UA is well-suited to supervisory and monitoring applications where cycle times in the range of milliseconds to seconds are acceptable. For very tight deterministic real-time control loops in the sub-millisecond range, OPC UA over standard Ethernet has historically not been the right tool.

The OPC Foundation is addressing this through the integration of OPC UA with Time-Sensitive Networking (TSN), a set of IEEE Ethernet standards that add deterministic timing to standard Ethernet. OPC UA over TSN enables OPC UA to be used in motion control, robotics, and synchronized drive applications where deterministic timing is required. This is an active area of development and deployment is beginning in high-end machine tool and robotics applications.

For most industrial automation use cases, including SCADA, HMI, historians, MES integration, and IIoT data pipelines, standard OPC UA over TCP/IP is entirely appropriate.

What is an OPC UA address space and how is it organized?+

The OPC UA address space is the structured representation of all data and objects a server makes available to clients. It is organized as a graph of nodes, where each node has a NodeId (its unique identifier), attributes (name, description, data type, value, etc.), and references to other nodes that define relationships.

Nodes can represent variables (tag values), objects (equipment items), methods (callable functions), views (filtered subsets of the address space), data types, and reference types. The result is a hierarchical, browsable structure where an engineer or a client application can navigate from a plant to a unit to a piece of equipment to an individual sensor reading, with the relationships between everything preserved in the data model itself.

How does OPC UA fit into a Unified Namespace architecture?+

OPC UA is typically the primary data source protocol feeding a Unified Namespace. Device data is accessed through OPC UA servers (like TOP Server) at the device layer. That data is then published into the UNS via MQTT using Sparkplug B payloads, which carry the structured, contextualized OPC UA data model through the broker to all subscribers.

OPC UA's information model is particularly valuable in this context because it provides the semantic context that makes UNS data meaningful. Instead of publishing raw register values to MQTT topics, OPC UA data carries asset hierarchy, engineering units, and relationship context that the UNS preserves. This is the difference between a UNS that is a topic tree of numbers and one that is a true operational model of the facility.

What is OPC UA pub/sub and how does it differ from client-server?+

In OPC UA client-server mode, a client establishes a direct connection to a server and maintains a session. The server knows about each connected client and can manage subscriptions, security sessions, and access rights per client. This model works well for SCADA, HMI, and historian applications where you have a defined set of consumers each with their own subscription requirements.

In OPC UA pub/sub mode, publishers send data to a broker or network without any knowledge of who is listening. Subscribers register their interest with the broker, not with the publisher. New consumers can be added without any changes to the publisher. This model scales much better for IIoT scenarios where many different systems need to receive the same data, and for cloud and edge architectures where maintaining persistent connections to every consumer is impractical.

OPC UA pub/sub uses MQTT or UDP as the transport. OPC UA with MQTT pub/sub is the foundational mechanism behind Sparkplug B and most modern Unified Namespace implementations.

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.

Ready to deploy OPC UA in your plant?

Software Toolbox's engineers have been implementing OPC UA since before most of the industry had heard of it. Whether you are migrating from OPC Classic, building a new UNS architecture, or troubleshooting a certificate issue, we can help.

Talk to an engineer