Hubbry Logo
ModbusModbusMain
Open search
Modbus
Community hub
Modbus
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Modbus
Modbus
Modbus
View on Wikipedia
from Wikipedia
Modbus
Communication protocol
Developer(s)
  • Modicon (1979–1997)
  • Schneider Electric (1997–2004)
  • Modbus Organization, Inc. (since 2004)
Introduction1979
Logo of Modbus-IDA, the older name of the industry consortium

Modbus (or MODBUS) is a client/server data communications protocol in the application layer.[1] It was originally designed for use with programmable logic controllers (PLCs),[2] but has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and networks.[3][1]

Modbus is popular in industrial environments because it is openly published and royalty-free. It was developed for industrial applications, is relatively easy to deploy and maintain compared to other standards, and places few restrictions on the format of the data to be transmitted.

The Modbus protocol uses serial communication lines, Ethernet, or the Internet protocol suite as a transport layer.[1] Modbus supports communication to and from multiple devices connected to the same cable or Ethernet network. For example, there can be a device that measures temperature and another device to measure humidity connected to the same cable, both communicating measurements to the same computer, via Modbus.

Modbus is often used to connect a plant/system supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems. Many of the data types are named from industrial control of factory devices, such as ladder logic because of its use in driving relays: a single-bit physical output is called a coil, and a single-bit physical input is called a discrete input or a contact.

It was originally published in 1979 by Modicon (a company later acquired by Schneider Electric in 1997). In 2004, they transferred the rights to the Modbus Organization[4] which is a trade association of users and suppliers of Modbus-compliant devices that advocates for the continued use of the technology.[5]

Protocol description

[edit]
MODBUS communication stack
MODBUS communication stack

Modbus standards or buses include:[1]

  • TCP/IP over Ethernet
  • Asynchronous serial communication in a wide range of standards, technologies: EIA/TIA-232-E, EIA-422, EIA/TIA-485-A, fiber, radio frequency,...
  • MODBUS PLUS, a high speed token passing network.
Architecture of a network for Modbus communication

To support Modbus communication on a network, many modems and gateways incorporate proprietary designs (refer to the diagram: Architecture of a network for Modbus communication). Implementations may deploy either wireline or wireless communication, such as in the ISM radio band, and even Short Message Service (SMS) or General Packet Radio Service (GPRS).

PDU and ADU

[edit]

Modbus defines a client which is an entity that initiates a transaction to request any specific task from its request receiver.[6] The client's "request receiver", which the client has initiated the transaction with, is then called the server.[6] For example, when a microcontroller connects to a sensor to read its data by Modbus on a wired network, e.g RS485 bus, the MCU in this context is the client and the sensor is the server. In former terminology, the client was named master and the server named slave.

Modbus defines a protocol data unit (PDU) independently to its lower layer protocols in its protocol stack. Mapping MODBUS protocol on specific buses or networks requires some additional fields, defined as the application data unit (ADU). The ADU is formed by a client inside a Modbus network when the client initiates a transaction. Contents are:[7]

  • PDU = Function code + data
  • ADU = Additional address + PDU + error check

The ADU is officially called a Modbus frame by the Modbus Organization,[7] although frame is used as the data unit in the data-link layer in the OSI and TCP/IP model (while Modbus is an application layer protocol).

PDU max size is 253 bytes. ADU max size on RS232/RS485 network is 256 bytes, and with TCP is 260 bytes.[8]

For data encoding, Modbus uses a big-endian representation for addresses and data fields. Thus, for a 16-bit value, the most significant byte is sent first. For example, when a 16-bit register has value 0x1234, byte 0x12 is sent before byte 0x34.[8]

Function code is 1 byte which gives the code of the function to execute. Function codes are integer values, ranging from 1 to 255, and the range from 128 to 255 is for exception responses.

The data field of the PDU has the address from 0 to 65535 (not to be confused with the address of the Additional address field of ADU).[9] The data field of the PDU can be empty, and then has a size of 0. In this case, the server will not request any information and the function code defines the function to be executed. If there is no error during the execution process, the data field of the ADU response from server to client will include the data requested, i.e. the data the client previously received. If there is any error, the server will respond with an exception code.[6]

Modbus transaction and PDU

[edit]

A Modbus transaction between client and server includes:[6][10]

  • Step 1: Client initiates a request with PDU = Function code + data request
  • Step 2: Server receives the request from client. Server will then read/parse the function code, get the address of the data field of the PDU, then get this data field value and finally perform the action based on the function code. If there is no error during those steps, the server will respond with PDU = Function code + data response. As long as there is no error during those steps, the server's responding function code will also be the function code sent from the client. If there is any error during those steps, the server will respond with PDU = Exception Function code + Exception code (Reference to PDU mb_excep_rsp_pdu defined below).
  • Step 3: Client receives the response and ends the transaction.

Based on that, Modbus defines 3 PDU types:[8]

  • MODBUS Request PDU, mb_req_pdu
  • MODBUS Response PDU, mb_rsp_pdu
  • MODBUS Exception Response PDU, mb_excep_rsp_pdu
mb_req_pdu = Function code (1 byte) + request data (n bytes)
request data field's size depends on the function code and usually includes values like variable values, data offset, and sub-function codes.[8]
mb_rsp_pdu = Function code (1 byte) + response data (n bytes)
As in mb_req_pdu, response data field's size depends on the function code and usually includes values like variable values, data offset, and sub-function codes.[8]
mb_excep_rsp_pdu = Exception Function code (1 byte) + exception code (1 byte)
Exception Function code = Function code (1 byte) + 0x80. Exception Function code is equal to the Function code, except that its MSB is set to 1.
Exception code (1 byte) of mb_excep_rsp_pdu is defined in the MODBUS Exception Codes table.

Modbus data model

[edit]

Modbus defines its data model based on a series of tables of four primary types:[11]

Primary tables Access Size Features
Discrete input R 1 bit (0–1) Read on/off value
Coil (discrete output)[12] R/W 1 bit (0–1) Read/Write on/off value
Input register R 16 bit words (0–65,535) Read measurements and statuses
Holding register R/W 16 bit words (0–65,535) Read/Write configuration values

For each of the primary tables, the protocol allows individual selection of 65536 data items, and the operations of read or write of those items are designed to span multiple consecutive data items up to a data size limit which is dependent on the transaction function code.[11]

Function code

[edit]

Modbus defines three types of function codes: Public, User-Defined and Reserved.[13]

Public function codes

[edit]
Function type Function name Function code Comment
Data Access Bit access Physical Discrete Inputs Read Discrete Inputs 2
Internal Bits or Physical Coils Read Coils 1
Write Single Coil 5
Write Multiple Coils 15
16-bit access Physical Input Registers Read Input Registers 4
Internal Registers or Physical Output Registers Read Multiple Holding Registers 3
Write Single Holding Register 6
Write Multiple Holding Registers 16
Read/Write Multiple Registers 23
Mask Write Register 22
Read FIFO Queue 24
File Record Access Read File Record 20
Write File Record 21
Diagnostics Read Exception Status 7 serial only
Diagnostic 8 serial only
Get Com Event Counter 11 serial only
Get Com Event Log 12 serial only
Report Server ID 17 serial only
Read Device Identification 43
Other Encapsulated Interface Transport 43

Note: Some sources use terminology that differs from the standard; for example Force Single Coil instead of Write Single Coil.[14]

Function code 01 (read coils) as an example of public function code

[edit]

Function code 01 (read coils) allows reading the state from 1 to 2000 coils of a remote device. mb_req_pdu (request PDU) will then have 2 bytes to indicate the address of the first coil to read (from 0x0000 to 0xFFFF), and 2 bytes to indicate the number of coils to read. mb_req_pdu defines coil address by index 0, i.e the first coil has address 0x0. On a successful execution, mb_rsp_pdu will return one byte to note the function code (0x01), followed by one byte to indicate the number of data bytes it is returning (n), which will be the number of coils requested by mb_req_pdu, divided by 8 bits per byte, and rounded up. The remainder of the response will be the specified number (n) of data bytes.[15] That is, the mb_req_pdu and mb_rsp_pdu of function code 01 will take the following form:[15]

mb_req_pdu:
  • Function code: 0x01 (1 byte)
  • Starting Address (1st coil address to read): From 0x0000 to 0xFFFF (2 bytes)
  • Quantity of coils to read: Range from 1 to 2000 (0x7D0) (2 bytes)
