MODBUS Messaging on TCP/IP Implementation Guide V1.

0b Modbus Organization

Idle

Wait

[Reveive_Response_from_TCP_Mgt]
[Request_from_the_user application]
Waiting_response_timer_expires

Process Find out pending Build MODBUS

MODBUS transaction request
Confirmation

[Confirmation error] [Retries number not reached] Send MODBUS request

To TCP management

[Confirmation OK]

[Retries number reached]

Send positive
confirmation to [Send Not OK] [Send OK]
User Application

Send negative
confirmation to user Set Waiting
Application response timer

Figure 11: MODBUS Client Activity Diagram

A MODBUS client can receive three events:

A new demand from the user application to send a request, in this case a MODBUS
request has to be encoded and be sent on the network using the TCP management
component service. The lower layer ( TCP management module) can give back an
error due to a TCP connection error, or some other errors.
A response from the TCP management, in this case the client has to analyze the
content of the response and send a confirmation to the user application
The expiration of a Time out due to a non-response. A new retry can be sent on the
network or a negative confirmation can be sent to the User Application.
Remark : These retries are initiated by the MODBUS client, some other retries can
also be done by the TCP layer in case of TCP acknowledge lack.

4.4.1.2 Build a MODBUS Request

Following the reception of a demand from the user application, the client has to build a
MODBUS request and to send it to the TCP management.
Building the MODBUS request can be split in several sub-tasks:

The instantiation of a MODBUS transaction that enables the Client to memorize all
required information in order to bind later the response to the request and to send
the confirmation to the user application.
The encoding of the MODBUS request (PDU + MPAB header). The user application
that initiates the demand has to provide all required information which enables the
Client to encode the request. The MODBUS PDU is encoded according to the
MODBUS Application Protocol Specification [1]. (MB function code, associated
parameters and application data ). All fields of the MBAP header are filled. Then,
the MODBUS request ADU is built prefixing the PDU with the MBAP header

October 24, 2006 http://www.Modbus.org 21/46

MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

The sending of the MODBUS request ADU to the TCP management module which is
in charge of finding the right TCP socket towards the remote Server. In addition to
the MODBUS ADU the Destination IP address must also be passed.

The following activity diagram describes, more deeply than in Figure 11 MODBUS
Client Activity Diagram, the request building phase.

Instantiate a MB
transaction

[No Transaction available]

[Transaction available]

Initialize the
transaction

Encode the MB
request PDU

Encode the
MBAP header

Send a Send MB
negative request to TCP
confirmation to Mgt
the user
application

Figure 12: Request building activity diagram

The following example describes the MODBUS request ADU encoding for reading the
register # 5 in a remote server :

♦ MODBUS Request ADU encoding :

Description Size Example

MBAP Header Transaction Identifier Hi 1 0x15
Transaction Identifier Lo 1 0x01
Protocol Identifier 2 0x0000
Length 2 0x0006
Unit Identifier 1 0xFF
October 24, 2006 http://www.Modbus.org 22/46
MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

MODBUS Function Code (*) 1 0x03

request Starting Address 2 0x0004
Quantity of Registers 2 0x0001

(*) please see the MODBUS Application Protocol Specification [1].

• Transaction Identifier

The transaction identifier is used to associate the future response with the request.
So, at a time, on a TCP connection, this identifier must be unique. There are
several manners to use the transaction identifier:
- For example, it can be used as a simple "TCP sequence number" with a
counter which is incremented at each request.
- It can also be judiciously used as a smart index or pointer to identify a
transaction context in order to memorize the current remote server and the
pending MODBUS request.

Normally, on MODBUS serial line a client must send one request at a time. This means
that the client must wait for the answer to the first request before sending a second
request. On TCP/MODBUS, several requests can be sent without waiting for a
confirmation to the same server. The MODBUS/TCP to MODBUS serial line gateway is
in charge of ensuring compatibility between these two behaviors.
The number of requests accepted by a server depends on its capacity in term of
number of resources and size of the TCP windows. In the same way the number of
transactions initialized simultaneously by a client depends also on its resource capacity.
This implementation parameter is called "NumberMaxOfClientTransaction" and must
be described as one of the MODBUS client features. Depending of the device type this
parameter can take a value from 1 to 16.

