Modbus

What is Modbus?

Modbus history

The first Modbus protocol – Modbus RTU (Remote Terminal Unit) – was originally published by Modicon (now Schneider Electric) systems in 1979 as a programming protocol for use with its PLCs. Modbus is an open protocol but the word "Modbus” is a registered trademark of Schneider Electric.

Modbus RTU is a simple serial communication protocol. Over time, there was a growing need for a standard that allowed more complex implementations using popular transport protocols like Transmission Control Protocol/Internet Protocol (TCP/IP) and User Datagram Protocol (UDP). Developed in 1999, the Modbus variant addressed this need.

What kinds of devices support Modbus?

Examples of Modbus devices include HMI hardware, I/O interfaces and modules, sensors, modems, device controllers, PLCs, network gateways, network host adapters, AC/DC inverters, RTUs, SCADA hardware, software device drivers, smart home devices, routers, etc. The majority of real-world implementations of Modbus are for devices that transfer small amounts of data at a time in scenarios where speed is not a critical requirement, for example monitoring temperature.   

Modbus variants

There are several variants of Modbus; variants rather than versions as they are not interoperable on the same network segment and have different uses.

Modbus RTU

Modbus RTU is the most common variant and is used for serial connections.

There are two types of Modbus serial connections, Modbus RTU and Modbus ASCII. For convenience, Modbus RTU and Modbus ASCII are usually referred to generically as Modbus RTU, grouped as the variants that use serial cables.

With Modbus RTU, data is transmitted in binary. With Modbus ASCII, data is presented as readable ASCII. Binary messages are shorter than ASCII and theoretically faster to transmit and receive, while ASCII messages have the advantage of being easily monitored by administrators.

An important difference for developers is that Modbus RTU messages do not have start-of-text tokens. Instead, the receiving device in a transaction listens for a "silent" period to determine the start of a new message. ASCII messages do have start-of-text tokens.

Serial connections like Modbus RTU and Modbus ASCII are point-to-point (P2P) connections. P2P provides a channel of communication between two ports, and transactions are initiated only by the client device. Point-to-point is not to be confused with peer-to-peer communication, which is a connection that allows both devices to initiate communication. An example of a common P2P connection is the use of a USB drive.

In contrast to Modbus TCP, Modbus RTU can only have one client device and up to 247 server devices, depending on the physical signal standard used, and a separate port is required for each device.

Serial connections that use serial cables are simpler to set up than Ethernet connections where a network card and some software must be installed, and IP addresses must be configured.

Types of serial connections in Modbus RTU

In Modbus RTU networks, messages are transmitted according to EIA-approved RS-485, RS-422, or RS-232 physical signal standards that define the electrical characteristics of drivers and receivers used in serial communications. EIA stands for the Electronic Industries Alliance and RS stands for recommended standard. Other standards may be used but these are the most common standards. The EIA standards are physical layer interfaces that use communication converter chips to convert the way that signals are transmitted to and from different types of devices. Data rate, driver load, maximum driver output voltage, baud rate, etc. all differ between the three standards. Sometimes, Modbus implementations are referred to by the type of interface they use, for example Modbus RS-232 or Modbus RS-485.

RS-232, used with the first version of Modbus, is slow with a maximum data rate of 20 kilobytes per second, only allows cables up to 50 feet in length, and is limited to connecting one client and one server device. However, RS-232 is still used, for instance, with older printers or as an inexpensive way to connect PLCs to other devices that use RS-232. There are two types of RS-232-enabled devices: data terminal equipment (DTE) devices, for example PCs, and data communications equipment (DCE) devices, for example modems. For two of the same types of these devices to communicate, they are connected using a reverse RS-232 cable connection.

Modern systems require that Modbus can support the connection of multiple server devices, facilitate faster data transfers, and provide data transfers over greater distances. To do this, RS-485 and RS-422 were used. RS-485 and RS-422 (less commonly used) facilitate the use of multidrop wiring methods (connecting multiple server devices to client devices), extend the range of transmissions to up to 4000 feet before a repeater is needed, and have a data rate of 10 megabits per second (Mbps) up to 100 kilobits per second.

Without a repeater, RS-485 is configured with one trunk cable, the bus, along which devices are daisy chained. RS-485 can multidrop up to 32 client devices. It has the added benefit of providing better noise immunity than the original RS-232 standard. Up to 256 server devices can be added to an RS-485 network segment using repeaters. RS-485 can be full duplex (4-wire mode) or half duplex (2-wire mode).

