What does OPC UA stand for?

OPC UA stands for Open Platform Communications Unified Architecture. It is an open, vendor-neutral standard, maintained by the OPC Foundation and published as IEC 62541, for exchanging industrial data between machines, controllers, and software securely and with shared meaning.

What is the difference between OPC UA and OPC Classic?

OPC Classic was built on Microsoft's COM/DCOM technology and ran only on Windows, with limited built-in security. OPC UA is platform-independent, runs on any operating system from embedded devices to the cloud, has encryption and authentication built in, and carries data with its meaning through an information model.

Security is built into OPC UA: authentication with X.509 certificates, authorization, encryption, and message integrity, with selectable security policies. It is secure when configured deliberately, but a plant still has to enable it, manage certificates, and segment its networks. Treat it as one layer within a broader industrial-security discipline.

What is an OPC UA information model?

An information model is how OPC UA describes what a value means, not just its number. A node can carry the name, unit, data type, parent object, relationships, and callable methods along with the value. Companion specifications standardize these models per industry so machines expose data in an agreed shape.

Does OPC UA use client-server or publish-subscribe?

Both. Client-server suits direct request-and-response reads, like a dashboard querying a controller. Publish-subscribe (PubSub) suits fanning data out to many systems at scale, often over MQTT or UDP. Modern architectures mix the two depending on whether the link is interactive or high-volume.

Is OPC UA better than MQTT?

They do different jobs and work well together. OPC UA is strongest at modeling and securing industrial data; MQTT is a lightweight transport for moving many messages over unreliable networks. A common approach uses OPC UA to structure and secure data at the source and MQTT to carry it up to a platform.

Do I need to replace my machines to use OPC UA?

No. Newer controllers and SCADA systems often include an OPC UA server already. For older or proprietary equipment, an edge gateway reads the native protocol and re-exposes the data as OPC UA without touching control logic, so you get standardized connectivity without a rip-and-replace.

What Is OPC UA? The Factory Interoperability Standard

The common language that lets machines from different vendors and decades hand their data to the same software, securely, and without lock-in.

OPC UA (Open Platform Communications Unified Architecture) is an open, vendor-neutral standard for moving industrial data between machines, controllers, and software securely and with shared meaning. Standardized as IEC 62541, it lets a plant get OT data off the floor without locking into a single vendor.

Here is the problem OPC UA exists to solve. A typical plant floor speaks a dozen dialects: one controller brand talks its own protocol, a second brand talks another, older equipment talks serial fieldbus, and none of them agree on what a "temperature" or a "part count" even means as a piece of data. Getting all of that into one system used to mean custom integration for every machine, expensive, brittle, and impossible to maintain. OPC UA is the common language that ends the babel, so equipment from different vendors and eras can hand their data to the same software in the same form.

This guide explains what OPC UA is, how it improved on the older OPC Classic, why its information model is the part that actually matters, how it moves data and secures it, and how OPC UA data gets from a controller into a unified operational layer. For the broader plumbing this fits into, see the industrial internet of things.

What is OPC UA, and what problem does it solve?

OPC UA is a standard maintained by the OPC Foundation that defines how devices and software exchange industrial data in a secure, platform-independent, vendor-neutral way. Its job is interoperability: letting a controller from one maker, a sensor from another, and a piece of analytics software all share data without a custom bridge built for each pairing.

OPC UA sits between the floor and the software, translating many machine dialects into one standard form so any consumer can use the data.

The name carries history. The original OPC ("OLE for Process Control") was a Windows-only technology from the mid-1990s that solved the same interoperability problem for its era. "UA", Unified Architecture, is the modern rebuild that kept the goal and dropped the Windows dependency. Today OPC UA is the standard most new controllers, SCADA systems and platforms support natively, which is exactly why it matters for getting data out of the floor and into systems that can act on it.

How is OPC UA different from OPC Classic?

OPC Classic was tied to Microsoft's COM/DCOM technology and ran only on Windows; OPC UA is platform-independent, more secure, and built as an international standard. That single change, cutting the Windows-and-DCOM cord, is why OPC UA runs on Linux, embedded controllers, cloud platforms, and Windows alike, and why it can cross network boundaries that DCOM made painful.

OPC Classic solved interoperability on Windows in the 1990s. OPC UA rebuilt it as a secure, platform-independent international standard.

Three practical consequences follow. First, OPC UA is not locked to one operating system, so an edge gateway on Linux can serve data just as well as a Windows server. Second, security is built in rather than bolted on, which matters the moment control data leaves the machine cabinet. Third, and most important, OPC UA carries not just values but their meaning, which OPC Classic never did well.

What is an information model, and why does it matter?

An information model is OPC UA's way of describing what a value means, not just what it is. Instead of shipping the bare number 74.2, OPC UA can say: this is the discharge temperature of pump 3, measured in degrees Celsius, with a normal range, related to this motor and this line, and here are the methods you can call on it. The data arrives self-describing.

