Experimental Implementation and Performance Evaluation of an IoT Access Gateway for the Modbus Extension

This paper presents the relevant aspects regarding the experimental implementation and performance evaluation of an Internet of things (IoT) gateway for the Modbus extension. The proposed Modbus extension specifications are extended by defining the new optimized message format, and the structure of the acquisition cycle for obtaining a deterministic temporal behavior and solutions are presented for the description of devices at the MODBUS protocol level. Three different implementations are presented, and the Modbus extension’s performance is validated regarding the efficiency in the use of the acquisition cycle time. The software and hardware processing time and the importance and effect of the various components are analyzed and evaluated. They all support the implementation of an Internet of things gateway for Modbus extension. This paper introduces solutions for the structure of the acquisition cycle to include other valuable extensions, discusses the performance of a real implementation in the form of a gateway, adds new features to the Modbus extension specification, and strengthens some of the existing ones. In accordance with the novelty and contribution of this paper to the field of local industrial networks, the results obtained in the analysis, testing, and validation of the Modbus extension protocol refer to the extending of the Modbus functions for industrial process monitoring and control management.


Introduction
Few developments, such as the introduction of networks as a support for communication of information between devices (local industrial network; LINW) have changed the face of automation profoundly. They provide physical and logical support to create data acquisition channels that depart from sensors and transducers and must end with integration into Internet of things (IoT), especially industrial IoT (IIoT). LINW is a comprehensive term that includes networks on a sensor/actuator level (sensor bus, fieldbus, or field area network (FAN)) that connect smart sensors and execution elements with 4-16 digital inputs/outputs (AS-I, CANOpen, Modbus RTU, Lonworks), those on a device level (device bus) that connect groups of 32-256 digital inputs/outputs and small automation units (Profibus, Interbus-S, CANOpen, Modbus, etc.), and those on a control level, where the best networks can connect data concentrators, automation units, controllers for CNC machines, PCs, HMI, and PLCs, with many inputs/outputs (industrial Ethernet, EtherCAT, EPL, Sercos III, CC-Link, Profinet, ControlNet, WorldFIP, and Modbus TCP/IP).
There are also LINWs (fieldbuses) oriented for specific applications or domains.
The following examples may be given: the automotive industry, "smart" homes, centralized management of a building, movement control, networks implementing measurement and testing techniques, and the military or the air force, where stringent reliability restrictions are imposed [1]. In recent years, LINW concerns have consistently remained at a high level. As a result, a multitude of specifications and communication protocols have emerged, either free or private. Due to their accumulation, the efforts of specialists in the field are currently ARM (Advanced RISC Machines) hardware was designed and implemented to verify the operation and performance of the software. By designing a new software architecture and integrated stacks, the time period corresponding to the development was reduced, and the software was easy to port, maintain, and reuse.
Adapting network levels and implementing gateways between protocols is another area of research in Modbus RTU. In [20], the authors proposed a Modbus adaptation level for the controller area network, called MODBUS CAN, which was formally verified and evaluated experimentally. The results presented by the authors showed that, in a typical low-cost built-in system, MODBUS CAN performance compares favorably with regard to a Modbus TCP implementation, based on an Ethernet network with a 100 Mbps transfer rate, performed on the same system and using the same set of protocols. However, the comparison does not refer to the same class of protocols. The paper describes the design and validation of MODBUS CAN, the main purpose of which is to fragment and reassemble MODBUS protocol data units (PDUs) (up to 253 bytes in length) and, thus, fit them into CAN frames (which hold up to 8 bytes of payload). Compared to Modbus RTU, MODBUS CAN delivers considerably higher performance, while retaining similar implementation costs and simplified wiring based on bus topology. The claim is not supported and, in [3], is somewhat countered.
Reference [21] proposed an architectural improvement of the Modbus RTU protocol for the integration of equipment into industrial automation networks, using hybrid communications with wired Modbus RTU and wireless IEEE 802. 15.4. The proposed hybrid communications protocol increases the control and topological limits imposed by Modbus RTU, allowing for a wired/wireless tree-bus topology and master multiplexing. On the basis of the tests, the proposed architecture showed a low rate of communication error, indicating that the developed solution can meet the robust requirements of industry communications networks.
In [22], the authors presented a response and scheduling time analysis tool for Modbus communications on RS485 networks. The response times of a message set were collected by a specialized Modbus device and then sent to the software performing the analysis. To evaluate the developed tool, a Modbus application was implemented on the RS485 network in a laboratory environment. The paper discussed the development of a tool to assess real-time requirements in Modbus RS485 networks. The authors' proposal involved evaluating response times in two approaches. In the first approach, the Master Device of the Modbus network was replaced with a specialized device capable of assessing response times for a set of known messages. In the second approach, the specialized device acted as a passive device that was connected to the network and collected information about messages exchanged between devices and their response times. Using statistics, charts, and lists, information about response time, periods, and message content was displayed, helping the user with different ratings. Using the proposed tool, three case studies were carried out to verify the communication characteristics and query set, thus indicating the variation in response times according to device characteristics. However, in order to improve network characteristics for particular applications, issues involving time-outs and communication errors should also be taken into account. Due to the popularity of the Modbus protocol, various Modbus extensions have been proposed, and, for the most part, they retain compatibility with the specifications mentioned in Section 1. Some of these extensions are analyzed below.
In ref. [23], the authors first proposed the extension of the address space using a reserved address and then extended the address space from 8 to 16 bits. Only stations aware of this extension can understand this way of addressing those that are immune to these messages. The paper also proposed a multi-master architecture with the choice of the next master. To do this, a master choice protocol is periodically launched. The second function of this protocol is to make all master devices aware of the presence of others. This way, it can send them additional information about the current activity.
In ref. [3], an AC was presented in order to achieve an extended temporal coherence, which can also be customized for Modbus. An original protocol extension called ModbusE, based on multi-microprocessor (MM) working mode, was proposed that brought it close to the performance of the CANOpen protocol. In the ModbusE protocol, only the slot number, data, and cyclic redundancy check (CRC) are transmitted during a slot, thus increasing the bandwidth of the communication channel. The meaning of the data is defined by default in device configuration, or by classic Modbus commands when initializing the AC. A similar idea can be found in [24], but for CAN FD; in that paper, the authors proposed a solution for an extension of the CAN protocol (CAN) with extensible in-frame reply (XR) that allows higher levels of the protocol to define new dedicated user services for, e.g., network management, application-specific functions, and a data transfer with increased efficiency. At the application level, the management of variables and device parameters can be a challenge. In ref. [25], research focused on a universal method for describing protocols, and that method aimed to encapsulate packages, where various protocol messages can be encapsulated and analyzed by an interpreter in a unified way. To ensure communication efficiency and quality of service (QoS) for different types of messages, the encapsulation of packages using the protocol description was optimized and scheduled before transmission by the interpreter. A closer approach to Modbus was presented in ref. [26]. There are also implementation approaches in field-programmable gate arrays (FPGA) [27] or systems on chip (SoC) [28].