Modbus TCP

Modbus TCP – sometimes called Modbus Ethernet – is an industrial Ethernet protocol that uses TCP/IP at the transport layer. It is used to create a multipoint network where a single client device may communicate with multiple server devices over a physical Ethernet layer. With Modbus TCP, a message is wrapped in a TCP packet, which is then wrapped in an IP packet, which uses Ethernet electrical signaling to transmit the package. The main function of TCP is to ensure that data packets are correctly received, while IP ensures that messages are correctly addressed and routed.

There are two types of Modbus Ethernet connections. Modbus TCP and Modbus over TCP variants are usually referred to generically as Modbus TCP. Modbus TCP is a Modbus TCP packet in a TCP wrapping, while Modbus over TCP is a Modbus RTU packet in a TCP wrapping. Strictly speaking, the latter could be called Modbus RTU over TCP, but it is grouped with Modbus TCP because it uses Ethernet.

An Ethernet connection is faster than a serial connection although speed is not usually a critical requirement for the functioning of many Modbus devices, like reporting temperatures. It is also more reliable and allows the transmission of data over longer distances.

In contrast to Modbus RTU, Modbus TCP allows multiple devices to use a single network port and messages to include a 7-byte header, which is called a Modbus application protocol (MBAP) header. The MBAP header identifies the Modbus Application Data Unit (ADU) that is used, which itself is used to identify the transport protocol to be used. Modbus TCP allows the concurrent connection of thousands of server devices and supports multiple client devices in a network.

There are other variants to the original Modbus protocol that were developed for specific use cases. Pemex Modbus and Enron Modbus were developed to support historical and event flow data in the oil, gas, and petroleum industries. Enron Modbus natively supports 32-bit integers and floating-point variables.

Secure Modbus

The Modbus Security protocol was published in 2018 to implement some security features without making any changes to the original specification.  

Secure Modbus uses Transport Layer Security (TLS). It provides certificate-based authorization that uses role information that is transferred via certificate extensions. Authorization is product specific and invoked by the Modbus function code handler. It also provides certificate-based authentication.

Modbus Plus

Modbus Plus, a high-speed token-passing network protocol, is proprietary to Schneider Electric and is not a Modbus variant; proprietary cabling and terminators must be used. With Modbus Plus, the main message structure is peer-to-peer but Modbus Plus can also function on P2P and multidrop networks. Modbus Plus requires a dedicated coprocessor and uses a twisted pair at 1 Mbps. It is transition triggered rather than voltage triggered like the Modbus variants. 

How does Modbus work?

 
Serial connections

Each server device is preassigned a unique ID. When a client requests data from a server device, it uses the first byte of the message to identify which server device should respond.

The Modbus message structure uses an ADU/PDU frame. The protocol data unit (PDU) is independent of the underlying communication layers. The ADU includes the address of the server device, the PDU, and a checksum field. The PDU includes a function code with a read or write command, and any data, where relevant. The ADU determines the beginning and end of a request frame so a receiving device will always know when a message has started and when it has been completed. Frame formats are not interoperable between variants.

Information about the data that is requested by a client device is stored on server devices in up to four tables. Two tables store on/off discrete values (coils) and two tables store numeric values (registers). There is a read-only table for inputs and a read-write table for outputs for both coils and registers. Tables are navigated on a server device using a Modbus map that defines what the data is, where it is stored, and in what format it is stored.

Information about offsets is also specified in the Modbus map. Data addresses on a Modbus server device are each assigned a number between 1 and 10000. However, data addresses in the messages themselves use numbers between 0 and 9999. This means that an offset must be subtracted from the address on a device before using it in a message. Device manufacturers may specify the offsets their products use.

Data models may vary from one device to another depending on what is needed, for example a particular device may only store discrete inputs.

Modbus only transmits two data types. Registers are 16-bit unsigned integers that are used to store analog inputs and outputs. Coils are single binary bits and can represent a state of either ON or OFF. There is no representation for negative values and floating point numbers. Negative integers are transmitted using two's complement format. There are a few workarounds to transmit floating points, for example rounding a fraction up or down, or transmitting it in two registers, that is, using two registers to emulate a 32-bit data type. Modbus specifies how many registers need to be read or written and, according to the specification, “uses a 'big-endian' representation for addresses and data items. This means that when a numerical quantity larger than a single byte is transmitted, the most significant byte is sent first.” Some device manufacturers use a ‘little-endian’ representation. Either method works if both client and server devices use the same method.

