Proposed Modbus Extension Protocol and Real-Time Communication Timing Requirements for Distributed Embedded Systems

Abstract

The general evolution of fieldbus systems has been variously affected by both computer electrical engineering and science. First, the main contribution undoubtedly originated from network IT systems, when the Open Systems Interconnection model was presented. This reference model with seven layers was and remains the foundation for the development of numerous advanced communication protocols. In this paper, the conducted research resulted in a major contribution; specifically, it describes the mathematical model for the Modbus protocol and defines the acquisition cycle model that corresponds to incompletely defined protocols in order to provide a timestamp and achieve temporal consistency for proposed Modbus Extension. The derived technical contribution of the authors is to exemplify the functionality of a typical industrial protocol that can be decomposed to improve the performance of data acquisition systems. Research results in this area have significant implications for innovations in industrial automation networking because of increasing distributed installations and Industrial Internet of Things (IIoT) applications.

1. Introduction

The process of acquiring real-time data from fieldbuses depends very much on the type of network and protocol used. Currently, there are an impressive number of fieldbuses, some of which are fully defined and others incompletely defined. In the second category, the time variable that is the main element in real-time data acquisition is not explicitly mentioned. Examples include protocols such as Modbus ASCII/RTU, M-bus, character-based ASCII and so on. In principle, distributed projects, which focus on the supervision and management of industrial processes, are conceived as a chain of data acquisition starting from transducers and sensors and finishing with uploading the data to the Internet [1]. This information flow supports the further development of large-scale remote distributed applications, services and configuration [2]. Importantly, fieldbuses are being used for the incorporation of sensors, actuators and control devices into automation [3] based on AS-I or DeviceNet fieldbus standards, smart cities and smart buildings [4] using KNX or LonWorks, photovoltaics, Industry 4.0 [5], and monitoring systems integrating Modbus RTU, Interbus-S or even CANOpen communication protocols. Currently, it is estimated that there are over 290 fieldbus protocols that have been defined. They are implemented in two layers or even more in the structural arrangement of the network.

At the peripheral level, fieldbuses are typically specialized to interconnect sensors and actuators or to interface digital I/O devices. These fieldbuses need to be inexpensive relative to the attached devices, and AS-I, IO-Link, LIN, CANOpen and LonWorks represent typical implementations of fieldbuses successfully used in the automation industry. The device level is in some cases referred to as the field-level network. The performance of these fieldbuses has been steadily improved; they were originally developed to interface 32–256 I/O groups and automated units that can transfer condition information and floating-point values, where the cost of the interface locations would be higher. Profibus DP, Modbus RTU, DeviceNet, LonWorks, Interbus-S and CANOpen also appear in the latter category. In terms of control level, fieldbuses have the highest performance in this respect, being able to connect automation units, PCs, CNC controllers, HMIs and multiple I/O data acquisition. For this reason, fieldbuses operate using long, relatively high-speed messages and generally belong to this category of networks, such as EtherCAT, CC-Link, WorldFIP, Profinet, ControlNet, EPL, Sercos III and industrial Ethernet. Other fieldbuses are used in specific applications such as building automation (BACnet, KNX, LonWorks) [6], ARINC, continuous processes such as HART, Profibus PA, Foundation Fieldbus, machine safety such as Si-bus, BusSafety, or integrated transportation applications.

Some of these protocols are fully defined so they provide the specification of the acquisition cycle as well as the parameters to describe the peripherals attached to the network. High-speed networking protocols such as Profinet, EtherCAT, CC-Link, Sercos III, EPL or EthernetIP rigorously define the architecture of the protocol as well as various synchronization schemes. Some of these networks require specialized hardware support, so they do not lend themselves to low-cost solutions. This category includes time-triggered protocols such as TTP/C, TTP, FT-CAN, TTA or TTE. They are widely applied in the machine building industry or in aviation, with stringent constraints on robustness, timing synchronization and failure recovery that cannot be adequate for low-cost implementations [7]. While not all protocols developed for the various kinds of communication systems are completely defined, one can mention ASCII, Modbus, M-bus and others. Consequently, time consistency, MAC access and the identification of electronic peripherals can be potentially at risk. In general, a number of protocols implemented on the first two layers are completely defined [8].

The benefits of partially specified protocols are due to their very inexpensive and simple implementation and absence of complex transmission lines, as well as the need for asynchronous communication over serial interfaces. In this paper, we eliminate two of these drawbacks: the MAC addressing pattern and the time coherence. In the following, the term client will be used for master (M) and server for slave (S), according to the new Modbus specifications. As a main goal, we deployed the structure of an acquisition cycle for incompletely defined networks to add a timestamp and to gain a wide temporal consistency. This paper defines a versatile client–server architecture-based cycle acquisition pattern that can be deployed on a client machine designated as Base Station Gateway (BSG). Here, the communication message structure, the BSG as the client device, and the data acquisition cycle were defined. Thus, the BSG may provide the timestamp for the temporal localization. After the description of the mathematical model for the Modbus protocol, an extended Modbus implementation is presented, designed as a cost-effective and lightweight model built on available hardware. The microcontroller validation of the ModbusE design is attributed to the new communication message structure, a deterministic temporal behavior due to the acquisition cycle, the proposal of Modbus devices in an embedded IIoT architecture. These proposals and research were based on analysis from the presented mathematical model for an architecture incorporating a Modbus protocol, SmartConvert, STM32F7 and RTX RTOS. Another contribution concerns the measurement of the jitter inserted by the Windows 10 operating system with an average load in the communication among client and server PC stations. Systems that can employ the ModbusE protocol are industrial monitoring processes, medium- and high-response-time processes, and IIoT.

This paper is organized as follows: After the Introduction, Section 2 describes the Modbus RTU protocol and related services. Section 3 presents the supporting architecture for the description of the mathematical model and Section 4 validates the experimental results. Section 5 presents the proposed Modbus Extension concept, and Section 6 reviews previous Modbus-based projects. Section 7 and Section 8 present the discussions and final conclusions.

2. Modbus RTU Protocols and Services

Conventional Modbus messages can be packaged in RTU or ASCII frames and packed with a TCP/IP interface so that they can be routed over the Internet. The IoT Gateway will be provided with a MODBUS TCP/IP server. Server deployments based on this protocol will have an interface commonly called the Data Provider, which will deliver a packet between the server and the MODBUS TCP/IP driver. Modbus-based gateways were developed quite some time ago and others are still in development, with Modbus remaining the second most common protocol commercially in use, along with other available protocols. The gateway between the serial Modbus protocol and the popular Modbus TCP/IP protocol has allowed many older products to bypass TCP/IP with no need for upgrades. Frequently, gateways fulfill the function of proxy clients, i.e., a gateway placed between the serial Modbus and Modbus TCP/IP enables several clients on Modbus TCP/IP to connect quasi-competing servers on the serial Modbus by buffering and queueing independently without the necessity of synchronizing users. The Modbus protocol was utilized to provide communication with other networks in two important modes, by interpretation and also by mapping. Modbus has been utilized with other tunneling and bridging protocols as well. The present paper also introduces Modbus TCP/IP, since in the overall project the authors intend to propose a Modbus Gateway. Thus, an IoT gateway is designed with a Modbus TCP/IP enabled server. The implementation built using this protocol provides a wrapper from the server side to the Modbus TCP/IP driver. The Modbus TCP/IP and Modbus RTU acquisition cycle performance analysis will be integrated in the deployment of an IIoT ModbusE_Gateway within the IIoT_ModbusE_System. It evaluates ModbusE clocks and timings as BSG workstations (client) and a server. In order to achieve improved acquisition cycle timings, an incompletely defined Modbus protocol extension (ModbusE) has been proposed and validated. Hence, ModbusE is tested with respect to the new message and acquisition cycle structure in order to achieve time-deterministic behavior for IIoT_ModbusE_Gateway, which also integrates Modbus TCP/IP in the IIoT_Modbus_Server system.

