Complete Guide to Modbus RTU, ASCII, and TCP

↑ Click the above

“Smart Manufacturing Home”

Source: FreeBuf COM

Written in front

Hello everyone, I am Xiao Zhi, the owner of Smart Manufacturing Home~

When it comes to digitization, industrial networks and data communication are topics we can never avoid~

Previously, I introduced various protocols, interfaces, etc. in industrial communication:

The most comprehensive organization of various buses + protocols + specifications + interfaces in industrial communication—data acquisition and control

I also analyzed the automation pyramid of industrial networks from ISA-95:

Complete interpretation of industrial communication network levels, analyzing the automation pyramid of industrial networks

At the same time, I technically analyzed various common industrial Ethernet:

Technical interpretation of PROFINET, Ethernet/IP, and 7 mainstream industrial Ethernet

Today, let’s talk about Modbus, first let’s take a look at today’s main content:

01 Terminology Interpretation

02 Background

03 Protocol Principles

04 Transmission Methods

05 Differences between Modbus RTU and Modbus ASCII

06 Modbus TCP and its Precautions

07 Function Code Functions

08 Modbus Protocol Security Analysis

PS: The content of this account includes “one hardware (PLC, robots, drives, vision, etc.) + one software (PLM, MOM, and other industrial software) + one network (network and IT related) + one security (industrial security)”, for those interested in other sections, you can check historical articles or recommendations at the end of the article

01 Terminology Interpretation

1 word = 2 bytes;

1 byte = 8 bits.

Checksum: A checksum is derived from previous data through a certain algorithm to verify the correctness of the data set. When code is input as data to a computer or other devices, input errors can easily occur; to reduce such errors, coding experts have invented various checksum error detection methods and set checksums based on these methods.

Common checksums include: Sum, XOR, LRC, CRC…

Discrete Input: Mainly used to read data from a single bit, such as the status of IO;

Coil: Switch output signals, mainly used to write data to a single bit, forming paired operations with discrete inputs;

Input Register: Mainly used to read 16 bits, which is two bytes of data;

Holding Register: Mainly used to write 16 bits of data.

PLC: Programmable Logic Controller, a type of programmable memory used to store programs internally, executing logical operations, sequential control, timing, counting, and arithmetic operations directed by user instructions, controlling various types of machinery or production processes through digital or analog input/output.

Serial Communication: With the application of computer systems and the development of microcomputer networks, communication functions have become increasingly important. The communication referred to here is the exchange of information between the computer and the outside world. Therefore, communication includes information exchange between computers and external devices, as well as between computers. Since serial communication transmits information one bit at a time over a single transmission line, it uses fewer transmission lines and can utilize existing telephone networks for information transmission, making it particularly suitable for long-distance transmission. For those external devices that are not far from the computer, such as terminals, printers, logic analyzers, disks, etc., serial data exchange is also common. In real-time control and management, communication between CPUs in a hierarchical distributed control system is generally serial. Therefore, serial interfaces are commonly used in microcomputer application systems. Many peripherals and computers communicate in a serial manner; the term serial refers to the method of information transfer between peripherals and interface circuits, while the CPU and interface still operate in parallel.

Serial Port: A serial port is a very common communication protocol for devices on computers, not to be confused with Universal Serial Bus (USB). Most computers contain two RS232-based serial ports. The serial port is also a common communication protocol for instruments and devices; many GPIB compatible devices also have RS-232 ports. Additionally, the serial communication protocol can also be used to retrieve data from remote acquisition devices.

The concept of serial communication is very simple; the serial port sends and receives bytes bit by bit. Although it is slower than parallel communication, which sends data byte by byte, the serial port can send data on one line while receiving data on another line. It is simple and can achieve long-distance communication. For example, when IEEE488 defines the parallel communication state, it stipulates that the total length of the device line should not exceed 20 meters, and the length between any two devices should not exceed 2 meters; however, for serial ports, the length can reach 1200 meters.

Typically, serial ports are used for the transmission of ASCII character data. Communication is accomplished using three lines: (1) Ground, (2) Send, (3) Receive. Since serial communication is asynchronous, the port can send data on one line while receiving data on another line. Other lines are used for handshaking but are not mandatory. The most important parameters of serial communication are baud rate, data bits, stop bits, and parity. For two ports communicating, these parameters must match:

