Selecting protocol conversion gateways

Many protocol communication options are available for connecting control systems to numerous devices on the plant floor.


Figure 1: This system architecture drawing shows how gateways enable users to migrate legacy VFDs, operator interfaces, HMIs, and remote I/O over EtherNet/IP. Courtesy: ProSoft TechnologyThink of a candy store: there are hundreds of flavor types and combinations including chocolate malt balls, peanut butter/chocolate candy bars, orange/grape soft chews-virtually any combination of candy or sugary treat imaginable. There are some that look the same but are from different manufacturers. However, each candy, while having different varieties of similar flavors, has its own distinct identity-from the brand recognition to taste. Some are sweeter than others, while others can have a bitter taste. Many look like they can satisfy your sweet tooth, but looking closely only a few are right for you.

What does a candy store have to do with industrial automation? Just as there is a plethora of selections in a candy store, there is also an abundance of protocol conversion choices from many different manufacturers. The lineup, which this article will explore, includes gateways that offer different communications methods, support for big data applications, those with client and/or server configurations, and those with master or slave capabilities. In addition, gateways can be configured via Web-based platforms, or using separate software.

Choosing whether to use a gateway or an in-chassis module can depend on:

  • Which protocols you need to interface
  • How much integration time you want to invest
  • Whether the network you need to connect to is close to your PLC/PAC
  • How much data you need to send back to your PLC/PAC
  • Cost.

Typically, gateways can be less costly than their in-chassis counterparts, but offer less PLC/PAC integration capabilities.

In industrial control applications, PLCs/PACs often need to communicate with many different devices. Whether an OEM has sent you a new piece of equipment and the PLC/PAC is not made by the same supplier as the rest of your line, or you need to connect to your favorite drive, power monitor, flow device, or actuated valve that does not communicate to your PLC/PAC, a gateway is required. There are many control devices that offer specific features you want or need and are often on networks that are not native to your PLC/PAC supplier of choice.

Application scenarios

Industrial gateways are designed to pass control system data from one protocol to another. There are hundreds of different protocols available, such as Modbus, PROFIBUS, EtherNet/IP, DNP3, and IEC 61850, to name a few (see Figure 1). Just as there are hundreds of different protocols, there are also many different gateway specifications. Features can range from offering multiple I/O connections for real-time data transfer to being able to pass thousands of words of data.

Different applications put different requirements on the gateways. Considerations include:

  • What type of devices do I need to communicate with?
  • Is my device a master or slave, or a client or server?
  • How much data do I need to transfer?
  • How fast do I need this data?
  • What diagnostics are available and how easy are they to get to?
  • Can I view them in PLC/PAC tags so that I can display them on an operator terminal?
  • If I need to communicate with many server devices, does the gateway support multiple clients, and if so, how many?
  • If the gateway fails, how easy is it to restore a valid configuration?

One example of a specific need for gateways is in the energy industry. The energy industry uses protocols such as IEC 61850, DNP3, Modbus TCP/IP, or IEC 60870-5-104 with the newer IEC 61850 becoming more prevalent for green field applications. The energy industry requires specific types of devices that come with specific protocols. With PLCs/PACs also becoming popular in these applications, gateways become necessary to complete the control system.

Figure 2: This drawing shows how an IEC 61850 protocol gateway can be used to transfer data from a variety of electrical substation devices, such as IEDs, to an EtherNet/IP PAC. Courtesy: ProSoft TechnologyThe IEC 61850 protocol is becoming popular in substation automation (see Figure 2). Although there are many protocols worldwide for substation automation, IEC 61850 is the only one that provides a standardized method of communication and integration that supports systems networked together to perform intelligent transmission and distribution protection, monitoring, automation, metering, and control. The standardization of IEC 61850 enables the integration of the equipment and systems from different suppliers, reducing the burden on the configuration and maintenance of these systems. The protocol also meets utilities' requirements for long-term system expandability.