The implementation of the Modbus protocol over the serial interface utilizes one of two distinctive transmission types, RTU and ASCII. While RTU is more reliable but slightly more complex to realize, ASCII is simpler. The transmission method and serial port configuration should be identical for all components along a Modbus serial bus. If devices transmit over a Modbus serial line utilizing the RTU transmission method, every character on the line constitutes one byte of the corresponding application message. The primary benefit with this mode it that its higher density enables improved data transfer for the same transfer rate compared to ASCII mode. Every message needs to be streamed as a flow of characters. This mode is more efficient than the ASCII mode because each byte of the application message takes just one character to be transmitted. RTU transmission mode identifies the limits of the transmission element as a function of time. The format for each character sent (11 bits) in RTU mode has the following characteristics:

• Coding system based on 8-bit binary, with two hexadecimal characters (0–9, A–F) contained in the 8-bit character field on the wire.
• Bits output per character: one start bit, eight data bits, least significant bit (LSB) sent first, one bit for odd/even parity, no bit for no parity, one stop bit if parity is used, and parity.
• Even parity: Other modes may be used (odd parity, no parity). For maximum interoperability with different products, the integration of parity-free mode is advised. The implicit parity mode must be even parity.
• Error checking field: cyclic redundancy check (CRC).
• The way in which characters are transmitted serially, i.e., every character along the wire is transferred from left to right, from LSB to MSB.

Units can be configured to accept odd or even parity check as well as no parity check. If parity is not set, an optional stop bit is sent to complete the characters in the framing. The maximum Modbus RTU frame size is 256 bytes. For Modbus RTU message frames, a Modbus message is placed by the transmitting device in a frame that has a known start and end point. This allows devices receiving a new frame to start at the beginning of the message and know when the message is completed. Partial messages must be detected and errors must be clearly established. Within RTU mode, message slots are delimited by an idle period of 3.5 characters at minimum. In the next paragraphs, this period is named t3.5. The message stream must be passed as a single stream of characters. Where an idle gap of at least 1.5 characters exists between 2 transmitted characters, the frame is declared invalid and shall be rejected at the receptor.

When devices communicate over a Modbus serial line using ASCII mode, each byte of the request message is sent over the wire using two ASCII characters. ASCII mode is selected in cases where device features cannot comply with RTU-mode timing requirements. It is less time-efficient compared to RTU due to the fact that each byte of the request message requires two characters. Figure 1 shows the Modbus protocol data unit and the Modbus frame for the serial line. For the Modbus serial line, the address field contains only server address and the function code tells the server what actions to perform. This may be followed by the data field, which contains the request and response parameters. Error detection is performed according to the content of the message. There are two calculation methods based on the selected communication mode (RTU vs. ASCII). For the serial line, the Modbus protocol is client–server. It is placed at level 2 of the Open Systems Interconnection (OSI) model. A client–server system has a client node that sends explicit commands to a server node and processes the responses.

Usually, server nodes do not send data in the absence of a query from the client or exchange data between servers. On the physical layer, different interfaces can be used (RS485, RS232). In this respect, the two-wire TIA/EIA-485 is the most common use. A four-wire interface can also be implemented as an option.

The client node can send a request to server nodes in two ways:

• In unicast mode, the client addresses a specific server. After receiving a processing request, the server returns a reply message to the client. In this mode, a Modbus transaction consists of two messages: a request from the client and a response from the server. Each server has a unique address, ranging from 1 to 247, and can therefore be accessed separately from another server.
• Broadcast mode enables the client request to be broadcast to servers. In this situation, no response is returned to broadcast requests sent by the client. Broadcast requests are mandatory write commands, so all devices must accept broadcast for write functions. Address 0 is reserved to identify a broadcast request.

The messages exchanged by Modbus client and server services (client messages versus server messages) are characterized by a structure defined as APDU (Application Protocol Data Unit), described below. The application payload, also referred to as the “Modbus Protocol Data Unit”, is composed of two separate fields, data and code. The structure aggregated is called Modbus APDU, and the argument for using APDU is the compatibility in different Modbus transfers. The Modbus client lets the subscriber application specifically enable the user application to explicitly control the interchange of information remotely with the controlled peripheral unit. This Modbus client consists of building a Modbus query from parameters passed from the application to the Modbus client device. The client–server model used is shown in Figure 2.

If the Modbus client handles a Modbus transaction, which consists of an expected and computed Modbus acknowledgment, under the client–server model, two stations cooperate in exchanging information. The entity that supplies a service or data is also referred to as the server, whereas the entity that solicits the service is considered the client. Typically, a server can only turn active at the demand of the client [9], which implies that the model is more appropriate for state-based and schedule-managed data traffic.

Figure 3 shows the status diagram for the RTU transmission mode. In the same diagram, both server and client views are expressed. Considering the state diagram in Figure 3, the following points can be made:

• The transition from the initial state to the idle state requires the expiration of time t3.5 (this ensures the inter-frame delay).
• Normal state, in that no transmission/reception is activated, is the idle state.
• With the RTU mode, the transmission line is considered idle if there is no transmission operation for at least 3.5 chars.
• If the unit is in idle state, every sent character recognized on the link is detected as a start of the frame. The link transitions to the enabled state, and then the frame end is detected once no further characters are passed after t3.5.
• Once the end of a frame is detected, the CRC is calculated, resulting in a complete verification. Then, the addr field is analyzed to find whether this frame is addressed to the targeted device. In case it is not for the current device, it is then rejected. To minimize the processing time on the receive, the address can be processed immediately as it is received rather than waiting for the completion of the frame. The CRC in this case will only be processed and verified if that frame is directed to the device or is a broadcast frame.

In fieldbus systems, there are many types of traffic that need to be considered. However, there exist a number of various services a fieldbus must offer to the end-user application. Besides simple operations such as reading and writing parameters, object handling is required.

This includes updating unit configurations, switching on and off tasks executing on different nodes, uploading or downloading routines, gating and synchronizing events, initiating and terminating connections within nodes, and controlling access to the data of individual nodes [6]. Generally stated, fieldbus services need to manage objects by tagging them, the actions to be performed on them, and the corresponding parameters for these actions. These services should be specified and offered by the upper-level stack, mostly the application level. The communication and interoperation of different application layers within a fieldbus system rely on a set of two or even three different basic models. These models again represent different views on the type of data that is shared between different entities. An approach is to structure the cooperation on the principle of actions or features into which a more complex process breaks down. The responsibility for parsing information is concentrated mostly on the sender end. This is the model behind the client–server paradigm. The other model is data-driven. In this case, actions are not shared, but data are exchanged, and the responsibility for data interpretation is realized by the receiver, who could then take appropriate action with the information received. This is the concept behind the publisher–subscriber pattern and the producer–consumer pattern.