a. Baud Rate: This is a parameter that measures communication speed. It indicates the number of bits transmitted per second. For example, 300 baud means 300 bits are sent per second. When we refer to clock cycles, we are referring to the baud rate. For instance, if the protocol requires a baud rate of 4800, then the clock is 4800Hz. This means that the sampling rate for serial communication on the data line is 4800Hz. Typically, telephone lines have baud rates of 14400, 28800, and 36600. Baud rates can be much higher than these values, but baud rate is inversely proportional to distance. High baud rates are often used for communication between instruments placed very close together, a typical example being GPIB device communication.b. Data Bits: This is a parameter that measures the actual data bits in communication. When a computer sends a packet of information, the actual data is not 8 bits; the standard values are 5, 7, and 8 bits. How to set this depends on the information you want to transmit. For example, standard ASCII codes are 0-127 (7 bits). The extended ASCII code is 0-255 (8 bits). If the data uses simple text (standard ASCII), then each data packet uses 7 bits of data. Each packet refers to a byte, including start/stop bits, data bits, and parity bits. Since the actual data bits depend on the chosen communication protocol, the term ‘packet’ refers to any communication scenario.c. Stop Bits: Used to indicate the last bit of a single packet. Typical values are 1, 1.5, and 2 bits. Since data is timed on the transmission line and each device has its own clock, it is likely that a slight desynchronization occurs between two devices during communication. Therefore, stop bits not only indicate the end of transmission but also provide an opportunity for the computer to correct clock synchronization. The more bits suitable for stop bits, the greater the tolerance for clock synchronization discrepancies, but the data transmission rate also decreases.d. Parity Bits: A simple error detection method in serial communication. There are four types of error detection: even, odd, high, and low. Of course, it is also possible to have no parity bit. For even and odd parity cases, the serial port will set a parity bit (one bit after the data bits) with a value to ensure that the transmitted data has an even or odd number of logical high bits. For example, if the data is 011, then for even parity, the parity bit is 0, ensuring there are an even number of logical high bits. If it is odd parity, the parity bit is 1, resulting in 3 logical high bits. High and low bits do not actually check the data; they simply set a logical high or low parity. This allows the receiving device to know the state of a bit, giving it a chance to determine whether noise has interfered with communication or whether the transmission and reception of data are unsynchronized.

02 Background

As early as 1971, Modicon first introduced the Modbus protocol, giving birth to Modbus RTU and Modbus ASCII. Later, Schneider Electric acquired Modicon and launched the Modbus TCP protocol in 1997. In 2004, the National Standard Committee of China officially made Modbus a national standard, marking the beginning of Modbus’s contribution to industrial communication in China.

Through this protocol, controllers can communicate with each other, and controllers can communicate with other devices via the network. The Modbus protocol is characterized by being standard, open, supporting multiple electrical interfaces, having a simple and compact data frame format, large data transmission volume, and good real-time performance, making it widely used in industrial control systems and becoming a universal industrial standard. A thorough analysis of the implementation principles and security of the Modbus protocol is of great practical significance for improving the security of industrial control systems. Modbus RTU and Modbus ASCII are mainly used in serial communication fields, while Modbus TCP is commonly used in Ethernet communication. Now, Modbus has become the communication protocol standard in the industrial field and is a widely used connection method between industrial electronic devices.

03 Protocol Principles

Modbus uses a simple Master and Slave protocol (client/server protocol) for communication. The client acts as the master, sending requests to the server; the server (slave) analyzes the request upon receipt and responds accordingly. The communication frame used is called the Application Data Unit (ADU), which includes the communication address segment, function code segment, data segment, and checksum segment, as shown in the figure below:

Generally, in use, monitoring systems (HMI) are masters, while PLCs, electric meters, instruments, etc. are slaves. The HMI system continuously polls various relays and registers for the latest values, then displays and processes various logic calculations and control adjustments.

Here, the function code segment and data segment combined are referred to as the Protocol Data Unit (PDU). The function code segment occupies one byte, with a value range of 1-255, where 128-255 are reserved for exception message response packets. The values 1-127 are function code numbers, with 65-72 and 100-110 being user-defined codes.

04 Transmission Methods

The Modbus protocol is an application layer message transmission protocol that includes three message types: ASCII, RTU, and TCP. The protocol itself does not define the physical layer; it only defines the message structure that controllers can recognize and use, regardless of the network used for communication.

When using the Modbus protocol for serial transmission, one can choose either RTU or ASCII mode, specifying the message, data structure, commands, and response methods, and requiring data verification. The ASCII mode uses LRC for verification, while the RTU mode uses 16-bit CRC for verification. When transmitted via Ethernet, TCP is used, and this mode does not use verification because the TCP protocol is a reliable connection-oriented protocol.

05 Differences between Modbus RTU and Modbus ASCII