Modbus Extension-MBE
MBE was succinctly defined in ref. [3] specifying the structure of the message, the structure of the AC, BSG (base station gateway) as the Master device (we still call it Client) that manages the AC and provides a gateway to other protocols such as Modbus TCP-IP, PDO (process data object), and SDO (service data object), the use of new generations of microcontrollers (µCs) that can support speeds above 12 Mb/s (e.g., 27 Mb/s for STM32F756), MM work for UART (in this case only with MBE devices), interrupts, direct memory access (DMA) transfer, and RS485-specific facilities for changing the communication direction.

MBE Message Structure
There are three types of transactions in MBE: Send Data with Acknowledgment (SDA), which sends data with recognition (request and response), Send Data with No Acknowledgment (SDN), which sends data without recognition (request), and Send and Request Data (SRD), which sends and requests data (request-response). Figure 1a shows the frames sent on serial lines for both Modbus RTU and MBE. They can contain one bit of parity and one bit of stop, or only two bits of parity. Figure 1b shows specific MBE frames that have a bit for MM communication control and a stop bit, or only one or two stop bits. The data size is 8 bits in the µC (due to DMA transfer for characters exceeding 8 bits, 16 bits of data are rarely transmitted), and there can also be data sizes of 16, 32, and 64 bits for FPGA implementations.
Sensors 2020, 20, x FOR PEER REVIEW 5 of 23 In ref. [3], an AC was presented in order to achieve an extended temporal coherence, which can also be customized for Modbus. An original protocol extension called Mod-busE, based on multi-microprocessor (MM) working mode, was proposed that brought it close to the performance of the CANOpen protocol. In the ModbusE protocol, only the slot number, data, and cyclic redundancy check (CRC) are transmitted during a slot, thus increasing the bandwidth of the communication channel. The meaning of the data is defined by default in device configuration, or by classic Modbus commands when initializing the AC. A similar idea can be found in [24], but for CAN FD; in that paper, the authors proposed a solution for an extension of the CAN protocol (CAN) with extensible in-frame reply (XR) that allows higher levels of the protocol to define new dedicated user services for, e.g., network management, application-specific functions, and a data transfer with increased efficiency. At the application level, the management of variables and device parameters can be a challenge. In ref. [25], research focused on a universal method for describing protocols, and that method aimed to encapsulate packages, where various protocol messages can be encapsulated and analyzed by an interpreter in a unified way. To ensure communication efficiency and quality of service (QoS) for different types of messages, the encapsulation of packages using the protocol description was optimized and scheduled before transmission by the interpreter. A closer approach to Modbus was presented in ref. [26]. There are also implementation approaches in field-programmable gate arrays (FPGA) [27] or systems on chip (SoC) [28].

Modbus Extension-MBE
MBE was succinctly defined in ref. [3] specifying the structure of the message, the structure of the AC, BSG (base station gateway) as the Master device (we still call it Client) that manages the AC and provides a gateway to other protocols such as Modbus TCP-IP, PDO (process data object), and SDO (service data object), the use of new generations of microcontrollers (µCs) that can support speeds above 12 Mb/s (e.g., 27 Mb/s for STM32F756), MM work for UART (in this case only with MBE devices), interrupts, direct memory access (DMA) transfer, and RS485-specific facilities for changing the communication direction.

MBE Message Structure
There are three types of transactions in MBE: Send Data with Acknowledgment (SDA), which sends data with recognition (request and response), Send Data with No Acknowledgment (SDN), which sends data without recognition (request), and Send and Request Data (SRD), which sends and requests data (request-response). Figure 1a shows the frames sent on serial lines for both Modbus RTU and MBE. They can contain one bit of parity and one bit of stop, or only two bits of parity. Figure 1b shows specific MBE frames that have a bit for MM communication control and a stop bit, or only one or two stop bits. The data size is 8 bits in the µC (due to DMA transfer for characters exceeding 8 bits, 16 bits of data are rarely transmitted), and there can also be data sizes of 16 Figure 2 shows the message structure for MBE. The first message is a request, the second is used for a response, and the structure of the Modbus RTU request/response message is illustrated by the third message. It is easy to see that MBE messages do not have the function code fields and function parameters in either the request message or the  Figure 2 shows the message structure for MBE. The first message is a request, the second is used for a response, and the structure of the Modbus RTU request/response message is illustrated by the third message. It is easy to see that MBE messages do not have the function code fields and function parameters in either the request message or the response message, and the required bandwidth is clearly lower than in the case of Modbus RTU; in other words, for the same useful amount of data, the MBE message is shorter than the Modbus RTU message (data structure and length information is either configured offline with simple Modbus configuration tools or carried out online by BSG). An MBE message easily defines a Modbus RTU message if the slot address becomes a server (slave) address and if the first part of the data range becomes the function code with function parameters. Additional MBE addresses larger than 0 × 80 are treated by default as Modbus RTU addresses. Modbus RTU (MMRTU) message = address (1×control frame (cf)) + function code (fc) (1×control frame) + function parameters (fp) (fp×control frame) + data (n×data frame (df)) + CRC (2×control frame) = > _ = (4 + ) × + × (1) A MBE message has a maximum of 256 bytes. MBE (MMBE) message = address (1×control frame (cf)) + data (n×data frame (df)) + CRC (2×control frame) = > For the same amount of payload data,

Acquisition Cycle Architecture
The structure of the AC is presented in Figure 3 and is based on the proposal presented in ref. [3], where S0 is SYNC and Sn-1 is SEND. As a result, an 8 bits Modbus RTU/MBE frame for 8 bits data has 11 bits (11b). A Modbus RTU message has a maximum of 256 bytes.