3. Architecture to Support the Description of the Mathematical Model Corresponding to the Modbus Protocol

Fieldbuses only deploy levels 1, 2, and 7 of the OSI stack; the current implementation addresses level 2. For partitioned fieldbus networks, the referencing is managed by the Media Access Control (MAC) sub-system. Typically, the partially specified protocols have no specification for the timing; thus, at the server side of the protocol, the time variable is not explicitly addressed. Therefore, a client station named Base Station Gateway (BSG) is needed to introduce the timestamp variable. This terminal enables access to the fieldbus through the Internet, by direct link or via a host machine. BSG may provide a timestamp for a unit of data or a dataset. This way, wide temporal consistency can be achieved. The time interval is governed firstly by the specification in the protocol of a broadcast command, for instance, the beginning of data acquisition, and secondly by the architecture of the acquisition cycle at individual stations; usually, binary variables are faster to write and read than analog channels, which need more processing time to convert data. Not to neglect the time needed for signal processing in this type of network, the stations are completely synchronized. In this approach, the research has resulted in a main contribution, namely defining the architecture of an acquisition cycle that matches incompletely specified networks to provide a timestamp addition and temporal consistency. Thus, the implementation effort focuses entirely on the BSG station. In this acquisition cycle, as a research result, we present a practical example for the Modbus protocol that is in widespread use in SCADA systems [10]. In comparison with previous works published by the authors, this paper presents the equations of the request and response times for the client and server stations, experimental results for the Modbus functions FC03 and FC16 based on new oscilloscope captures, the timestamp of the Modbus messages, and the values for tMcommi (the time taken to send the message via DMA from client to server) obtained with the ModbusE extension.

Within the SMARTConvert platform, a module has been implemented to interchange messages between different types of communication modules using different communication protocols. These communication protocols include the Modbus protocol. Both the Modbus RTU protocol and Modbus TCP/IP protocol are used in this module. For example, we can have a room thermostat and a fan coil communicating over Modbus. The thermostat is used to take a temperature preset by a user (called Setpoint) which will be transmitted to the fan coil. Synchronization mode involves reading the Setpoint register value from the thermostat and writing this value to the fan coil. This paper will address different scenarios involving a scalable physical bus architecture configuration, based on the information in [11], the equations presented in the following being a continuation of the research presented previously. The update of the states of each Modbus module is performed depending on the device addressing (1–247), as well as the device register numbers. Communication scenarios requiring Modbus devices in the identical network, on the same Virtual COM port, or in different networks (different COMs) and changing a register value from a thermostat to a fan coil will be investigated. Note that all devices take 10 successive registers to actualize, and the devices are at various addresses. The thermostat may have address 1, the fan coil may have 247, and other devices may have to be updated between these addresses. Tests will consider refresh times for a 9600 bps communication speed. Based on the Modbus protocol and the model relations given by the latency of Modbus transactions on the RS485 bus, an application was developed on an STM32F4/7 Discovery development kit where 247 stations, each with 1 or 10 holding registers, were simulated, as suitable Modbus stations were not available to meet the project demands. For the present work, one of the stations can support the two types of tests required. For the registers present at each station (server) the available Modbus functions required, respectively, FC03 for read and FC16 for write. Formats of FC03 and FC16 messages are described in

Table 1. Modbus format function FC03 and FC16 (N represents the number of transferred registers).

Request FC03	(bytes)	(hex)	Request FC16	(bytes)	(hex)
Function code	1	0x03	Function code	1	0x10
Start address	2	0x0000–0xFFFF	Start address	2	0x0000–0xFFFF
Register number	2	1–125 (0x7D)	Register number	2	0x0001–0x007B
			Byte counter	1	2 × N
			Data	N\time 2	values
Response FC03	(bytes)	(hex)	Response FC16	(bytes)	(hex)
Function code	1	0x03	Function code	1	0x10
Byte counter	1	2 × N	Start address	2	0x0000–0xFFFF
Data	N × 2		Register number	2	1–123 (0x7B)
Error FC03	(bytes)	(hex)	Error FC16	(bytes)	(hex)
Error code	1	0x83	Error code	1	0x90
Exception code	2	01, 02, 03 or 04	Exception code	1	01, 02, 03 or 04
Error code	1	0x83	Error code	1	0x90

. The values to be written are specified in the application data field. The data are packaged as two bytes per register, so that a response returns the function code, starting address and number of registers written. For lab practical tests, using an STM32F7 microcontroller on which Modbus devices were emulated, the PC did not have enough resources to communicate with more than 39 devices. Thus, it was concluded that the OS in this case must be used only for application-specific Modbus communication. Devices that can incorporate the ModbusE concept are those embedded in systems with moderate and high response times, industrial data acquisition processes, and IoT devices. In this research, we have tested the delays appropriate to the Modbus communication protocol in a PC (client)-STM32F7 (server) configuration by emulating on the several MC configurations of server stations, and at the same time transmitting various messages each with a specific number of registers on Modbus.

Figure 4 defines a client, in this case an application (SMARTConvert), running on a PC-like computer system. As regards the system constituent components, SMARTConvert, OS (Windows 10 in this example), a sniffer software (Modbus Poll, version 7.2, Witte Software, 2019) for monitoring messages on the virtual COMx, and USB Driver have been highlighted. An acquisition slot (Si) includes all the actions on a transaction from dispatching a Modbus request to receiving a reply or timeout. Given the basic considerations introduced in [11], it can be stated that the time duration of a slot (i) is defined by Equation (1). Starting from Figure 4, the following equations were obtained representing the time slots for the request, i.e., the response from the server station.

tSi(adr,FCxx, nreg) = tSiReq(adr,FCxx, nreg) + tSiRsp (adr,FCxx, nreg)

(1)

The times in Equations (2) and (3) were considered to depend mainly upon the Modbus control function, as the number of characters may be different at receive or transmit based on the respective control function. Timing may further vary depending on the message size in terms of nr_reg, number of registers.

tSiReq(FC_xx.nr_reg) = tAppCreq (adr,FC_xx,nr_reg) +
tOS_C(FC_xx,nr_reg) + tSniff adr,(FC_xx,nr_reg) + tDrvCreq(FC_xx,nr_reg)
+ tConvReq(FC_xx,nr_reg) + tNETphyReq(FC_xx,nr_reg) +
tDrvSreq(adr,FC_xx,nr_reg) + tOS_S(FC_xx,nr_reg) +
tAppSreq(adr,FC_xx,nr_reg) + tAppS(adr,FC_xx,nr_reg)

(2)

tSiRsp(FC_xx.nr_reg) = tAppSrsp(adr,FC_xx,nr_reg) + tOS_S(FC_xx,nr_reg)
+ tDrvSrsp(FC_xx,nr_reg) + tNETphyRsp(FC_xx,nr_reg) +
tConvRsp(FC_xx,nr_reg) + tDrvCrsp(FC_xx,nr_reg) + tSniff
(adr,FC_xx,nr_reg) + tOS_C(FC_xx,nr_reg) + tAppCrsp (adr,FC_xx,nr_reg)
+ tAppC(adr,FC_xx,nr_reg)

(3)

