OPC UA (OPC Unified Architecture) is an open, platform-independent standard for exchanging industrial data securely, with the meaning of the data built in. Instead of reading register 40001 and hoping it is a temperature, an OPC UA client browses a server and finds an object called, say, Pump_101 with a property Temperature in degrees Celsius. That self-describing structure is why it has become the default interface between PLCs, SCADA, MES, historians and cloud platforms.
The OPC Foundation released OPC UA in 2008 as a service-oriented architecture that merged the older OPC Classic specifications. It is also published as the IEC 62541 series; IEC TR 62541-1 gives the overview and concepts.
How OPC UA works: the four ideas that matter
1. Information modelling
Data is organised as objects with variables, methods and events, linked by typed references. A server can describe a whole machine, not just a list of tags. This is the feature the OPC Foundation calls fundamental to the architecture, and it is what makes data reusable across systems.
2. Security by design
OPC UA supports encrypted sessions, signed messages, X.509 certificates for applications and user authentication. These are options, though: a server left in 'None' security mode is as open as Modbus. Specify the security policy and certificate handling in every project.
3. Client-server and publish-subscribe
Client-server suits HMIs, SCADA and engineering tools that request data or call methods. Publish-subscribe (PubSub) suits many-to-many distribution, over UDP on the plant network or over MQTT to brokers and cloud services. Many architectures use both.
4. Companion specifications
Industry groups define standard information models for their equipment, for example machine tools, robotics, packaging machines and process instruments. The OPC Foundation lists more than 150 companion specifications. If your equipment has one, you can integrate machines from different vendors with the same client code.
What is OPC? UA in a Minute
TheOPCFoundation
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeOPC UA vs Modbus vs MQTT
| OPC UA | Modbus TCP | MQTT | |
|---|---|---|---|
| Data meaning | Built in (information model) | None (registers only) | Up to the payload design |
| Security | Certificates, encryption, user auth | None in the base protocol | TLS and broker auth |
| Pattern | Client-server and PubSub | Master-slave polling | Publish-subscribe via broker |
| Best for | PLC to SCADA/MES, multi-vendor plants | Simple devices, meters, legacy kit | Cloud and IT integration at scale |
In practice these complement each other. A common pattern is fieldbus or Modbus at device level, OPC UA from controllers to plant systems, and MQTT, sometimes carrying OPC UA PubSub messages, to the cloud. For machine tools, MTConnect is another widely used standard and can be mapped to OPC UA.
Where OPC UA fits in a plant architecture
- Inside the controller. Siemens S7-1500, Beckhoff TwinCAT, CODESYS-based controllers and many others include an OPC UA server.
- At the edge. An edge gateway aggregates several PLCs and publishes a clean model upwards.
- In SCADA and MES. Ignition, WinCC and most MES platforms act as OPC UA clients.
- In digital twins. A twin needs a stable, well-described data source; OPC UA is often the cleanest one. See digital twin vs simulation.
How to specify OPC UA in a project
- State which companion specification applies, if any, and require the supplier to implement it.
- Define the minimum security policy, how certificates are issued, renewed and trusted, and who holds them.
- Limit exposed nodes to what clients need; do not publish the whole PLC memory.
- Set naming rules for custom objects so models are consistent across machines.
- Agree performance: sampling and publishing intervals, number of monitored items, client sessions.
- Place servers in the right network zone; see our IEC 62443 guide.
A worked example: one packaging line, five suppliers
Picture a line with a filler, capper, labeller, case packer and palletiser from five different builders. Without a plan, each arrives with its own tag names and its own idea of what 'running' means, and the integrator spends weeks mapping signals for the line SCADA and OEE system. With OPC UA specified up front, the picture changes:
- Each machine exposes an OPC UA server using an agreed state model, for example PackML-style states
- Counters, reject reasons and alarms follow one naming convention written into the purchase specification
- Line SCADA and the OEE system connect as clients and browse each machine the same way
- Security policy and certificates are set at FAT, not left for later
- Adding a sixth machine later means connecting a client, not writing new mapping logic
The cost is a few extra pages in each purchase specification and some discipline at FAT. The saving shows up at every integration, upgrade and analytics project for the life of the line.
Using OPC UA for analytics and AI
Predictive maintenance, energy analytics and machine-learning models all need consistent, contextualised data. OPC UA's information models provide that context at the source, so data scientists spend less time guessing what a tag means. It is one of the first things we check when a client asks about predictive maintenance sensors or an operational twin.
Wartens designs data architectures that connect PLCs, SCADA and analytics, and builds the twins and AI tools that use them. Explore our industrial AI service and automation engineering, or ask us about your plant's data.