• Unit Identifier

This field is used for routing purpose when addressing a device on a MODBUS+
or MODBUS serial line sub-network. In that case, the “Unit Identifier” carries the
MODBUS slave address of the remote device:
If the MODBUS server is connected to a MODBUS+ or MODBUS Serial Line
sub-network and addressed through a bridge or a gateway, the MODBUS Unit
identifier is necessary to identify the slave device connected on the sub-
network behind the bridge or the gateway. The destination IP address
identifies the bridge itself and the bridge uses the MODBUS Unit identifier to
forward the request to the right slave device.
The MODBUS slave device addresses on serial line are assigned from 1 to
247 (decimal). Address 0 is used as broadcast address.
On TCP/IP, the MODBUS server is addressed using its IP address; therefore, the
MODBUS Unit Identifier is useless. The value 0xFF has to be used.
When addressing a MODBUS server connected directly to a TCP/IP network,
it’s recommended not using a significant MODBUS slave address in the “Unit
Identifier” field. In the event of a re-allocation of the IP addresses within an
automated system and if a IP address previously assigned to a MODBUS
server is then assigned to a gateway, using a significant slave address may
cause trouble because of a bad routing by the gateway. Using a non-
significant slave address, the gateway will simply discard the MODBUS PDU
with no trouble. 0xFF is recommended for the “Unit Identifier" as non-
significant value.
Remark : The value 0 is also accepted to communicate directly to a
MODBUS/TCP device.

October 24, 2006 http://www.Modbus.org 23/46

MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

4.4.1.3 Process MODBUS Confirmation

When a response frame is received on a TCP connection, the Transaction Identifier
carried in the MBAP header is used to associate the response with the original request
previously sent on that TCP connection:
If the Transaction Identifier doesn't refer to any MODBUS pending transaction, the
response must be discarded.
If the Transaction Identifier refers to a MODBUS pending transaction, the response
must be parsed in order to send a MODBUS Confirmation to the User Application
(positive or negative confirmation)

Parsing the response consists in verifying the MBAP Header and the MODBUS PDU
response:
MBAP Header
After the verification of the Protocol Identifier that must be 0x0000, the length gives
the size of the MODBUS response.
If the response comes from a MODBUS server device directly connected to the
TCP/IP network, the TCP connection identification is sufficient to unambiguously
identify the remote server. Therefore, the Unit Identifier carried in the MBAP
header is not significant (value 0xFF) and must be discarded.
If the remote server is connected on a Serial Line sub-network and the response
comes from a bridge, a router or a gateway, then the Unit Identifier (value != 0xFF)
identifies the remote MODBUS server which has originally sent the response.

MODBUS Response PDU

The function code must be verified and the MODBUS response format analyzed
according to the MODBUS Application Protocol:
• if the function code is the same as the one used in the request, and if the
response format is correct, then the MODBUS response is given to the user
application as a Positive Confirmation.
• If the function code is a MODBUS exception code (Function code + 80H), the
MODBUS exception response is given to the user application as a Positive
Confirmation.
• If the function code is different from the one used in the request (=non
expected function code), or if the format of the response is incorrect, then an
error is signaled to the user application using a Negative Confirmation.

Remark: A positive confirmation is a confirmation that the command was received and
responded to by the server. It does not imply that the server was able to successfully
act on the command (failure to successfully act on the command is indicated by the
MODBUS Exception response).

The following activity diagram describes, more deeply than in Figure 11 MODBUS
Client Activity Diagram, the confirmation processing phase.

October 24, 2006 http://www.Modbus.org 24/46

MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

Find Out pending

MB transaction

[PendingTransaction ]

[No Pending Transaction ]

Use MB transaction to
bind with the request
Discard
Response

Analyse MBAP header

[Modbus_protocol] [Other_protocol]

