P1: TIX/XYZ P2: ABC

JWST118-c05 JWST118-Hersent November 28, 2011 21:28 Printer Name: Yet to Come

5
ModBus

5.1 Introduction
Many protocols have been designed for the needs of industrial automation and metering.
These protocols generally use simple query/response models and allow for extremely
simple implementations. Many protocols derived from the frame formats defined by IEC
870-5 such as:

– T101 (IEC 870-5-101) that was generated by the IEC TC57 for electric utility com-
munication between master stations and remote terminal units, it is also based on the
IEC-870-5-x link layer, using frame format FT 1.2.
– DNP 3.0, a protocol originally designed by Westronic, Inc. that was released into the
public domain in 1993, based on the IEC-870-5-x link layer with a few modifications
(e.g., use of FT3 frames for asynchronous, rather than synchronous, communication,
inclusion of both source and destination addresses).
– M-Bus (see Section 9.3)
– Profibus, a fieldbus initially designed by Siemens and later standardized as IEC 61 158
(“Digital Data Communication for Measurement and control, Fieldbus for use in in-
dustrial control systems” for versions DP-V0, DP-V1 and DP-V2) and IEC 61 784
(Communication Profile Family DPF3). The protocols user’s association website is
http://www.profibus.com/.

Other protocols developed independently into de-facto standards, such as ModBus, a very
common protocol that is used in many industrial and HVAC installations.

The Internet of Things: Key Applications and Protocols, First Edition.

Olivier Hersent, David Boswarthick and Omar Elloumi.
© 2012 John Wiley & Sons, Ltd. Published 2012 by John Wiley & Sons, Ltd.
P1: TIX/XYZ P2: ABC
JWST118-c05 JWST118-Hersent November 28, 2011 21:28 Printer Name: Yet to Come

80 The Internet of Things

5.2 ModBus Standardization

ModBus is a trademark of Modicon inc (Schneider Electric group), which also main-
tains the standard. The ModBus standard specification over a serial line can be found at
http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf.
ModBus is an application layer messaging protocol that provides client/server com-
munication between devices connected on different types of buses or networks. Because
of its simplicity, ModBus has become one of the de-facto standards for industrial serial-
message-based communications since 1979.
ModBus typically runs on top of RS 232, RS 442 point to point or RS 485 point to
multipoint links. The ModBus/TCP specification, published in 1999 defines an IP-based
link layer for ModBus frames.
ModBus devices communicate using a master-slave model: one device, the master, can
initiate transactions (called queries), which can address individual slaves or be broadcast
to all slaves. The slaves take action as specified by the query, or return the requested data
to the master.

5.3 ModBus Message Framing and Transmission Modes

The transmission mode defines the framing and bit encoding of the messages to be
transmitted on the ModBus network. In a given ModBus network, all nodes must use the
same mode and serial parameters:

r In the ASCII Transmission Mode, each byte is encoded on the serial link as 2 ASCII
characters. Each ASCII character is sent separately as 1 start bit, 7 data bits, zero or one
parity bit, one or two stop bits. The message is framed by a starting “:” ASCII byte, and
ends with a “CR-LF” byte sequence (see Figure 5.1).
r In the RTU (remote terminal unit) transmission mode, the message is transmitted in a
continuous stream. Each 8-bit byte is framed by 1 start bit, 8 data bits, zero or one parity
bit, one or two stop bits. The message itself starts after a silent period of at least 3.5
character times.

ModBus Addresses: ModBus messages begin by the target 8-bit address that can take
any decimal value between 1 and 247. 0 is used for broadcasts. The address field of the
message frame contains two characters in ASCII mode, or 8 bits in RTU Mode. Each
query contains the address of a specific slave. When it responds, the slave includes its
own address in the message.
ModBus Functions: The function code field contains two characters in ASCII mode,
and 8 bits in RTU mode, which can take any decimal value between 1 and 255
and are selected based on the device application profile. Some example functions are
listed:
P1: TIX/XYZ P2: ABC
JWST118-c05 JWST118-Hersent November 28, 2011 21:28 Printer Name: Yet to Come

ModBus 81

ModBus ModBus
MASTER SLAVE
Query
:
(0x3A)
DeviceAddress (2 bytes)

Funcon code (2 bytes)

Query Data (variable)

CRLF
ErrorCheck (2 bytes) (0x0DOA)

Response
:
(0x3A)
DeviceAddress

Funcon code

Response Data

CRLF
ErrorCheck (0x0DOA)

Figure 5.1 ModBus message framing (ASCII mode).

r 0x02: Read Input Status. Parameters: starting register address, and number of consecu-
tive addresses to read. Response data: 1 bit per input read.
r 0x11: Report Slave ID. Parameters: none. Response data: slave ID, run indicator, device
specific data.

ModBus Data Field: The data field provides the application level information, as required
by the ModBus function. When a given ModBus function requires variable size data, the
data field begins with the “byte count” of the data.

5.4 ModBus/TCP
The ModBus/TCP specification can be found at http://www.eecs.umich.edu/∼modbus/
documents/Open_ModbusTCP_Standard.doc
ModBus/TCP provides TCP/IP access to the ModBus functionality. Each ModBus
Request/response is sent over a TCP connection established between the master and the
slave, using well-known port 502. The TCP connection may be reused for several query/
response exchanges.
The byte content of the ModBus request and response frames (i.e. without framing start-
stop-parity bits specific to the serial physical layer) is simply transported over the TCP
P1: TIX/XYZ P2: ABC
JWST118-c05 JWST118-Hersent November 28, 2011 21:28 Printer Name: Yet to Come

82 The Internet of Things

connection, in big indian order. The only addition of ModBusTCP is to add a seven-byte
message prefix:
ref ref 00 00 00 len unit

The ref bytes are simply copied by the slave from the request, and may be used as a handle
by the master. The length information in the message prefix allows proper reassembly of
the ModBus message when it has been segmented in several IP packets. The slave address
has been renamed “unit identifier” and is contained in unit. The rest of the message
conforms to the regular ModBus structure, but the error check fields may be omitted for
obvious reasons.