Modbus provides services that are specified by function codes. When a client device communicates with a server device, the second byte of the message contains a function code that tells the server device which table to access and what to do, for example to retrieve some data for the client device or to write some data sent by the client device.

Function codes include public, user, and reserved codes. Public function codes are publicly documented and validated by the MODBUS.org community, user-defined function codes are custom codes, and reserved codes are reserved for specific legacy implementations and are not available for public use.

For every message, a cyclic redundancy check (CRC) is performed. A CRC is an error-detecting code that is used to detect accidental changes to the data being transmitted. It is calculated before a transmission begins and again when a message is received. Two bytes in every message are used to store this value with Modbus.

Messages also include information about the number of data bits to be read or written, the number of registers to read or write, and the total number of bits of data in the request or response.

When a server device responds to a client device request, it uses the function code field to indicate a successful response by echoing the original function code, or it returns an error code in the function code field if the request was unsuccessful.

Server devices never initiate messages, for example they cannot initiate an alert to a client device, and they can receive but never respond to broadcast messages. Broadcast messages have a server device address of 0.  

Ethernet connections

Generically referred to usually as Modbus TCP, Modbus TCP and Modbus TCP over UDP are essentially versions of the Modbus RTU serial variant with a TCP/IP interface that runs over Ethernet and fiber networks, allowing fast and stable connections.

Modbus TCP data transactions work in a similar manner to that of Modbus RTU transactions with a few differences. Modbus TCP allows more addresses than Modbus RTU, supports multiple client devices, enables faster transmission speeds, and allows as many server devices as the physical layer can handle. Modbus TCP allows multiple client devices to concurrently send requests to a single server device and allows client devices to simultaneously broadcast messages to multiple client devices.

Modbus TCP includes an MBAP header. The 7-byte header is added to the start of messages and contains a transaction identifier to uniquely identify a request, a protocol identifier that is set to 0 to identify the protocol as Modbus (this field may be used for intra-system multiplexing), the length of the data in the message that follows, and a unit identifier set by the client device to identify the server device.

With Modbus TCP, the ADU contains the Modbus message and information about the transport protocol being used. Modbus includes ADU variants that are tailored to support different network protocols and buses.

With Modbus TCP, the server device does not need an ID because it uses an IP address and messages routed by the network. The checksum field is also not needed as checksum calculations are done at the Ethernet layer. Routing information that is specific to the transport method, for example TCP or UDP, is stored in the ADU.  

Wireless Modbus

Wireless Modbus is increasingly being used to save wiring costs and where sensors are located in remote geographic areas. A Modbus network can easily be set up to work over a wireless link by replacing the twisted pair cables commonly used with RS-485, with a standard transmitter at each end of the network. Wireless Modbus is transparent to the client and server devices as the data packets that are sent and received in an encrypted form are always converted back to their original format before the receiving device gets them.

Where is Modbus used?

At its inception, Modbus was primarily designed for use with PLCs and used in industrial manufacturing applications, for example to communicate sensor data to a supervisory PLC.

Thanks to a proliferation of proprietary and open routers and gateways, Modbus is used today in virtually every sector, including oil and gas, property and building management, telecommunications, cloud services, telemedicine, connected homes, farming and agriculture, engineering, electric vehicle manufacturing, smart factories, the IoT, climate research and control, security, mission-critical systems, etc. Modbus is also used by companies that supply system integration services in these industries and in other industries where there are large numbers of connected devices, for example at data centers and in Edge computing.

Because Modbus supports a number of types of communication media, including twisted-pair wires, wireless, fibre optics, cell phones, and microwave, it is a flexible option for complex systems. RS-485 analog-to-digital converters (ADC) allow administrators to monitor information gathered from multiple sensors at different locations via a single interface.

The development of modern gateway technologies allows high-tech and legacy applications and devices to communicate using Modbus. For example, via a Modbus gateway, the charging infrastructure for high-tech electric vehicles may communicate with legacy energy management systems.

In the IoT and IIoT, a Modbus-enabled IoT device may be connected to a Modbus device through an IoT gateway that controls other Modbus devices. This connection allows secure, P2P connections over the internet that mitigate the use of firewalls and VPNs and improve performance.  

Modbus RTU is ideal in the following implementations: for local communications in remote areas where there is no internet; where devices have static addresses and do not switch networks; and where a confirmation that the end of a message request or response is necessary.

Modbus RTU is not recommended in the following scenarios: where server devices need to be able to push data; for applications with band restrictions; where devices switch networks or have an unknown address; and applications that send data to cloud servers.

