• Latency from serial and Ethernet transmission
• Latency from the fieldbus gateway
• Methods of priority control for reduced latency

The suitability of using a Modbus system for real-time applications depends on the system's ability to delivery a response time within a certain time frame. The required access cycle time for real-time applications can be separated into three different levels:

Minimizing latency for Modbus systems is an especially tricky matter when integrating Modbus Ethernet and serial networks. Can real-time operation be achieved when communicating across both protocols? If so, how? Read further to find out where latency is introduced and how it can be managed.

Latency from serial and Ethernet transmission
The most significant source of latency in Modbus control systems is the transmission time. Devices in industrial automation are often controlled over serial connections (RS-232/422/485) using the Modbus ASCII/RTU protocol. Although serial connections are inexpensive, robust, and easy to implement, data transmission speeds are slow when compared to today's networking standards. Baudrates range from 110 to 115200 bps. With a baudrate of 38400, it would take 26 milliseconds to transfer 100 bytes of data from one device to another.

Aside from normal data bits, serial transmission can also involve additional bits for parity check or for stop bits. Using 10 bits for each byte of data is simply a rough calculation. Even at higher baudrates, serial transmission introduces too much latency to be suitable for motion control applications.

Ethernet transmission involves a different kind of latency. TCP/IP is designed to establish a network of networks, each of which may be designed by different vendors. The architecture is very robust and can automatically restore connections between different network elements. However, the nature of automatic recovery means that network problems can go undiagnosed and uncorrected for long periods of time, regardless of the network speed. The latency introduced by Ethernet transmission is therefore unpredictable and difficult to handle.

Theoretically, it is not possible to control Ethernet latency. However, practical solutions have been developed. Unpredictable latency occurs when there are complex routing paths and a large number of Ethernet elements. If controllers and devices are directly connected to each other, or if a private network is used, then the latency can be kept to within a specific range. A direct Ethernet link could be established between the SCADA system and the PLC or meter, with no other devices on the network. In a 100 Mbps Ethernet environment, the transmission latency for 100 bytes of data could be calculated as follows:

By using a dedicated high-speed Ethernet network for communication between two devices, transmission latency for a 100-byte message with a 54-byte header can be kept to about 12 microseconds. With more complex networks and additional devices such as switches and hubs, the transmission latency will increase.

New technologies are also available to address Ethernet latency. Real-time Ethernet can be established using different standards, such as EtherCAT or Ethernet Powerlink. Some of these real-time standards are compatible with existing Ethernet networks, while others are not. Though real-time Ethernet technology has been available for some time now, standard Ethernet technology still dominates the market and remains the easiest and cheapest solution for networking.

Latency from the fieldbus gateway
Even with a real-time Ethernet installation, relaying devices can lead to unpredictable propagation delays. The typical topology for a factory floor is shown below:

A fieldbus gateway is used to connect serial devices to Ethernet SCADA systems. The gateway is in charge of converting between protocols, which requires translation of data formats and messaging rules. Latency can be introduced through the computation involved, as well as through the management of different messaging rules. Note that any latency introduced by the repeater is usually ignored. The repeater simply resends signals to extend the length or number of nodes in the network, and users are primarily concerned about its robustness.

To determine the amount of computational latency introduced by the gateway, let's first assume that the gateway relies on a 32-bit RISC embedded computer operating at 200 MHz. Furthermore, let's assume that for the TCP/IP network, roughly 50000 instructions and 5000 memory access cycles are required to handle a single TCP/IP datagram. Computational latency can therefore be calculated as follows:

The computational latency calculates to around 1.3 ms, depending on the gateway's processing power and the size of the message. In real-world measurements, computational latency typically ranges from 4 ms to 10 ms.

Although the computational latency introduced by fieldbus gateways seems low enough for real-time discrete control, there is an additional source of latency that must be dealt with. The Modbus TCP protocol supports multiple masters, which means that servers (slave devices) are expected to support more than one client (master) and more than one request at the same time. This is a fundamental change from the original Modbus serial protocol, where all devices must remain silent after a command has been sent. Additional commands can only be sent after the slave device responds.

When a gateway receives multiple Modbus Ethernet commands for Modbus serial devices, it must hold these commands in a queue and send them one by one to the different slave devices. Assuming that each slave device responds in about 5 ms and that an average of 3 commands are held in the queue at any time, the resulting latency can be calculated as follows:

When there is a large number of Modbus TCP masters and commands, the latency increases dramatically. Furthermore, the latency is essentially unpredictable because any number of commands may be sent at any time.

It would seem impossible to eliminate this source of latency, since it is based on a fundamental difference between the Modbus protocols. Although the gateway cannot eliminate the overall latency that is introduced by command queuing, there are mechanisms that can be used to manage the latency for critical commands. Administrators can determine which commands require a real-time response, and the gateway can be configured so that those commands are sent directly to the front of the queue. All other commands would be queued as normal. This ensures that conversion between the protocols remains fully compliant, but latency is minimized for the most critical operations.

Methods of priority control for reduced latency
Every Modbus system has its own requirements, and the identification of critical vs. non-critical commands may be handled differently by each administrator. In the typical scenario, administrators require specific commands to be given top priority, such as "device shut down". For this scenario, the fieldbus gateway would need the ability to filter out specific commands and send them to the front of the queue. It may even be desirable to assign different priority levels depending on the command.

Another common scenario is for a Modbus system to incorporate master devices that are used for monitoring purposes only and do not require real-time control of slave devices. For example, a "control" master in a redundant system may be the only device that actually sends commands. Other "monitor" masters in the system simply monitor the data. If the control master fails, one of the redundant masters would take over. For this kind of system, all commands from the control master would require top priority. The fieldbus gateway would need the ability to filter out commands from a specific source, such as by IP address, and send them to the front of the queue.

In certain systems, there may not be an easy way to categorize critical commands by type or by source. However, if Ethernet-based commands are sent by a SCADA system, it may be possible to allow the SCADA system to make the determination between critical and noncritical commands. Noncritical commands could be sent as usual using TCP port 502, while critical commands could be sent using a different port. In this scenario, the fieldbus gateway would need the ability to recognize commands coming in from a different port and send them to the front of the queue.

In summary
When integrating Modbus serial and Ethernet networks into one system, it is inevitable that some latency is introduced through Ethernet and serial transmission, gateway computation, and command queuing. Due to these factors, integrated Modbus systems cannot guarantee response times that are fast enough for real-time motion control applications. However, it is possible to predict and manage latency so that real-time process and discrete control applications are possible. Armed with an understanding of how latency can be introduced and which gateway functions to look for, administrators should have no trouble designing a control system architecture that achieves the desired response time.

For more information on Modbus gateways with priority control functions, please click here.

» Back to index