Acquisition Cycle Architecture
The structure of the AC is presented in Figure 3 and is based on the proposal presented in ref. [3], where S0 is SYNC and Sn-1 is SEND.
Tcycle S0, S1 and Sn-1 are mandatory time slots; Θ-basic time amount (tick = time of 1 bit from frame, for example 0.1 ms for 10 Kb/s); S0-Always, the first slot in the cycle; S1-Always, indirect slot for empty slots; S2-Sn-2 MBE slots (Modbus Extended working); Sn-1-the last slot is used for aperiodic Modbus commands (with indirect); Duration of a slot aSi = i x Θ ( i, a calculated value in microseconds); Tcycle-the period of the acquisition cycle; Tcycle = tS0 +tS1 + tS2 + … + tSn-2 + tSn-1. For the AC of gateMBEx, the following requirements are defined: • The AC can have n slots, where n ϵ 3-46 (one less than the maximum number of Modbus addresses, 247, with the latter number being retained for local gateway commands), each slot supporting n0, n1, ...., nn−1 characters issued, except Slots 0, Slot 1, and those redirected to Slot 1.

•
The minimum number of slots in an AC is 3.

•
A slot is made up of ni × 11 × θ ticks (it is preferable that the tick does not generate interrupts but is the clock in the timer).

•
Each slot has a data structure attached with status, control, and data information.

•
A ModbusE (ModbusExtension) station, by configuration, can subscribe to multiple broadcast/reception slots.
There are three slots with special functions: • Slot 0 (n0) is the slot that marks the beginning of the cycle and can be used, for example, to broadcast the "start scanning" inputs or update outputs. • Slot 1 (n1) is used for indirect empty slots (either they have not been defined or the slaves working with these slots are stopped or defective). If indirectness is not carried out, sending the command could mislead those stations that subscribed to these slots. Slot 1 has no slave device connected; thus, it cannot be subscribed. When used for indirection, only the slot address and the CRC are sent, but its duration inherits the time period of the indirection. There is a byte that usually has a value of 0, but other values may have different meanings. For now, a value other than 0 in the range 1-127, but not greater than the number for Sn-1, can indicate a slot where there is a possible gateway client that can take over the gateway function and, thus, AC management.

•
The last slot (nn−1) is used for aperiodic commands and is usually indirectly with Slot 1, if there are no aperiodic commands, or with a slot with a number greater than the last slot in the cycle containing the indirect command. This command must have a number of bytes in the message issued that is less than or equal to the allowed (defined) message for the last slot. It is not prohibited for other slots to take in aperiodic requests (especially slots that have larger cycles than Tcycle).

•
The indirect action procedure on a slot can transmit the data of a slot that is not in the AC provided that the length of the data is not greater than the length of the data of the indirect slot (which, for reasons of determinism, cannot change the time period of a slot without a reconfiguration of the AC). The system may have a maximum number of slots available, but the AC may use fewer. The remaining slots can be used for indirection. For the AC of gateMBEx, the following requirements are defined: • The AC can have n slots, where n 3-46 (one less than the maximum number of Modbus addresses, 247, with the latter number being retained for local gateway commands), each slot supporting n 0 , n 1 , ..., n n−1 characters issued, except Slots 0, Slot 1, and those redirected to Slot 1.

•
The minimum number of slots in an AC is 3. • A slot is made up of n i × 11 × θ ticks (it is preferable that the tick does not generate interrupts but is the clock in the timer). • Each slot has a data structure attached with status, control, and data information. • A ModbusE (ModbusExtension) station, by configuration, can subscribe to multiple broadcast/reception slots.
There are three slots with special functions: • Slot 0 (n 0 ) is the slot that marks the beginning of the cycle and can be used, for example, to broadcast the "start scanning" inputs or update outputs. • Slot 1 (n 1 ) is used for indirect empty slots (either they have not been defined or the slaves working with these slots are stopped or defective). If indirectness is not carried out, sending the command could mislead those stations that subscribed to these slots. Slot 1 has no slave device connected; thus, it cannot be subscribed. When used for indirection, only the slot address and the CRC are sent, but its duration inherits the time period of the indirection. There is a byte that usually has a value of 0, but other values may have different meanings. For now, a value other than 0 in the range 1-127, but not greater than the number for Sn-1, can indicate a slot where there is a possible gateway client that can take over the gateway function and, thus, AC management.

•
The last slot (n n−1 ) is used for aperiodic commands and is usually indirectly with Slot 1, if there are no aperiodic commands, or with a slot with a number greater than the last slot in the cycle containing the indirect command. This command must have a number of bytes in the message issued that is less than or equal to the allowed (defined) message for the last slot. It is not prohibited for other slots to take in aperiodic requests (especially slots that have larger cycles than Tcycle).

•
The indirect action procedure on a slot can transmit the data of a slot that is not in the AC provided that the length of the data is not greater than the length of the data of the indirect slot (which, for reasons of determinism, cannot change the time period of a slot without a reconfiguration of the AC). The system may have a maximum number of slots available, but the AC may use fewer. The remaining slots can be used for indirection.
With the exception of Slots 0 and 1, which only have messages issued from the gateway, the other slots, except those indirect to Slot 1, have both a gateway message, hereinafter referred to as a request message, and a response from the server station (slave), hereinafter referred to as a reply message. The structure of these messages is presented in Figure 2. During the AC execution, only the thread dealing with the implementation of AC (thread CYCLE) can have write access to the members of the structure presented above. For this purpose, by means of, e.g., a flag, event, or signal mechanism specific to a specific RTOS, a thread may require thread CYCLE to execute at least the following commands (see Figure 4b): • Disable/activate slot, which reads write values from the data area of the slot. • Set the alternate slot, which can replace the current slot in the cycle with an alternate one outside the cycle (e.g., Location Index Slot 2 with Location Index Slot 5 or, e.g., n − 3, a position with Incremental Index 2, and the location index slot can later be replaced with the location index slot m + 3 < n, a position with Incremental Index 2). • Notify the execution of a particular slot i, notify and activate a slot, and notify and activate the alternate slot, via which operations can be performed on the entry into the data structure of the slot, having a time Tcycle-t si (see Figure 4a). Notifications can be sent for or without running an alternative function on that slot once, a useful feature, for example, for setup from running.
Sensors 2020, 20, x FOR PEER REVIEW 8 of 23 With the exception of Slots 0 and 1, which only have messages issued from the gateway, the other slots, except those indirect to Slot 1, have both a gateway message, hereinafter referred to as a request message, and a response from the server station (slave), hereinafter referred to as a reply message. The structure of these messages is presented in Figure 2. During the AC execution, only the thread dealing with the implementation of AC (thread CYCLE) can have write access to the members of the structure presented above. For this purpose, by means of, e.g., a flag, event, or signal mechanism specific to a specific RTOS, a thread may require thread CYCLE to execute at least the following commands (see Figure 4b):  Disable/activate slot, which reads write values from the data area of the slot.  Set the alternate slot, which can replace the current slot in the cycle with an alternate one outside the cycle (e.g., Location Index Slot 2 with Location Index Slot 5 or, e.g., n − 3, a position with Incremental Index 2, and the location index slot can later be replaced with the location index slot m + 3 < n, a position with Incremental Index 2).  Notify the execution of a particular slot i, notify and activate a slot, and notify and activate the alternate slot, via which operations can be performed on the entry into the data structure of the slot, having a time Tcycle-tsi (see Figure 4a). Notifications can be sent for or without running an alternative function on that slot once, a useful feature, for example, for setup from running.   Figure 5 shows all possible slots defined at the BSG level with indices of the location of the input into the structure area of that index and with the incremental index corresponding to the physical slot. In a physical slot, the location index (AlternativeSlot), which covers the range from 0 to MAX_SLOTS, does not have to coincide with the incremental index (SlotAddress) covering the range of consecutive values from 0 to MAX_CY-CLE_SLOTS, for example, in the usual AlternativeSlot = SlotAddress structure. However, there may also be a situation where AlternativeSlot ≠ SlotAddress, in which case the Alter-nativeSlot value is taken into account if it is different from 0. As a result, an entry into the structure area that defines slots can be IN_CYCLE if its location index has a SlotAddressi pair (1 < i < m, Slots 0 and 1 of the AC have been excluded) and OUT_OF_CYCLE if it does not have such a pair.