The request and response timings have been highlighted separately, due to the fact that the messages in the Modbus traffic transaction are quite asymmetric the higher the nreg is, and the asymmetry depends on the control function. Hardware delays noted with tHWnet can be added to the given transaction delay. These latencies may be given by line drivers, signal propagation on long lines, etc., but still these delays are somewhat felt at high communication speeds, but may be negligible at 9600 b/s. We will write Equations (2) and (3) as follows.

tSiReq(adr_i,FC_xx.nr_regi) = tClientReqi(adr_i,FC_xx,nr_regi) +
tNETphyReqi(FC_xx,nr_regi) + tServerReqi(adr_i,FC_xx,nr_regi)

(4)

where

tClientReqi(adr_i,FC_xx,nr_regi) = tAppCreqi (adr_i,FC_xx,nr_regi) +
tOS_Ci(FC_xx,nr_regi) + tSniff(adr_i,FC_xx,nr_regi) +
tDrvCreqi(FC_xx,nr_regi) + tConvReqi(FC_xx,nr_regi)

(5)

tServerReqi(adr_i,FC_xx,nr_regi) = tDrvSreqi(adr_i,FC_xx,nr_regi) +
tOS_Si(FC_xx,nr_regi) + tAppSreqi(adr_i,FC_xx,nr_regi) +
tAppSi(adr_i,FC_xx,nr_regi)

(6)

tSiRsp(adr_i,FC_xx.nr_regi) = tClientRspi(adr_i,FC_xx,nr_regi) +
tNETphyRspi(FC_xx,nr_regi) + tServerRspi(adr_i,FC_xx,nr_regi)

(7)

The response times for client and server are as follows:

tClientRspi(adr_i,FC_xx,nr_regi) = tAppCrspi (adr_i,FC_xx,nr_regi) +
tOS_Ci(FC_xx,nr_regi) + tSniff (adr_i,FC_xx,nr_regi) +
tDrvCrspi(FC_xx,nr_regi) + tConvRspi(FC_xx,nr_regi)

(8)

tServerRspi(adr_i,FC_xx,nr_regi) = tDrvSrspi(adr_i,FC_xx,nr_regi) +
tOS_Si(FC_xx,nr_regi) + tAppSrpi(adr_i,FC_xx,nr_regi) +
tAppSi(adr_i,FC_xx,nr_regi)

(9)

According to Equations (3) and (6), we have the following time for an acquisition slot:

tSi(adr_i,FC_xx,nr_regi) = tClientReqi(adr_i,FC_xx,nr_regi) +
tServerReqi(adr_i,FC_xx,nr_regi) + tNETphyReqi(FC_xx,nr_regi) +
tNETphyRspi(FC_xx,nr_regi) + tClientRspi(adr_i,FC_xx,nr_regi) +
tServerRspi(adr_i,FC_xx,nr_regi)

(10)

4. Experimental Results Based on Modbus Mathematical Model Description

The following is the test methodology of the SMARTConvert platform for the interchange of messages between devices belonging to the common Modbus protocol. The worst case will be considered if a thermostat has address 1, with a fan coil having 39, and there are no spare addresses among them. For the purpose of this example experiment, all units will be assumed to actualize 10 successive registers. The experiment will consider the refresh timings for the 9600 bps communication baud rate. As regards the problem addressed, the solutions proposed in this paper are simple and low-cost, because they allow the integration of existing acquisition modules without changes in terms of hardware or software. For client–server communication between devices connected on different types of buses or networks, Modbus uses application-layer messaging, a protocol placed at level 7 of the OSI stack. This paper details the connections between a PC running a Virtual COM, a USB to 3.3V converter, and the server stations emulated on the STM32F7 microcontroller development kit. Figure 5 shows a screenshot of the Modbus data transmission, STM32F7 kit and PicoScope 6404B (Pico Technology) oscilloscope. The four Ci signals measured with the oscilloscope were connected to the microcontroller; thus, an output pin (PF8-C1) was used to indicate the station of server 1, the microcontroller’s PF9 output pin (C2) indicates the send/receive status of server i, and signals 3 and 4 represent the receive and transmit on the UART (PF6-C3, PF7-C4).

As we can see in Figure 6, marker C1 is set as the pointer trigger on server 1, whereas slider C2 marks the communication driver switched on server i from receive to broadcast. The C3 cursor is a request message from the client (PC), and the cursor (C4) is a reply message of server i, the STM32F4/7 hardware emulator. The requests corresponding to the servers with addresses 39 and 1 correspond to the thermostat and fan coil, so the experimental data obtained from the oscilloscope measurements indicate time periods between 99.75 ms and 101 ms.

The duration of the request and response messages, respectively, is about 15 ms shorter than the queries of the servers with 10 registers. The practical data obtained for FC03 and FC16 with one register are 99.75 ms, 100.2 ms, 100.6 ms and 101 ms, respectively. The laboratory tests measured the duration of server queries in the of range 2 to 38. The output of the FC03 function, corresponding to the server query message for reading 10 payload registers, was performed in the following time periods: 7.694 ms, 8.118 ms, 8.224 ms (Figure 6) and 8.234 ms, with an average of 8.0675 ms. The request processing at the queried server is performed in at most 5.837 ms, and the server response message for the FC03 function with 10-register payload is at least 25.85 ms, according to the measurements. The time required to perform the server request with ID 39 is only 11.16 ms in the best case, so that the server processing of the query message is between 4.978 and 5.47 ms (Figure 7). According to practical laboratory tests, the measured jitter corresponding to the request analysis and response emission is 0.492 ms. Based on the Modbus Poll sniffer,

Table 2. Modbus FC03 and FC16 functions, timestamps and CRC checksum.

Request/Response	Timestamp	Modbus Function (hex)	Data (hex)	CRC (hex)
Tx:	001827-10:32:18.611-01	10	00 00 00 01 02 6D 6E	1F DC
Rx:	001828-10:32:18.611-01	10	00 00 00 01	01 FA
Tx:	001829-10:32:18.611-01	03	00 00 00 01	84 0A
Rx:	001830-10:32:18.611-01	03	02 69 6A	16 3B
Tx:	001831-10:32:18.611-01	10	00 00 00 01 02 6D 6E	1F DC
Rx:	001832-10:32:18.611-01	10	00 00 00 01	01 FA
Tx:	001833-10:32:18.611-01	03	00 00 00 01	84 0A
Rx:	001834-10:32:18.611-01	03	02 6B 6C	97 59
Tx:	001835-10:32:18.611-01	10	00 00 00 01 02 6D 6E	1F DC
Rx:	001836-10:32:18.611-01	10	00 00 00 01	01 FA
Tx:	001837-10:32:18.611-01	03	00 00 00 01	84 0A
Rx:	001838-10:32:18.611-01	03	02 6B 6C	97 59
Tx:	001839-10:32:18.611-01	10	00 00 00 01 02 6D 6E	1F DC
Rx:	001840-10:32:18.611-01	10	00 00 00 01	01 FA
Tx:	001827-10:32:18.611-01	10	00 00 00 01 02 6D 6E	1F DC
Rx:	001828-10:32:18.611-01	10	00 00 00 01	01 FA

shows the Modbus messages corresponding to Modbus functions FC03 and FC16 and their timestamps, together with the CRC checksum. Within fieldbuses, the transmission of data might be cyclic, on-demand, event-driven and/or combined.

