For many applications, embracing the IIoT has paid big dividends. One noticeable trend is the migration of a large number of serial devices to Ethernet-based networks, allowing plant managers to tap the full potential of their legacy devices by unlocking previously unused data.
However, adding value to these serial devices comes at a cost in terms of time and effort, especially when dealing with a large-scale Modbus network. For example, let us take a look at how the complicated nature of this type of network presents itself in building automation, where hundreds to thousands of serial-based temperature controllers communicate via Modbus RTU protocol. These temperature controllers need to be controlled and monitored in a control room, which uses Modbus TCP. At this point, the non-interoperability of protocols becomes an issue. A tried and tested solution to overcome non-interoperable protocols is installing high port density Modbus gateways that convert serial to Ethernet, as well Modbus RTU to Modbus TCP, and vice versa. However, engineers still have to figure out how many gateways need to be installed and how many serial ports are needed on each gateway. Therefore, planning a network’s topology that involves a large number of Modbus devices to achieve full-fledged connectivity can really test designers.
Reality bites
To engineers, spending too much time and effort on planning a Modbus network’s topology is counterproductive. For example, they find it especially time-consuming to set up a Modbus slave ID routing table, which lists the connections of Modbus devices (Modbus slave IDs) to specific serial ports on a gateway. Adding to the frustration is a high possibility that things might not go according to plan in the field. Connectivity errors at field sites can undo all the meticulous planning in the office within moments, sending engineers back to the drawing board. A crucial aspect of planning Modbus network topology is to eliminate these connectivity errors when dispatching a large number of Modbus requests to the serial devices that are connected to a Modbus gateway. Life would be so much easier for engineers if they did not have to worry about which serial devices were connected to which serial ports on a Modbus gateway. In an ideal situation, they would be able to send out Modbus requests to a Modbus gateway, and the latter would automatically find the correct serial port that connects with the target device. This would iron out many problems, even when adding new devices to a system or connecting existing devices to a different serial port.
The key challenges
Serial-based device response times are generally slower than those of Ethernet-based devices. Their slower response time is even more evident when they are connected to a gateway in a daisy-chain topology, as the one-request-one-response nature of a Modbus protocol leads to a longer polling time. In these types of setups, a one-port Modbus gateway delivers better performance because a scada system can communicate independently with each gateway, thus shortening the communication gap between a large number of devices and the scada system. However, the management of multiple Modbus gateways is complicated. Hence, multiport Modbus gateways are more adept at managing a large number of Modbus devices. For example, one 16-port gateway can replace 16 one-port units. This frees up physical space and also only requires one power cable and one Ethernet cable. In addition, the large number of IP addresses needed for 16 one-port gateways can be consolidated into a single IP address.
But multiport gateways are not exactly a breeze when it comes to the management of multiple Modbus devices. Engineers first need to segment all the devices into groups and then connect them to a specific port. This is why a well created Modbus slave ID routing table of a gateway’s serial ports is so important, but creating an efficient routing table is time consuming.
Dispatching a large number of Modbus requests
Unlike Ethernet switches, where routing is accomplished automatically through an ARP table, the routing mechanism for Modbus gateways with multiple ports is much more intricate. Currently, two types of routing mechanisms address the different requirements in Modbus-based networks.
Routing by an IP address or TCP port
Some Modbus gateways perform the serial-port mapping functionality via an IP address or TCP port. This mechanism is suitable for engineers who want to monitor field devices in segments. All the Modbus slave devices that are connected to the same serial port through daisy-chain wiring correspond with a specific IP address or TCP port. That is, each serial port on a gateway corresponds with a unique IP address or TCP port. Furthermore, a high-port-density gateway can be used instead of a large number of low port density gateways. As previously mentioned, this reduces cabling significantly.
A drawback is that engineers have to configure as many IP or TCP connections as the number of serial ports available. In large-scale Modbus environments, systems usually adopt a large number of multiport Modbus gateways, making configuration a time-consuming task – not to mention the extremely high connection fees involved.
Furthermore, serial-port mapping with IP addresses or TCP ports needs to be manually maintained by an engineer, which requires the engineer to identify the serial port that a device is connected to, and the corresponding IP address or TCP port.
Routing by using a gateway’s Modbus-ID routing table
For engineers who care about connection fees and do not need to monitor devices in segments, a more popular option is using a Modbus slave ID routing table. The main purpose of the routing table is to indicate which Modbus device (Modbus ID) is connected to which serial port on a gateway. Once a gateway receives a Modbus request for a specific device, it can dispatch this request via the referring Modbus slave ID routing table to the serial port that connects to the target device. A scada system benefits by using only one IP address or TCP port to communicate with all the Modbus devices that are connected to a gateway, easing the management of devices and reducing connection fees considerably.
However, creating and maintaining a Modbus slave ID routing table is laborious. Also, it needs to be stressed that when engineers come in contact with a Modbus gateway for the first time, it would be as if they are climbing a mountain as they would be completely unfamiliar with routing table settings. They have to bundle the Modbus slave IDs into groups and then connect each group to a different serial port. For example, slave IDs 1-5 are connected to serial port 1, slave IDs 6-10 are connected to serial port 2, and so on. According to this method, they will have to set the routing rules 16 times for a 16-port gateway. The situation becomes a lot more taxing if serial port 1, for example, is connected to ID 1, ID 6 and ID 11, and serial port 2 is connected to ID 2, ID 7, ID 12, and so on, because they need to keep track of which IDs are connected to each port. Engineers will then have to set routing rules as many times as the number of Modbus slave IDs. It does not get any easier when they have to reset the Modbus slave ID routing table for newly added Modbus devices.
Just one click
A new leading-edge technology that automatically detects the Modbus requests from a scada system and sets up the Modbus slave ID routing table provides the answer. The Auto-Device Routing function only requires a single click to help the gateway detect which serial port is connected to a target Modbus device, allowing it to automatically dispatch a Modbus request to the correct serial port. It automatically creates the routing table, saving significant time and costs as engineers no longer need to create the Modbus slave ID routing table, eliminating possible human error in the process. Furthermore, it eliminates the effort needed to double-check the actual connections at field sites. Also, there is no need to refer to a historical Modbus slave ID routing table when adding or removing devices, saving time and effort.
By automatically creating a routing table, the Auto-Device-Routing technology makes the configuration and maintenance of a gateway’s Modbus slave routing table a thing of the past. This function features in Moxa’s MGate MB3000 Series, which consists of high-performance Modbus gateways with 2,4,8, or 16 serial ports. The series also supports routing by IP address or TCP port.
| Tel: | +27 11 781 0777 |
| Email: | [email protected] |
| www: | www.rjconnect.co.za |
| Articles: | More information and articles about RJ Connect |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version