Duration of an Acquisition Cycle
A ModbusE AC consists of n slots. As a result, the time period of a tCYA AC is as follows: The period of tsi Slot consists of the following times: where tswi, thwi, and tcommi are defined as follows: tswi (tswCi, tswSi) The time required for software processing (to the client (master) and the server (slave)). Possible causes are the following: delay given by the interrupts handler (character or block level if DMA transfer is used); the time to switch two tasks if an RTOS is used (from the current task to the task that implements the Mod-busE AC); time taken to calculate the CRC; the time it takes to transfer between buffers if applicable (from the reception buffer to the application buffer, or from the application buffer to the broadcast buffer); time required to prepare the slot for emission (indirect, checking, and updating the emission timers from k to k cycles, for creating history from j to j cycles, action on the status of a slot-activating/disabling the slot, activating/disabling indirection, activating/disabling read/write operation); time to update the result of the emission of a message (increment of the message counter issued on the slot, of emission errors); time to handle the response (incrementing message counter received by slot, errors); the time it takes to notify other event tasks (the slot has been activated/disabled, takes the value for the history); other implementation-specific processes. thwi (thwCi, thwSi, tlinei) Hardware delay times at master and slave, usually given by line drivers and other external intermediate logical gates if any, and internal specific to the µC used, plus the delay given by the communication line that depends on the physical distance relative to the device that emits (the master to which other devices to which the current device can subscribe) are added. tcommi (tcommCi, tcommSi) The times consumed by the characters issued by the master by the request message issued on each slot and those issued by the slave in response to these requests (except for Slots 0, 1, and indirect Slot 1).

Duration of an Acquisition Cycle
A ModbusE AC consists of n slots. As a result, the time period of a t CYA AC is as follows: The period of ts i Slot consists of the following times: where tsw i , thw i , and tcomm i are defined as follows: tsw i (tswC i , tswS i ) The time required for software processing (to the client (master) and the server (slave)). Possible causes are the following: delay given by the interrupts handler (character or block level if DMA transfer is used); the time to switch two tasks if an RTOS is used (from the current task to the task that implements the ModbusE AC); time taken to calculate the CRC; the time it takes to transfer between buffers if applicable (from the reception buffer to the application buffer, or from the application buffer to the broadcast buffer); time required to prepare the slot for emission (indirect, checking, and updating the emission timers from k to k cycles, for creating history from j to j cycles, action on the status of a slot-activating/disabling the slot, activating/disabling indirection, activating/disabling read/write operation); time to update the result of the emission of a message (increment of the message counter issued on the slot, of emission errors); time to handle the response (incrementing message counter received by slot, errors); the time it takes to notify other event tasks (the slot has been activated/disabled, takes the value for the history); other implementation-specific processes. For the time spent with the actual communication, the previously entered θ is used, which is the bit time period of a transmitted character. For ModbusE messages, the following general equations can be written (nchC i and nchS i represent the number of characters of the type given in the slot, i.e., without the slot address and CRC): If o (optional = 0), the equation becomes (htslot = 3, 1 ch slot number, 2 ch CRC), and 3.5 ch the end of the message.
If o (optional = 0), the equation becomes As a result, for o = 1, tcomm i is For o = 0, where the components are defined as follows: htslot Header and trailer slot = 1 + 2. One byte is the slot address and 2 16-bit CRC bytes.

1.5
The distance between two characters is 1.5 characters.

3.5
The distance between two messages is 3.5 characters. nchC i Number of customer-issued data characters (master). nchS i Number of data characters issued by slave. nbht Number of bits in header + trailer for a character (usually a start bit and a stop bit). Replacing the times in Equations (6) and (7) with the values in the Equations (8)-(16), we get the following equation: There is the possibility to write t si in the form where the components are defined as follows: As a result, it is possible to rewrite Equation (17) if Slots 0 and 1 have no response.
The last term in Equation (18) is tpyld i . If o is 0, the ModbusE case, the equation becomes where t Sj , j = {0, 1}, can be written as For o = 0, the equation becomes

MBE Implementation Aspects
For specific Modbus RTU communication speeds from 9.6 kb/s to 115.2 kb/s corresponding to practical implementations, the implementation does not pose major designing issues. The interrupt service routine (ISR) can be used for the issuing of requests and the reception of responses (client gateway) or for receiving requests and issuing responses (server). A peculiarity for servers is that the server responses are broadcast and can be captured by all other servers (slave) connected on the same bus with two twisted wires. For speeds greater than 1 Mb/s (up to 27 Mb/s, the range of serial communication speeds explored in this paper), the duration of a serial communication bit may vary from 1 µs to 0.037 µs, which leads, for example, to two 13-frame MBE messages (1 slot address, 2 CRC, and 10 data) at an ideal transmission/reception time from 282 µs (1 Mb/s) to 10.59 µs (27 Mb/s), and the time distance character that generates a break for each frame (character) received/issued can be from 11 µs to 0.4 µs. These times can be stressful for an access gateway that can deploy, on the same µC and a Modbus TCP/IP or Modbus RTU server, multiple transactions and implement Modbus RTU functions under the control of an RTOS. For this reason, implementation should make intensive use of DMA transfer, interrupts, and possible Modbus facilities made available by the hardware architecture of the µC. CRC calculation or moving messages from the communication area to the processing area should not be forgotten if necessary. Scenarios are presented below for overlapping software (SW)/hardware (HW) operations in a kind of SW/HW pipeline. A first SW/HW pipeline implementation scenario is illustrated in Figure 6.  10  1  2  3  4  5  6  7  8  9  11  12   Ts1  Ts2  Ts3  Ts4  Ts5  Ts6 Ts7 Ts8  Ts9  Ts10  Ts11 Ts12 Other thread

