Modbus TCP

It is used to create a multipoint network where a single client device may communicate with
multiple server devices over a physical Ethernet layer. With Modbus TCP, a message is
wrapped in a TCP packet, which is then wrapped in an IP packet, which uses Ethernet electrical
signaling to transmit the package.

What is difference between Modbus and Ethernet?

Modbus TCP is known for its simplicity and ease of integration. It is a straightforward
protocol with a simple messaging structure. Ethernet/IP can be more complex to
integrate compared to Modbus TCP. It has a more intricate messaging structure and
additional layers for device-level communication

What is an example of Modbus communication?

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.

What is the difference between Modbus and TCP?

TCP/IP does not define what the data means or how the data is to be interpreted, it is
merely a transport protocol. To contrast, Modbus is an application protocol. It defines
rules for organizing and interpreting data and is essentially a messaging structure that is
independent of the underlying physical layer.

Modbus
20 languages
 Article
 Talk
 Read
 Edit
 View history
Tools

















From Wikipedia, the free encyclopedia
Not to be confused with M-Bus.
Modbus or MODBUS is a client/server data communications protocol in the application
layer.[1] It was originally published by Modicon (now Schneider Electric) in 1979 for use
with its programmable logic controllers (PLCs).[2] Modbus has become a de
facto standard communication protocol for communication between
industrial electronic devices in a wide range of buses and network.[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.
The development and update of Modbus protocols have been managed by the Modbus
Organization[4] since April 2004, when Schneider Electric transferred rights to that
organization.[5] The Modbus Organization is an association of users and suppliers of
Modbus-compliant devices that advocates for the continued use of the technology.
[6]
Modbus Organization, Inc. is a trade association for the promotion and development of
the Modbus protocol.[4]
Protocol description[edit]
 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 client which is an entity which initiates a transaction to request any
specific task from its "request receiver".[7] The client's "request receiver", which the client
has initiated the transaction with, is then called server.[7] For example, when a MCU
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.
Modbus defines a protocol data unit (PDU) independently to its lower layer protocols
in its protocol stack. The mapping of MODBUS protocol on specific buses or network
requires some additional fields, which are defined as application data unit (ADU).
ADU is formed by a client inside a Modbus network when the client initiates a
transaction. Contents are:[8]

 PDU = Function code + data

 ADU = Additional address + PDU + error check
ADU is officially called a Modbus frame by the Modbus Organization,
[8]
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.[9]
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.[9]
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).[10] 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.[7]
Modbus transaction and PDU[edit]
A Modbus transaction between client and server includes:[7][11]

 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, server will response PDU = Function code + data response. As
there is no error during those steps, the server responded function code will also be
the function code sent from the client. If there is any error during those steps, server
will response 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:[9]

 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's value, data offset, sub-function codes,...
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's value, data offset, sub-function codes,...
mb_excep_rsp_pdu = Exception Function code (1 byte) + exception code (1 byte)
Exception Function code = Function code (1 byte) + 0x80
Exception Function code will then have MSB bit is 1, and its left bit is equal to the
Function code.
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 table with four primary tables: [12]

Primary tables Access Size Features

Coil (discrete output)[13] Read-write 1 bit Read/Write on/off value

Discrete input Read-only 1 bit Read on/off value

16 bits (0–
Input register Read-only Read measurements and statuses
65,535)

16 bits (0–
Holding register Read-write Read/Write configuration values
65,535)

Function code[edit]
Modbus defines three types of function codes: Public, User-Defined and Reserved. [14]
Public function codes[edit]

Function
Function type Function name Comment
code

Data Physical Discrete Inputs Read Discrete Inputs 2

Access

Read Coils 1
Bit
access
Internal Bits or Physical
Write Single Coil 5
Coils

Write Multiple Coils 15

16-bit Physical Input Registers Read Input Registers 4

 Read Multiple Holding
3
Registers

Write Single Holding

6
Register

Write Multiple Holding

16
Internal Registers or Physical Registers
access
Output Registers

Read/Write Multiple
23
Registers

Mask Write Register 22

Read FIFO Queue 24

Read File Record 20

File Record Access
Write File Record 21

Read Exception Status 7 serial only

Diagnostic 8 serial only

Get Com Event Counter 11 serial only

Diagnostics
Get Com Event Log 12 serial only

Report Server ID 17 serial only

Read Device
43
Identification
 Encapsulated Interface
Other 43
Transport

Note: Some sources use terminology that differs from the standard; for example Force
Single Coil instead of Write Single Coil.[15]
Function code 01 (read coils) as an example of public function code [edit]
Function code 01 (read coils) allow reading the state from 1 to 2000 coil 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 1st coil (the very first
coil) has address 0x0. mb_rsp_pdu (response PDU) - if reading successfully - has 1
byte to indicate the number of bytes which is the number of coils that mb_req_pdu has
required, and the left bytes store the status (on/off value) of those requested coils.
[16]
Specifically, mb_rsp_pdu and mb_rsp_pdu of function code 01 is:[16]
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
 Coil Status: n byte
