2. OVERVIEW-
ABBREVIATIONS
ADU: Application Data Unit
IETF: Internet Engineering Task Force
IP: Internet Protocol
MAC: Medium Access Control
MB: MODBUS
MBAP: MODBUS Application Protocol
PDU: Protocol Data Unit
PLC: Programmable Logic Controller
TCP: Transport Control Protocol
BSD: Berkeley Software Distribution
MSL: Maximum Segment Lifetime
3. OVERVIEW……
MODBUS is an application layer messaging protocol, positioned at
level 7 of the OSI model, which provides client/server communication
between devices connected on different types of buses or networks.
The industry’s serial de facto standard since 1979, MODBUS continues
to enable millions of automation devices to communicate. Today,
support for the simple and elegant structure of MODBUS continues to
grow. The Internet community can access MODBUS at a reserved
system port 502 on the TCP/IP stack.
MODBUS is a request/reply protocol and offers services specified by
function codes. MODBUS function codes are elements of MODBUS
request/reply PDUs. The objective of this document is to describe the
function codes used within the framework of MODBUS transactions.
MODBUS is an application layer messaging protocol for client/server
communication between devices connected on different types of
buses or networks.
4. OVERVIEW……
It is currently implemented
using:
TCP/IP over Ethernet.
Asynchronous serial
transmission over a variety
of media (wire: EIA/TIA-
232-E, EIA-422, EIA/TIA-
485-A; fiber, radio, etc.)
MODBUS PLUS, a high speed
token passing network.
5. Network Architecture of MODBUS-
Every type of devices (PLC, HMI,
Control Panel, Driver, Motion control,
I/O Device…) can use MODBUS
protocol to initiate a remote
operation.
The same communication can be
done as well on serial line as on an
Ethernet TCP/IP networks. Gateways
allow a communication between
several types of buses or network
using the MODBUS protocol.
6. Protocol Description-
The MODBUS protocol defines a simple protocol data unit (PDU)
independent of the underlying communication layers. The
mapping of MODBUS protocol on specific buses or network can
introduce some additional fields on the application data unit
(ADU).
7. Protocol Description……
The MODBUS application data unit is built by the client that
initiates a MODBUS transaction. The function indicates to the
server what kind of action to perform. The MODBUS application
protocol establishes the format of a request initiated by a client.
The function code field of a MODBUS data unit is coded in one
byte. Valid codes are in the range of 1 ... 255 decimal (the range
128 – 255 is reserved and used for exception responses). When a
message is sent from a Client to a Server device the function
code field tells the server what kind of action to perform.
Function code "0" is not valid. Sub-function codes are added to
some function codes to define multiple actions.
The data field of messages sent from a client to server devices
contains additional information that the server uses to take the
action defined by the function code. This can include items like
discrete and register addresses, the quantity of items to be
handled, and the count of actual data bytes in the field.
8. Protocol Description……
The data field may be nonexistent (of zero length) in certain kinds of
requests, in this case the server does not require any additional
information. The function code alone specifies the action.
If no error occurs related to the MODBUS function requested in a properly
received MODBUS ADU the data field of a response from a server to a
client contains the data requested. If an error related to the MODBUS
function requested occurs, the field contains an exception code that the
server application can use to determine the next action to be taken.
For example a client can read the ON / OFF states of a group of discrete
outputs or inputs or it can read/write the data contents of a group of
registers.
When the server responds to the client, it uses the function code field to
indicate either a normal (error-free) response or that some kind of error
occurred (called an exception response). For a normal response, the
server simply echoes to the request the original function code.
9. Protocol Description……
For an exception response, the server returns a code that is
equivalent to the original function code from the request PDU
with its most significant bit set to logic 1.
10. Protocol Description……
The size of the MODBUS PDU is limited by the size constraint
inherited from the first MODBUS implementation on Serial Line
network (max. RS485 ADU = 256 bytes).
Therefore:
MODBUS PDU for serial line communication = 256 - Server
address (1 byte) - CRC (2 bytes) = 253 bytes.
Consequently:
RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC
(2 bytes) = 256 bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.
11. MODBUS TCP/IP-
A communicating system over
MODBUS TCP/IP may include
different types of device:
A MODBUS TCP/IP Client and
Server devices connected to a
TCP/IP network
The Interconnection devices like
bridge, router or gateway for
interconnection between the
TCP/IP network and a serial line
sub-network which permit
connections of MODBUS Serial line
Client and Server end devices.
12. MODBUS Data Model-
MODBUS bases its data model on a series of tables that have
distinguishing characteristics.
The four primary tables are:
The distinctions between
inputs and outputs, and
between bit-addressable and
word-addressable data
items, do not imply any
application behavior. It is
perfectly acceptable, and
very common, to regard all
four tables as overlaying one
another, if this is the most
natural interpretation on the
target machine in question.
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.
13. MODBUS Addressing Model-
The MODBUS application protocol
defines precisely PDU addressing rules.
In a MODBUS PDU each data is
addressed from 0 to 65535.
It also defines clearly a MODBUS data
model composed of 4 blocks that
comprises several elements numbered
from 1 to n.
In the MODBUS data Model each
element within a data block is
numbered from 1 to n.
Afterwards the MODBUS data model
has to be bound to the device
application (IEC-61131 object, or
other application model).
The pre-mapping between the
MODBUS data model and the device
application is totally vendor device
specific.
14. Modbus Component Architecture
Model-
Communication Application Layer - A MODBUS device may provide a client
and/or a server MODBUS interface. A MODBUS backend interface can be
provided allowing indirectly the access to user application objects. Four
areas can compose this interface: input discrete, output discrete (coils),
input registers and output registers. A pre-mapping between this
interface and the user application data has to be done (local issue).
MODBUS Client - The MODBUS Client allows the user application to
explicitly control information exchange with a remote device. The
MODBUS Client builds a MODBUS request from parameter contained in a
demand sent by the user application to the MODBUS Client Interface. The
MODBUS Client uses a MODBUS transaction whose management includes
waiting for and processing of a MODBUS confirmation.
MODBUS Client Interface - The MODBUS Client Interface provides an
interface enabling the user application to build the requests for various
MODBUS services including access to MODBUS application objects. The
MODBUS Client interface (API) is not part of this Specification, although
an example is described in the implementation model.
15. Modbus Component Architecture
Model…….
MODBUS Server - On reception
of a MODBUS request this
module activates a local
action to read, to write or to
achieve some other actions.
The processing of these
actions is done totally
transparently for the
application programmer. The
main MODBUS server functions
are to wait for a MODBUS
request on 502 TCP port, to
treat this request and then to
build a MODBUS response
depending on device context.
16. Modbus Component Architecture
Model…….
MODBUS Backend Interface - The MODBUS Backend Interface is an
interface from the MODBUS Server to the user application in which
the application objects are defined.
17. Modbus Component Architecture
Model…….
TCP Management Layer – Establishment, ending and to manage the data flow on
established TCP connections.
Connection Management - A communication between a client and server MODBUS
Module requires the use of a TCP connection management module. It is in charge
to manage globally messaging TCP connections.
The listening TCP port 502 is reserved for MODBUS communications. Two
possibilities are proposed for the connection management. Either the user
application itself manages TCP connections or the connection management is
totally done by this module and therefore it is transparent for the user
application. The last solution implies less flexibility.
It is mandatory to listen by default on that port. However, some markets or
applications might require that another port is dedicated to MODBUS over TCP.
For that reason, it is highly recommended that the clients and the servers give
the possibility to the user to parameterize the MODBUS over TCP port number. It
is important to note that even if another TCP server port is configured for
MODBUS service in certain applications, TCP server port 502 must still be
available in addition to any application specific ports.
18. Modbus Component Architecture
Model…….
Access Control Module - In certain critical contexts, accessibility to
internal data of devices must be forbidden for undesirable hosts. That’s
why a security mode is needed and security process may be implemented
if required.
TCP/IP Stack Layer - The TCP/IP stack can be parameterized in order to
adapt the data flow control, the address management and the connection
management to different constraints specific to a product or to a system.
Generally the BSD socket interface is used to manage the TCP
connections.
Resource Management and Data Flow Control - In order to equilibrate
inbound and outbound messaging data flow between the MODBUS client
and the server, data flow control mechanism is provided in all layers of
MODBUS messaging stack.
The resource management and flow control module is first based on TCP
internal flow control added with some data flow control in the data link
layer and also in the user application level
19. The Two Serial Transmission Modes-
Controllers can be setup to communicate on standard Modbus
networks using either of two transmission modes: ASCII or RTU.
Users select the desired mode, along with the serial port
communication parameters (baud rate, parity mode, etc.), during
configuration of each controller.
The mode and serial parameters must be the same for all devices
on a Modbus network. The selection of ASCII or RTU mode
pertains only to standard Modbus networks.
It defines the bit contents of message fields transmitted serially
on those networks. It determines how information will be packed
into the message fields and decoded.
On other networks like MAP and Modbus Plus, Modbus messages
are placed into frames that are not related to serial transmission.
For example, a request to read holding registers can be handled
between two controllers on Modbus.
20. The Two Serial Transmission Modes..
ASCII Mode-
When controllers are setup to communicate on a Modbus network using
ASCII (American Standard Code for Information Interchange) mode, each
8–bit byte in a message is sent as two ASCII characters. The main
advantage of this mode is that it allows time intervals of up to one second
to occur between characters without causing an error.
The format for each byte in ASCII mode is:
Coding System: Hexadecimal, ASCII characters 0–9, A–F. One hexadecimal
character contained in each ASCII character of the message.
Bits per Byte: 1 start bit
7 data bits, least significant bit sent first
1 bit for even/odd parity; no bit for no parity
1 stops bit if parity is used; 2 bits if no parity
Error Check Field: Longitudinal Redundancy Check (LRC)
21. The Two Serial Transmission Modes..
RTU Mode-
When controllers are setup to communicate on a Modbus network using RTU
(Remote Terminal Unit) mode, each 8–bit byte in a message contains two 4–bit
hexadecimal characters. The main advantage of this mode is that its greater
character density allows better data throughput than ASCII for the same baud
rate. Each message must be transmitted in a continuous stream.
The format for each byte in RTU mode is:
Coding System: 8–bit binary, hexadecimal 0–9, A–F. Two hexadecimal characters
contained in each 8–bit field of the message.
Bits per Byte: 1 start bit
8 data bits, least significant bit sent first
1 bit for even/odd parity; no bit for no parity
1 stops bit if parity is used; 2 bits if no parity
Error Check Field: Cyclical Redundancy Check (CRC)