CRC CRC
Ti -slot time A few remarks on this scenario are the following:      SO  TR   10  1  2  3  4  5  6  13  8  9  11  12   Ts1  Ts2  Ts3  Ts4  Ts5  Ts6  Ts13  Ts8  Ts9  Ts10  Ts11 Ts12 Other thread Other thread Ti -slot time Therefore, the following requirements for compatibility with the classic Modbus specification and ModbusE requirements must be taken into account for the implementation of the AC: • Change the direction of the RS485 driver from reception to transmission and vice versa. This involves identifying the end of the broadcast message. The DMA-controlled emission provides an appropriate time period of 1.5 characters between two characters.

•
In ModbusE, the presence of slots makes it possible to identify at the gateway a maximum duration of 1.5 characters between two consecutive characters of the reception message, as well as a duration of 3.5 characters, which signals the end of the message (with slot address, length, and CRC, one can easily verify the accuracy and presence of the received message, thus avoiding additional interrupts given by the DMA controller at the end of the message that can require significant additional time at high working speeds of more than 10 MB/s). This cannot be avoided at the level of the slave station, which must track all messages containing its own message(s), as well as the messages to which it has subscribed and Slot 0 or 1, e.g., the launch of the acquisition task.
As a result, the following factors are included in the implementation of the AC: thread CYCLE (set with the highest priority in the system), an RTOS that schedules the launch of the threads in execution, as well as the mechanisms of synchronization and communication between threads, the interrupts launched by the timer for the duration of a slot, DMA indicating that the timer attached to the emission message reaches 0, and USART for switching the direction of the RS485 driver back to reception and for launching the operation to receive the response message from the slave, if any.

Performance Evaluation of the Proposed MBE Solution
In this section, we aim to evaluate the performance implementation of the MBE concept proposed in Section 4, on the basis of the equations presented in Section 3.
We are interested in answering the following questions: What is the bandwidth of the serial communication channel? How much of this bandwidth is used to transport payload data? What is the usability of a slot time? What are the factors that have a great influence on the parameters previously mentioned? Proposals for optimizations and improvements are made on the basis of the results of the experiments.

Organizing the Experiment
For the implementation of the experiment, we used the following:  Therefore, the following requirements for compatibility with the classic Modbus specification and ModbusE requirements must be taken into account for the implementation of the AC:

•
Change the direction of the RS485 driver from reception to transmission and vice versa. This involves identifying the end of the broadcast message. The DMA-controlled emission provides an appropriate time period of 1.5 characters between two characters. • In ModbusE, the presence of slots makes it possible to identify at the gateway a maximum duration of 1.5 characters between two consecutive characters of the reception message, as well as a duration of 3.5 characters, which signals the end of the message (with slot address, length, and CRC, one can easily verify the accuracy and presence of the received message, thus avoiding additional interrupts given by the DMA controller at the end of the message that can require significant additional time at high working speeds of more than 10 MB/s). This cannot be avoided at the level of the slave station, which must track all messages containing its own message(s), as well as the messages to which it has subscribed and Slot 0 or 1, e.g., the launch of the acquisition task.
As a result, the following factors are included in the implementation of the AC: thread CYCLE (set with the highest priority in the system), an RTOS that schedules the launch of the threads in execution, as well as the mechanisms of synchronization and communication between threads, the interrupts launched by the timer for the duration of a slot, DMA indicating that the timer attached to the emission message reaches 0, and USART for switching the direction of the RS485 driver back to reception and for launching the operation to receive the response message from the slave, if any.

Performance Evaluation of the Proposed MBE Solution
In this section, we aim to evaluate the performance implementation of the MBE concept proposed in Section 4, on the basis of the equations presented in Section 3.
We are interested in answering the following questions: What is the bandwidth of the serial communication channel? How much of this bandwidth is used to transport payload data? What is the usability of a slot time? What are the factors that have a great influence on the parameters previously mentioned? Proposals for optimizations and improvements are made on the basis of the results of the experiments.

Organizing the Experiment
For the implementation of the experiment, we used the following: • The test AC had 30 slots in cycles from 0 to 29, with messages of lengths described in Table 1 and calculated with Equation (3). Corresponding to the example in Table 1, for ModbusE, we have the following data.  Figure 8 shows the evolution over time during Slot 2. Points of interest obtained using a marker implemented on the switch signal of the direction of the RS485 driver are marked on the figure. Markers typically flag the entry and exit of an event (code sequences in thread Cycle, interrupts, and the activation/deactivation of the RS485 line driver). Start and stop bits mark the broadcast periods on the RS485 bus. The ISR marker for the timer that signals the start of a new slot is longer to make it easier to detect the start of a slot.

Results of the Experiment
On the basis of the points indicated in Figure 8, measurable times were defined (Appendix A). Table 2 shows the measured values for Slot 3. On the basis of the points indicated in Figure 8, measurable times were defined (Appendix A). Table 2 shows the measured values for Slot 3.

