Many serial devices still work very efficiently at a large number of field sites, and if a good thing works, it is certainly a good reason to keep using it. The full potential of many serial devices, however, is still very much untapped. One sure way to add value to such devices is by having the data collected from them stored in the cloud for further analysis to unlock previously untapped information that can yield greater possibilities to streamline and optimise operations. For this to happen, these legacy serial devices first need to be integrated into a network.
Serial device servers
To connect legacy serial devices to an Ethernet-based network, a serial-to-Ethernet converter, also called a serial device server, can be installed. Serial device servers support two interfaces: a serial interface on the one side, and an Ethernet interface on the other side. Also, serial device servers support virtual COM ports so that they work as legacy COM ports in your scada system. This means you can use your existing system, saving the costs of developing a new one. Furthermore, serial device servers also support the so-called raw socket mode, which converts serial data to TCP or UDP packets transparently. Most scada systems and OPC servers support Ethernet encapsulation drivers, which work with serial device servers to receive proprietary protocols. You still have to handle the protocol manually as before, but the serial device server helps you to transfer data to an Ethernet network effortlessly.
Before you can receive data from legacy serial devices, you need to configure them properly. Most of these serial devices use proprietary protocols, so you need to consider how to convert serial data into Ethernet packets. Several factors need to be considered when using serial device servers to support IoT cloud applications.
Multiple polling
Connecting a serial device to one scada system is simple and easy. When it comes to the IoT, however, it is not as straightforward, as the collected data may need to be transferred to the cloud. A scada system and a remote cloud application may issue a command simultaneously to a serial device via a serial device server. Therefore, the serial device server needs to have a FIFO (first in, first out) queue to handle all queries. Only the first query will be sent to a serial device, and the rest will wait in the FIFO queue. Once the serial device server receives the response from a serial device, it will send the response to the relevant scada system or cloud application and process the next query in the FIFO queue. This kind of command-by-command handling is very important in IoT multiple polling applications due to the large number of serial devices supporting proprietary protocols. Without this design, an extra IoT gateway that supports multiple polling is required.
Proprietary protocols over Ethernet
As many serial devices may use proprietary protocols, the main issue is converting serial data into Ethernet packets properly. Many serial device servers support raw socket and TCP server modes, which can handle these types of conversions. The problem, however, is a serial device server may not know how to divide serial data into TCP packets. Serial device servers do not understand serial data formats, so they may put a response from a serial device into two or more TCP packets. This will result in a scada system or a cloud application rejecting these packets as incorrect responses since they expect each TCP packet to represent a single response from a serial device. To get around this issue, serial device servers need to support flexible data packing options because the proprietary protocol may have a different format. For example, fixed data lengths or special delimiter characters can be used to identify single serial device responses. This means a serial device server will keep receiving data from a serial device and not transfer it to the Ethernet until it receives the fixed amount of data or a delimiter character. Without support for data packaging options, you would have to develop complex scada software applications to handle the TCP packets properly. These alternatives waste time and may also create bugs in a system.
More connections, more bandwidth
In many applications, serial devices need to send data back to a control room or a cloud application. To do this, serial device servers need to open a remote connection before they can transfer serial data. If a large number of serial devices are connected to the same network, the connection will require many resources in the control room or cloud application. To handle these large numbers of remote connections properly, serial device servers should support flexible connection control. The best way to do this is to open a connection only when serial data is received from a device. When the transmission is completed, the serial device server should close the connection as soon as possible. Without flexible connection control support, you will have to spend extra time to handle connections at the central site or cloud application.
Make the most of the NPort serial device server by properly matching operation modes
Moxa has been a leader in device connectivity for more than 25 years and provides a wide selection of industrial-grade device connectivity products that are used in a broad spectrum of industrial applications around the world. Many people are already aware that NPort serial device servers provide a variety of operation modes to help different types of serial devices to be seen on a network. What they might not know is that the NPort serial device servers provide various advanced functions as part of each operation mode to assist users in streamlining operations and maximising benefits of serial-to-Ethernet connectivity.
| Tel: | +27 11 781 0777 |
| Email: | info@rjconnect.co.za |
| www: | www.rjconnect.co.za |
| Articles: | More information and articles about RJ Connect |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version