Known limitations
Modicon developed the Modbus protocol with a narrow scope of requirements. Back in the late 1970s, this was a good thing. However, today, these design decisions result in several limitations.
Table of Content
Security
The Modbus protocol has several limitations in terms of security that can make it more difficult to protect the data transmitted over a Modbus network and may leave the system vulnerable to attacks or unauthorized access. To address these security concerns, it may be necessary to implement additional security measures, such as encryption, authentication, and access control, at the application level or by using other protocols or technologies.
Lack of encryption
The Modbus protocol does not include any built-in encryption for protecting the data transmitted between devices. This means that the data transmitted over a Modbus network can be intercepted and read by anyone with access to the network.
Lack of authentication
The Modbus protocol does not include any authentication mechanisms for verifying the identity of devices on the network. This means that anyone with access to the network can potentially send requests or commands to a Modbus server, potentially resulting in unauthorized access or manipulation of the data on the server.
Lack of access control
The Modbus protocol does not include any access control mechanisms for regulating which devices can access which registers on a server. This means that any device with access to the network can potentially read or write to any register on the server, potentially resulting in unauthorized access or manipulation of the data.
Supported data types
Modbus was developed in the late 1970s as a protocol for communicating with PLC controllers, which were common at the time. As a result, the data types supported by the Modbus protocol are limited to those that could be understood by PLC controllers. The protocol does not have the ability to handle complex data structures or large binary objects, and only supports a few basic data types, such as 16-bit and 32-bit integers, 32-bit floating point numbers, and strings of up to 252 characters. This can be a limitation for devices that need to work with other types of data, such as 64-bit integers or more complex data structures.
No query support
There is no standard function for discovering the number, type, or size of the registers on a server. This means that a device that wants to access the registers on a server must know in advance the addresses and data types of the registers it wants to access.
The Modbus protocol does not include any functions for browsing or searching the contents of a server. This can be a limitation for devices that need to dynamically discover or access the registers on a server, as they must manually request the values of individual registers or groups of registers.
This lack of standard functions for discovering and accessing the contents of a Modbus server can make it more difficult for devices to interact with the server and may require more complex programming and configuration to access the desired registers. It can also make it more difficult to integrate Modbus devices with other systems or software that need to dynamically discover and access the contents of a server.
The request-reply model
Since the protocol is based on a client-server model, where the client initiates communication with the server by sending requests for data or commands, and the server responds to these requests. This means that it is not possible for the client and server to switch roles at runtime.
As a result, it is not possible to transmit data using an event mechanism in Modbus. Instead, a client must continuously read data from a server to get the current data or to detect alarm conditions. This can be inefficient, as it requires the client to constantly poll the server for data, even if there are no changes or events to report.
This limitation can make it more difficult to use Modbus in systems that need to quickly and efficiently detect and respond to events or changes in data, such as real-time control systems or systems with a high-frequency of data updates. It may also require more complex programming or configuration to implement event-based communication using Modbus.
Number of devices
It is important to note that both Modbus RTU and Modbus TCP are designed for use in small to medium-sized networks, and may not be suitable for large networks with a large number of devices. In such cases, it may be necessary to use other protocols or technologies to support the required number of devices.
Modbus RTU
The maximum number of devices that can be connected to a Modbus RTU network is limited by the capacity of the communication link, as well as the addressing range of the Modbus protocol. Modbus RTU uses a single-master, multiple-slave architecture, where a master device initiates communication with one or more slave devices. The Modbus RTU specification defines a range of device addresses from 1 to 247, which means that a maximum of 247 slave devices can be connected to a single Modbus RTU network. However, the actual number of devices that can be connected may be limited by the capacity of the communication link and the amount of data being transmitted.
Modbus TCP
The maximum number of devices that can be connected to a Modbus TCP network is limited by the capacity of the communication link and the IP addresses available in the network. Modbus TCP uses a client-server architecture, where multiple clients can communicate with one or more servers. The Modbus TCP specification does not define a specific limit on the number of devices that can be connected to a single network, but the actual number of devices that can be connected may be limited by the capacity of the communication link and the number of IP addresses available in the network.