The contributions refer to the performance analysis of the Modbus protocol based on the duration of the request transmitted by the client, the processing time at the server including the CRC, and the time period associated with the server response on the communication medium, resulting in a rough estimate of the server behavior over time. The measured performances were focused on the FC03 and FC16 functions, with the server having address 39, differentiating the times for the FC03 read and write operations, respectively. Thus, for the FC03 function, a significantly higher time period was measured for the read data operation (25.85 ms), compared to the FC16 write (8.206 ms); in this case, only the header is sent in response. With respect to communication medium access, the approaches utilized can be nondeterministic (Ethernet) or deterministic (central client, token (round-robin) passing, and collision with a winner). In principle, acquisition cycle structure depends on the specific type of industrial network utilized [12].

5. Proposed Modbus Extension (ModbusE) Protocol

ModbusE was originally defined in [10], specifying message structure, AC structure, and BSG as the client device. The extension for Modbus was implemented in STM32F7 at the application level. The validation of ModbusE in practice supported the proposal of a new structure of communication frames, an acquisition cycle to achieve deterministic synchronization behavior, a definition of Modbus network devices, and the specification architecture for the integration of ModbusE into the IIoT concept. The acquisition cycle structure consists of an optional slot named SYNC to be operated by the BSG station to invoke a broadcast command as “start scanning inputs” and/or “start a new acquisition cycle”. The cycle completes with an option slot SLEND (Slot END), which denotes the end of the acquisition cycle and may eventually handle errors that have caused the length of some slots to increase. The S1 to SN slots allow transactions, having lengths defined by multiples of ticks (θ). Alternatively, the tick can also be omitted if the slot is stated directly, e.g., in μs. A minimum of one slot is allocated for aperiodic data traffic. Thus, it should be sufficient in length for the transaction to take place and, for simplicity, the option to use slots with the same length can be chosen. The acquisition cycle timing (t_AC) may be determined simply by applying Equation (11).

t_AC = t_SYNC + t_END + t_S1 + …+ t_SN

(11)

If there are multiple control loops within the given sub-cycle, the case is treated similarly, as long as the length of the remaining interval is greater than the longest duration of the scheduled gap. To close the slots gaps between Sc slots and to form the acquisition cycle, there are two options, gap filling considering the number of slots, as priorities, and optimal gap filling, in which case slots are used in such a way that utilization is as efficient as possible, with no unused ticks. Therefore, a priority-based algorithm can be utilized to estimate the duration of an acquisition cycle, where the priority represents the slot number, the lowest number corresponding to the highest priority. The algorithm has the according slot types: SYNC, i = 1, 2, …, N, SLEND and Sc (Figure 8).

Optimized, the algorithm calculates the acquisition cycle and, additionally, calculates the locations of the slots in the acquisition cycle and the respective location and dimension of the gaps. These intervals can be used to transmit SDO messages if they fit inside the interval period. The goals are provided in the BSG; in addition, Sc could also be Sc1 + Sc2 + Sc3 + … as long as all control loops have an identical duration. A different situation arises when the disparity between slot times is extremely large, e.g., from hundreds of milliseconds to seconds or tens of seconds; in this case, there exists several options. In the first approach, one or more slots are used for aperiodic operations, using a round-robin technique, with such messages receiving a greater priority over aperiodic messages. The second solution is the allocation of a slot in the acquisition cycle that is used when the period is out of time or closer to the time when the period expiration +/−Δt, in which case the slots can be utilized for aperiodic messages and/or alarms. Another solution is a priority-based scheduling, with or without strict compliance with SYNC and the slots generating sub-cycles.

Slot-level highlights for the ModbusE deployment are shown in Figure 9. These output results were acquired utilizing the MCBSTM 32F400 development kit, this being a Keil development kit implemented with the ST32F407IG microcontroller, this being a Cortex-M4 processor (168MHz, 1MB flash, 196KB SRAM, ETM Trace and Cortex debug). From Figure 9, it is possible to plot the degree of overlap of operations during a slot. The significance of these points and the times they delimit are given in

Table 3. Significance of the times shown in Figure 9 for ModbusE implementation.

Symbol	Significance	Start/End Position
tSi	Slot duration i	T1/T24
For client—slot i
Tssl	The time at which the slot starts.	T1
Tfsl	Time when the slot interval ends.	T24
tSi = Tssl − Tfsl	Slot duration.	T1/T24 (from T1 to T24)
tintT4i	Interrupt duration measured by timer 4 which counts the slot length.	T1/T2
tMswitchi	Switch duration to the mbeThreadCycleRTU(thd) task that handles slots (the highest priority in the system).	T2/T3
tMthd1i	Time 1 local mbeThreadCycleRTU (variable update).	T3/T4
tMpsnsli	Time to start transmission of the request for the new slot (client initiates transmission of the next slot i).	T4/T6
tMthd2i	Time 2 local mbeThreadCycleRTU (clears the event sent by the interrupt given by timer 4 (client thread)).	T6/T7
tMfosli	Complete transactions associated with the previous slot (client completes the previous slot).	T7/T10
tMthd3i	Time 3 local mbeThreadCycleRTU (prepares new slot, takes a command sent by event from dispatcher thread). At time 11, the ThreadCycleRTU thread goes into standby, waiting for a timer-4 event to indicate the start of a next slot.	T10/T11
tMintDMAtx	Handler duration for the interrupt generated by the DMA once the whole message is a broadcast.	T12/T14
tMintUSART	The handler duration for the interrupt triggered by the USART signaling that it has completed transmitting the last character. This handler also provides, if needed without the 0,1 slots, the response reception.	T15/T15′
tMCRC	CRC calculation time for the received message for the previous slot.	T8/T9
tMcommi	Time for the client to send the message via DMA to the server.	T5/T13
tMsmssr	Duration from when the client has finished transmitting and the server starts CRC calculation.	T13/T16
tintDMArx	Handler duration for the interrupt generated by the DMA upon receipt of the entire message from the server.	T20/T21
tMsuspend	Duration while the ThreadCycleRTU thread is waiting.	T11 slot i, T3 slot i + 1
tMthd	Duration while the ThreadCycleRTU thread is active.	T3/T11
tSCRC	CRC calculation time for the message received by the server for the current slot. To this time is added the preparation for the transmission of the reply.	T16/T25
tSmove	Time for the server to move the message from the receive buffer to the final buffer.	T26/T27
tSsuspend	Duration while the thread running on the server is suspended between slots.	T23 slot i, T16 slot i + 1
tSthd	Duration while the received message-processing task is active.	T16/T18 + T22/T23
tScommi	Time for the server to send the message via DMA to the client.	T17/T19
tSthd	Duration while the server thread is active.	T16/T18 + T22/T23

. As an observation following the data analysis, it should be specified that slots 0, 1, 2 and 3 also include the DMAtx + USART interrupt.

Table 4. Execution times per server acquisition cycle slot for ModbusE deployment at 27 Mbps (μs).

