What Is OPC UA? How It Works and How It Differs from Modbus

A new machine arrives with a spec sheet that lists "OPC UA server". Next to it, older power meters and PLCs still speak Modbus. The engineering team asks: should we use OPC UA, and how does its data reach the dashboards management looks at?

So what is OPC UA? It is an open standard for exchanging data between machines, controllers, and industrial software. Unlike older protocols, it carries not just a number but its meaning: name, unit, data type, timestamp, and quality. This guide covers how it works, how it differs from Modbus, when a plant needs it, and how a system integrator usually bridges it to an IoT platform.

What is OPC UA

OPC UA (Open Platform Communications Unified Architecture) is a machine communication protocol developed by an industry consortium and standardised as the IEC 62541 series. It succeeds the earlier generation, often called OPC Classic, which was tied to one operating system and to DCOM, a technology that struggles to pass through firewalls.

OPC UA is independent of operating system and programming language, so a server can run inside a PLC, an industrial PC, or a SCADA server. Many newer machines include one as standard.

How OPC UA works

• Information model. Data on a server is a tree of nodes: objects, variables, and methods. For example, Extruder1/Zone2/Temperature holds 215.4 with the unit °C, a range, a timestamp, and a quality status. A client can browse the tree instead of guessing what a register address means.
• Client and server. The software that needs data, such as SCADA or a gateway, acts as a client and connects to the server on the machine. The address looks like opc.tcp://ip-address:4840. Port 4840 is the registered default, though many servers use others.
• Subscriptions. Instead of polling every value, a client subscribes to selected variables, and the server sends only changes, per the requested sampling interval and deadband.
• Built-in security. Every application has an X.509 certificate. Messages can be sent with no security, signed, or signed and encrypted. Users can also authenticate with a username and password or a certificate.
• PubSub. Newer versions add publish/subscribe (part 14 of the standard) over MQTT or UDP, though fewer devices support it so far.

Some machine types also have standard information models, called companion specifications, so similar machines from different makers present data the same way.

OPC UA vs Modbus

Aspect	Modbus	OPC UA
Data	Raw numbers in registers; the meaning lives in the maker's manual	Named variables with data type, unit, timestamp, and quality
Finding data	Needs a register map	Can be browsed on the server
Communication	Polled at intervals	Client and server with subscriptions, plus PubSub
Security	No built-in authentication	Certificates, signing, encryption, user authentication
Medium	RS-485 (RTU) or Ethernet (TCP)	IP networks only; not over RS-485
Typical devices	Power meters, sensors, inverters, older PLCs	Newer PLCs, CNC and packaging machines, SCADA servers
Implementation weight	Light, fine for small devices	Heavier: certificates, configuration, memory

Neither replaces the other. A typical plant runs both: Modbus for meters and sensors, OPC UA for machines and controllers with lots of structured data. The difference between the two Modbus variants is covered in Modbus RTU vs Modbus TCP.

When a plant needs OPC UA

• The machine or PLC already has an OPC UA server. Using it is cleaner than mapping hundreds of registers. Check that it is enabled; on some controllers the feature has to be switched on or licensed separately.
• Each machine has a lot of structured data, such as states, recipes, part counters, and alarm codes, where mapping registers by hand invites mistakes.
• A line mixes machines from many makers, and several systems need the data at once, for example SCADA, an MES (manufacturing execution system), and an IoT platform.
• Data crosses network boundaries, so authentication and encryption matter.

For a few readings from power meters or sensors, Modbus is enough. There is no need to buy new hardware just for OPC UA.

How OPC UA is bridged to an IoT platform

Cloud IoT platforms usually take data over MQTT or HTTP, while OPC UA servers sit on the production network. A system integrator usually bridges the two like this:

1. Inventory. List every OPC UA server (machines, PLCs, SCADA servers), its endpoint, its security policy, and the nodes you actually need.
2. An OPC UA client on the plant network. An industrial PC, a protocol converter, or a SCADA server that already collects the data acts as the client and subscribes to the selected nodes.
3. Mapping. Nodes get consistent names and units, with sensible sampling intervals and deadbands. Send the few dozen variables people use, not thousands.
4. Send outward over MQTT or HTTP. The connection opens from inside the plant, so no port is opened from the internet into the production network. The bridging device should buffer data if the internet drops.
5. Secure it. Exchange certificates between client and server, use signing and encryption, give the client a read-only account, and keep OT and IT networks separated. The principles are covered in OT and industrial IoT cybersecurity.
6. Test end to end. Compare dashboard values with the machine HMI, then check what happens when the connection drops and comes back.

Things to keep in mind

• OPC UA is not automatically plug and play. Certificates expire and must be trusted on both sides; an expired one is a common reason a working connection suddenly fails.
• Support varies by device. Check subscriptions, security policies, and session limits. Controllers often cap the number of clients, and each extra client adds load to the PLC.
• Limit write access. Setpoint changes should still go through the control system and its procedures.
• Very fast data does not belong in the cloud. Summarise millisecond signals on site and send averages, peaks, or events.

Frequently asked questions

Is OPC UA secure out of the box?

Only when configured that way. Some servers still allow the no-security mode or anonymous access. Use signing and encryption, turn off anonymous access, and give monitoring clients read-only rights.

How is OPC UA different from MQTT?

MQTT is a lightweight messaging protocol that passes messages through a broker, with no built-in data model. OPC UA defines the information model, services, and security. They work together well: data is read over OPC UA and sent to the cloud over MQTT. See what MQTT is.

Can IncludeGateways read OPC UA?

Not directly. IncludeGateways reads Modbus RTU devices. For machines with OPC UA, the bridge is an OPC UA client on the plant network that forwards data to the INCLUDE platform over MQTT or HTTP. The hardware and scope are settled during the site survey.

What should we prepare before an OPC UA integration?

A list of machines with an OPC UA server and their addresses, whether the feature is enabled or licensed, security settings, a network diagram, and an OT contact who can approve certificates and network changes.

OPC UA integration with INCLUDE

The INCLUDE platform takes data over MQTT and HTTP and turns it into dashboards, history, and alarms. Connecting machines to it is the job of our industrial automation and system integration service: a survey of every machine, controller, protocol, and network; a design for the data path; phased integration starting with one line, without stopping production; then end-to-end testing and a documented handover.

Sources are often mixed: OPC UA machines through an OPC UA client, Modbus RTU meters and PLCs through IncludeGateways, and machines with no data output through IncludeBox wireless sensors, all on one platform.