In all likelihood, your automation applications forge ahead thanks to Modbus. It is also safe to say that this widely used industrial communications protocol, following a master-slave architecture, will remain the lifeblood of networks for a long time to come. Its two prominent formats—Modbus RTU and Modbus TCP (a modified version of the former)—work their magic in serial-based communications and Ethernet-based connections, respectively.

A number of reasons justify Modbus’s status as the de facto industrial communications protocol. Modbus RTU, specifically, is easy to install in field devices. Furthermore, it allows for easy troubleshooting that is not too costly. Modbus RTU’s cousin, Modbus TCP, is for the same reasons the marrow in Ethernet connections. The snag is that they have communications issues, and therefore need a mediator to smooth things out between them. So, network engineers are constantly scrambling for the right solution to ensure that all the serial devices can communicate with the SCADA host. This has become a pertinent issue as more and more serial devices are connecting to Ethernet networks.

Along with this issue of incompatibility, other challenges also come with the territory. The first challenge involves the vast array of proprietary SCADA software on the market. As each software program brings different supporting abilities for Modbus drivers, things become complicated for system operators to match the right product with their network’s requirements. Throwing them further off balance are continuous requests by multiple SCADA hosts to access the same Modbus RTU-supported device. In addition to all the foregoing, operators must also ensure a faster response time of devices in mission-critical applications.

In this article we will suggest solutions to these challenges. Most of the solutions involve embedding gateways in your network to make sure you get the most out of your serial devices.

The Link That Makes Things Tick

Right now, the marketplace is crowded with SCADA software offering different capabilities to support Modbus drivers. Therefore, you need to know beforehand exactly which SCADA software will be the perfect match for your system. In this section, we will briefly look at a few common scenarios.

1. A SCADA host with a Modbus TCP driver: A protocol conversion gateway is the most obvious solution here. A gateway will allow you to use Modbus TCP protocol to communicate with Modbus RTU-supported devices. When the gateway receives the Modbus TCP request, it converts the packet to a Modbus RTU packet and sends it to the Modbus RTU-supported devices immediately.
2. A SCADA host with a Modbus RTU-driver—without a built-in serial port: If you want to use your existing SCADA program and devices, but your original SCADA host does not have a built-in serial port, a serial device server can be used to build a virtual COM port for the serial port on the remote serial device server connected to your serial devices. This configuration allows you to access remote serial devices through the serial device server as if it had a native COM port. The serial device server will install the virtual COM port driver on your SCADA host to create a virtual COM port. To enable the virtual COM port, the serial device server must be configured to virtual COM mode. The data sent to this virtual COM port will be transferred to the remote serial port of the serial device server. Actions for the modem signal will also be handled in the same way. Since you can use the virtual COM port in the same way as a native local COM port, you can send the Modbus RTU request to the COM port directly, just as you would if it were a physical COM port. 

Virtual COM port: Acessing a remote serial device as if the SCADA host posseses a native COM port.

Although serial device servers can also connect Modbus RTU devices to an Ethernet network, a gateway solution can meet almost every system requirement. Your host must be able to support Modbus TCP connections. This shouldn’t be a problem since Modbus TCP, as stated earlier, is very popular and already widely supported. Here are a few situations where you will need to use a designated gateway solution:

1. Multiple masters or redundancy: In addition to enabling remote access, Ethernet connections also provide multiple connection access capabilities. Most gateways can support up to 32 connections, which means up to 32 SCADA hosts can query the Modbus-RTU supported devices simultaneously. Although it will be difficult for a serial device server to provide network redundancy in this situation, as most serial device servers do not support multiple masters, a gateway, on the other hand, will have no problem.
2. Simultaneous device access for old Modbus RTU HMIs and new Modbus TCP SCADA systems: Although Ethernet connections offer easy-to-deploy remote access, there may be times you want to keep your existing local HMI connections active. The problem is the serial port on the device is already connected to a gateway, so there is no available serial port for the HMI connection. In this situation, some gateways provide a serial port redirector to overcome this obstacle. The serial port redirector is very similar to a router in that the gateway can transfer the request between different serial ports based on the slave ID.

A serial port redirector keeps local HMI connections active even when new Modbus TCP SCADA systems are added.

All Access Pass

In projects with a big scope, several hosts could monitor a territory, as well as act as a redundant host to monitor devices in other territories when required. Therefore, Modbus RTU-supported devices need to be connected to multiple masters to allow simultaneous access. Although a gateway can handle this adequately, you need to remember that the serial port bandwidth stays the same. If multiple requests are received through the same serial port, you will likely experience a delay because the gateway needs to handle the earlier requests in the queue first. This means you need to calculate the proper polling time if you want to enable multiple masters to access the same Modbus RTU device simultaneously. For example, if one request takes 100 ms, five multiple connections would require you to wait at least 100 ms ×(5 − 1) = 400 ms before sending the next request. This means each SCADA host will need to use 400 ms (plus some tolerance) for polling cycle time.

The above offering is not the only solution. Some gateways support an agent mode, which actively and continuously retrieves data from connected devices. The updated data is stored in internal memory, which is used to reply to host requests. Although this solution is faster and more efficient, the data retrieved might not be the most current.

Send in the Agent

For some critical applications, it is vital to have fast responses from devices. However, due to Modbus’s one-polling-with-one-response behavior and the limited speed limitation of serial transmissions, speed is lacking when multiple Modbus RTU-supported devices are connected. In these cases, an agent gateway is needed. An agent gateway can send a Modbus command to each Modbus RTU-supported device one by one, so it can actively retrieve data from multiple Modbus RTU-supported devices and place them into a single register, storing the data in its internal memory. Thus, to get a faster response, the host just needs to retrieve data through an Ethernet connection. Besides, all the data can be arranged into a single data block in the gateway’s internal memory to retrieve data from a host with just one Modbus read command.

About Moxa’s Solutions

Moxa is the industry leader in serial-to-Ethernet connectivity. NPort® serial device servers support different operation modes, including Real COM Mode, TCP Client Mode, and UDP Mode, to control the way your serial devices connect to a network. Moxa’s MGate™ gateways enable protocol conversions between SCADA/PLC and devices with different protocols. Standout features that set MGate™ gateways apart from others in the industry include easy configuration with a user-friendly web console, easy maintenance with built-in monitoring and diagnostics, and reliable performance. To learn more about our solutions, download our brochure.