Modbus gives you numbered registers and nothing else. OPC UA gives you named, typed values with a timestamp, a quality code and security attached. Modbus is the easier protocol to start with and OPC UA is the richer one, and a lot of plants use both.
If you manage a plant or buy systems rather than configure them, the question is usually "what will we be able to trust, and what will it cost to set up?" The sections below answer both. Engineers can skip to the table.
What Modbus gives you
Modbus exposes a device as four tables of numbered coils and registers. Reading holding register 100 returns a 16-bit number. The protocol does not say what that number means: not the tag name, the engineering unit, the scale factor, or whether it is a signed integer, half of a 32-bit float or a bit field. That lives in the device's manual, and someone has to copy it into the SCADA configuration by hand. The details of the two Modbus variants are in Modbus TCP vs RTU.
There is also no timestamp and no quality. A register that returns 0 might mean zero flow or a dead sensor, and the protocol cannot tell you which. Data moves by polling: the client asks every cycle, whether or not anything changed. And there is no security. Anyone who can reach the device can read and write it.
In return, Modbus is nearly universal. Drives, power meters, flow computers, temperature controllers and a long tail of third-party equipment speak it, on serial or Ethernet. A device can be reading in minutes with a register map and a cable.
What OPC UA gives you
OPC UA is a family of specifications standardised as IEC 62541. Where Modbus gives you a table, OPC UA gives you an address space: a browsable tree of nodes with names, data types and relationships. A client can connect, browse to Pumps/P101/Discharge Pressure, see that it is a floating-point value in a stated unit, and read it without a register map.
Four things set it apart:
- Subscriptions. A client creates monitored items, and the server reports a value when it changes by more than a deadband or at a set interval. The client does not poll. Traffic follows the process instead of the clock, which matters on slow or metered links.
- Timestamp and status on every value. Each value arrives with a source timestamp and a status code, so a bad sensor reads as bad, not as a plausible zero.
- Security built in. Applications identify themselves with certificates. Messages can be signed, or signed and encrypted, under a named security policy, and users can authenticate with a username and password or a certificate.
- Structure. Nodes can be grouped into objects with typed members, such as a pump with a status, a speed and a fault flag, so a client can read a whole object and not scattered registers.
The default port for the opc.tcp protocol is 4840, though a server can use any port and publishes its endpoint URL.
The cost is setup
OPC UA takes more steps to set up than Modbus. Server and client each hold a certificate, and each side has to trust the other's before the connection is accepted. The endpoint's URL, security policy and security mode must match what both sides support. User credentials, firewall rules for the port and clock accuracy (certificates have validity dates) all need attention. A small device needs more memory and processing to host a server. That is why you meet OPC UA on newer controllers and gateways, and rarely on a 15-year-old power meter.
Side by side
| Modbus | OPC UA | |
|---|---|---|
| Data model | Numbered coils and registers | Browsable address space of named, typed nodes |
| Names, types, units | Not in the protocol | In the address space |
| How data moves | Client polls | Subscriptions report on change, or polling |
| Timestamp and quality | None | On every value |
| Security | None | Certificates, signing, encryption, user authentication |
| Transport | Serial (RTU) or Ethernet (TCP, port 502) | Ethernet (opc.tcp, default port 4840) |
| Standard | Modbus Organization specifications | IEC 62541 |
| Setup effort | Low: addresses and a cable | Higher: certificates, endpoints, security policy |
| Device support | Very wide, including old equipment | Newer controllers, gateways and software servers |
When Modbus is the right choice
- Simple devices. Drives, power meters, temperature controllers and similar devices expose a few dozen registers. The overhead of a full information model buys little.
- Serial links. RS-485 trunks run Modbus RTU. OPC UA does not run on a serial line.
- Legacy equipment. If the device is already installed and only speaks Modbus, that settles it.
- A network you control. On an isolated segment with a firewall in front, the lack of security is a lower risk, though it is still a risk.
When OPC UA is the right choice
- PLC to SCADA with structured data. If the controller has a tag structure, an OPC UA server lets the SCADA system browse it instead of retyping every address.
- Crossing network zones. When data has to pass between a control network and a business network, you want authentication and encryption on the link. IEC 62443 is the series of standards most security programs follow for this.
- System to system. Connecting a SCADA server to a historian, an MES or another SCADA system is easier when both sides share one vendor-neutral standard.
- Anything where quality matters. If the receiving side must know whether a value is good, stale or substituted, quality codes and timestamps are the answer.
They are not rivals at the device level
The choice is rarely one or the other across a whole plant. A common shape is a gateway that polls a set of Modbus devices on the plant floor and serves the same values upward as OPC UA nodes. The devices stay simple, and everything above the gateway gets names, types, timestamps, quality and security. The gateway carries the work of mapping register 40001 to Pumps/P101/Discharge Pressure, with a scale factor, once, in one place.
If you build this, check two things. First, the quality the gateway reports. If a Modbus device stops answering, the OPC UA value should go bad and not hold the last number as good. Second, the polling rate: subscriptions make the upstream side efficient, but the gateway still polls the Modbus devices, and on a serial trunk the baud rate sets how fast.
For where both fit in a larger system, see What is SCADA?.
Where Raylux fits
Raylux's gateway, Nexus, is both an OPC UA client and an OPC UA server, and OPC UA and the Modbus drivers are included in the base licence with no per-driver charge. See the OPC UA and Modbus compatibility pages and the Nexus page.
Frequently asked questions
Is OPC UA better than Modbus?
It carries more: names, data types, timestamps, quality and security. That does not make it the better choice for every link. Modbus is simpler, runs on almost every device, and is easy to troubleshoot. OPC UA fits best where the receiving system needs structured data, security or change-based reporting.
Can OPC UA replace Modbus?
At the system level it often does. At the device level it usually does not, because many meters, drives and small controllers only speak Modbus. A common design has a gateway that polls those devices over Modbus and offers the same values upward over OPC UA.
What port does OPC UA use?
The default port for the opc.tcp protocol is 4840. A server can listen on any port, so the endpoint URL in the server's settings is the real answer. Modbus TCP uses port 502.
Is OPC UA secure by default?
It has security built in: application certificates, message signing and encryption, and user authentication. A server can also offer an endpoint with no security at all, which is easy to leave switched on during testing. Check which security policy and mode each endpoint uses.
Do I need OPC UA to use Modbus data in SCADA?
No. A SCADA driver can read Modbus devices directly. OPC UA becomes useful when a second system also needs those values, or when the link crosses a network boundary where you want encryption and authentication.