Analyse Response
PDU

[MB response OK]

[Incorrect Response]
Send negative
[MB Exception response] Confirmation to
user Application
Extract MB Process_MB_
Response exception

Send positive
confirmation to user
application

Wait

Figure 13: Process MODBUS Confirmation activity diagram

4.4.1.4 Time-out management

There is deliberately NO specification of required response time for a transaction over

MODBUS/TCP.
This is because MODBUS/TCP is expected to be used in the widest possible variety of
communication situations, from I/O scanners expecting sub-millisecond timing to long
distance radio links with delays of several seconds.
From a client perspective, the timeout must take into account the expected transport
delays across the network, to determine a ‘reasonable’ response time. Such transport
delays might be milliseconds for a switched Ethernet, or hundreds of milliseconds for a
wide area network connection.
In turn, any ‘timeout’ time used at a client to initiate an application retry should be
larger than the expected maximum ‘reasonable’ response time. If this is not followed,
there is a potential for excessive congestion at the target device or on the network,
which may in turn cause further errors. This is a characteristic, which should always be
avoided.

October 24, 2006 http://www.Modbus.org 25/46

MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

So in practice, the client timeouts used in high performance applications are always
likely to be somewhat dependent on network topology and expected client performance.
Applications which are not time critical can often leave timeout values to the normal
TCP defaults, which will report communication failure after several seconds on most
platforms.

4.4.2 MODBUS Server

Modbus
Client
Serial Line

Modbus Modbus
Client Client
Client TCP/IP
TCP/IP TCP/IP
gateway

Modbus TCP / IP

Modbus Modbus
Modbus Modbus
Server Server
Server Server
Serial Line Serial Line
TCP/IP TCP/IP Server TCP/IP
gateway

Modbus Serial line

Figure 14: MODBUS Server unit

The role of a MODBUS server is to provide access to application objects and services
to remote MODBUS clients.

Different kind of access may be provided depending on the user application :

simple access like get and set application objects attributes
advanced access in order to trigger specific application services

The MODBUS server has:

To map application objects onto readable and writable MODBUS objects, in order
to get or set application objects attributes.
To provide a way to trigger services onto application objects.

In run time the MODBUS server has to analyze a received MODBUS request, to
process the required action, and to send back a MODBUS response.

Informative Note: The application objects and services of the Backend Interface obtain
the requested data based upon the function code, and the User is responsible.

October 24, 2006 http://www.Modbus.org 26/46

MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

4.4.2.1 MODBUS Server Design

The MODBUS Server design depends on both :

the kind of access to the application objects (simple access to attributes or

advanced access to services)
the kind of interaction between the MODBUS server and the user application
(synchronous or asynchronous).

The following activity diagram describes the main treatments that are processed by the
Server to obtain a MODBUS request from TCP Management, then to analyze the
request, to process the required action, and to send back a MODBUS response.

Idle

[Server init]

[Response from user application]

Wait
[Invocation user application done]

[MB Indication discarded] [Reception of a MODBUS indication

from TCP Mgt]

Invoke back [MB transaction refused] MODBUS_PDU_Checking...

end interface
[MODBUS transaction accepted]

[Processing not complete]

[Need user application processing] MODBUS_Service_Processing
Response
processing
[Processing not OK]

[Processing not OK]

[Processing OK] [Processing OK]

Build a MODBUS Build a MODBUS

Exception response

[MB Exception OK] [MB Response OK]

Send response
to TCP_Mgt

[processing ends] Release the

MODBUS server
transaction

Figure 15: Process MODBUS Indication activity diagram

October 24, 2006 http://www.Modbus.org 27/46

MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

As shown in the previous activity diagram:

Some services can be immediately processed by the MODBUS Server itself, with
no direct interaction with the User Application ;

Some services may require also interacting explicitly with the User Application to
be processed ;

Some other advanced services require invoking a specific interface called

MODBUS Back End service. For example, a User Application service may be
triggered using a sequence of several MODBUS request/response transactions
according to a User Application level protocol. The Back End service is
responsible for the correct processing of all individual MODBUS transactions in
order to execute the global User Application service.

