Modbus or OPC UA? Differences and when to use each

Modbus in brief

Modbus was born in 1979 for Modicon controllers and, thanks to its simplicity, has remained the language of meters, power analysers, drives and instruments of every make. It works by request and response: a client (in the original terminology, the master) asks a server (the slave) for a value and receives it. Over Ethernet it is Modbus TCP, on port 502; over an RS-485 serial line it is Modbus RTU.

The data model is a table of four blocks, with no names and no types: the data are only bits and 16-bit registers, identified by an address.

There are three practical consequences. First, a 32-bit or floating-point value takes two registers, and the word and byte order is not fixed by the specification: each manufacturer chooses, and the instrument's manual is the only source. Second, a value with decimals is usually a scaled integer (energy in tenths of a kWh), and the factor is again in the manual. Third, the addresses in manuals sometimes use a numbering that starts at 1 with a prefix (such as 40001 for the first holding register), while on the wire the address starts at 0: the most common commissioning mistake is an off-by-one.

Modbus has no native security: it does not authenticate the requester and does not encrypt, and anyone who can reach port 502 can read and, where allowed, write. A variant with TLS exists (Modbus/TCP Security, port 802), little used on devices. It has no subscriptions: whoever wants the updated value must request it at intervals (polling), and the data carries neither a measurement time nor a quality flag.

OPC UA in brief

OPC UA (standard IEC 62541) is a client-server architecture, not a simple list of registers. The server exposes an address space: a tree of nodes (objects, variables, methods) that the client can explore, called browsing, without a manual. Each node has an identifier (a namespace index and a name or number), a data type and attributes: engineering unit, range, description.

A value read carries its type, the source timestamp and a quality code: a stale reading or one without a sensor is told apart from a real zero. Clients can also call methods, for instance to start a recipe, and companion specifications define standard models for whole families of machines.

To receive data there is no need to poll continuously: the client creates a subscription on one or more nodes (monitored items), says how often the server should sample and an optional change threshold (deadband), and the server sends values only when they change. The server usually listens on port 4840 (address opc.tcp://host:4840), although many products use another; discovery services can be used to find servers.

Security is in the protocol. You choose a security policy (for example Basic256Sha256 or Aes128_Sha256_RsaOaep; the older ones, such as Basic128Rsa15, are deprecated) and a message mode: none, signed, or signed and encrypted. Client and server recognise each other with X.509 certificates that the administrator must approve, and the user can authenticate with name and password or with a certificate. It takes more configuring than Modbus, but it is the most complete of the three as regards channel protection.

Comparison table (data, security, discovery, cost)

What about Siemens S7 PLCs?

Siemens PLCs speak S7comm, a proprietary protocol over TCP, encapsulated in the ISO-on-TCP standard, on port 102. A client (a library, a gateway or a system such as Muvia Industrial) reads and writes portions of the PLC's memory by giving the area, the address and the length: a data block (DB), inputs, outputs, markers.

On S7-1200 and S7-1500 PLCs this kind of access is disabled by default, for security reasons: in the CPU properties you must enable permission for access with PUT/GET communication from a remote partner, and the data blocks accessed by address must have optimised block access turned off, otherwise the data offset is not fixed. They are settings of the PLC program, so they must be agreed with whoever wrote it.

The alternative, where it exists, is OPC UA: S7-1500 CPUs have an integrated OPC UA server; for the other families it depends on the model, the firmware and the licence. An OPC UA server exposes variables by name and does not force you to know the data blocks' offsets. If the PLC does not have one, S7 by address remains the practical channel.

Do you need a gateway?

A gateway is needed when the protocol the machine speaks is not one the downstream system can read. The typical cases:

• Serial line: an instrument on Modbus RTU over RS-485 has no Ethernet port. An RTU-to-TCP converter makes it reachable over Modbus TCP, and Muvia Industrial's drivers read Modbus only over TCP networks.
• Protocol not available: a machine that speaks only its own fieldbus or a proprietary protocol is connected with a gateway that exposes it over Modbus TCP or OPC UA.
• Network security: an OPC UA server or a gateway at the right network level avoids opening the PLCs' ports 502 and 102 to the whole plant network. The PLC talks to the gateway, and the corporate network only to the gateway.
• One port for many machines: collecting the data of several PLCs in one OPC UA server and reading only that.

You do not need a gateway if the machine already has an Ethernet port with one of the protocols the system reads. Before buying anything, get the machine's engineer to confirm which interface it exposes and how it is enabled: often it is already there, and it only needs switching on.

MQTT: where it fits

MQTT is not a competitor of Modbus and OPC UA, but something else: a lightweight message transport with the publish/subscribe model. Devices publish to a topic and a broker distributes the messages to subscribers; there are three levels of delivery guarantee (QoS 0, 1 and 2) and the usual ports are 1883 and 8883, with TLS. MQTT does not say what is inside the message: to give it an industrial meaning there are specifications such as Sparkplug B, and OPC UA PubSub can also travel over MQTT.

Its place is more often upstream than at the machine: it carries data from a site to a central system, over slow or unstable links. From the PLC to the collection node, inside the plant, the protocols are still the ones in this guide. Muvia Industrial's drivers are Siemens S7, OPC UA, Modbus TCP, SQL Server tables and SEW-Eurodrive: a machine that only publishes over MQTT is connected by interposing a gateway that exposes it over one of these.

From the machine to the dashboard

Whatever the protocol, the path is the same, in five steps:

• Choose the interface the machine exposes, with the engineer who knows it, and enable it (PUT/GET, OPC UA server, Modbus port).
• List the variables you need, with address or node, type, scale and unit. Few and useful: part counter, state, downtime reason, a couple of temperatures and pressures.
• Give each a readable, stable tag name, one that survives a PLC replacement.
• Choose how to read: at regular intervals, or by subscription where the protocol has it, at the interval you really need (reading every second what changes every hour only wastes resources).
• Bring the data where it is used: dashboards, alarms, calculations, reports.

With Muvia Industrial the drivers run on the node near the machines, read the variables you choose and turn them into named tags; if the link to the cloud drops, the node keeps the data in a local buffer. Where the protocol allows it you can also write (Siemens S7 and OPC UA), and a simulator lets you build dashboards and alarms before connecting the line. The data then arrives in the same Muvia sources as ERP and CRM, to cross what the machine does with orders and items. An example path is the use case on connected machines for manufacturers; the quantities you derive are covered in the guide to production KPIs.