What is OPC UA?
The IEC 62541 standard for exchanging factory data along with its meaning, not just raw numeric values.
OPC UA (OPC Unified Architecture, where OPC today stands for Open Platform Communications) is the open standard, defined in the IEC 62541 series, through which machines, PLCs and factory systems exchange data in a way that is interoperable and independent of platform and vendor. The difference that matters is the information model: OPC UA does not just transmit a numeric value, it also transmits what that value represents, its unit of measure and which asset it belongs to, through nodes organized in an address space and companion specifications for entire industries. It defines two communication models: client/server, with requests over TCP, HTTPS or WebSockets, and publish/subscribe, introduced in Part 14 of the specification and mapped onto MQTT, AMQP or UDP. In both, security is built into the protocol (authentication, encryption, message signing) rather than bolted on afterward. It replaces OPC Classic (DA, A&E and HDA), the earlier generation built on Microsoft's COM/DCOM, tied to Windows and lacking a comparable information model.
Meaning travels with the data
A transport-only protocol such as MQTT or Modbus delivers bytes: it is up to the receiver to know, by external agreement or documentation, that a given number is a temperature in Celsius from sensor 7 on line 3. OPC UA embeds that semantics into the model itself, through node types, relationships and, for entire industries, companion specifications that define a shared vocabulary (for machine tools or robotics, for example). The practical benefit for anyone building a factory-floor data ingestion pipeline is that data arrives already described: there is no need for manual, machine-by-machine and field-by-field mapping just to understand what is being ingested. It is also why OPC UA is the reference protocol cited inside IIoT architectures: it provides the semantic layer that IIoT, as a sensor and connectivity infrastructure, assumes but does not define on its own.
An enterprise example
An Italian manufacturing SMB with production lines from different vendors (a German CNC lathe, a Japanese welding robot, an Italian vision system) installs OPC UA servers on each machine, often already shipped by the manufacturer. A single OPC UA client on the IT side reads every line with the same protocol and the same information model, instead of writing a separate connector for every brand and firmware version. The collected data feeds both OEE reporting and a digital twin of the line, and the base for a predictive maintenance model arrives already contextualized: it knows which asset, which machine cycle and which unit of measure each time series refers to, without the data team having to reconstruct it by hand.
Why it matters to decision makers
Whoever has to bring factory data into a data platform or an industrial AI project spends most of the time, in practice, understanding what the machines' raw data means rather than building models. OPC UA cuts that upfront interpretation work because meaning is already part of the protocol, not an integration to redo for every vendor. It is also a concrete procurement criterion: requiring OPC UA in the tender for a new machine avoids inheriting, for years, a proprietary data island that will have to be translated separately. One layer down, on the control logic, the criterion applies in a weaker form: requiring the PLC to be programmed to IEC 61131-3 does not make the code transferable to another supplier, but it does make it readable to someone who did not write it.
Related terms
- Unified Namespace (UNS) · The single event-driven hierarchical structure where every plant system publishes its current state.
- IIoT (Industrial IoT) · The network of connected sensors and machines generating a plant's raw data: the source layer every industrial AI story is built on.
- IEC 61131-3 · The standard defining the PLC languages, but not the development environment: code is not as portable as it promises.
- Digital twin · A digital representation of a plant or process, updated in real time from data: an integration problem, not a CAD problem.
- Predictive maintenance · Predicting a failure before it happens by analyzing sensor data: a data pipeline and modeling story, not a robotics one.
A term that hits close to home? Let's talk.
CONTACT ME