Modbus is an application layer protocol that defines data units (ADU) independent of the underlying network, allowing communication over Ethernet (TCP/IP) or serial links (RS232, RS485, etc.) (Ethernet ADU and serial ADU are slightly different). On serial links, the Modbus protocol has two transmission modes—ASCII mode and RTU mode. ASCII is the abbreviation for “American Standard Code for Information Interchange”; RTU stands for “Remote Terminal Unit.”

First, let’s take a look at how Modbus works.

Modbus uses a master-slave communication mode, where only the master device can initiate transmission, and the slave device responds to the master’s requests. Typical master devices include field instruments and display panels, while typical slave devices are programmable logic controllers (PLCs).

In master-slave communication over serial links, a Modbus master device can connect to one or N (up to 247) slave devices. Communication between master and slave devices includes unicast and broadcast modes.

In broadcast mode, the Modbus master can simultaneously send requests to multiple slave devices (device address 0 is used for broadcast mode), and slave devices do not respond to broadcast requests.

In unicast mode, the master sends requests to a specific slave device (each Modbus slave device has a unique address), and the request message frame contains function codes and data, such as function code “01” used to read the status of discrete coils. After receiving the request, the slave responds and provides feedback to the master device.

In communication between master and slave devices, either ASCII mode or RTU mode can be used.

In ASCII (American Standard Code for Information Interchange) transmission mode, the message frame starts with an English colon (“:”, ASCII 3A Hex) and ends with carriage return and line feed (CRLF, ASCII 0D and 0A Hex). The allowed character set for transmission is hexadecimal 0-9 and A-F; slave devices in the network monitor whether there is an English colon (“:”) on the transmission path. If there is, they decode the message frame and check if the address in the message matches their own; if it matches, they accept the data; if not, they ignore it.

In ASCII mode, each 8-bit byte is split into two ASCII characters for transmission. For example, the hexadecimal number 0xAF is split into ASCII characters “A” and “F” for transmission, doubling the number of characters sent compared to RTU. The advantage of ASCII mode is that it allows a time gap of up to 1 second between two characters without causing communication failure. This mode uses Longitudinal Redundancy Check (LRC) for error detection.

When the controller is set to communicate over the Modbus network in RTU mode, each 8-bit byte contains two 4-bit hexadecimal characters, and this mode has no start and end markers. Its advantages include: being able to transmit more data at the same baud rate.

In RTU (Remote Terminal Unit) mode, each byte can transmit two hexadecimal characters, for example, the hexadecimal number 0xAF is sent directly as hexadecimal 0xAF (binary: 10101111), so its transmission density is twice that of ASCII mode; RTU mode uses Cyclic Redundancy Check (CRC), and the summary of the RTU mode is as follows:

Specific formats are shown in the figure.

06 Modbus TCP and Its Precautions

6.1 Master and Slave, Server and Client

[In the Modbus protocol]

The master sends the Modbus request, and the slave returns a response based on the request content. In the Modbus protocol, the master is always the active party, while the slave is always the passive party.

[In network applications]

In network applications, there are clients and servers; the client (e.g., a browser) sends requests to the server, and the server returns content (e.g., HTML text) to the client.

[In Modbus TCP]

The master is the client, while the slave is the server. Do not think that the server is more important; the master is also important, so the master is the server.

6.2 Can There Be Multiple Masters?

From the previous analysis, if the master is the client, then Modbus TCP supports multiple masters, and multiple masters and slaves can exist in a local area network. The connection capacity of the slave (the number of connected masters) is determined by the maximum TCP connections of uIP.

6.3 Brief Introduction to Modbus TCP Protocol

Modbus TCP is fundamentally the same as Modbus RTU, but there are some differences.

a. The slave address becomes less important and is often ignored. In a sense, the slave address is replaced by the IP address.

b. CRC verification becomes less important and can even be ignored. Since there is already verification in the TCP packet, Modbus TCP simply cancels CRC verification to avoid redundancy.

The TCP mode was developed to allow Modbus data to be transmitted smoothly over Ethernet, using TCP port 502. The physical layer, data link layer, network layer, and transport layer of this protocol are all based on TCP, only modifying and encapsulating the Modbus protocol at the application layer; the receiving end unpacks the TCP packet to retrieve the original Modbus frame, then parses it according to the Modbus protocol specification, and re-encapsulates the returned data packet into the TCP protocol to send back to the sender. Unlike the data format transmitted over serial links, TCP mode removes additional addresses and checksums while adding a message header, as shown in Figure 4.

In Modbus TCP, there is an MBAP header that contains the following parts:

Area	Length	Description	Client	Server
Transmission Flag	2 bytes	Sequence number during MODBUS request and response transmission	Generated by the client	Copied by the server in response
Protocol Flag	2 bytes	Modbus protocol defaults to 0	Generated by the client	Copied by the server in response
Length	2 bytes	Length of the remaining part	Generated by the client	Generated by the server in response
Unit Flag	1 byte	Slave flag (slave address)	Generated by the client	Copied by the server in response

[Note]

[1] The transmission flag can be understood as a sequence number to prevent MODBUS TCP communication misalignment, for example, a later response arriving at the master before an earlier response.

[2] The unit flag can be understood as the slave address, which is no longer important.

6.4 Relationship between Modbus TCP and TCP IP

Modbus TCP can be understood as an application layer protocol that occurs over TCP. Since it is a TCP protocol, a complete MODBUS TCP message must include TCP headers, IP headers, and Ethernet headers.

07 Function Code Functions

The client that initiates the Modbus transaction creates the Modbus application data unit. The function code (in the PDU) indicates to the server which operation to perform.

The function code field of the Modbus data unit is encoded in one byte. The valid range is decimal 1-255 (128-255 are reserved for exception responses). When sending a message from the client to the server, the function code field indicates which operation the server should perform.

The data field in the message sent from the client to the server includes additional information that the server uses to perform the operation defined by the function code. This field also includes discrete item and register addresses, the number of items to process, and the number of actual data bytes in the field.

In certain requests, the data field may not exist; in this case, the server does not need any additional information. The function code only indicates the operation.

Types of Function Codes

Function codes are mainly divided into valid function codes, exception function codes, and error function codes.

If no errors related to the requested Modbus function occur in a correctly received Modbus ADU, the response data from the server to the client will contain the normal function code from the request. If errors related to the requested Modbus function occur, the response data will contain an exception code and an error code.

For example, the client can read the on/off status of a group of discrete outputs or inputs, or the user can read/write a group of register data contents. When the server responds to the client, it uses the function code field to indicate a normal (no error) response or the occurrence of some error (called an exception response). For a normal response, the server only responds with the original function code, as shown in the figure below:

For an exception response, the server returns a code equal to that of the client, setting the most significant bit of the original function code to logical 1 and adding the exception code and error code to notify the client of the exception reason. As shown in the figure below:

Valid function codes

There are more than twenty valid function codes, but generally, the most commonly used ones are 1, 2, 3, 4, 5, 6, 15, and 16, along with two specially used ones, 20 and 21, which are General Reference Registers. Most Modbus devices do not provide this register. The main control data types on PLCs are as follows. These eight function codes are used to process this control data, detailed below:

Four types of control data:

DI: Digital Input (discrete input), one address one data bit, the user can only read its status, cannot modify. Represented by one bit as On/Off, used to record the status input of control signals, such as switches, contact points, motor operation, limit switches, etc. On PLCs, it is referred to as Input relay, input coil, etc.

DO: Digital Output (discrete output), one address one data bit, the user can set, reset, and read back the status. Represented by one bit as On/Off, used to output control signals to activate or stop motors, alarms, lights, etc. On PLCs, it is referred to as Output relay, Output coil, etc.

AI: Analog Input (input register), one address 16-bit data, the user can only read, cannot modify, represented by a 16 bits integer, used to record the value input of control signals, such as temperature, flow, material quantity, speed, rotation speed, valve opening, liquid level, weight, etc. On PLCs, it is referred to as Input register.

AO: Analog Output (holding register), one address 16-bit data, the user can write and read back, represented by a 16 bits integer, used to output control signal values, such as temperature, flow, speed, rotation speed, valve opening, feed quantity, etc. On PLCs, it is referred to as Output register, Holding register.

08 Modbus Protocol Security Analysis

The Modbus protocol is a typical industrial control network protocol, and studying its security is of great importance for strengthening the security of industrial control networks. Generally speaking, protocol security issues can be divided into two types: one is security issues caused by the design and description of the protocol itself; the other is security issues caused by incorrect implementation of the protocol. The Modbus protocol also has

these two types of problems.

8.1 Inherent Issues of the Modbus Protocol

Most industrial control protocols were designed primarily with functionality, efficiency, and reliability in mind, without considering security issues. The Modbus protocol is no exception, even though it has become a de facto industrial standard. From the previous principle analysis, it can be seen that its inherent security issues include: lack of authentication, authorization, encryption, and function code abuse.

(1) Lack of Authentication