mb_rsp_pdu:
  • Function code: 0x01 (1 byte)
  • Byte count: 1 byte (n=quantity of coils/8, rounded up)
  • Coil Status: n bytes

For instance, mb_req_pdu and mb_rsp_pdu to read coils status from 20-38 will be:[16]

mb_req_pdu:
  • Function code: 0x01
  • Starting Address High byte: 0x00
  • Starting Address Low byte: 0x13
  • Quantity of Outputs High byte: 0x00
  • Quantity of Outputs Low byte: 0x13
Starting Address (2 bytes) is 0x0013, (or 19 in decimal) which is the 20th coil.
Quantity of Outputs (2 bytes) is 0x0013, (or 19 in decimal) which corresponds to 19 values of status of coils 20th to 38th.
mb_rsp_pdu:
  • Function code: 0x01
  • Byte Count: 0x03
  • Outputs status 27-20: 0xCD
  • Outputs status 35-28: 0x6B
  • Outputs status 38-36: 0x05
As 19 coils (20-38) are required, 3 bytes is used to indicate the coil's state. So that Byte Count is 0x03. States of coil from 20 to 27 is 0xCD, which is 1100 1101 in binary. So coil 27 is MSb, and coil 20 is LSb. Same for coil 28 to 35. With coil from 36 to 38, the state will be 0x05, which is 0000 0101. Coil 38 state is the 3rd bit (count from the right), i.e 1, coil 37 is 0, and coil 36 state is LSb bit, i.e. 1. 5 left bits are all 0.

User-defined function codes

[edit]

User-Defined Function Codes are function codes defined by users. Modbus gives two range of values for user-defined function codes: 65 to 72 and 100 to 110. Obviously, user-defined function codes are not unique.[13]

Reserved function codes

[edit]

Reserved Function Codes are function codes used by some companies for legacy product and are not available for public use.[13]

Exception responses

[edit]

When a client sends a request to a server, there can be four possible events for that request:[17]

  • If server receives the request and execute successfully, server will return a normal response.
  • If server cannot receive the request as having communication channel error, server will not respond anything to the client. Client will then have the timeout request error.
  • If server receives the request and detect an error on the communication channel (e.g parity, LRC, CRC), server will not response anything to the client. Client will then have the timeout request error.
  • If server receives the request and is unable to execute it (e.g client requests to read a non-existent register), server will return an exception response to client to indicate the nature of the error.

Exception response message includes two other fields when compared to a normal response message:[17]

  • Function Code: Function code's MSB bit of Exception is 1. This will make this function code 0x80 higher than then request message function code.
  • Data: Server returns the exception code inside the Data field. This field defines the nature of the error.

All Modbus exception code:[18]

Code Text Details
1 Illegal Function Function code received in the query is not recognized or allowed by server
2 Illegal Data Address Data address of some or all the required entities are not allowed or do not exist in server
3 Illegal Data Value Value is not accepted by server
4 Server Device Failure Unrecoverable error occurred while server was attempting to perform requested action
5 Acknowledge Server has accepted request and is processing it, but a long duration of time is required. This response is returned to prevent a timeout error from occurring in the client. client can next issue a Poll Program Complete message to determine whether processing is completed
6 Server Device Busy Server is engaged in processing a long-duration command; client should retry later
7 Negative Acknowledge Server cannot perform the programming functions; client should request diagnostic or error information from server
8 Memory Parity Error Server detected a parity error in memory; client can retry the request
10 Gateway Path Unavailable Specialized for Modbus gateways: indicates a misconfigured gateway
11 Gateway Target Device Failed to Respond Specialized for Modbus gateways: sent when server fails to respond

Modbus over Serial Line protocol

[edit]

Modbus standard also defines Modbus over Serial Line, a protocol over the data link layer of the OSI model for the Modbus application layer protocol to be communicated over a serial bus.[19] Modbus Serial Line protocol is a master-slave protocol which supports one master and multiple slaves in the serial bus.[20] With Modbus protocol on the application layer, client/server model is used for the devices on the communication channel. With Modbus over Serial Line, client's role is implemented by master, and the server's role is implemented by slave.[20][21]

The organization's naming convention inverts the common usage of having multiple clients and only one server. To avoid this confusion, the RS-485 transport layer uses the terms "node" or "device" instead of "server", and the "client" is not a "node".[21]