For instance, mb_req_pdu and mb_rsp_pdu to read coils status from 20-38 will be:[17]
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.[14]
Reserved function codes[edit]
Reserved Function Codes are function codes used by some companies for legacy
product and are not available for public use.[14]
Exception responses[edit]
When a client sends a request to a server, there can be four possible events for that
request:[18]

 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 response 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:[18]

 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:[19]

Cod
Text Details
e
1 Illegal Function Function code received in the query is not recognized or allowed by server

Data address of some or all the required entities are not allowed or do not
2 Illegal Data Address
exist in server

3 Illegal Data Value Value is not accepted by server

Server Device Unrecoverable error occurred while server was attempting to perform
4
Failure requested action

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
5 Acknowledge
in the client. client can next issue a Poll Program Complete message to
determine whether processing is completed

Server is engaged in processing a long-duration command; client should retry

6 Server Device Busy
later

Negative Server cannot perform the programming functions; client should request
7
Acknowledge diagnostic or error information from server

Memory Parity
8 Server detected a parity error in memory; client can retry the request
Error

Gateway Path
10 Specialized for Modbus gateways: indicates a misconfigured gateway
Unavailable

Gateway Target
11 Device Failed to Specialized for Modbus gateways: sent when server fails to respond
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.[20] Modbus Serial Line protocol is a master-slave protocol which
supports one master and multiple slaves in the serial bus.[21] 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.[21][22]
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". [22]
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 1 master. Those slaves have a unique address ranging
from 1 to 247 (decimal value).[23] The master doesn't need to have an address.[23] 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.[24]
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.[23] 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.[23] In broadcast mode, the master can send a request to all the
slaves, using the broadcast address 0,[23] which is the address reserved for broadcast
exchanges (and not the master address). Slaves must accept broadcast exchanges but
must not respond.[24] The mapping of PDU of Modbus to the serial bus of Modbus over
Serial Line protocol results in Modbus Serial Line PDU.[23]
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.[21] 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.[25]
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. Every 1
byte (8 bit) data/message of Modbus RTU needs to have 3 more bits to form the total 11
bits:[3][25]

 1 start bit
 8 bit data/message, LSB bit is first sent
 1 bit parity
 1 stop bit
A Modbus RTU frame then will be:[26]
Slave address Function Code Data CRC

0 - 252
1 byte 1 byte 2 bytes: 1 CRC Low byte and 1 CRC High byte
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 ).[27]
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 the Modbus frame integrity during the transmission, the time interval between
two frames must be at least equal to 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.[26]
For example with the default baudrate of 19200 bps, the transmission time of 3.5 (t3.5)
and 1.5 (t1.5) characters are (note that each 8-bit character requires 3 extra framing bits
to be transmitted):
For higher baudrates, Modbus RTU recommends to use the fixed values 750µs for t1.5
and 1.750ms for t3.5.[26]
Modbus ASCII[edit]
Modbus ASCII makes use of ASCII characters for protocol communication. The ASCII
format uses a longitudinal redundancy check checksum. Modbus ASCII messages are
framed by a leading colon (":") and trailing newline (CR/LF).
A Modbus ASCII frame includes:[28]
Name Length (bytes) Function
 Start 1 Colon : (ASCII value 3A16)

Address 2 Station address

Function 2 Indicates the function code e.g. "read coils"

Data n×2 Data + length will be filled depending on the message type

LRC 2 Checksum (longitudinal redundancy check)

End 2 Carriage return + line feed (CR/LF) pair (ASCII values 0D16 and 0A16)

Address, Function, Data, and LRC are ASCII hexadecimal encoded values, whereby 8-
bit values (0–255) are encoded as two human-readable ASCII characters from the
ranges 0–9 and A–F. For example, a value of 122 (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.[29] 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'.[30]
The ADU for Modbus TCP is officially called MODBUS TCP/IP ADU (or Modbus TCP/IP
ADU) by the Modbus organization[31] 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:[32]
 Length
Name Function
(bytes)

Transaction
2 For synchronization between messages of server and client
identifier

Protocol identifier 2 0 for Modbus/TCP

Length field 2 Number of remaining bytes in this frame

Server address (255 if not used), treated like slave address

Unit identifier 1
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:[32][31]
Unit
Transaction identifier Protocol identifier Length Function code Data
identifier

2 bytes 2 bytes 2 bytes 1 byte 1 byte n bytes

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

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.[33]
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.[34] Despite the
name, Modbus Plus[35] 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.[36] 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,[22] 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.[37]