A user may want to use a PLC/PAC to monitor electrical substation intelligent electronic devices (IED) to gain information such as volts, VARs, amps, or transformer temperature. A gateway can be used to transfer this IEC 61850 data into the PLC/PAC. Some gateway suppliers have designed their offerings that offer a premier integration into the control system and can import device tags from the IEDs and send them to the PAC tag database. This means that the user no longer has to type in tag names manually, reducing downtime and programming errors.

Gateways can also be useful when migrating legacy PLC systems to newer PAC systems in stages. For example, you may need to upgrade some legacy equipment, such as a drive or electronic operator terminal that is sitting on an older network, and the new replacement units are only offered in a newer protocol. Without the gateway, you would have to upgrade your entire control system to one that uses the newer protocol. This would require significant downtime and would introduce the risk of not getting the new system up and running in time. A gateway would allow the newer drive or electronic operator terminal to be upgraded without the need for extended downtime. This same solution can be applied when older PLCs from different vendors need to be upgraded to a different vendor's PAC. A gateway can be deployed to have the newer PAC control the existing remote I/O system, again minimizing downtime and risk.

Brewing a gateway solution

Located in Cardiff, Wales, Brains Brewery needed to upgrade some of its legacy equipment. The brewery used gateways to upgrade a legacy PLC system in its yeast handling process to a new PAC system. By using the gateways, the new PAC was able to communicate with the existing six racks of remote I/O over Ethernet.

"The commissioning time was reduced massively because the existing remote I/O cards and wiring could be retained," said Mike Cooper of IAC Engineering, who proposed using the gateway. "Only the processor and software needed to be added and commissioned, not the field wiring."

Without the gateway system, a new I/O system would have been required. In addition, a new I/O system would have to be installed and wired. The gateway solution reduced project cost and allowed the PAC processor to communicate to the remote I/O cards. The gateway helped bring Ethernet and control system flexibility to the plant.

Configuration and setup

Gateway configuration and setup can range from very simple to very complex, depending on the protocol and the gateway manufacturer. Some gateways are designed to be optimized to interface with specific PLC vendors. Depending on the selected unit, gateways can have different diagnostic levels. This feature can be very important when facilities consider the downtime associated with a network device failure.

Some gateways act as clients by grabbing data from one device and sending it to another without intervention from a PLC/PAC. With this type of communication, the PLC/PAC responds to the gateway's request as it has time available, and can vary in response time from one request to the next. In some applications, this performance may be acceptable. This type of gateway requires no PLC/PAC configuration and is invisible to the PLC/PAC. If a device fails, the PLC/PAC has no information on what has gone wrong and can require extended downtime to troubleshoot the problem. Gateways that use an I/O connection to the PAC are integrated into the PAC configuration environment. They support real-time data transfers, and can identify communication problems and alert an operator accordingly, thereby reducing unscheduled downtime. A gateway that acts as a server and requires the PLC/PAC to message back to it can alert the PLC/PAC that the gateway has stopped talking and has the same communication response time issues as the client mode.

Some gateways use a Web configuration, which means that no external tools or software are needed for configuration. A Web browser is used to configure and monitor the gateway. This may be a concern for some IT departments, depending on how the Web interface has been designed. Other gateways use separate configuration software that has its own set of challenges.

An important consideration when choosing a gateway is selecting a vendor that can provide good technical support. Having a reliable technical support team available for assistance with configuration, start-up, commissioning, and operation should be among the gateway selection criteria.

Protocol conversion gateways will be around for the foreseeable future. They fill the void for distributed network applications or for OEMs that focus on low-cost connectivity. There will continue to be a wide variety of gateway connectivity options, just like candy in a candy store.

Victor Garcia is a marketing staff writer for ProSoft Technology. Ken Roslan is the vice president of Global Marketing for ProSoft Technology.


MCKINLEY , TN, United States, 06/11/14 01:27 PM:

great article


click me