The full potential of many serial devices is still very much untapped. In the age of the Industrial Internet of Things (IIoT), however, the time has never been more opportune for network managers to get more value from their serial devices. One way to do this is to connect the devices to the Internet to extract untapped and potentially valuable information from existing processes. Many applications are already reaping the benefits of integrating their serial devices to IP-based networks, as previously untapped information is unlocked to help streamline and optimize operations.
There are numerous advantages to connecting serial devices to the Internet, but you should plan ahead. In this article, we emphasize three features that are important when implementing complex serial-to-Ethernet applications.
Getting Connected
Serial device servers (also referred to as serial-to-Ethernet converters) can be used to connect legacy serial devices to Ethernet-based networks. Serial device servers have two interfaces: a serial interface on one side and an Ethernet interface on the other side. Serial device servers use the virtual COM port concept to allow data from legacy serial devices to be transmitted over a network to an existing SCADA system. Furthermore, serial device servers also support raw socket mode, which packages serial data into 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 transmit data to an Ethernet network with little effort.
Three key points need to be considered when using serial device servers to support IoT cloud applications: (1) multiple polling, (2) proprietary protocols, and (3) bandwidth.
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 transmit data to an Ethernet network with little effort.
1. Multiple polling
SCADA systems and remote cloud applications may send several commands, seemingly at the same time, to the same serial device server. For this reason, the serial device server needs to support a FIFO (first in, first out) queue to handle all the queries. The first query in the queue will be sent to the serial device first, while the rest wait in the FIFO queue inside the device server. 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 would be required.
2. Proprietary protocols
As many serial devices use proprietary protocols, the device server must be able to convert 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 the best way to divide serial data into separate TCP packets. Serial device servers do not understand proprietary serial data formats, so they may break up a single response from a serial device into two or more TCP packets. When the packets are unpacked by the SCADA system or a cloud application, they will be rejected since the serial data presented by a single packet does not follow the expected format. The SCADA system or cloud application will generally expect a single serial device server response to be packed into a single TCP packet. To ensure that this is handled properly, serial device servers need to support flexible data packing options because different proprietary protocols have different data formats. For example, fixed data lengths or special delimiter characters can be used to identify single serial device responses. In this case, the serial device server will keep receiving data from the serial device until it receives the expected amount of data or a preconfigured delimiter, and only then transmit the data over the Ethernet network. If your serial device server does not support data packing options, you would have to develop complex SCADA software applications to handle the TCP packets properly. Developing this kind of special-purpose software wastes valuable time and money, and may also create bugs in your system.
3. Bandwidth
The serial device servers used to send serial device data back to a control room or a cloud application need to open a remote connection before they can transfer the 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 immediately close the connection. Without support for flexible connection control, you would need to spend extra time handling connections at the central site or cloud application.
Conclusion
Moxa’s NPort serial devices servers support a variety of advanced functions as part of each operation mode to assist users in streamlining operations and maximizing the benefits of serial-to-Ethernet connectivity.
source: http://www.moxa.com
Industrial Communication Network's Blog 