Slot	tSmove	tMcommSi	tSCRC	tSthd
0 (3/0)	0.780	0	0.982	8.092
1 (4/0)	0.881	0	1.189	8.677
2 (16/4)	3.083	5.594	2.775	8.898 + 5.418
3 (32/8)	5.419	9.778	5.09	14.49 + 5.347
4 (64/16)	10.57	18.1	11.54	25.06+ 5.242
5 (64/32)	10.53	34.93	11.19	24.75 + 5.372
6 (256/256)	140.5	268.5	41.32	87.39 + 5.286
7 (64/64)	10.5	68.35	11.61	24.95 + 5.27
8–28 (64/64)	10.66	26.16	11.72	24.93 + 5.462
29 (indirect slot 1)	1.057	0	1.321	8.633

shows the measured slot times for the server acquisition cycle for ModbusE for the 27 Mbps ModbusE implementation. At speeds up to 115 Kbps, ModbusE can also operate with standard Modbus servers. With these, it is not subject to any specific restriction on the answer time to a client query.

Consequently, this time helps to control the duration of a slot until the number of errors (reported by the receive error counter associated with that slot) fulfills a certain criterion (e.g., 1.0% errors/day or no errors, etc.). For ModbusE devices, there are no limitations on the response time of the server as well, since it is difficult to estimate for complex software. Again, the tadjusti parameter [11] helps to solve this problem (designers of devices implementing the ModbusE protocol must take into account that it can operate at speeds up to 27 Mbps, and therefore, a fast station response time negates the benefits of this increased communication speed).

Two types of objects are defined within an acquisition cycle:

• Process Data Object (PDO), used in process-to-process data transfer;
• Service Data Object (SDO), for configuration, servicing and functional test data.

Within an acquisition cycle, there are three classic possible types of messages:

• Send data with acknowledgment (SDA) (request, reply);
• Send data with no acknowledgment (SDN) (request);
• Send and request data (SRD) (request–response).

Typical communication rates are in the interval 9.6 ÷ 921.6 Kbps, meaning that, in the worst case, a maximum value for messages is within the range 1.471 s + tsproc ÷ 0.015 s + tsproc. By developing and analyzing an experimental system, it is possible to put theoretical solutions into practice. If we assume the BSG can handle 1 ms ticks, the communication speed is 115.2 Kbps and there are 10 stations attached to the network. In this scenario, 10 PDO items and 8 SDO items are transmitted. With this speed, the maximum length of a message is 0.122 s + tsproc.

Figure 10 shows the experimental values of the acquisition cycle, with tMcommi representing the time to send messages through the DMA from client to server. BSG considers potential commands and retrieves a set of outcomes for PDO and SDO. After summing the values for the PDO slots, the result is 27 θ (27 ms, approximately 37 cycles per second). Adding a tolerance of 1 θ to every slot, we obtain 37 θ (about 27 cycles per second). Adding the SDO with the largest value for RTT, we have 37 θ + 50 θ = 87 θ (about 11 cycles per second). If the value is sufficient with respect to the application demand, this can be the eventual structure of the acquisition cycle (in this case, having a network of incorrect use if there are no SDO messages continuously). BSG can realize this acquisition cycle and we may analyze the error counters. If these counters are within reasonable tolerances, the proposed acquisition cycle is passed. If the slot duration related to the SDO objects is too long (more than half of the cycle), then it can be restricted to 10 ÷ 15% of the entire length of all PDO objects, in this case approximately 37 × 0.15 ≈ 6, i.e., 6 θ.

The acquisition cycle length becomes 37 θ + 6 θ = 43 θ (about 23 cycles per second). The BSG must validate the slot duration related to the SDO objects (whether long messages can be partitioned into 6θ messages). If the length cannot be successfully enabled, the slot length is incremented until the BSG acknowledges the segmentation. For other kinds of situations, other alternatives may be utilized. A comparable evaluation can be conducted for similar incompletely defined protocols. With ModbusE, an optimization of the PDO length based on the size of the data region from a minimum of 26 bits up to a maximum of 760 bits can be obtained. This implies a minimum of 2.6 ms and a peak of 76 ms at 10 Kbps and a minimum of 26 μs and a peak of 760 μs at 1 Mbps. In practice, this is more difficult because of the assumptions made. Hence, the UART can become a solid candidate in the development of applications that do not rely on events (the proposed ModbusE protocol uses TDMA) and not need a complicated fault monitoring and recovery system similar to CANOpen. In addition, at application level there are correspondences between Modbus (TCP/IP) and CANOpen, and data can be carried CANOpen-style (by using CANOpen-based tools). An additional motivation for using ModbusE is the effectiveness gained at the server station level. With the classical Modbus standard protocol, the stations have to monitor the interval between frames. This can be achieved by listening to network traffic. If a station detects a gap between frames, it must scan the first character of the next frame to check if it is its own address. Generally, this is performed using interrupts, the load being at the upper bound for a microcontroller to fulfill the tasks for a given implementation. Normally, the communication task receives the highest priority in order not to lose characters. In addition, in order not to perform task switching on each received character, the communication driver should execute out-of-core in real time and signal the communication task when the message ends. To support the ModbusE protocol, at minimum, the following additional new commands are required: a PDO transmit/receive mapping command, a PDO transmit/receive read command, a physical address mapping command, a slot address mapping command, and classical Modbus commands.

The designs described in the literature do not propose an acquisition cycle based on incompletely defined protocols. If we take the case of the Modbus protocol, in [13], the authors address these issues with solutions using address space size, guaranteed bandwidth allocation, and managed handover between several client points, without defining the acquisition cycle. An extension of the Alarm Broadcast Request message type over Modbus is presented by the authors in [14]. This solution permits multiplexed transmission of alarm messages, although it does not specify an acquisition cycle. Fully defined protocols describe the acquisition cycle for either periodic or aperiodic messages, realizing models for traffic type such as time-triggered, event-triggered, and scheduling paradigm for Static Priority-Driven, Static Table-Driven, Dynamic Planning-Based or Dynamic Best Efforts categories. In any case, these protocols use dedicated external circuitry such as FPGAs or ASICs, or are embedded in a small set of microcontrollers that implement advanced protocol stacks. Such acquisition loops can be seen in EtherCAT, CC-Link, Profinet, EPL, FTT-CAN, TTP/C, SERCOS III, WorldFip, TT-CAN and FF-H1.

6. Related Work

The client–server paradigm is mainly characterized for leader–follower systems, i.e., PROFIBUS, ASi, MODBUS, P-NET, BITbus and INTERBUS, and for reliable data transfer at the application level (file transfer, network and device management). Thus, given the interdependency between the client–server model and MAC strategies, it must be noted that, in general, client–server communication can be implemented in both single-leader and multi-leader systems. For communications based on CSMA, TDMA or TP, each leader can assume the role of a client. In single-leader systems this function is reserved for the bus leader. In particular for management functions, the client–server model is also widely used in fieldbus systems that organize regular data transfer based on the publisher–subscriber model, such as WorldFIP, EIB, CANOpen, DeviceNet, ControlNet or LonWorks. Paper [15] introduces and presents the Modbus server protocol model relying on Modbus/RS-485 and its deployment. This paper focuses on the design of a novel software architecture; program execution is controlled by an RTOS. ARM hardware is designated and realized to check the software execution and performance. By providing a new software architecture design and embedded stacks, the design lifecycle is reduced and the software is easy to port, support and reutilize. A new feature based on Modbus capability makes it simple for the designer to split the software into three tasks and to synchronize. The authors propose hardware based on Modbus and ARM, performing experiments to validate that the Modbus server can be part of a robust and stabilized communication architecture. It achieves several features corresponding to the incorporated network software.