The (Modbus Organization) is using "client-server" to describe Modbus communications, characterized by communication between [client device (s), which initiates communication and makes requests of server device(s), which process requests and return an appropriate response (or error message).

A serial bus for Modbus over Serial Line can have a maximum of 247 slaves communicating with one master. Those slaves have a unique address ranging from 1 to 247 (decimal value).[22] The master doesn't need to have an address.[22] The communication process is initiated by the master, as only it can initiate a Modbus transaction. A slave will never transmit any data or perform any action without a request from the master, and slaves cannot communicate with each other.[23]

In Modbus over Serial Line, the master initiates requests to the slaves in unicast or broadcast modes. In unicast mode, the master will initiate a request to a single slave with a specific address. Upon receiving and finishing the request, the slave will respond with a message to the master.[22] In this mode, a Modbus transaction includes two messages: one request from the master and one reply from the slave. Each slave must have a unique address (from 1 to 247) to be addressed independently for the communication.[22] In broadcast mode, the master can send a request to all the slaves, using the broadcast address 0,[22] which is the address reserved for broadcast exchanges (and not the master address). Slaves must accept broadcast exchanges but must not respond.[23] The mapping of PDU of Modbus to the serial bus of Modbus over Serial Line protocol results in Modbus Serial Line PDU.[22]

Modbus Serial Line PDU = Address + PDU + CRC (or LRC)

With PDU = Function code + data

  • Address is slave address
  • PDU is defined identically to the PDU of Modbus Application protocol
  • The Error check field with CRC/LRC: The error check methods depend on the protocol versions of the MODBUS over Serial Line, whether it is Modbus RTU or Modbus ASCII.

On the physical layer, MODBUS over Serial Line performs its communication on bit by RS485 or RS232, with TIA/EIA-485 Two-Wire interface as the most popular way. RS485 Four-Wire interface is also used. TIA/EIA-232-E (RS232) can also be used but is limited to point-to-point short-range communication.[20] MODBUS over Serial Line has two transmission modes RTU and ASCII which are corresponded to two versions of the protocol, known as Modbus RTU and Modbus ASCII.[24]

Modbus RTU

[edit]

Modbus RTU (Remote Terminal Unit), which is the most common implementation available for Modbus, makes use of a compact, binary representation of the data for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods. Each byte (8 bits) of data is sent as 11 bits:[3][24]

  • 1 start bit
  • 8 bit data/message, least significant bit sent first
  • 1 bit parity
  • 1 stop bit

The default is even parity, while odd or no parity may be implemented as additional options.[24]

A Modbus RTU frame then will be:[25]

Slave Address Modbus PDU CRC
Function Code Data
1 byte 1 byte 0 – 252 bytes 2 bytes: 1 CRC low byte and 1 CRC high byte

The CRC calculation is widely known as CRC-16-MODBUS, whose polynomial is x16 + x15 + x2 + 1 (normal hexadecimal algebraic polynomial being 8005 and reversed A001).[26]

Example of a Modbus RTU frame in hexadecimal: 01 04 02 FF FF B8 80 (CRC-16-MODBUS calculation for the 5 bytes from 01 to FF gives 80B8, which is transmitted least significant byte first).

To ensure frame integrity during the transmission, the time interval between two frames must be at least the transmission time of 3.5 characters, and the time interval between two consecutive characters must be no more than the transmission time of 1.5 characters.[25] For example, with the default data rate of 19200 bit/s, the transmission times of 3.5 (t3.5) and 1.5 (t1.5) 11-bit characters are:

For higher data rates, Modbus RTU recommends to use the fixed values 750 μs for t1.5 and 1.750 ms for t3.5.[25]

Modbus ASCII

[edit]

Modbus ASCII makes use of ASCII characters (chars) for protocol communication. The ASCII format uses a longitudinal redundancy check checksum. Modbus ASCII messages are framed by a leading colon (":", ASCII value 3A16) and trailing newline (CR/LF, ASCII values 0D16 and 0A16). Modbus ASCII frame do not need to be sent in bursts like Modbus RTU, a delay up to 1 second is permitted between each character transmission by default. Each ASCII character is sent as 10 bits:

  • 1 start bit
  • 7 bit ASCII character, least significant bit sent first
  • 1 bit parity
  • 1 stop bit

The default is even parity, while odd or no parity may be implemented as additional options.

A Modbus ASCII frame includes:[27]

Start Slave Address Modbus PDU LRC End
Function Code Data
1 char (always ":") 2 chars 2 chars 0-252 x 2 chars 2 chars 2 chars (always CR/LF)

Address, Function, Data, and LRC are ASCII hexadecimal encoded values, whereby each byte (8 bits) of information is encoded as two human-readable ASCII characters from the ranges 0–9 and A–F. For example, a byte value of 122 (11110102 or 7A16) is encoded as two ASCII characters, "7" and "A", and transmitted as two bytes, 55 (3716, ASCII value for "7") and 65 (4116, ASCII value for "A").

LRC is calculated as the sum of 8-bit values (excluding the start and end characters), negated (two's complement) and encoded as an 8-bit value. For example, if Address, Function, and Data are 247, 3, 19, 137, 0, and 10, the two's complement of their sum (416) is −416; this trimmed to 8 bits is 96 (256 × 2 − 416 = 6016), giving the following 17 ASCII character frame: :F7031389000A60␍␊. LRC is specified for use only as a checksum: because it is calculated on the encoded data rather than the transmitted characters, its 'longitudinal' characteristic is not available for use with parity bits to locate single-bit errors.

Modbus messaging on TCP/IP

[edit]

Modbus TCP

[edit]

Modbus TCP or Modbus TCP/IP is a Modbus variant used for communications over TCP/IP networks, connecting over port 502.[28] It does not require a checksum calculation, as lower layers already provide checksum protection.

Modbus TCP nomenclature is the same as for the Modbus over Serial line protocol, as any device which send out a Modbus command, is the 'client' and the response comes from a 'server'.[29]

The ADU for Modbus TCP is officially called Modbus TCP/IP ADU by the Modbus organization[30] and is also called Modbus TCP frame by other parties.[3]

MODBUS TCP/IP ADU = MBAP Header + Function code + Data

Where MBAP - which stands for MODBUS Application Protocol header - is the dedicated header used on TCP/IP to identify the MODBUS Application Data Unit.

The MBAP Header contains the following fields:[31]

Name Length (bytes) Function
Transaction identifier 2 For synchronization between messages of server and client
Protocol identifier 2 0 for Modbus/TCP
Length field 2 Number of remaining bytes in this frame
Unit identifier 1 Server address (255 if not used), treated like slave address in Modbus over Serial line

Unit identifier is used with Modbus TCP devices that are composites of several Modbus devices, e.g. Modbus TCP to Modbus RTU gateways. In such a case, the unit identifier is the Server Address of the device behind the gateway.

A MODBUS TCP/IP ADU/Modbus TCP frame format then will be:[31][30]

MBAP Header Modbus PDU
Transaction identifier Protocol identifier Length Unit identifier Function code Data
2 bytes 2 bytes 2 bytes 1 byte 1 byte n bytes

Example of a Modbus TCP/IP ADU/Modbus TCP frame in hexadecimal

[edit]

12 34 00 00 00 06 01 03 00 01 00 01

  • 0x12 and 0x34 : With transaction ID = 0x1234 (2 bytes) as a "unique number" to be identified between the Modbus TCP client/server, the transaction ID High byte is 0x12 and transaction ID Low byte is 0x34
  • 0x00 and 0x00 : Protocol identifier high byte and low byte
  • 0x00 and 0x06 : Length high byte and low byte. The length is 6 bytes which includes: unit identifier (slave address) (1 byte), function code (1 byte), high byte of the register address to read (1 byte), low byte of the register address to read (1 byte) and data (2 bytes = high byte and low byte of the number of registers to read)
  • 0x01 : Unit identifier (slave address)
  • 0x03 : Function code (Read Multiple Holding Registers)
  • 0x00 and 0x01 : high byte and low byte of the register address to read. The register address to read in this case is 0x0001.
  • 0x00 and 0x01 : high byte and low byte of the number of registers to read. The number of registers to read in this case is 0x0001. (i.e 1 register)

Other Modbus protocol versions over TCP/IP

[edit]
  • Modbus over TCP/IP, Modbus over TCP, or Modbus RTU/IP – a variant that differs from Modbus TCP in that a checksum is included in the payload, as with Modbus RTU.
  • Modbus over UDP – some have experimented with using Modbus over UDP on IP networks, which removes the overhead of TCP.[32]

Other Modbus protocol versions

[edit]

Besides the widely used Modbus RTU, Modbus ASCII and Modbus TCP, there are many variants of Modbus protocols:

  • Modbus Plus (Modbus+, MB+, or MBP) – Modbus Plus is proprietary to Schneider Electric, though it is unpublished rather than patented, and unlike the other variants, it supports peer-to-peer communications between multiple clients.[33] Despite the name, Modbus Plus[34] is not a variant of Modbus. It is a different protocol, involving token passing. It requires a dedicated co-processor to handle fast HDLC-like token rotation. It uses twisted pair at 1 Mbit/s and includes transformer isolation at each node, which makes it transition/edge-triggered instead of voltage/level-triggered. Special hardware is required to connect Modbus Plus to a computer, typically a card made for the ISA, PCI, or PCMCIA bus. Modbus Plus is normally implemented using a custom chipset available only to partners of Schneider.
  • Pemex Modbus – an extension of standard Modbus with support for historical and flow data. It was designed for the Pemex oil and gas company for use in process control and never gained widespread adoption.
  • Enron Modbus – another extension of standard Modbus developed by Enron with support for 32-bit integer and floating-point variables, and historical and flow data. Data types are mapped using standard addresses.[35] The historical data serves to meet an American Petroleum Institute (API) industry standard for how data should be stored.[citation needed]

Data models and function calls are identical for the first four variants listed above; only the encapsulation is different. However the variants are not interoperable, nor are the frame formats.

JBUS mapping

[edit]

Another de facto protocol closely related to Modbus appeared later, and was defined by PLC maker April Automates, the result of a collaborative effort between French companies Renault Automation and Merlin Gerin et Cie in 1985: JBUS. Differences between Modbus and JBUS at that time (number of entities, server stations) are now irrelevant as this protocol almost disappeared with the April PLC series, which AEG Schneider Automation bought in 1994 and then made obsolete. However, the name JBUS has survived to some extent.

JBUS supports function codes 1, 2, 3, 4, 5, 6, 15, and 16 and thus all the entities described above, although numbering is different:

  • Number and address coincide: entity #x has address x in the data frame.
  • Consequently, entity number does not include the entity type. For example, holding register #40010 in Modbus will be holding register #9, at address 9 in JBUS.
  • Number 0 (and thus address 0) is not supported. The server should not implement any real data at this number and address, and it can return a null value or throw an error when requested.

Limitations

[edit]
  • Since Modbus was designed in the late 1970s to communicate to programmable logic controllers, the number of data types is limited to those understood by PLCs at the time. Large binary objects are not supported.
  • No standard way exists for a node to find the description of a data object, for example, to learn that a register value represents a temperature between 30 and 175 degrees.
  • Since Modbus is a client/server (formerly master/slave) protocol,[21] there is no way for a field device to get data by the event handler mechanism (except over Ethernet TCP/IP, called open-mbus) as the client node must routinely poll each field device and look for changes in the data. This consumes bandwidth and network time in applications where bandwidth may be expensive, such as over a low-bit-rate radio link.
  • Modbus is restricted to addressing 247 devices on one data link, which limits the number of field devices that may be connected to a parent station (again, Ethernet TCP/IP is an exception).
  • Modbus protocol itself provides no security against unauthorized commands or interception of data.[36]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Modbus

View on Grokipedia
from Grokipedia
Modbus is a widely adopted, open protocol originally developed in 1979 by Modicon (now part of ) to facilitate data exchange between programmable logic controllers (PLCs) and other industrial automation devices. Operating at the (Layer 7) of the , it defines a simple, request-response messaging structure for reading and writing data such as discrete inputs, coils, input registers, and holding registers, typically in 16-bit word formats representing statuses, counters, or analog values. The protocol employs a master-slave architecture, where a master device (e.g., an HMI or system) initiates transactions and slaves (e.g., sensors or actuators) respond, ensuring reliable communication across diverse physical media like serial lines or Ethernet. The core of Modbus is its (PDU), a compact structure consisting of a 1-byte function code (e.g., 03 for reading holding registers or 16 for writing multiple registers) followed by up to 252 bytes of , with a maximum PDU size of 253 bytes to support efficient, low-overhead transactions. Addressing in Modbus uses four distinct banks—coils and discrete inputs for values, and holding and input registers for 16-bit words—each supporting up to elements addressed from 0 to , often prefixed in documentation (e.g., 4xxxx for holding registers). handling includes exception responses for issues like invalid addresses or unsupported functions, using codes such as 01 (illegal function) or 02 (illegal address). Modbus has evolved into several variants to accommodate different network types, including Modbus RTU (binary format over serial lines like with CRC error checking and silent inter-frame periods), Modbus ASCII (human-readable hexadecimal over serial with LRC checks), and Modbus TCP/IP (adapted for Ethernet using TCP for reliable delivery and a Modbus Application Protocol header). The protocol's serial line specifications date back to 1996, with ongoing updates like the Modbus Security Protocol, which integrates (TLS) and X.509v3 certificates for authentication and integrity on port 802. Despite its simplicity and lack of native support for advanced features like large data types or built-in security in base variants, Modbus remains a due to its openness, broad device compatibility, and ease of implementation in industrial environments. In practice, Modbus powers critical applications in , , and process control, enabling seamless integration between PLCs, sensors, drives, and supervisory systems while serving as a foundational protocol in the transition to Industrial IoT (IIoT). Its enduring popularity stems from over four decades of widespread adoption, with conformance classes (0 for basic public functions, 1 for diagnostics, and 2 for vendor-specific extensions) ensuring interoperability across thousands of compliant devices globally.

Overview

History and Development

The Modbus protocol was developed in 1979 by Modicon, a pioneering company in programmable logic controllers (PLCs) that is now part of , to enable reliable communication between PLCs and other devices in industrial automation systems. Initially designed as a simple, master-slave protocol for reading and writing data over serial lines such as and , it addressed the need for standardized data exchange in manufacturing environments dominated by Modicon's proprietary hardware. This foundational version, often referred to as Modbus RTU or ASCII, quickly gained traction within Modicon ecosystems for its robustness and ease of implementation in multidrop networks. Originally proprietary to Modicon, the protocol was released as an open, royalty-free standard in the , allowing broader adoption across vendors and reducing barriers to in industrial settings. A significant milestone came in 1999 with the introduction of Modbus TCP/IP by Modicon, which extended the protocol over Ethernet networks using TCP/IP as the , facilitating higher-speed integration with modern IT infrastructure while preserving the core messaging structure. This adaptation marked Modbus's transition from serial-based systems to networked environments, enhancing its applicability in distributed control architectures. In 2004, transferred stewardship of the Modbus specification to the newly formed Modbus Organization, a nonprofit comprising users, suppliers, and developers dedicated to maintaining, evolving, and certifying the protocol. This shift ensured ongoing support and , solidifying Modbus's status as a . Evolution continued with proprietary variants like Modbus Plus, introduced by Modicon in the late as a high-speed, token-passing network for demanding applications, though it diverged from the in implementation. Additionally, integrations such as gateways for have enabled Modbus to coexist with other industrial protocols, extending its utility in hybrid networks.

General Protocol Characteristics

Modbus operates as a client-server, request-response protocol, originally designed as a master-slave , facilitating communication between devices in industrial environments. In this model, a single client (master) initiates requests to one or more servers (slaves), which respond with the requested data or actions, enabling efficient control and monitoring without constant polling from all devices simultaneously. This structure positions Modbus at the of the , independent of the underlying physical and data link layers, allowing it to run over serial lines, Ethernet, or other networks. Key characteristics of Modbus include its simplicity, openness, and royalty-free nature, which have contributed to its widespread adoption since its inception. The protocol features a minimalistic messaging structure with low overhead, making it easy to implement on resource-constrained devices such as programmable logic controllers (PLCs), sensors, and actuators. It supports up to 247 devices on a single network, addressed via 8-bit identifiers ranging from 1 to 247, allowing for scalable deployments in multi-device systems. As an maintained by the , it is freely available for use without licensing fees, promoting across vendors in industrial control systems (ICS), supervisory control and data acquisition (), and automation applications. Modbus finds primary applications in industries such as , production, and , where it enables the reading and writing of discrete inputs/outputs, analog values, and diagnostic information between field devices and control systems. For instance, it allows PLCs to query sensors for process variables like or and command actuators to adjust valves or motors accordingly, supporting real-time tasks. Its ease of implementation and low protocol overhead make it suitable for legacy and modern systems alike, though it lacks built-in security mechanisms such as or , necessitating additional safeguards in sensitive deployments.

Protocol Fundamentals

PDU and ADU Structure

In the Modbus protocol, the (PDU) represents the core, application-layer message that is independent of the underlying physical and layers. It consists of a single-byte function code followed by variable-length bytes specific to the requested operation or response. The function code, ranging from 0x01 to 0xFF (with values 0x80 to 0xFF indicating exceptions), specifies the action to be performed, such as reading or writing , while the data field carries parameters like register addresses or values. The maximum PDU size is 253 bytes to accommodate transport-layer constraints, ensuring compatibility across different implementations. The Application Data Unit (ADU) encapsulates the PDU with transport-specific headers and integrity checks to form a complete frame suitable for transmission over a particular medium. In serial line implementations, the ADU prepends a one-byte slave (ranging from 0x01 to 0xF7 for individual devices or 0x00 for broadcast) to the PDU and appends an error-checking field: either a two-byte CRC-16 for binary RTU mode or a one-byte LRC for ASCII mode. This results in a maximum ADU of 256 bytes for RTU, comprising the , up to 252 bytes of PDU data, and the CRC. For ASCII mode, the ADU uses printable characters, with the and LRC each represented as two characters, leading to a maximum of 513 characters including delimiters. For Modbus TCP, the ADU replaces serial-specific elements with a seven-byte Modbus Application Protocol (MBAP) header prefixed to the PDU, yielding a maximum of 260 bytes. The MBAP includes a two-byte transaction identifier for matching requests and responses, a two-byte protocol identifier (fixed at 0x0000 for Modbus), a two-byte field indicating the bytes following it (always at least 1 for the unit identifier), and a one-byte unit identifier serving as the logical slave address. Unlike serial ADUs, TCP variants omit explicit CRC or LRC, relying instead on the TCP/IP stack's checksum mechanisms for error detection. Error-checking fields ensure data integrity in serial ADUs. The CRC-16 used in RTU mode employs the polynomial 0xA0010xA001 (equivalent to x16+x15+x2+1x^{16} + x^{15} + x^2 + 1) with an initial register value of 0xFFFF0xFFFF. The calculation processes each byte of the message (address through PDU data) by XORing it with the low byte of the register, right-shifting 16 times while XORing the polynomial into the high byte whenever the outgoing bit is 1, and appending the low byte followed by the high byte. For ASCII mode, the LRC is computed as the two's complement negation of the sum of all message bytes (address through PDU data) modulo 256, represented in two hexadecimal characters with the high-order nibble first. These mechanisms provide robust frame validation without impacting the protocol-independent PDU.
ComponentRTU ADU (Serial)ASCII ADU (Serial)TCP ADU
Prefix/HeaderSlave Address (1 byte)Start (:) + Address (2 chars) + Function (2 chars)MBAP (7 bytes: Transaction ID , Protocol ID , Length , Unit ID )
CorePDU (up to 253 bytes: Function Code + Data [0-252])Data (up to 2×252 chars)PDU (up to 253 bytes: Function Code + Data [0-252])
Suffix/CheckCRC-16 (2 bytes)LRC (2 chars) + End (CR LF)None (TCP checksum)
Max Length256 bytes513 characters260 bytes

Data Model and Addressing

Modbus employs a straightforward organized into four distinct tables, each representing a different type of data accessible within a device. These tables are: coils (discrete outputs), discrete inputs, holding registers, and input registers. Coils and discrete inputs store single-bit values, while holding and input registers hold 16-bit words. This model allows for the logical separation of read-write and read-only data, as well as bit-level and word-level information, facilitating efficient access in industrial control systems. The following table summarizes the four data tables, including their characteristics and associated primary function codes for access:
Data TableDescriptionAccess TypeSizePrimary Function Codes
CoilsDiscrete outputs (bits)Read-Write1 bit01 (Read), 05/15 (Write)
Discrete InputsDiscrete inputs (bits)Read-Only1 bit02 (Read)
Holding RegistersAnalog values/output (words)Read-Write16 bits03 (Read), 06/16 (Write)
Input RegistersAnalog input values (words)Read-Only16 bits04 (Read)
Each table supports up to 65,536 (2^16) addresses, addressed using 16-bit unsigned integers ranging from 0 to 65,535 in the protocol definition. However, practical limitations arise from the function codes, which allow accessing up to 2,000 consecutive coils or discrete inputs or 125 holding or input registers per transaction, depending on the function code (e.g., function code 01 reads up to 2,000 coils). In the protocol, addressing is zero-based, starting from 0, but many device implementations and documentation use one-based referencing for readability, such as labeling the first coil as 00001 (corresponding to protocol address 0) or the first holding register as 40001. Data types in Modbus are limited to support its original design for simple industrial . Coils and discrete inputs represent values (on/off, 0/1). Holding and input registers store 16-bit integers, which can be interpreted as signed or unsigned depending on the application. Larger data types, such as 32-bit integers or floating-point numbers, are not natively supported but can be represented by combining two consecutive registers (e.g., a 32-bit float spans registers N and N+1, with byte ordering conventions like big-endian or little-endian specified by the device). The protocol provides no built-in support for strings, 64-bit values, or other complex types; such representations must be handled at the by concatenating multiple registers. Device addressing in Modbus distinguishes between serial and TCP implementations. In serial modes (RTU/ASCII), each slave device is assigned a unique slave ID from 1 to 247, with 0 reserved for broadcast messages that do not require a response. For Modbus TCP, the and (default 502) identify the device, while a one-byte unit identifier (0–255) in the MBAP header serves a similar role to the slave ID, enabling through gateways or encapsulation of serial Modbus messages over TCP; a value of 255 is commonly used for direct TCP devices or unspecified . This unit identifier is echoed back in responses and ignored by simple TCP servers.

Communication Mechanisms

Modbus Transactions

Modbus transactions operate on a , where the master (client) initiates all communications in a polling manner by transmitting a request Application Data Unit (ADU) to one or more slave devices (servers). The targeted slave processes the request and returns a response ADU containing the results or an indication of success; requests to specific slaves expect a reply, while the master implements a timeout mechanism—typically 1 to several seconds at —to detect non-responses and handle errors accordingly. In broadcast transactions, the master addresses the request to all slaves using device 0, limiting it to write operations since no responses are generated or expected from the slaves; this allows efficient multi-device updates without reply overhead. The master-slave polling ensures orderly access to shared media, preventing collisions in multi-drop networks. Timing constraints are essential for reliable transaction framing, particularly in serial line implementations. In Modbus RTU mode, a frame begins and ends with a silent interval of at least 3.5 character times, while the interval between consecutive characters must not exceed 1.5 character times to avoid the receiver declaring the frame incomplete and discarding it. For ASCII mode, inter-character timeouts allow up to 1 second of silence. Turnaround delays after broadcasts range from 100 to 200 ms to permit slave processing before the next master transmission, and these must be shorter than the overall response timeout. A representative example of a simple read transaction involves the master sending an ADU with the slave's address, a read function identifier, and references to specific data locations such as coils or holding registers. Upon receipt, the slave validates the request, retrieves the data, and transmits a response ADU mirroring the structure but populated with the read values; the entire exchange completes within the configured timeout if successful. These transactions reference the Modbus of discrete inputs, coils, input registers, and holding registers.

Function Codes Overview

Modbus function codes define the specific operations requested by a client device in a Modbus transaction, forming a critical part of the (PDU) to specify actions such as reading or writing data from server devices. These codes are standardized to ensure across devices, with the function code occupying the first byte of the PDU following the transaction identifier and protocol ID fields. Some functions include an optional subfunction code byte for additional specificity, such as in diagnostic operations, while multi-bit or multi-register functions employ bitmasks or byte arrays to efficiently handle batches of data without individual addressing. Function codes are categorized into public, user-defined, and reserved groups to balance standardization with flexibility for custom implementations. Public codes, ranging from 1 to 127 (0x01 to 0x7F), are officially defined and validated by the Modbus Organization for broad use in reading and writing coils (discrete outputs) and registers (analog values). User-defined codes, in the ranges 65-72 (0x41-0x48) and 100-110 (0x64-0x6E), allow vendors to implement device-specific commands without conflicting with public standards, though they lack uniqueness guarantees and are intended for proprietary extensions. Reserved function codes are those currently used by some companies for legacy products and are not available for public use (as listed in Annex A of the specification). The public function codes are grouped by data type and operation, primarily targeting coils (single-bit values representing on/off states) and registers (16-bit words for holding or input data). For coils, code 01 reads the status of multiple coils, code 02 reads discrete inputs (read-only coil equivalents), code 05 writes a single coil to on or off, and code 15 writes multiple coils using a bitmask-packed byte array for efficiency. For registers, code 03 reads multiple holding registers (writable), code 04 reads input registers (read-only), code 06 writes a single holding register, code 16 writes multiple holding registers with a sequence of 16-bit values, code 22 performs a mask write on a single register using AND/OR bitmasks to modify specific bits without affecting others, and code 23 combines reading and writing multiple holding registers in one transaction to reduce communication overhead. These groupings enable targeted access to the Modbus data model, where coils address up to 2000 bits and registers up to 125 words per function call, promoting scalable industrial automation.
CategoryCode (Hex)PurposeData Type
Public (Coils/Discrete)01Read multiple coilsBits (outputs)
Public (Coils/Discrete)02Read discrete inputsBits (inputs)
Public (Coils/Discrete)05Write single coilBit (output)
Public (Coils/Discrete)15 (0F)Write multiple coilsBits (outputs, bitmask)
Public (Registers)03Read holding registers16-bit words (holding)
Public (Registers)04Read input registers16-bit words (input)
Public (Registers)06Write single register16-bit word (holding)
Public (Registers)16 (10)Write multiple registers16-bit words (holding)
Public (Registers)22 (16)Mask write register16-bit word (holding, bitmask)
Public (Registers)23 (17)Read/write multiple registers16-bit words (holding)
Exception responses, which modify the function code by setting the high-order bit, are used when a server cannot process a public function request due to errors like invalid addresses.

Error Handling

Exception Responses

In Modbus, when a server (slave) encounters an error while processing a client (master) request, it generates an exception response to indicate the issue rather than a normal response. The server detects errors such as unsupported functions, invalid addresses, or invalid data values in the request. To signal an exception, the server modifies the function code in the response by setting its most significant bit to 1, which is equivalent to adding 0x80 (in hexadecimal) to the original function code; for example, a request with function code 0x01 would result in an exception response with function code 0x81. This modified function code allows the client to immediately recognize the response as an exception without parsing further data. The structure of an exception response follows the same application data unit (PDU) format as a normal response but includes the modified function code followed by a single-byte exception code in the field, with no additional . In the full application data unit (ADU), which encompasses the PDU plus transport-layer elements (such as address fields in serial implementations or transaction identifiers in TCP), the exception response maintains the overall frame structure of the original request type but flags the error via the function code and exception code. This concise format ensures minimal overhead while providing essential diagnostic information about the failure. Modbus defines a set of standard exception codes to specify the nature of the error, each represented as a single byte value. These codes are universally applicable across Modbus variants and are returned only when a specific condition is met during request validation or execution. The following table summarizes the standard exception codes:
Code (Hex)NameDescription
01Illegal FunctionThe function code received is not supported by the server or the server is in an improper state to execute it.
02Illegal Data AddressThe data address referenced in the request is not accessible or does not exist in the server's data model.
03Illegal Data ValueA value contained in the request data is invalid, such as a quantity exceeding supported limits.
04Server Device FailureAn unrecoverable error occurred while the server attempted to perform the requested action.
05AcknowledgeThe server has accepted the request but requires significant processing time; the client should perform a polling operation to monitor completion, such as using Read Exception Status (function code 0x07).
06Server Device BusyThe server is engaged in processing another request and cannot handle the current one; the client should retry later.
07Negative AcknowledgeThe data value received in the query is not an allowable value for the server (e.g., a parameter that is ignored or an unsupported operation).
08Memory Parity ErrorA parity error was detected in the memory during file record read or write operations (specific to functions 20 and 21).
0AGateway Path UnavailableIn a gateway configuration, the path to the target device cannot be established due to configuration or overload issues.
0BGateway Target Device Failed to RespondThe gateway was unable to receive a valid response from the target device within the timeout period.
Upon receiving an exception response, the client typically logs the for diagnostics, may retry the transaction after a delay (especially for transient errors like code 06), or escalate to higher-level handling in the application. This mechanism enhances transaction reliability by allowing graceful degradation in noisy or fault-prone environments, though repeated exceptions can indicate configuration issues or hardware faults requiring manual intervention. The exception responses are integral to Modbus's robustness, ensuring that errors do not propagate silently and enabling systematic in industrial control systems.

Diagnostic and Error Codes

Modbus provides diagnostic capabilities primarily through Function Code 08 (Diagnostics), which enables masters to query slaves for communication status and internal error conditions, particularly in serial line implementations. This function is essential for network issues, such as verifying message integrity or resetting communication counters, without disrupting normal data access operations. It operates by specifying a subfunction code in the request PDU to select the diagnostic test, with the slave echoing or providing relevant data in the response. The subfunctions for Diagnostics (Function Code 08) include a range of tests, as defined in the Modbus Application Protocol Specification. For example, subfunction 00 (Return Query Data) simply echoes the request data back to confirm basic communication, while subfunction 01 (Restart Communications Option) restarts the slave's communication port and clears diagnostic counters, though it generates no response if the slave is in Listen Only Mode. Other key subfunctions provide counters for error tracking: subfunction 0C (Return Bus Communication Error Count) reports the number of messages discarded due to CRC errors since the last restart, and subfunction 0D (Return Bus Exception Error Count) counts exception responses sent by the slave. The complete set of subfunctions includes the following:
Subfunction (Hex)DecimalNameDescription
000Return Query DataEchoes request data for communication verification.
011Restart Communications OptionRestarts port and clears counters; no response in Listen Only Mode.
022Return Diagnostic RegisterReturns 16-bit diagnostic register contents.
033Change ASCII Input DelimiterSets new end-of-message delimiter (replaces default colon and line feed).
044Force Listen Only ModePuts device in Listen Only Mode; no response returned.
0A10Clear Counters and Diagnostic RegisterClears all counters and diagnostic register.
0B11Return Bus Message CountReturns total messages processed or detected since last restart.
0C12Return Bus Communication Error CountCounts CRC errors since restart.
0D13Return Bus Exception Error CountCounts exception responses since restart.
0E14Return Server Message CountCounts processed messages since restart.
0F15Return Server No Response CountCounts messages addressed to server but no response sent since restart.
1016Return Server NAK CountCounts Negative Acknowledge exception responses since restart.
1117Return Server Busy CountCounts Server Device Busy exception responses since restart.
1218Return Bus Character Overrun CountCounts messages lost due to character overrun since restart.
1420Clear Overrun Counter and FlagClears overrun error counter and resets overrun flag.
Beyond Function Code 08, vendor-specific diagnostics are supported through the Modbus Encapsulated Interface (MEI) via Function Code 43 (Read Device Identification), which encapsulates additional interfaces for extended querying. MEI Type 14 specifically enables reading device identification objects, such as vendor name, product code, and revision details, which assist in diagnosing compatibility or configuration issues during troubleshooting. MEI Type 13 provides access to CANopen object dictionary entries for devices supporting that extension, allowing indirect error analysis through specialized data reads. These MEI mechanisms are particularly useful in TCP/IP implementations for non-standard diagnostic needs, though they rely on standard exception codes for error reporting. In addition to proactive diagnostic queries, Modbus includes non-exception error indicators detected primarily by the master during communication. Timeout errors occur when no response is received within the configured interval, often signaling or slave unavailability. CRC failures in RTU mode or LRC errors in ASCII mode are detected by the master upon validating the received frame, prompting retransmission or alerting for cabling faults. In serial implementations, parity errors during bit transmission indicate or hardware issues, typically leading to frame rejection without a slave response. These indicators complement diagnostic functions by providing immediate feedback on transmission integrity, essential for maintaining reliable industrial networks.

Serial Line Implementations

Modbus RTU

Modbus RTU is a binary of the Modbus protocol designed for , utilizing compact 8-bit byte encoding to maximize efficiency on low-bandwidth lines. Each byte in an RTU frame consists of 1 start bit, 8 data bits transmitted least significant bit first, an optional , and 1 or 2 stop bits, resulting in a total of 11 bits per character. Even parity is typically required, though odd parity or no parity (with 2 stop bits) may be used depending on the . This binary format allows for higher data throughput compared to text-based alternatives due to its greater character density. RTU frames are delimited by periods of silence on the communication line, with a minimum of 3.5 character times of idle space before the start of a frame and after its end to separate messages. The frame structure begins with a 1-byte slave address field (ranging from 1 to 247, or 0 for broadcast), followed by a 1-byte function code, a variable-length field (0 to 252 bytes), and ends with a 2-byte CRC-16 checksum appended in low-byte-first order. The total frame length is limited to a maximum of 256 bytes to ensure compatibility across devices. Strict timing is essential for RTU operation to detect frame boundaries and errors; between consecutive characters within a frame, the inter-character timeout must not exceed 1.5 character times, or the receiver discards the frame. For baud rates of 19,200 bits per second or lower, these timings are calculated directly in character times (e.g., 3.5 character times equates to approximately 1.75 ms at 19.2 kbps), while higher baud rates use fixed values of 1.750 ms for the frame delimiter and 750 µs for inter-character gaps to account for hardware variations. Modbus RTU is particularly suited for resource-constrained serial interfaces such as and , where its compact binary nature optimizes bandwidth usage in master-slave or multi-drop network configurations. It supports up to 247 addressable slave devices in a network, though practical limits without repeaters typically allow for 32 devices due to electrical constraints on bus loading.

Modbus ASCII

Modbus ASCII is a human-readable variant of the Modbus protocol designed for transmission over serial lines, where each binary byte is represented by two characters in the ASCII character set. This mode encodes the (PDU) into a text-based frame that begins with a colon (:) character (ASCII 3A hex) and ends with a return-line feed (CRLF) pair (ASCII 0D 0A hex), making it suitable for environments where of messages is beneficial. Unlike binary formats, Modbus ASCII allows for easier and since the transmitted data can be directly interpreted by humans using standard text tools. The frame structure in Modbus ASCII consists of the start (1 character), slave address (2 characters), function code (2 characters), data field (an even number of characters, up to 504 for a maximum PDU size of 252 bytes), (LRC) (2 characters), and end (2 characters), resulting in a total frame length of up to 513 characters. Each byte from the binary message is converted to two ASCII digits (0-9, A-F), ensuring the data portion has an even character count. The LRC, an 8-bit , is computed by summing all bytes in the address, function, and data fields (excluding delimiters), taking the of the result, and appending it as two characters before the CRLF; this provides basic error detection for the frame. Timing requirements in Modbus ASCII are more lenient than in binary modes, with inter-character intervals permitted up to 1 second (or up to 4-5 seconds in wide-area network scenarios) before the frame is considered invalid, eliminating the need for precise millisecond-level . This flexibility arises because the explicit start and end delimiters (: and CRLF) clearly bound the message, allowing receivers to tolerate delays without ambiguity. However, the encoding doubles the transmission size compared to binary equivalents, leading to higher bandwidth consumption and reduced throughput at the same rate, which can slow parsing and increase latency in high-volume applications. Modbus ASCII is particularly employed in legacy systems or scenarios where the strict timing constraints of binary modes cannot be reliably met, such as over noisy or low-speed serial connections, and its readable format supports and integration with text-based monitoring tools. Despite these benefits, its inefficiencies make it less common in modern, high-performance industrial networks, where compact binary alternatives are preferred for better resource utilization.

TCP/IP Implementations

Modbus TCP

Modbus TCP is an adaptation of the Modbus protocol designed for communication over Ethernet networks using the Transmission Control Protocol (TCP) as the . It encapsulates the Modbus (PDU) within an Application Data Unit (ADU) that includes a Modbus Application Protocol (MBAP) header, eliminating the need for slave address fields and cyclic redundancy checks (CRC) present in serial variants. This implementation enables direct integration with standard TCP/IP infrastructure, allowing Modbus devices to operate within or environments without requiring specialized serial hardware. The MBAP header consists of four fields: a 2-byte transaction identifier for matching requests and responses, a 2-byte protocol identifier set to 0 to denote Modbus TCP, a 2-byte length field indicating the size of the subsequent data, and a 1-byte unit identifier for to specific devices on the network. Modbus TCP operates on TCP port 502, facilitating client-server interactions where clients initiate connections to servers. These connections are typically persistent, supporting multiple concurrent transactions over a single socket; the transaction identifier ensures proper pairing of requests and responses, preventing mismatches in high-traffic scenarios. Unlike serial Modbus, there is no inherent addressing or error-checking overhead in the ADU, as TCP handles reliability and ordering. To illustrate, consider a request to read two holding registers starting from 0 using function code 03. The ADU in format is 00 01 00 00 00 06 01 03 00 00 00 02, broken down as follows:
  • 00 01: Transaction identifier
  • 00 00: Protocol identifier (0)
  • 00 06: Length (6 bytes following)
  • 01: Unit identifier
  • 03: Function code (read holding registers)
  • 00 00: Starting register
  • 00 02: Number of registers
A corresponding response, assuming values of 555 and 100 in the registers, would be 00 01 00 00 00 07 01 03 04 02 2B 00 64:
  • 00 01: Transaction identifier
  • 00 00: Protocol identifier (0)
  • 00 07: Length (7 bytes following)
  • 01: Unit identifier
  • 03: Function code
  • 04: Byte count (4 bytes of data)
  • 02 2B 00 64: Register values (big-endian: 555 and 100 )
This structure maintains compatibility with core Modbus PDUs while leveraging TCP for transport. Modbus TCP offers significant advantages over serial implementations, including higher data transmission speeds—up to 100 Mbps or more on standard Ethernet—and the ability to cover longer distances without repeaters, limited only by . It is widely deployed in modern industrial control systems (ICS), often via gateways that bridge legacy serial devices to Ethernet, enhancing and remote in environments like and .

Modbus over UDP and Other IP Variants

Modbus over UDP represents a connectionless adaptation of the Modbus protocol, leveraging the (UDP) for IP-based communication, typically on port 502. This variant retains the core Modbus while eliminating the connection overhead of TCP, enabling faster transmission with reduced bandwidth usage. It supports stateless, transaction-oriented exchanges where requests and responses are paired using a transaction identifier in the MBAP header, similar to Modbus TCP but without persistent sessions. Key advantages include support for and broadcast messaging, which facilitates efficient dissemination in multi-device environments such as low-latency sensor networks in industrial IoT setups. For instance, in real-time monitoring applications, UDP's nature allows quicker polling of multiple slaves without the retransmission delays inherent in TCP. However, the lack of built-in reliability means no guaranteed delivery, ordering, or error correction at the , necessitating application-level acknowledgments and retry logic to handle . This makes Modbus UDP particularly suited for scenarios where occasional is tolerable, but it sees limited adoption due to the prevalence of more robust alternatives and the absence of an official specification from the Modbus . Beyond UDP, other IP variants extend Modbus TCP with enhancements, such as the Modbus Security Protocol, which integrates (TLS) to encapsulate messages, ensuring via X.509v3 certificates, , and . Operating on port 802, this wrapper addresses Modbus's inherent vulnerabilities in open networks by providing encrypted channels without altering the underlying protocol structure. Additionally, protocol gateways enable Modbus integration with contemporary IP-based systems, mapping device registers to publish/subscribe topics for cloud connectivity or to OPC UA information models for secure, semantic exchange in enterprise environments. These mappings support IIoT but require careful configuration to maintain timing and . Overall, such variants enhance Modbus's versatility on IP networks while mitigating its traditional limitations in reliability and .

Protocol Extensions and Variants

User-Defined and Reserved Codes

In the Modbus protocol, user-defined function codes provide a mechanism for implementers to extend the standard set of operations without conflicting with publicly defined codes. These codes allow for the creation of custom services tailored to specific applications, such as device interactions or specialized data exchanges. The ranges designated for user-defined codes are 65 to 72 ( 0x41 to 0x48) for simple extensions and 100 to 110 ( 0x64 to 0x6E) for more complex encapsulated interfaces. Implementers selecting these codes must ensure no overlap with public function codes (1 to 64), and there is no guarantee of uniqueness unless a (RFC) is submitted to the Modbus Organization for potential reclassification as public. Reserved function codes, spanning 73 to 99 (hexadecimal 0x49 to 0x63) and 111 to 127 (hexadecimal 0x6F to 0x7F), are held exclusively for future allocation by the and are not available for public or user-defined implementations. These ranges support legacy uses by specific companies but prohibit new public developments to maintain protocol integrity. No known public implementations exist within these reserved spaces, ensuring they remain protected for standardized extensions. Implementation guidelines emphasize compatibility and non-interference; user-defined codes must adhere to the general (PDU) structure, with responses including the same function code unless an exception occurs (indicated by setting the high-order bit). These codes are often employed for proprietary features, such as advanced operations that build on public codes like 20 (Read File Record) and 21 (Write File Record) for subfunction-based record access, or function code 23 (Read/Write Multiple Registers) for atomic read-write combinations in specialized contexts. A key application of the higher user-defined range involves encapsulation, where function code 43 (Encapsulated Interface Transport) uses Modbus Encapsulated Interface (MEI) types—such as type 13 for tunneling commands—to wrap non-Modbus protocols within a Modbus frame for in hybrid networks.
CategoryDecimal RangeHexadecimal RangePurpose
User-Defined (Simple)65–720x41–0x48Basic custom extensions without encapsulation
User-Defined (Encapsulated)100–1100x64–0x6EComplex interfaces, e.g., protocol tunneling
Reserved73–990x49–0x63Future public use by
Reserved111–1270x6F–0x7FLegacy and future allocations, no new public use

JBUS and Enron-Daniels Mappings

JBUS, developed in 1985 by the French company Merlin Gerin (now part of ), represents an early variant of the Modbus protocol tailored for industrial in programmable logic controllers. This protocol emerged from collaborations between companies like Automation and Merlin Gerin, sharing the core Modbus messaging structure but introducing specific adaptations for compatibility with their hardware. Over time, initial differences in entity counts and slave station limits became obsolete, aligning JBUS closely with standard Modbus. The primary distinction in JBUS lies in its addressing scheme, which employs zero-based indexing compared to Modbus's one-based indexing. For instance, a JBUS such as a word (QW) or bit (QB) at address n maps to the equivalent Modbus holding register or coil at address n + 1. This offset requires careful handling in gateways or drivers to ensure seamless , as JBUS objects like input words () or output words (QO) directly correspond to Modbus input or holding registers with the adjusted addressing. Function codes remain largely identical, supporting standard operations like reading or writing registers via codes 03 and 06. Today, JBUS is considered largely obsolete, having faded with the decline of associated legacy PLCs like the series, though it persists in some older European industrial equipment. The views such variants as historical, recommending standard Modbus for new deployments to avoid compatibility issues. The Enron-Daniels mapping extends Modbus for enhanced data precision, particularly in the and gas sector, where high-resolution measurements like flow rates demand 32-bit floating-point or long integer support beyond the protocol's native 16-bit registers. Originating from implementations by Corporation and Daniels (a equipment provider), this variant treats 32-bit values as single logical registers, returning 4 bytes per request instead of 2, often within designated address ranges such as 4x7001–4x7999 for floats. This approach modifies the interpretation of the register count in standard function codes like 03 (Read Holding Registers), assuming units of 32-bit words rather than 16-bit, which can lead to offset errors if not handled explicitly (e.g., the next block starts at 4x5051, not 4x5101). A key non-standard aspect involves the use of function codes 20 (Read File Record) and 21 (Write File Record), originally defined for accessing sequential files in Modbus, but repurposed here to read and write 32-bit high-precision records in a structured format. For example, in Daniels flow computers like the 2551 series, function 20 retrieves sequential of extended , enabling efficient transfer of multi-word values without fragmenting them across standard register reads. This mapping supports industry-specific needs, such as AGA gas metering calculations, by embedding 32-bit longs in 4x5001–4x5999 ranges. Enron-Daniels remains common in legacy supervisory control and (SCADA) systems for oil and gas but is discouraged for new designs by the Modbus Organization due to its deviations from the standard protocol, which can cause failures with compliant devices. Support persists in specialized drivers and gateways for .

Security and Limitations

Known Vulnerabilities

Modbus lacks built-in , , and checks, exposing it to , modification, and unauthorized access by attackers on the same network. This , originating from its development in the late for industrial environments assuming trusted networks, allows any device to send commands, enabling unauthorized reads or writes to registers and coils without verification of the sender's identity. For instance, attackers can exploit this to alter control parameters, potentially causing physical damage in industrial control systems (ICS). Replay attacks are a significant risk due to the absence of session or timestamps in the protocol, permitting captured packets to be retransmitted to execute legitimate commands illicitly. In Modbus TCP implementations, man-in-the-middle (MITM) attacks are facilitated by the lack of , often combined with to redirect traffic and impersonate devices. Broadcast write functions, using address 0 in Modbus TCP, allow a single malicious packet to affect all listening devices on the network, amplifying the impact of unauthorized commands. Device enumeration is straightforward through port scanning on TCP port 502 or serial line probing, revealing active slaves and their configurations without barriers. Specific vulnerabilities have been documented in various implementations. For example, CVE-2017-6032 highlights a session-related weakness in Modicon Modbus protocol, enabling brute-force attacks to replay sensitive commands. CVE-2021-22779 (ModiPwn) demonstrates how attackers can bypass in Modicon PLCs by exploiting Modbus's lack of , allowing remote code execution. Additionally, malformed packets can trigger denial-of-service (DoS) conditions, as seen in CVE-2023-25619, where improper handling of exceptional conditions in Modbus communications causes controller unresponsiveness. More recent vulnerabilities include CVE-2024-10918, a stack-based in libmodbus version 3.1.10, which could allow remote to execute arbitrary code or cause a DoS by sending specially crafted Modbus responses. In 2024, the FrostyGoop was discovered targeting ICS environments, exploiting Modbus protocol weaknesses to manipulate device controls and exfiltrate data. A notable real-world incident occurred in 2024 when used Modbus commands to alter readings in a Ukrainian heating utility, disrupting operations and demonstrating the protocol's ongoing risks in . To mitigate these vulnerabilities, isolates Modbus traffic using VLANs or air-gapped systems, preventing lateral movement by attackers. Firewalls should restrict access to port 502, allowing only whitelisted IP addresses and function codes. Wrapping Modbus in VPN or provides and ; for instance, can encapsulate Modbus TCP to ensure and prevent replay via session keys. The Modbus Security protocol, specified in 2018 and using () with certificates on port 802 for and , remains largely unimplemented in commercial devices as of 2025, with limited adoption reported. CISA recommends ongoing use of and monitoring for legacy Modbus systems lacking native security.

Performance and Scalability Issues

Modbus serial implementations, particularly RTU and ASCII over , are constrained by low bandwidth, typically operating at rates from 9.6 kbps to 115.2 kbps, which limits the network to only a few transactions per second depending on message size and inter-frame delays of at least 3.5 character times. This results in effective throughputs often below 10 kbps in practice for multi-device setups, making it unsuitable for high-volume data exchange. In contrast, Modbus TCP leverages Ethernet's higher speeds—up to 100 Mbps or more—but suffers from polling overhead, where the master sequentially queries slaves, reducing effective bandwidth utilization to 1-10% in busy networks due to request-response cycles and TCP/IP encapsulation. Scalability in Modbus is inherently limited, with serial variants supporting a maximum of 247 slaves per master to avoid address conflicts and maintain reliable addressing from 1 to 247. Without native prioritization or quality-of-service mechanisms, large systems exceeding 100 devices experience bottlenecks, as each slave must wait for its poll cycle, amplifying delays in master-slave communications. Modbus TCP offers theoretical scalability beyond 247 devices via IP addressing, but practical performance degrades similarly in oversized networks due to the lack of built-in , leading to increased latency and dropped requests under load. Key performance issues stem from the protocol's design, including half-duplex operation in serial modes, which risks data collisions if turnaround timing (e.g., 100-200 ms for broadcast responses) is not precisely managed, further slowing communications. Basic Modbus TCP lacks protocol-level flow control beyond TCP's congestion avoidance, exacerbating issues in contended networks, while overall latency ranges from milliseconds at high rates to seconds in low-speed or crowded setups, rendering it inadequate for real-time applications requiring sub-10 ms responses. To mitigate these, common workarounds include deploying gateways to bridge Modbus with higher-performance protocols like for enhanced throughput and scalability, or optimizing master configurations with reduced polling rates to balance load and minimize overhead.

References

  1. https://www.modbus.org/introduction-to-modbus
  2. https://www.ni.com/en/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/the-modbus-protocol-in-depth.html
  3. https://www.modbus.org/modbus-specifications
  4. https://www.rtautomation.com/technologies/modbus-tcpip/
  5. https://www.se.com/us/en/product-range/574-modbus/
  6. https://www.prosoft-technology.com/kb/assets/intro_modbustcp.pdf
  7. https://www.emqx.com/en/blog/modbus-protocol-the-grandfather-of-iot-communication
  8. https://us.profinet.com/white-papers/profibus-v-modbus/
  9. https://www.wevolver.com/article/modbus-tcp-ip
  10. https://www.hilscher.com/service-support/glossary/modbus
  11. https://www.afs.enea.it/project/protosphera/Proto-Sphera_Full_Documents/mpdocs/docs_EEI/Modbus_Application_Protocol_V1_1b3.pdf
  12. https://www.modbus.org/
  13. https://ieeexplore.ieee.org/document/8997492
  14. https://pmc.ncbi.nlm.nih.gov/articles/PMC9607043/
  15. https://cdn.linak.com/-/media/files/ic-and-bus-actuators/modbus-over-serial-line-v1-02.pdf

  16. Summary of the Modbus Protocol

  17. Modbus consists of a set of standardized digital codes intended to read data from and write data to industrial devices. A Modbus-compliant industrial device has ...
  18. https://ctlsys.com/support/modbus-register-addressing/
  19. https://www.support.aceautomation.eu/wp-content/uploads/Modbus_Application_Protocol_V1_1b.pdf
  20. https://ipc2u.com/articles/knowledge-base/detailed-description-of-the-modbus-tcp-protocol-with-command-examples/
  21. https://jamod.sourceforge.net/kbase/modbus_udp.pdf
  22. https://www.modbus.org/specs.php
  23. https://www.emqx.com/en/blog/bridging-modbus-data-to-mqtt-for-iiot
  24. https://industrial.softing.com/us/products/gateways/gateways-for-access-of-controller-data/uagate-mb.html
  25. https://www.can-cia.org/fileadmin/cia/documents/publications/cnlm/previous_issues/14-4_cnlm.pdf
  26. https://www.javanelec.com/stfiles/getappdocument/1/true/81099bbb-1242-4ef6-a853-9324cb10f73b.pdf
  27. https://minimalmodbus.readthedocs.io/en/stable/modbusdetails.html
  28. https://store.chipkin.com/articles/different-types-of-modbus-such-as-rtu-tcp-etc
  29. https://www.socomec.co.uk/sites/default/files/2021-02/JBUS-MODBUS-FOR-DELPHYS-MP-AND-DELPHYS-MX_INSTALLATION-AND-OPERATING-MANUAL_2005-08_MODBUS_EN-GB.pdf
  30. https://store.chipkin.com/articles/modbus-daniels-what-is-enron-or-daniels-modbus
  31. https://www.prosoft-technology.com/kb/article.php?id=601
  32. https://www.scribd.com/document/191825645/M2000-Technical-Manual-V6-300
  33. https://www.veridify.com/modbus-security-issues-and-how-to-mitigate-cyber-risks/
  34. https://www.sciencedirect.com/science/article/pii/S1877050925012566
  35. https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/lights-out-and-stalled-factories-using-matrix-to-learn-about-modbus-vulnerabilities/
  36. https://onlinelibrary.wiley.com/doi/10.1155/2021/8887666
  37. https://redbotsecurity.com/examining-the-modbus-protocol/
  38. https://www.mdpi.com/2571-5577/8/3/65
  39. https://www.armis.com/research/modipwn/
  40. https://www.cisa.gov/news-events/ics-advisories/icsa-17-101-01
  41. https://nvd.nist.gov/vuln/detail/CVE-2023-25619
  42. https://nvd.nist.gov/vuln/detail/CVE-2024-10918
  43. https://www.veridify.com/modbus-vulnerabilities-used-for-cyberattack-on-heating-utility/
  44. https://www.sealevel.com/securing-modbus-communications-modbus-tls-and-beyond
  45. https://www.incibe.es/en/incibe-cert/blog/evolving-towards-secure-modbus
  46. https://www.cisa.gov/news-events/ics-advisories/icsa-21-194-02
  47. https://www.ccontrols.com/pdf/Extv9n5.pdf
  48. https://www.rtautomation.com/rtas-blog/modbus-rtu-over-rs-485/
  49. https://www.iot.daviteq.com/post/modbus-protocol
  50. https://www.hashstudioz.com/blog/step-by-step-guide-setting-up-a-modbus-rtu-gateway-on-rs485/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.