The purpose of authentication is to ensure that the information received comes from legitimate users; unverified users sending control commands to devices will not be executed. In the Modbus protocol communication process, there are no relevant definitions regarding authentication. An attacker only needs to find a legitimate address to establish a Modbus communication session using function codes, thereby disrupting the entire or part of the control process.

(2) Lack of Authorization

Authorization ensures that different privileged operations need to be performed by authenticated users with different permissions, significantly reducing the probability of operational errors and internal attacks. Currently, the Modbus protocol lacks a role-based access control mechanism, does not categorize users, nor define user permissions, which can lead to any user executing any function.

(3) Lack of Encryption

Encryption can ensure that the information of both parties during communication is not illegally obtained by third parties. In the Modbus protocol communication process, addresses and commands are transmitted in plaintext, making it easy for attackers to capture and analyze the data, providing convenience for attackers.

(4) Function Code Abuse

Function codes are an important part of the Modbus protocol, and nearly all communication includes function codes. Currently, function code abuse is a major factor leading to Modbus network anomalies. For example, illegal message lengths, short cycles of useless commands, incorrect message lengths, and delayed acknowledgment of exception codes can all lead to denial-of-service attacks.

8.2 Issues Caused by Protocol Implementation

Although the Modbus protocol has been widely used, developers do not possess security knowledge or are not aware of security issues when implementing specific industrial control systems. This has resulted in various security vulnerabilities in systems using the Modbus protocol.

(1) Design Security Issues

Modbus system developers focus primarily on functionality implementation, with security issues rarely being noted during design. Design security refers to fully considering security during design, addressing various anomalies and illegal operations that may occur in Modbus systems. For instance, if a certain node is maliciously controlled and sends illegal data during communication, it is necessary to consider how to identify and handle this data.

(2) Buffer Overflow Vulnerabilities

Buffer overflow occurs when data exceeds the capacity of the buffer during filling, causing the overflowing data to overwrite legitimate data. This is one of the most common and dangerous vulnerabilities in software development, which can lead to system crashes or allow attackers to control the system. Most Modbus system developers lack security development knowledge, leading to many buffer overflow vulnerabilities that, if exploited by malicious actors, can result in severe consequences.

(3) Modbus TCP Security Issues

Currently, the Modbus protocol can be implemented on general-purpose computers and operating systems, running over TCP/IP to meet development needs. Thus, the security issues inherent in the TCP/IP protocol inevitably affect the security of industrial control networks. Common attack methods in the IP Internet, such as illegal network data acquisition, man-in-the-middle attacks, denial of service, IP spoofing, and viruses, will all impact the security of Modbus systems.

8.3 Security Recommendations

Currently, the security measures taken by Modbus systems are generally insufficient. Here are some security recommendations based on information security industry research and the specific security issues of industrial control systems, which can effectively reduce the threats faced by industrial control systems.

(1) Start from the Source

Industrial control network vulnerabilities largely stem from issues that arise during the implementation process. If security measures are controlled from the source, throughout the entire life cycle of the Modbus system—from requirement design, development, internal testing, to deployment—integrating security design, secure coding, and security testing techniques can greatly eliminate security vulnerabilities and reduce the overall security risks of the Modbus system.

(2) Anomaly Behavior Detection

Anomalous behavior represents potential threats, regardless of whether there are attackers. Therefore, developing dedicated anomaly detection devices for Modbus systems can greatly enhance the security of industrial control networks. For Modbus systems, the first step is to analyze the various operational behaviors that exist and describe behaviors using a six-tuple model based on “subject, location, time, access method, operation, object”; further analyze whether these behaviors are anomalous; and ultimately decide to take measures such as logging or alerting.

(3) Security Audits

Modbus security audits involve in-depth decoding and analysis of protocol data, recording key information such as the time, location, operator, and operational behavior of actions, achieving security audit log recording and auditing functions for Modbus systems, thus providing traceability capabilities after security incidents.

(4) Use Network Security Devices

Utilize intrusion prevention systems and firewalls as network security devices. A firewall is a serial device that, through settings, only allows specific addresses to access the server, prohibiting external addresses from accessing the Modbus server, effectively preventing external intrusions; intrusion prevention devices can analyze the specific operational contents of the Modbus protocol, effectively detecting and blocking anomalous operations and various penetration attacks from both internal and external sources, providing protection for the internal network.

Reprinted from FreeBuf COM

Disclaimer: The articles contained in this public account are either original or edited and organized based on online searches. The copyright of the articles belongs to the original author. Due to numerous reprints, it is impossible to find the true source. If there is a misattribution of the source or any infringement regarding the images, materials, or download links used in the article, please contact us for negotiation or deletion. Thank you!