In [16], the authors propose a formally verified and experimentally evaluated Modbus conformance for a Controller Area Network, referred to as Modbus CAN. The results presented by the authors indicate that, in a representative low-cost embedded application, the performance of Modbus CAN is favorably benchmarked against a Modbus TCP deployment relying on a 100 Mbps Ethernet network, realized on an identical system and utilizing an similar set of protocols. The paper in [16] discusses the design and evaluation of Modbus CAN, for which the main objective is to partition and re-assemble Modbus protocol data units (PDUs) (up to 253 bytes long) to match into CAN frames (carrying at most 8 bytes of payload). Other protocols are supported that can transport messages or data streams of arbitrary message length over CAN.

In [17], the authors present a set of rules for intrusion detection in Modbus TCP and Modbus serial line systems. Authors provide a set of signature-based intrusion detection rules based on an analysis of the Modbus protocol. The rules described in [17] were originally deduced from a vulnerability profile analysis of Modbus protocols. Altogether, the paper describes 50 system rules for signature-based intrusion detection. The rules outlined in this article are aimed for utilization with the SNORT intrusion detection scheme. Rules are, however, outlined in a free format to further support their use on any signature-based intrusion detection system. Details of protocol specifications are provided separately for each rule, and the rule descriptions are general to enforce utilization across multiple intrusion detection frameworks. Rules remain to be written for exception state reading, diagnostics, com event reading, server ID reports, event log records, file record reading, multiple register reading/writing, reading from an FIFO queue, transport interface encapsulation, CANOpen general reference query and PDU response, and reading device identification function codes. If these function codes are utilized by system rules, they might be written to check for invalid use cases. These function codes are unusual, and system designers might setup rules 8 and 9 to warn if error function codes are recognized on the Modbus link.

This paper [18] proposes an organizational improvement of the Modbus RTU for equipment integration in manufacturing automation networks based on hybrid wired Modbus RTU and IEEE 802.15.4 wireless Modbus RTU communications. The hybrid communication protocol proposed improves on the control and topology limitations required by Modbus RTU by enabling a wired/wireless tree-bus topology and client multiplexing. Based on tests, the architecture proposed in [18] exhibited a low error rate in communication, showing that the proposed solution can fulfill the overall requirements of robust industrial communication networks.

The authors of [19] present a tool for analyzing and scheduling response time for Modbus communications over RS485. The response delays of a set of messages are sampled by a dedicated Modbus device and then passed to the software that performs the statistics. In order to validate the developed instrument, a Modbus implementation over the RS485 communication network was implemented in a lab context. This article addresses the development of a tool for the evaluation of real-time requirements in Modbus RS485 networks. The authors’ proposal involves response time estimation in two approaches. For the first one, the client device of the Modbus network is substituted by a specialized device able to evaluate response times for a set of given messages. For the latter approach, the specialized device acts as a passive node that is attached to the network and collects information about the messages sent between devices and their response rates. By using stats, charts and lists, information on reply times, delay times and message content are visualized, assisting the user to perform various estimations. In [19], a tool for inspecting RS-485 Modbus serial networks is presented. The information capture is performed in a passive manner, using a specialized device connected to the network that allows the evaluation of response times for exchanged messages. Based on the proposed tool, three case experiments were conducted to check the communication features and the query set, thus pointing out the range of response times depending on device features. The authors intend to use the tool in the future to verify different aspects of device behavior and mechanisms used in Modbus device communications. However, in order to optimize the network performance for certain applications, aspects of dead times and communication errors should also be considered.

In [20], the authors present a program design that combines the Modbus communication protocol together with the 32-bit ARM Cortex-M0 processor. Experiments demonstrate that the embedded system is capable of deploying data acquisition and transmission reliably. The general system design scheme and the contents of the Modbus communication protocol are presented, whereas the RS485 circuit interface is described. The built-in RTOS uC/OS-II realizes the communication between the client station and the server station according to the Modbus RTU communication protocol and generates the CRC value for the Modbus communication protocol. To improve the efficiency of data transmission [20], the authors select the Modbus RTU protocol as the communication protocol and use ARM Cortex-M0 as the core to implement the communication between the Modbus RTU client station and server station. The data acquisition system, which, based on an ARM Cortex-M0 microprocessor, is configured as a server station on the RS485 bus and a PC as client station, successfully obtains the device parameters to realize the client station communication. Through experimental tests presented in [20], the authors describe the client–server communication mode based on the Modbus RTU protocol. It can be applied for the transmission of thermal parameters in power plants. The communication is reliable and the transmission speed is fast; therefore, it can be used practically in industry with wide application prospects.

In the experiment presented by the authors in [21], the Modbus TCP communication protocol is employed for communication and batch process control from a remotely located controller. In this work, which is based on Modbus RTU, the communication protocol for the remote controller is implemented and experimented for a local PLC (S7-1200) in the various data registers of the local PLC, controllogix-5560, DCS DeltaV and the remote triggered virtual lab. The register data are also checked by the Modscan software. Following the implementation of the communication protocol, the user can operate and control the processing unit using various remote controllers. This implementation provides precise temperature control in operations, which can help the user in the process of plant optimization.

The paper [22] describes a technique to recover corrupted frames caused by transmission errors in Modbus RTU serial communications preserving full protocol compatibility. One of the main drawbacks is that the protocol has no mechanisms to provide integrity of the transmitted data. The method utilizes forward error correction codes, thus providing additional parity bits in time frames when the communication network is idle. The protocol definition-compliant method allows easy extension of Modbus RTU functions while preserving compatibility with standard industrial equipment. REED-SOLOMON codes have been used for the repeater/fault corrector. The error repeaters/coders were developed using an 8-bit RS (255, 223) encoder/decoder, which in turn is derived from the ANSIC generic code for RS (n, k) encoders/decoders. In order to operate with the RS (255, 251) code, modifications were made in the libraries so that the dsPIC30F3010 microcontroller could be used for implementation. The method proposed by the authors in [22] is particularly suitable for bus communication segments that are subject to transmission errors induced by electromagnetic interference. It is important to note that, at transmission rates below 19 200 bps, most server stations in an industrial Modbus RTU network take less time to process responses than to transmit parity characters.

7. Discussion

We can see fieldbus as a particular case of distributed systems [23]. Particular attention must be paid to the time consistency of information, when some decisions have to be made upon a set of data delivered by distributed applications and systems. Neglecting temporal consistency will typically imply misbehavior of monitoring and control systems as well as diagnostic (error and fault detection) systems. In order to provide clarity on the notion of temporal coherence [24], depending on the context, two definitions are introduced [25]. The first one establishes the concept of temporal coherence as applied to a unit of information that must guarantee that all consumers of this information have the same view on the identical data (the same timestamp). In this instance, we are talking about the temporal coherence of a unit of information. For the second definition, the concept of strict temporal coherence extended to a set of information involves both observing the temporal coherence of individual items of the set and the fact that all information, belonging to a set, has the same timestamp. Nevertheless, due to total desynchronization, severe temporal coherence of an information set is very hard to achieve. Consequently, the notion of general temporal coherence of an information set is introduced when severe time consistency cannot be obtained. In this situation, the temporal coherence of a general information set tends to guarantee that, for each element, temporal coherence can be seen and that all information within this information set is generated at the same time. In the case of general temporal coherence, the problem is one of sizing a time period to achieve application granularity. Cauffriez et al. [25] also introduced the concept of reliability information, which seems to be a novel method to check real-time temporal consistency for decision making. However, the MAC utilized by field buses has a major influence on the temporal coherence of information, e.g., through the addressing mode [26].

