In the era of IIoT, network managers gain value from the information provided by serial devices to know the device status and work data, which allows the relatively old connection of serial ports to continue. One way is to connect the device to the Ethernet through serial device server.
Serial device server can be used to connect legacy serial devices to Ethernet. The serial device server has two interfaces: one is the serial interface and the other is the Ethernet interface. The serial server uses the virtual COM port concept to allow data from serial devices to be transferred over the network to the existing SCADA system. In addition, the serial device server supports raw socket mode, which transparently packs serial data into TCP or UDP packets. Most SCADA systems and OPC servers support Ethernet package drivers that are used with serial device servers to receive proprietary protocols. You still need to manually process the protocol as before, but the serial device server can help you easily transfer data to Ethernet.
There are three key points to be considered when using a serial device server to support IoT cloud applications: (1) multi-polling, (2) proprietary protocols, (3) bandwidth.
SCADA systems and remote cloud applications may send multiple commands to the same serial device server at the same time. Therefore, serial device servers need to support FIFO (first in, first out) queues to handle all queries. The first query in the queue will be sent to the serial device first, while the rest of the queries will wait in the FIFO queue within the device server. Once the serial device server receives a response from the 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 per-command processing is very important in IoT multi-polling applications because a large number of serial devices support proprietary protocols. Without this design, an additional IoT gateway supporting multi-polling is required.
2. Proprietary protocol (data packaging)
Since many serial devices use proprietary protocols, the serial device server must be able to properly convert serial data to Ethernet packets. Many serial device servers support raw socket and TCP server modes, which can handle these types of conversions. However, the problem is that the serial device server may not know the best way to divide the serial data into separate TCP packets. Serial device servers do not understand proprietary serial data formats, so they may decompose a single response from a serial device into two or more TCP packets. When SCADA systems or cloud applications are unpacked, they will be rejected because the serial data provided by a single package does not follow the expected format. SCADA systems or cloud applications typically want to package a single serial device server response into a single TCP packet. To ensure proper processing, the serial device server needs to support flexible data packaging options because different proprietary protocols have different data formats. For example, you can use a fixed data length or a special separator character to identify a single serial device response. In this case, the serial device server will continue to receive data from the serial device until it receives the expected amount of data or a pre-configured delimiter before transmitting the data over the Ethernet. If the serial device server does not support the data packaging option, you must develop a complex SCADA software application to properly handle TCP packets. Developing this special-purpose software wastes valuable time and money and can create errors in the system.
The serial device server needs to open the remote connection before transferring the serial data. If a large number of serial devices are connected to the same network, the connection will require many broadband resources in the control room or cloud application. To handle these large numbers of remote connections correctly, the serial device server should support flexible connection control. The best way to do this is to open the connection only when receiving serial data from the device. After the transfer is complete, the serial device server should immediately close the connection. If flexible connection control is not supported, it takes extra time to handle the connection to the central site or cloud application.