Discussions
The following is a comparison of message length using Modbus RTU, CAN, CAN FD, and Profibus DP-V0 protocols. As presented in Figure 2, the MBE message was introduced with support for ModbusRTU compatibility in the sense that the SYNC character also has slot address significance, and it can also indirectly be in a slot that does not have an IN_CYCLE index (see Figure 5). This reduced the number of bits considered in [3] from 11 (SyncSlot) + 33 (1 slot number + 2 CRC) + 11 × n to 33 + 11 × n.
Compared to the Profibus DP = V0 protocol, the SRD messages of the MBE protocol are shorter. The frames for 8b data are the same as 11b (1b START, 1b EVEN PARITY, 1b STOP, and 8b DATA), while the number of control characters (header + trailer), which accompany the SRD message, can be 6 or 9, i.e., greater than 3 (1 × slot address + 2 × for CRC), as required for MBE. Both protocols use a delimiter, 33b (three frames) and 3.5 frames, which makes it necessary to increase the control bits for MBE by 3.5 − 3 = 0.5 frames (5.5 b). Compared to the CAN protocol, calculation can be performed in bits as follows: When n = 0-4, the difference is positive; when n = 5, the difference is negative. When n = 8, the difference is positive; when n = 15, the difference is positive again. When n = 16, the difference is positive; when n = 23, the difference is positive again. Therefore, CAN has the shorter message only when n = 5, 6, or 7; otherwise, the MBE message is shorter. Compared to the CAN FD protocol, we have 62(67 n > 16)) + padding + 8n (CAN) − 33 − 11n (MBE) = 29 (34) + padding − 3n.
The message length for CAN FD can range from 0 to 8, whereas, in the normal CAN protocol, the message length is 12, 16, 20, 24, 32, 48, or 64 (for fixed values, one can achieve a standard length (padding)). These values are transported unnecessarily, and padding bits are added to the control bits. In a message of not more than 64 bits, on the basis of the equations for the two protocols, it can easily be shown that, when n = 0-11, 13, 14, 17, 25, 26, 33-38, and 49. Of the 64 CAN values, FD is shorter than the 41 n values; thus, overall, it is shorter in 64% of cases. However, CAN FD is a protocol only for Levels 1 and 2 of the ISO-OSI model. If an implementation such as CANOpen FD is considered, the USDO protocol adds 14 bytes to each message, which leads to the modification of previous assessments reported to CAN FD in favor of MBE.
In terms of maximum working speed, MBE has been tested at 27 Mb/s. CAN has rates of 1 Mb/s, Profibus has rates of 12 Mb/s, and CAN FD has rates of 8-10 Mb/s in the data cycle. From the point of view of access to the environment, CAN and CAN FD have an arbitrary mechanism of access to the multiple access environment with collision avoidance, while MBE and Profibus use TDMA (time division multiple access). In terms of the management of CAN and CAN FD, errors have evolved mechanisms, while Profibus and MBE have mechanisms provided by UART (universal asynchronous receiver). From an application point of view, MBE is an update for Modbus RTU. MBE allows the use/reuse of Modbus applications, which are used in low-(MBE/RTU) and medium-complexity (TCP/IP) applications at a low implementation cost, while maintaining the same ease of use, a low memory footprint, complexity scalability, domain and range, an ease of administration and improvement, and the same openness and inexpensiveness as those of MODBUS. The AC with the chosen cycle structure presented in Table 1, the measurement points indicated by the markers in Figure 8, the definitions in Appendix A, and the measured values in Table 2 is discussed below. According to the oscilloscope capture in Figure 8, the different levels of actions during execution for the chosen slot are shown in Figure 9. The total duration of the cycle period is 5666 ms, during which 3819 physical frames of 11b are transported on the physical medium for 70.62% of the cycle time, with this time period being managed by DMA channels without the intervention of the Cortex-M4 kernel, of which the load is 3644 B for 49.6% of the cycle duration. The time periods of Slots 0 and 1 (S0 and S1) are somewhat large compared to the small number of bytes transported on the physical environment, because the CRC of the aperiodic message (usually 134 B) is calculated during S0, and the indirectness is performed during S1, which in exceptional cases can have a response of up to 8 B. period being managed by DMA channels without the intervention of the Cortex-M4 kernel, of which the load is 3644 B for 49.6% of the cycle duration. The time periods of Slots 0 and 1 (S0 and S1) are somewhat large compared to the small number of bytes transported on the physical environment, because the CRC of the aperiodic message (usually 134 B) is calculated during S0, and the indirectness is performed during S1, which in exceptional cases can have a response of up to 8 B. The time period of the slot varies between 41.01 and 661 us depending on the size of the request/response messages. In this context, the time period of a slot can be used by the running threads of thread Cycle, which run on both the client and the server. Customerlevel interrupts are generated by the timer that (1) measures the times of a slot (~2.8 µs), the DMA emission channel (~0.9 µs), and the USART programmed on the broadcast that signals the full transmission of the last character (the RS485 driver can be switched to reception) and (2) schedules its reception status (~1.3 µs-S0.1, and 2.1 µs elsewhere). This results in a total of 5.8 µs, i.e., 0.1% of the time period of the AC. Processing at the thread Cycle (tmhd) level varies between 2% (S6 having the longest time period consumed by DMA channels) and 46.76% (S0) of AC, with an average per AC of 9.2%, of which the most time-consuming routine is the one that calculates the CRC (between 0 (S1, S2) and 44.73 µs (S7)), with an average of 5.6% of AC. Switching threads due to thread Cycle lasts ~3 µs, with an average of 1.6% of AC.
A discussion of the MBE client (SLAVE) at the slot and AC level is also given. First, according to the analysis of the interrupt generated by the timer that generates the interrupt for the end of the message, it has a duration of ~0.8 µs if the received message is in progress and a duration of ~2.9 µs if a message end has been determined. Overall, the time spent by this operation is about 2% of AC. The message was also highlighted to move the message from the reception buffer to the buffer of the thread that processes the request, calculates the CRC, and sends a notification to the thread Cycle (server). Moving times are 0.8-41.25 µs, with an average of 5.6% of AC. Finally, the times (%mbusySlot) occupied by SW at the BSG (client) slots range from 2.52% (long messages) to 45.16% (short messages), with an average of 11.16% of the AC time period. At the server (SLAVE), these times are longer from moving the message to another buffer and range between 10.84% (long messages) and 30.60% (short messages), with an average of 14.31% of the AC level. Percentages allow time for other tasks to be scheduled for execution (in this experiment, there were 15 threads of execution in the system). This experiment was repeated using two 32F746GDISCOVERY Discovery kits with µC STM32F746, the difference being the communication speed of 27 Mb/s and the µC speed of 216 MHz. The AC time period decreased from 5.665 ms to 4.12 ms. Although the communication rate is 2.7 times higher, the working frequency of the kernel is 1.28 times higher, and there is extended support for MOD-BUS (most complete). The reduction of the AC time period is only 27%. The explanation The time period of the slot varies between 41.01 and 661 us depending on the size of the request/response messages. In this context, the time period of a slot can be used by the running threads of thread Cycle, which run on both the client and the server. Customer-level interrupts are generated by the timer that (1) measures the times of a slot (~2.8 µs), the DMA emission channel (~0.9 µs), and the USART programmed on the broadcast that signals the full transmission of the last character (the RS485 driver can be switched to reception) and (2) schedules its reception status (~1.3 µs-S0.1, and 2.1 µs elsewhere). This results in a total of 5.8 µs, i.e., 0.1% of the time period of the AC. Processing at the thread Cycle (tmhd) level varies between 2% (S6 having the longest time period consumed by DMA channels) and 46.76% (S0) of AC, with an average per AC of 9.2%, of which the most time-consuming routine is the one that calculates the CRC (between 0 (S1, S2) and 44.73 µs (S7)), with an average of 5.6% of AC. Switching threads due to thread Cycle lasts~3 µs, with an average of 1.6% of AC.
A discussion of the MBE client (SLAVE) at the slot and AC level is also given. First, according to the analysis of the interrupt generated by the timer that generates the interrupt for the end of the message, it has a duration of~0.8 µs if the received message is in progress and a duration of~2.9 µs if a message end has been determined. Overall, the time spent by this operation is about 2% of AC. The message was also highlighted to move the message from the reception buffer to the buffer of the thread that processes the request, calculates the CRC, and sends a notification to the thread Cycle (server). Moving times are 0.8-41.25 µs, with an average of 5.6% of AC. Finally, the times (%mbusySlot) occupied by SW at the BSG (client) slots range from 2.52% (long messages) to 45.16% (short messages), with an average of 11.16% of the AC time period. At the server (SLAVE), these times are longer from moving the message to another buffer and range between 10.84% (long messages) and 30.60% (short messages), with an average of 14.31% of the AC level. Percentages allow time for other tasks to be scheduled for execution (in this experiment, there were 15 threads of execution in the system). This experiment was repeated using two 32F746GDISCOVERY Discovery kits with µC STM32F746, the difference being the communication speed of 27 Mb/s and the µC speed of 216 MHz. The AC time period decreased from 5.665 ms to 4.12 ms. Although the communication rate is 2.7 times higher, the working frequency of the kernel is 1.28 times higher, and there is extended support for MODBUS (most complete). The reduction of the AC time period is only 27%. The explanation lies in the adjustment time (tadjust i ) that allows the other threads in the system to run. The total period of the cycle period is 4.12 ms, during which 3819 physical frames of 11b are transported on the physical medium for 37.8% of the cycle, this time period being managed by DMA channels without the intervention of the Cortex-M4 kernel, of which the load is 3644 B for 36% of the cycle.
Another experiment considered the idea of using a multicore µC-in this case, a combination of Cortex-M4 and Cortex-M0. Two Keil MCB4300 kits were used. The Cortex-M0 core was used only for MBE implementation, without RTOS, interrupts, or DMA. The chosen communication rate was 11.5 MHz at a frequency of 180 MHz of the CortexM0 core.
RTOS, DMA transfer, and interrupts were abandoned, and pooling was used instead. The AC time period decreased from 5665 ms to 4324 ms. The communication rate was 1.01 times higher, the working frequency of the nucleus was 1.07, and the reduction in the AC time period was 23.7%. The explanation lies in the absence of RTOS and ISRs. The total period of a cycle time is 4324 ms, during which 3819 physical frames of 11b are transported on the physical medium for 84.5% of the AC time period, with this time being managed by DMA channels without the intervention of the Cortex-M4 kernel, of which the load is 3644 B for 80.6% of the AC time. It follows from Table 3 that the two-core solution in which a kernel is dedicated to MBE has the greatest efficiency. It works in a loop and does not use RTOS, ISR, or DMA. In this case, the working frequency of the Cortex-M0 core copes with the transfer rate of 11.5 Mb/s, a character at 0.955 µs. The implementation of an HW/SW "pipeline" using DMA channels, by parallelizing the software operations needed to implement the AC with the serial communication controlled by DMA channels, has led to improved communication channel usage (37.8% for STM32F746). It has been shown that the efficiency of using a slot's time decreases with increasing communication speed, but improves if the µC implementing MBE does not have other tasks. In other words, the adjustment time (tadjusti), invisible in the visualization of the temporal evolution within a slot, has a major influence and depends on the µC workload.