A more complete description is given in the following sections.

The MODBUS server can accept to serve simultaneously several MODBUS requests.
The maximum number of simultaneous MODBUS requests the server can accept is one
of the main characteristics of a MODBUS server. This number depends on the server
design and its processing and memory capabilities. This implementation parameter is
called "NumberMaxOfSeverTransaction" and must be described as one of the
MODBUS server features. It may have a value from 1 to 16 depending on the device
capabilities.

The behavior and the performance of the MODBUS server are significantly affected by
the "NumberMaxOfTransaction" parameter. Particularly, it's important to note that the
number of concurrent MODBUS transactions managed may affect the response time of
a MODBUS request by the server.

4.4.2.2 MODBUS PDU Checking

The following diagram describes the MODBUS PDU Checking activity.

October 24, 2006 http://www.Modbus.org 28/46

MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

Parse the
MBAP header

MB Indication [Error on MBAP ] [MBAP OK]

discarded

Instantiate a
MB Transaction

[No Transaction available] [Transaction available]

Parse The MB
PDU

[Error on MB PDU]
MB Transaction
refused
[OK]

MB Transaction
accepted

Figure 16: MODBUS PDU Checking activity diagram

The MODBUS PDU Checking function consists of first parsing the MBAP Header. The
Protocol Identifier field has to be checked :
If it is different from MODBUS protocol type, the indication is simply discarded.
If it is correct (= MODBUS protocol type; value 0x00), a MODBUS transaction is
instantiated.

The maximum number of MODBUS transactions the server can instantiate is defined by
the "NumberMaxOfTransaction" parameter ( A system or a configuration parameter).

In case of no more transactions available, the server builds a MODBUS exception

response (Exception code 6 : Server Busy).

If a MODBUS transaction is available, it's initialized in order to memorize the following

information:
• The TCP connection identifier used to send the indication (given by the TCP
Management)
• The MODBUS Transaction ID (given in MBAP Header)
• The Unit Identifier (given in MBAP Header)

Then the MODBUS PDU is parsed. The function code is first controlled :
in case of invalidity a MODBUS exception response is built (Exception code 1 : Invalid
function).
If the function code is accepted, the server initiates the "MODBUS Service
processing" activity.

October 24, 2006 http://www.Modbus.org 29/46

MODBUS Messaging on TCP/IP Implementation Guide V1.0b Modbus Organization

4.4.2.3 MODBUS service processing

Transaction_accepted Response_from_user_App

Analyse Response
requested service processing

[Local processing ] [Need User App processing] [Processing not completed]

Local Service
processing Send an invocation to [Completed]
User Application
through MB Backend
interface

[Processing OK]
[Processing not OK]
[Processing Not OK]

[Processing OK]

Build Modbus
Build Modbus Response
Exception Response

Figure 17: MODBUS service processing activity diagram

The processing of the required MODBUS service can be done in different ways
depending on the device software and hardware architecture as described in the
hereafter examples :

• Within a compact device or a mono-thread architecture where the MODBUS

server can access directly to the user application data, the required service can
be processed "locally" by the server itself without invoking the Back End service.
The processing is done according to the MODBUS Application Protocol
Specification [1]. In case of an error, a MODBUS exception response is built.
• Within a modular multi-processor device or a multi-thread architecture where the
"communication layers" and the "user application layer" are 2 separate entities,
some trivial services can be processed completely by the Communication entity
while some others can require a cooperation with the User Application entity
using the Back End service.

To interact with the User Application, the MODBUS Backend service must implement all
appropriate mechanisms in order to handle User Application transactions and to
manage correctly the User Application invocations and associated responses.

4.4.2.4 User Application Interface (Backend Interface)

Several strategies can be implemented in the MODBUS Backend service to achieve its
job although they are not equivalent in terms of user network throughput, interface
bandwidth usage, response time, or even design workload.
October 24, 2006 http://www.Modbus.org 30/46