One issue that needs special consideration is backward compatibility. Modbus CAN encodes each Modbus PDU independently through a thin layer of fragmentation under the Modbus protocol entity. Therefore, it is fully compliant with already-existing application software [27]. For existent Modbus devices, gateways can be specified, which are similar to those used to interoperable Modbus TCP and Modbus RTU, allowing seamless interconnection with CAN-based subnets. Modbus CAN is a quite attractive option for serial lines, regardless of whether it is used as a subnet of a broader Modbus TCP network or as a singular network.

Table 5. Communication protocol comparison and applications.

Bus	Communication Type	Data Transmission Speed	Topology	Max Devices	Protocol Type	Media	Typical Applications
Modbus RTU	Serial (RS-232/RS-485)	Up to 115.2 kbps	Bus or Daisy Chain	32 (per segment)	Leader/Follower (Polling)	Twisted pair (RS-485)	Industrial automation and SCADA
ModbusE	Serial (RS-232/RS-485)	27 Mbps	Bus	247	Client-server	Twisted pair (RS-485)	Industrial automation Building automation
DeviceNet	Serial (CAN-based)	Up to 500 kbps	Bus	64 nodes	Producer/Consumer	Twisted pair (CAN)	Industrial devices, sensors, actuators
LonWorks	Serial, Ethernet, TP/FT	78 kbps (TP/FT), 1.25 Mbps (PL)	Free topology	32.385	Peer-to-Peer	Twisted pair, Power Line	Building automation, HVAC, lighting
Interbus-S	Serial (RS-485 based)	500 kbps	Ring (Closed Loop)	512	Leader/Follower	Twisted pair (RS-485)	Factory automation, machine control
CAN (CANOpen)	Serial (CAN-based)	1 Mbps	Bus	64 (recommended)	Multi-leader	Twisted pair (CAN)	Automotive, industrial control

presents a comparison with other communication protocols based on the Modbus/ModbusE protocol. Throughout the standardization phase, there was a discussion on why it was not possible to limit the number of technical alternatives to three or four RTE profiles. However, there was a general agreement among manufacturers that it is not the job of the engineers in the standardization groups to decide [28,29]. Thus, it was accepted that the market should determine which system will be successful in the market. The issue of deciding on a good choice ultimately rests with the end user.

Small equipment manufacturers are also aware that they must rely on EIA-232 and/or EIA-485 to sell their equipment to system integrators for use in larger projects. System integrators know that Modbus is a reliable interface, and they are confident that they will find equipment on the market to both deliver the necessary projects and cope with the inevitable changes.

Within the Modbus protocol, functions in the range from 100 to 110 are open. We suggest to utilize codes 100, 101 and 102 for these three classes of functions. Mapping permits Modbus messages to be transmitted with no headers, so that over-control can be minimized. The main advantage of adding timestamping to a basic protocol such as Modbus is to obtain temporal coherence (a unified vision of the controlled and/or monitored process). Time consistency is particularly critical in the deployment of algorithms for industrial process. By providing this supplementary information, we can introduce a low-cost feature specific to advanced protocols. This setting is deployed at the fieldbus level for Modbus (the timestamp is added by the BSG) and on either the controller or the ModbusE fieldbus. These features are enabled or not in the BSG setup phase and in stations that provide ModbusE capability [30,31]. This paper is a follow-up of earlier work [10,30] on ModbusE and the acquisition cycle for incompletely defined protocols. In terms of the objectives of the paper, ModbusE brings improvements in the structure of Modbus messages, thus reducing communication times and improving data flow in the RS485 network. As potential future research directions, the LTM2881 circuit will be used for laboratory tests based on an architecture of data acquisition devices using RS485.

In terms of specialized services for clients and servers, many devices are on the market that combine Modbus functionality and enable it through simple configuration. One of these is a specialized client commonly known as a subscriber scanner. It enables the repeated configuration and read/write execution of field devices in the Modbus network, with resend support, all in an organized way. Such devices are applications of the protocol and support upper-level services [32].

The IIoT concept is often found in manufacturing spaces, referring to the industrial subset of the Internet. It is assumed that the IIoT will eventually lead to the fourth industrial revolution, so-called Industry 4.0 [33]. Thus, successful companies will be able to increase their revenues by creating new business models and improving productivity, exploiting analytics for innovation and workforce transformation. Microsoft recognized the significance of OPC UA (Open Platform Communications United Architecture) within the scope of Industry 4.0 early on and embedded OPC UA in Azure Cloud [34]. Future OPC UA servers that accept pub/sub functionality can upload telemetry data directly to the Azure Cloud using JSON/AMQP already. A gateway is supported for the OPC UA server with client–server (TCP) channel. There, UA data are translated to UA and forwarded via AMQP. Return channel “Control & Command” can also be customized.

8. Conclusions

When compared to Modbus RTU, Modbus CAN offers significantly higher efficiency while maintaining comparable implementation effort and reduced cabling due to simplified bus topology. This validates that Modbus CAN may be capable of outperforming Modbus TCP, at least for industrial process data transfer. The benefit largely depends on the efficient implementation of the fragmentation protocol, the software processing times being approximately an order of magnitude lower than those taken for lightweight TCP/IP (lwIP) on typical embedded architectures. Certainly, Modbus TCP’s performance might easily be improved, either by increasing processor speed or by overwriting the TCP/IP protocol stack. In both cases, however, this leads to higher implementation effort, which is possibly not the best solution given the target domains typically intended for Modbus. In practice, problems may arise due to the treatment of very specific properties of the wireless communication channel, such as attenuation, fading, multipath reception, temporarily hidden nodes, easy access by intruders, and many others. Today, wireless communication options exist for many domains. Until now, they have only been used to substitute traditional data cables. However, a truly effective use of wireless communications could require at least a redefinition of the lower protocol layers, while the upper protocol layers could be compatible with industrial Ethernet or fieldbus applications.

This paper discusses the mathematical model for Modbus RTU to highlight delays between client and server communications. In addition, an extension to the incompletely defined Modbus protocol has been proposed to achieve deterministic time behavior. Thus, the main benefit of providing a timestamp addition to the incompletely defined Modbus protocol is to guarantee time consistency, i.e., a unified vision of the controlled process with respect to real-time client–server communication. ModbusE can improve on the classical Modbus in that no headers are transmitted because they are configured at initialization and can concatenate registers stored at various addresses in memory. The behavior of the server becomes deterministic by implementing the acquisition cycle, with request response operations occurring at a well-defined point in time in the periodic acquisition cycle. Cooperation between academia and industry has led to remarkable innovations in communication protocols. The successful implementation and validation of research project results are demonstrated by the high efficiency of the systems, whose performance is evaluated by practical experiments in different network topologies.

9. Patents

The Modbus Extension server and smart switch embedded system device relies on the patent A/00224,OSIM, 2023.