Terminal Servers in Substation Applications
Terminal servers are inexpensive devices that are used for converting IP to serial traffic. They have found their way to SCADA application too. They are used where a legacy RTU not being able to cover IP communication must be used with a more modern SCADA or telecomm infrastructure in which IP communication is used as the backbone of the control system. There are several manufacturers already providing good and reliable terminal server type devices for industrial applications such as substation automation or plan automation.
Terminal servers, in general can operate in the following modes: TCP Server, TCP Client, UDP and Com.
In the TCP Server mode, the device is set to open a specific IP port. The device is listening on the IP port for incoming TCP connection calls from the remote host. Obviously, the remote host is responsible for making the connections in this mode. Once the connection between the host and device is made, the device repeats the packets it receives on the TCP connection to the serial port. On the other hand, if data is received on the serial port, the terminal server sends the traffic to the remote host via the open connection. Please note that in this mode, the software running on the remote host trying to communicate to the terminal server must be able to operate in TCP/IP mode. In addition, the host must be able to detect TCP session time out and capable of retrying for establishing the session again.
In the TCP client mode, the remote host is responsible for opening a specific IP port. The host is listening on the port for incoming TCP connection calls from the terminal server device. The sequence of the events is the same as the TCP Server mode except that the device is responsible for re-establishing the link.
In the UDP mode, both sides open specific ports. In addition, both sides need to be aware of IP address and IP port of the other party. If the remote host has something to send to the terminal server, it wraps the data in one or more UDP packets and sends to the device IP address/port. On the other hand, the device sends to the remote host IP address/port what it receives over the serial link. Again, the software running on the remote host should be able of sending the data via UDP packets.
The last mode the is Com mode. In this mode, a proprietary device driver developed by the terminal server manufacturer is installed on the host machine. The driver communicates over IP to a resident program in the terminal server. Via this communication path, the device is instructed to send data over the serial link. Likewise, the device sends the data received on the serial link to the driver residing in the remote host via the same channel. At the host, the device driver emulates itself as a regular serial port. Therefore, the application software running on the host must be able to drive the local machine’s serial ports
In some cases, the bandwidth is abundant and the remote device is located close to the host machine with no firewall in between. Examples are communicating over a local fiber optic or Ethernet network. In this case, there would be no real difference between the performances of the four modes of operation. Here you need to see what are the requirements of the host application and try to comply with them. The problems start appearing when you have smaller bandwidth, spotty communication or have to go through firewalls. In this case, the Com mode is out of picture since you must have more information about its communication standards and timings to get it to work. Even though UDP is less reliable compared to TCP, it may be the way to go since it requires less overhead. Remember, in most substation data protocols such as DNP or Modbus, the master is already keeping track of the remote device responses. Therefore, you do not need to add another layer on top of it. You also need to determine how the packets at the device side are packaged. For example, if you know that your serial link receives packets with 300 ms lengths, it is better to wait the full period before sending the packets on the UDP port. Otherwise, terminal server needs to send two UDP packets per RTU response. This is something that you find it troubling in wireless environments.
I will talk about ways for putting together more versatile terminal server applications in future posts.
Take care for now,
Rod