Complex networks that use Ethernet are able to combine technologies and code-appropriate applications to accommodate the use of Modbus TCP-enabled devices.

Modbus security

Modbus has error-detection capabilities, including CRC and device diagnostics, but is still vulnerable to cyberattacks and was also not designed to provide safety functionality. There are no integrity checks or authentication processes and messages are not encrypted.

Modbus RTU has less of a cybersecurity risk than Modbus TCP because there is only one server. With Modbus TCP, an attacker could get into the network by masquerading as a new server. However, the Modbus Security variant addresses cybersecurity issues in Modbus TCP.

To mitigate Modbus security vulnerabilities, industrial systems may use firewalls, a virtual private network (VPN), or a Modbus OPC Unified Architecture (OPC UA) gateway that encrypts data as it is sent across a network.

Modbus OPC UA

 
Any transport layer or gateway can be used to move Modbus messages, for example OPC UA or Message Queue Telemetry Transport (MQTT). Used for industrial automation, OPC UA is a platform-independent, machine-to-machine communication protocol. Integrating Modbus devices into OPC UA can address Modbus security issues and can also provide a centralized, graphical interface to combine and analyze data from different sources. Modbus devices are usually RTU, and OPC UA devices are Ethernet, so integration involves a conversion process but there are numerous plug-and-play products on the market to do this.

Modbus benefits

Modbus serial communication is an easy-to-use and inexpensive way to connect devices. It uses very little CPU  or RAM. It is typically implemented in small, low-cost devices that measure small amounts of data like temperature, pressure, fuel levels, etc.

Most, if not all, industries use PCs in development, collaboration, and support lifecycles. A serial interface like Modbus RTU is often easier to use to connect peripherals to PCs than using ISA or PCI interfaces. Common embedded system peripherals, like AC/DC converters, temperature sensors, and LCDs all support serial interfaces.

A semaphore is a synchronization object used for access to a common resource by multiple processes in a parallel programming environment. Serial interfaces allow small processors to independently perform small units of works but can still be easily connected to a larger processing unit without the need for shared memory or semaphores.

Every Modbus message has the same simple structure, so it can be easily parsed. The basic elements – server address, function code, data, and checksum field – are always in the same sequence.

Modern industrial products sh as PAC, I/O devices, and meters that may use a serial, Ethernet, or wireless interface can still be able to use Modbus.

Nonprogrammers, like engineers and technicians that work in the field, can easily understand the concepts of coil and registers and the simple commands to read and write them.

Because it is so popular and provides a manufacturer-independent interface, many tools and interfaces have been developed to enhance interoperability between applications, devices, and data.

Modbus limitations

Modbus is not suitable for applications that require an event-oriented response, like an alarm condition, and does not allow server devices to report unrequested exceptions.

The Modbus packet size is limited to 253 bytes, so devices can only transfer about 240 bytes of actual data.

The rate at which data is transferred using Modbus is relatively slow although Modbus TCP is a lot faster than Modbus RTU.

Modbus uses only two types of data, 16-bit unsigned integers and binary data. However, there are workarounds to support 32-bit data transfers.

Modbus simply sends data; it is not possible to get a meaningful description, like unit, resolution, or the name of a data object directly in a request. For example, you can easily ascertain that a temperature is 25 degrees but not whether that figure is expressed in Celsius or Fahrenheit. One workaround for this is to use an OPC UA gateway that can provide metadata about the values in Modbus holding registers.

Modbus is simple to use but the fact that it uses offsets for addressing can be confusing. The solution is to ensure that developers read the documentation (both client and server devices must use the same offset method) or use polling software to determine the format, and use a Modbus simulator for testing.

The number of client and server devices that a Modbus RTU network supports depends on the physical signal standard that is used, so the requirements from the network should be assessed before a standard is selected.

Modbus monitoring

PRTG is a customizable platform for monitoring and controlling Modbus RTU and Modbus TCP connections. To do this, PRTG provides custom RTU sensors and TCP sensors. Sensors are virtual monitoring devices that can monitor all types of measured values for connections that use Modbus. PRTG allows administrators to contextualize and analyze data from physical devices using Modbus through a user-friendly interface. Watch a video about how the custom Modbus TCP sensor works here.

Note: To see how Modbus stacks up against alternative network protocols – like BACnet, LonWorks, and M-Bus – read the Paessler blog post “Protocols, gateways and data transmission methods for building state monitoring”.