Sep 20, 2013

Reimagining Your Remote Communications with a New Distributed Architecture

Posted by Steve Sponseller

Optimizing communications between devices in the field and the centralized applications that need their data is a critical component to the success of a SCADA implementation. The networks that support these communications typically use radios, cellular networks, satellite links, or other types of wireless technology. Due to the bandwidth limitations of these networks, a non-streamlined and inefficient communications solution compromises the network’s ability to acquire and manage data as needed. This blog will discuss a new approach to a communications architecture that simplifies, enhances, and increases the reliability of data collection in a SCADA environment. 


An Example from the Field

Let’s use a compressor station facility in a gas pipeline as an example to highlight these communication challenges and show how a distributed communications architecture improves data collection and solves some of the communications challenges pipeline operators are facing today.

Compressor stations are located about every 100 miles in a gas pipeline to add pressure that was lost during those miles in order to keep the gas flowing. A compressor station would likely have an assortment of PLCs, RTUs, Flow Computers and other automation devices to monitor and control the facility, as well as measure and calculate gas flow data. Typically, there are several different local and remote software applications that need data from these devices. Examples of these applications include:

  • A local HMI and historian that are used by an on-site operator to monitor and control the equipment at the facility and store data locally.
  • The pipeline control room SCADA that is remotely monitoring the entire pipeline operation.
  • A corporate historian that might be storing data for predictive equipment maintenance, operational analysis and effectiveness, and Environmental Protection Agency (EPA) reporting.
  • A flow measurement and accounting system that is used for custody transfer purposes.

Your Current Communications Model—And Why It’s Not Working

In a typical non-distributed communications architecture, each of these applications would have its own data collector that is configured to poll each device specifically for the data the application needs. This can result in redundant, inefficient, and expensive communications that overly tax the network and flood the devices with data requests. This results in delayed communications, dropped data requests, and potentially excessive costs in charge-per-byte networks. The figure below demonstrates the inefficiencies of this communications structure.


Another problem this scenario presents is that the applications are required to use the native protocols of the devices. Many of these protocols were specifically developed using the bare minimum needed to communicate across limited bandwidth networks; as such, they have limited security and are frequently targets for man-in-the-middle attacks.

Proposal for a New Distributed Communications Architecture

In the new Distributed Communications Architecture, applications do not have their own data collector. Instead, one data collector is used to service many different applications, and in many scenarios, it can be placed close to the devices. The figure below shows what a distributed architecture might look like for the compressor station scenario described above.


As you can see, this architecture has many benefits. First, because the data collector is on-site at the compressor station and thus local to the devices, it does not require remote communications to connect to the devices. This gives the data collector a much higher succes rate for accessing those devices. Second, since the data collector does not need to communicate to the devices remotely through a site gateway, it can speak to multiple devices in parallel on the local network, improving effeciency and reducing the effects of unresponsive devices. Third, the single data collector reduces redundant communications to the devices from applications that are in need of the same data. This reduces the required bandwidth across the network, improving effeciency and reducing costs in charge-per-byte networks.

Communications between the data collectors in the field and centralized, corporate applications can be accomplished with a protocol that was specifically designed for this challenge. OPC UA is the latest standard from the OPC Foundation, whose purpose is to develop, promote, and maintain standards for open connectivity in the Automation Industry. Now data that has been successfully collected locally can be shared by on-site data collectors (OPC servers) to the corporate applications (OPC clients) in a secure, reliable, and efficient manner using OPC UA. Security across the Wide Area Network (WAN) is accomplished through OPC UA’s trusted certificate technology that allows for easy tunneling through firewalls. Configuring DCOM is no longer required for remote communications between client and server applications. Furthermore, OPC UA can limit access to the data collected by the data collector by user authentication of the application.

For more information on this technology, download the whitepaper: Leveraging KEPServerEX and Kepware’s New Security Policies Plug-In to Meet Your Security Requirements.

Wrap Up

Today, the EPA requires accurate reports on the emmissions of the large generators that power these compressor stations, and is penalizing companies with fines if data is missing in these reports. This data loss is often due to intermittent communications. However, if a local historian is attached to the data collector, critical data is not lost when communications go down. Data stored by a local historian can be retrieved via a suitable historical data interface like OPC HDA (Historical Data Access).

To learn more about this distributed architecture and the problems it addresses, download the whitepaper: A New Distributed Architecture for Remote Communications.

Download Kepware's Distributed Architecture Whitepaper

Please share your thoughts on this new architecture by posting a comment below. Let us know how you’re solving the challenges presented by remote communications in your own applications.