Description of Devices
FDI, FDT, and EDDL or the projects proposed in [25,26] may be solutions for describing networked devices that can be adapted for MBE. For sensors, the standard IEEE 1544.4, which is an emerging standard for adding plug-and-play capabilities to analog transducers, can be used. The basic mechanism for plug-and-play identification is the standardization of an electronic transducer data sheet (TEDS). A TEDS contains the critical information needed by a measuring instrument or system to correctly identify, characterize, interface, and use the signal from an analog sensor. TEDS is implemented for a sensor in one of two ways. First, TEDS can be stored in built-in memory, usually an EEPROM memory, in the analogue transducer as defined in IEEE 1451.4. Second, a virtual TEDS can exist as a separate, downloadable file from the internet. This virtual TEDS concept extends standardized TEDS benefits to old sensors and applications where built-in memory or EEPROM is not available. The IEEE 1451.4 defines the TEDS information encoding method for a wide range of sensor types and applications. To cover such a wide range while keeping the memory usage to a minimum, the IEEE 1451.4 TEDS uses the concept of templates that define the specific properties of different types of sensors. Another elegant concept is defined by the Foundation Fieldbus (FF) foundation, which uses function block, device description language, device description interoperability specification, transducer block common structure, pressure transducer block, communication profile, and more.
However, the simplest solution is the adaptation presented in [26] using the specifications of the CiA DS 306 series, with the stipulation that, for MBE, the section [COMMUNI-CATION] is not necessary.

