Sep 05, 2014

Untangling Network Communications: Channel Optimization (Part 1)

Posted by Sam Elsner

When discussing optimized automation systems, network communications are a common concern because of their significant complexity. Luckily, KEPServerEX has a number of tools available that make difficult optimizations easy to implement. In the first of a series of posts on project optimization, I will outline the optimization tools available to just one of the elements of a KEPServerEX project: the channel.

KEPServerEX Channel OverviewiStock_000008217270Small_Red

First, a primer on channels. In KEPServerEX, a channel defines two key parameters that the server uses when communicating to target devices: the protocol driver that will be used to correspond with target devices and a communications medium (usually Serial or Ethernet) that will allow messages to be transmitted and received. Channels are the parents of device objects in the server project. While channels define a protocol and communications medium, devices define how the protocol driver referenced in the channel should communicate with an individual device.

Determining a Channel Strategy

When creating channels in KEPServerEX, it is important to know that one communication thread is created per channel. This means that when multiple device objects are configured below a single channel, the single thread will communicate to one device at a time. The thread will correspond with each device to obtain data for all tags referenced by the clients connected to KEPServerEX. If the device does not respond to the request messages, the driver will retry and time out (per the settings configured in the Timing tab of Device Properties) before moving on to the next device in the channel.

In some environments, this can be an advantage. For example, if multiple serially-connected PLCs are placed behind a Serial to Ethernet converter, a KEPServerEX project that has one channel dedicated to each Serial Modbus PLC may quickly overwhelm the converter or the Serial network. In this environment, one channel with many devices would be appropriate. In contrast, if each Modbus PLC was individually connected to the Ethernet network, users could significantly improve the overall communication performance of the KEPServerEX project by placing each device on its own channel. This way, KEPServerEX would create one communication thread per device, and communication to each device would occur simultaneously.

Using KEPServerEX's Optimization Features

KEPServerEX also has optimization features at the channel level. Channel Serialization allows multiple channels to be grouped together into a “virtual network” where only one channel will communicate at a time. This feature is useful in environments where multiple protocols must be used to gather data from remote locations connected through a limited-bandwidth telemetry device (such as a low-performance Ethernet bridge or radio modem). In these cases, having one message transmission and receipt at a time yields better system performance than multiple simultaneous requests.

Another optimization at the channel level is Serial COM Port Sharing. This feature allows multiple channels in KEPServerEX to utilize the same Serial COM port of the host machine regardless of the protocol driver used in the channel. For example, a channel using the Modbus RTU Serial Driver and a channel using the ABB TotalFlow Driver (and other channels using Serial drivers) can take turns issuing requests and receiving responses over the same Serial COM port.

A third optimization at the channel level is the Inter-Device Delay. In understanding this feature, it is important to remember that when multiple devices are assigned to a single channel, the single communication thread created at the channel level corresponds with each device sequentially (one at a time). The Inter-Device Delay forces the single communication thread to wait a period of milliseconds before initiating communications with a device, thus slowing the communications thread as it initiates communication with each device in the channel. A KEPServerEX communication thread moves extremely quickly between communications to devices in a channel: if target devices are connected through a radio, cellular, or other type of modem, the modem may be sent a request for the next device in the channel before it has switched from receive to transmit mode. This can result in failed reads or writes that must be retried—which, in turn, slows communication performance considerably. The Inter-Device Delay is only available on select drivers: simply refer to the driver’s help documentation to see whether it is supported.

Coming Up

I hope this post has given you a better understanding of the tools available to optimize network communications when working with channels in KEPServerEX. In my next post, I will focus on other key elements of the KEPServerEX project; namely, devices and data server interfaces. I’ll also discuss environments where multiple features are used together to optimize communications performance. In the meantime, you can learn how Kepware's solutions help optimize OPC connectivity in the ARC Advisory Group's whitepaper below. Stay tuned!

Download the ARC View Whitepaper