Protocol Gateways: The Better Solution for Protocol Conversion

Submitted by Advantech
on Tue, 04/10/2018
In recent years, the trend in industrial automation is for all equipment, computers, and controllers to be able to communicate with each other to increase productivity, efficiency, and manufacturing quality. In this white paper, we will show different ways of how these industrial devices communicate with each other as well as offering a better solution.


Industrial communication protocols are used to establish a client-server or master-slave communication between industrial devices, such as Programmable Logic Controller (PLC) and Remote Terminal Unit (RTU). For industrial automated applications, there are many industrial communication protocols, such as Modbus TCP and PROFINET. Each industrial communication protocol was invented by different vendors and not really designed to communicate with each other. In today’s industrial environment, however, we want these devices to talk to each other, so how can we achieve this?

Communication between Different Industrial Protocols

With the progress of technology and the growth of Ethernet networks, industrial communication protocols have followed a steady evolution, such as Siemens PROFIBUS evolved to PROFINET, and Modbus RTU/ASCII evolved to Modbus TCP. From time to time, in order to improve production efficiency and stability, managers may adopt new industrial communication protocols with new automation equipment. But new industrial devices support specific protocols, which mean they may be incompatible with existing legacy equipment and protocols. So how can we make different devices communicate with each other, using an inexpensive solution which is also easy to implement—all of which are important issues for users.

Tradition Solution

In most cases, managers use a PLC to communicate with an RTU, to acquire data, and control the manufacturing process. But, because PLCs often only support vendor defined proprietary protocols, if you want a PLC to support other protocols, you need to use extension communication modules in the PLC. Siemens PLCs for example need extension communication modules to support Modbus RTUs. In this case, a user must input the function block diagram data of the new protocol into the PLC and enter the correct parameters for the data.

The main advantage of using PLC extension communication modules is reliability. However, the disadvantages of using PLC extension communication modules are:

  • The high cost of PLC extension communication modules.
  • Each PLC function block diagram occupies PLC memory and PLC memory is expensive.
  • It can be difficult to input a PLC function block diagram, and users must be familiar with the characteristics of different protocols and settings in order to correctly implement it.
  • There may not even be a suitable PLC extension communication module that supports your desired protocol.

Using an Industrial Protocol Gateway

Currently, we have another suitable solution called a protocol gateway. A protocol gateway is a device that converts from one protocol to another to allow communication between devices.

The general architecture of protocol gateway includes a protocol-A slave, a protocol-B master and an internal database. One normal scenario for a protocol gateway is the protocol-B master communicates with a remote device, gets that device’s data, and keeps it in the internal database. When remote protocol-A master, such as a PLC, asks the gateway about the data, gateway protocol-A’s slave obtains the data from its internal database, and sends it to remote protocol-A master.

Another typical scenario for a protocol gateway is the remote protocol-A master sends data or command to gateway’s protocol-A slave. Protocol-A slave passes the data or command to protocol-B master, and triggers protocol-B master to send the data or command to a remote device.

With the different protocols, the physical interface of protocol gateways may be different, such as the physical interface of DeviceNet is CAN bus, however the physical interface of Modbus RTU is RS-232/422/485.

What are the Benefits of Using Protocol Gateway?

As mentioned earlier, when using PLC extension communication modules, the user must program the PLC for the new industrial protocol. And in general, this is difficult for normal users. But if a protocol gateway is chosen, the user will not need to worry about how to write PLC programs for the new protocol. The market has many protocol gateways, which support a variety of industrial protocol conversions so a user can easily find a suitable protocol gateway to meet their conversion requirement.

There is also another important benefit of using a protocol gateway. Good protocol gateways have diagnosis and troubleshooting tools, which can help users to easily install industrial devices and help them with problem solving. For example, when an industrial device status or data is incorrect, you can use the diagnosis tools to confirm connection status, and through the data monitoring and analysis tool you can capture and analyze data sent from the device to figure out what the problem is.

Advantech Protocol Gateway Solution

Advantech provides a variety of Protocol Gateway solutions that support all major industrial protocols, such as PROFINET, EtherNet/IP, EtherCAT and Modbus TCP/RTU. Advantech protocol gateways use the highest quality components to enable them to operate in temperatures of between -40 and 75°C. To optimize protocol conversion, and reduce maintenance cost, Advantech protocol gateways also support these features below.

  • High speed conversion of data between different protocols provides runtime protocol information, such as connection status of peer-to-peer industrial devices to ensure everything is running smoothly.

  • Provides protocol traffic monitoring tools to instantly capture and clearly present protocol data. With this information, end users can ensure the accuracy of peer-to-peer industrial devices and discover problems when they arise.

  • User-friendly WEB design to help users quickly and easily establish a mapping table between different protocols, for example, users can duplicate existing protocol mapping to create a new mapping entry and shorten the time of deployment.


Download White Paper