Integrating BSG in IoT
The industrial Internet of things (IIoT) based on embedded systems or cyber physical systems (CPSs), running real-time applications for supervision, control, and monitoring of industrial processes, is designed to acquire data from and send data to sensors and transducers using LINWs. These data are sent to the application level where they can be distributed to the Internet using new Industrial IoT applications, SCADA applications [5], or smart building control applications. In this context, a fieldbus communication network has an important role in ensuring the support in order to transport these data.
The Modbus protocol with its RTU and TCP/IP variants is one of the oldest and most widely used, but it is only partially defined. For this reason, in this paper, an AC was implemented and evaluated for incomplete defined protocols using a proposed extension for Modbus, called ModbusE (Modbus Extension) [3], which is meant to achieve the Modbus RTU specifications and to increase its performance while maintaining compatibility with Modbus classic.
In the future, improvements can be made to the protocol, e.g., defining a microMBE architecture for short and reliable links in which the slot address is 4 bits and the other 4 bits can define the length of the message, continuously or with predefined values (as in CAN FD), replacing the CRC with a simpler control amount (as in MODBUS ASCII or Profibus). The goal of this architecture is to design and develop a demonstrative experimental system for the implementation and testing of an intelligent gateway Industrial IoT: the Modbus Extension protocol for process monitoring and control management (IIoT MBE System: an application instance of BSG). This system will be used to evaluate and validate the AC and the extension ModbusE for the Modbus RTU protocol. The general architecture of the experimental demonstration system is presented in Figure 10.
The experimental demonstration IoT MBE System consists of a smart gateway IIoT MBE Gateway with three gateways (Modbus TCP/IP-ModbusE, Modbus RTU-ModbusE, and IIoT-ModbusE using the UPC UA server/client) and allows for implementing the acquisition cycle for ModbusE (AC_MBE) presented in this paper as part of the ModbusE protocol, the IIoT MBE Slave provided with the ModbusE server connected to the RS 485 communication network, the PC Modbus TCP/IP, and the RTU driver (Windows, Linux), which will include a call to a utility application for the ModbusE protocol (UAP_MBE) for configuration, validation, testing, and integration in Industrial IoT applications and a PC OPC UA client.
An interesting question that arises for high transfer speeds is that of who processes these data. The BSG-level TCP/IP server receives transfer requests from common external applications with access times of 500 ms. Parallelization can be done if multiple transactions are used (a maximum of 16 stipulated in the specification for Modbus TCP/IP). BSG may not have time for processing if it is based on a single µC. In some applications, the server stations (SLAVE) in the MBE can subscribe and use the information of any slot. BSG only provides CA management.  Figure 10. The main architecture of the experimental system for IIoT-ModbusE, (RTU) smart gateway.
An interesting question that arises for high transfer speeds is that of who processes these data. The BSG-level TCP/IP server receives transfer requests from common external applications with access times of 500 ms. Parallelization can be done if multiple transactions are used (a maximum of 16 stipulated in the specification for Modbus TCP/IP). BSG may not have time for processing if it is based on a single µ C. In some applications, the server stations (SLAVE) in the MBE can subscribe and use the information of any slot. BSG only provides CA management.
Another solution may be to use SoCs at the BSG level with Cortex-Ax, DSP, or Cortex-Mx, where Cortex-Mx (or similar) implements MBA CA, Cortex-Ax implements a calculation and control algorithm, and Cortex-Ax implements a server (possibly a client) OPC UA. Among many others, we mention the Texas Instruments Sitara AM5729, the Dual Arm Cortex-A15 microprocessor subsystem, 2 C66x floating-point VlIW DSPs, a 2× Dual Arm Cortex-M4 coprocessor, a 2× dual-core Programmable Real-Time Unit and Industrial Communication SubSystem (PRU-ICSS), used by BeagleBone AI, or STM32MP157 (where microprocessors are based on the flexible architecture of a Dual Arm Cortex-A7 core running up to 800 MHz, a Cortex-M4 at 209 MHz, and a CAN FD interface), used by DK32MP1157C.

Conclusions
This paper presented an original implementation of MBE in the form of BSG (MAS-TER) and server workstations (SLAVE). The MBE validation enabled the performance evaluation of this Modbus extension on a new message structure, an AC for obtaining a deterministic temporal behavior, a description of Modbus and MBE devices, and the definition of an architecture for integration into IIoT. Mathematical equations were defined, and specific times within an AC slot were calculated on their basis.
In the first two examples presented, the CPU workload was substantial, with 15 threads with stacks for USB and TCP/IP with applications (BSD sockets). In the example in which a microcontroller looped the implementation of MBE, the time efficiency of a slot was much better. FPGA implementation is expected to achieve the best results. To complete the MBE, a method of approaching the Modbus and MBE devices was also proposed. Another important observation is that the algorithm proposed in [3], on the slot time period, through network adjustments, is useful because the measurements taken in the experiment presented in the paper are not accessible for a simple network configuration process. In addition, few Modbus devices define a response time to Modbus requests. To Another solution may be to use SoCs at the BSG level with Cortex-Ax, DSP, or Cortex-Mx, where Cortex-Mx (or similar) implements MBA CA, Cortex-Ax implements a calculation and control algorithm, and Cortex-Ax implements a server (possibly a client) OPC UA. Among many others, we mention the Texas Instruments Sitara AM5729, the Dual Arm Cortex-A15 microprocessor subsystem, 2 C66x floating-point VlIW DSPs, a 2× Dual Arm Cortex-M4 coprocessor, a 2× dual-core Programmable Real-Time Unit and Industrial Communication SubSystem (PRU-ICSS), used by BeagleBone AI, or STM32MP157 (where microprocessors are based on the flexible architecture of a Dual Arm Cortex-A7 core running up to 800 MHz, a Cortex-M4 at 209 MHz, and a CAN FD interface), used by DK32MP1157C.

Conclusions
This paper presented an original implementation of MBE in the form of BSG (MASTER) and server workstations (SLAVE). The MBE validation enabled the performance evaluation of this Modbus extension on a new message structure, an AC for obtaining a deterministic temporal behavior, a description of Modbus and MBE devices, and the definition of an architecture for integration into IIoT. Mathematical equations were defined, and specific times within an AC slot were calculated on their basis.
In the first two examples presented, the CPU workload was substantial, with 15 threads with stacks for USB and TCP/IP with applications (BSD sockets). In the example in which a microcontroller looped the implementation of MBE, the time efficiency of a slot was much better. FPGA implementation is expected to achieve the best results. To complete the MBE, a method of approaching the Modbus and MBE devices was also proposed. Another important observation is that the algorithm proposed in [3], on the slot time period, through network adjustments, is useful because the measurements taken in the experiment presented in the paper are not accessible for a simple network configuration process. In addition, few Modbus devices define a response time to Modbus requests. To this end, the theoretical communication time was decreased (69.39%), and a 100% adjustment time (empirical adjustment) was added, which was reduced or increased by a division algorithm with powers of 2, and a permitted error margin was taken into account. Since the experiment simulated all 30 slots on a single server card (SLAVE), this margin was 0. The criterion used was no error for 10 consecutive days (approximately 152,515,445 cycles). The algorithm in [3] was improved by a preassessment stage of server station response times. Different response times were simulated in the experiment. Random response times were also simulated, the conclusion being that, if these times have a sporadic occurrence, an acceptable margin of error can be allowed under the conditions of a specific application.
Lastly, it can be said that MBE is a simple extension that invigorates Modbus, retains compatibility, and can be used for low-and medium-complexity applications at a low cost. Because the MBE application level is based on the application level at MODBUS, MODBUS software is portable for Modbus stations and reusable with a simple wrapper for MBE.
Author Contributions: Conceptualization, V.G.G. and I.Z.; software, V.G.G. and I.Z.; data curation, V.G.G. and I.Z.; writing-original draft preparation, V.G.G. and I.Z.; writing-review and editing, V.G.G. and I.Z. All authors have read and agreed to the published version of the manuscript.