An OPC UA node ships the value with its meaning attached: name, unit, type, parent object, relationships, and callable methods. OPC Classic passed only the bare number.

This is the difference between data and information, and it is where OPC UA earns its keep. A bare number needs a human to build a lookup table explaining what every tag means before software can use it, the slow, error-prone step that sinks integration projects. A self-describing node lets a receiving system understand the data automatically, and companion specifications standardize these models for whole industries so a machine tool or a robot exposes its data in a shape everyone already agrees on. Well-modeled OPC UA data is a direct antidote to manufacturing data silos because the meaning travels with the value instead of living in one integrator's spreadsheet.

Client-server or pub/sub: which does OPC UA use?

Both. OPC UA supports a client-server model, where software asks a device for data and the device answers, and a publish-subscribe (PubSub) model, where a device publishes data to a broker and any number of subscribers receive it. Client-server suits direct, request-and-response reads, a dashboard querying a controller. PubSub suits fan-out and scale, one machine's data flowing to many systems at once, often over lightweight transports like MQTT or over UDP.

The practical read: client-server for tight, interactive links; PubSub when you need to move a lot of tag data to a lot of places efficiently. Many modern architectures use OPC UA to model and secure the data and MQTT as the lightweight pipe that carries it up from edge to platform, the two are partners, not rivals, which we come back to at the end.

How does OPC UA handle security?

Security is built into OPC UA rather than added later. It provides authentication (proving who a client and server are, using X.509 certificates), authorization (controlling what an authenticated party may do), encryption (so data cannot be read in transit), and message integrity (so data cannot be tampered with unnoticed). Administrators choose a security policy, from none, for isolated test benches, up to strong modern encryption for anything touching a real network.

That built-in security is a large part of why OPC UA is trusted to move control-adjacent data. But it is not automatic: a plant still has to turn it on, manage certificates, and segment its networks so OPC UA endpoints are not needlessly exposed. Treat OPC UA security as one layer inside a broader industrial-security discipline, aligned with standards like ISA/IEC 62443, not as a reason to skip network segmentation. The PLCs underneath were never designed to face the open internet, and OPC UA does not change that.

How do you get OPC UA data into a unified operational layer?

Having OPC UA on the floor is not the finish line, it is a clean on-ramp. Getting that data into a system that does something useful with it follows a repeatable path.

Inventory what already speaks OPC UA. Newer controllers and SCADA systems often have an OPC UA server built in. Find those first; they are free connectivity you already paid for.
Add an edge gateway for what does not. Older or proprietary equipment gets an edge device that reads its native protocol and re-exposes the data as OPC UA, no change to control logic.
Model the data with meaning. Use companion specifications or your own information model so tags arrive self-describing, not as a wall of cryptic addresses.
Turn on security deliberately. Certificates, encryption, and a chosen security policy, configured on purpose, not left at defaults.
Carry it up efficiently. Use PubSub or MQTT from edge to platform where you are fanning data out to many consumers at scale.
Contextualize and act. Land the data in a layer that ties each reading to a machine, order, and shift, then puts it in front of people and closes the loop with approval-gated action.

This is the "no rip-and-replace" path: OPC UA lets you get the data out cleanly, and a unified operational layer turns it into visibility and action across machines, systems, and paperwork (how Harmony connects your floor). When CLS built its real-time platform, the point was never the protocol for its own sake, it was getting trustworthy floor data into automated reporting the whole plant could use (the CLS case study).

What do the standards say?

OPC UA is developed and maintained by the OPC Foundation an industry consortium, and is the successor to the original OPC ("OLE for Process Control") specifications (OPC Foundation).
OPC UA is an international standard, published as IEC 62541 which is why it is treated as a stable, vendor-neutral foundation rather than one company's format (IEC 62541).
Its information modeling carrying data type, units, relationships, and methods with each value, is the feature that distinguishes it from simple value-passing protocols (OPC Foundation).
OPC UA data typically feeds systems standardized around ISA-95 / IEC 62264 the enterprise-control integration model that governs how floor data reaches business systems (ISA-95).

Where does OPC UA fit next to MQTT?

They do different jobs and work best together. OPC UA is strongest at modeling and securing industrial data, describing what each value means and proving who may access it. MQTT is a lightweight publish-subscribe transport that excels at moving many small messages over unreliable networks cheaply. A common, sound architecture uses OPC UA to structure and secure the data at the source and MQTT to carry it from edge gateways up to a platform, sometimes as OPC UA PubSub running over MQTT. You do not have to choose a winner. Get the data modeled well with OPC UA, move it efficiently, and land it in a layer that contextualizes and acts, the same message as the IIoT stack and the MES layer that sit alongside it.