Every industrial network has more than a single protocol within it. A simple analogy for a protocol is to think of it as a language. So if we are changing from one protocol to another, we are effectively translating between languages. And because of the complexity of today’s networks, you can almost guarantee that it will be necessary to translate protocols between different networks.
Gateways are an important part of any network. The IEC’s online data dictionary defines a gateway as a “functional unit that connects two computer networks with different network architectures and protocols.” Gateways are also used to connect networks operating at different transmission speeds.
I imagine that the most widely deployed gateway is therefore used when converting from a serial or field-level (fieldbus) signal to its Ethernet equivalent, such as Modbus RTU to Modbus/TCP. Practically every fieldbus also has its equivalent Ethernet version — i.e., Foundation Fieldbus H1 with HSE; Profibus with Profinet; and Devicenet and Controlnet with Ethernet/IP. These types of gateways, however, represent the most common configuration because both versions of the protocol continue to follow the same basic rules and principles while providing a single configuration environment, including — in most cases — the same tools to manage the full network. In addition, most facilities strive to manage and minimize the number of different protocols they have on a site.
The real workhorse gateways are those that transfer across or between protocols, such as between Modbus/TCP and DNP3 or Modbus/TCP and Foundation Fieldbus H1, because these devices require more intelligence and tools to map parameters from one protocol to the other. For example, the basic Foundation Fieldbus H1 parameters contained in a single process update command of PV, status, time stamp and quality need multiple Modbus registers, each of a different type (real, discrete, integer) and, therefore, typically also require manual intervention to create the linkage or map between the parameters.
So how do gateways accomplish this?
In an industrial setting, control information has the highest priority, so the gateway’s primary role is to transfer cyclic I/O data (control information) between two networks. This data transfer can either be a slave-slave combination or a master-slave combination. In all cases, the fieldbus or Ethernet network side connected to the field devices of the gateway acts as a slave to the controller with which the data is being shared.
Depending on the network combinations, acyclic data can also be transferred, enabling the transfer of non-time critical messaging and diagnostic information. Because the gateway can define which bytes from the serial data stream are data and which bytes are commands and control information — typically differentiated as cyclic and acyclic messages respectively — the overall network determinism can be maintained.
During the translation process, I/O data is temporarily stored in an internal memory buffer inside the gateway. One of the benefits of doing this translating and processing in the gateway, instead of in the PLC or controller, is that it simplifies the integration of serial devices into modern industrial networks and control systems. The penalty for this buffering, processing and conversion to the data format, the typical transfer time between the two networks, is in the range of 10 to 15 milliseconds.
Gateways may be used in single-drop mode to connect one device via its serial interface to a fieldbus or industrial Ethernet, or in multi-drop mode to connect one to many devices.
In addition to their translating function, because gateways need to support layers one through seven of the OSI (Open System Interconnect) model, they can be configured to do other functions as well. For example, two installations or networks being connected can also be logically and physically isolated from each other without losing the capability to transfer the selected data between them.
Once the system has been designed, the gateway and, in many cases, the devices connected to it also need to be configured to arrange the parameters in a format compatible with the protocol being used and in a way meaningful to all nodes/devices in the network. In all cases, the parameters have to be selected and arranged in a logical way. Logical means it must make sense for both the gateway and the person doing the configuration, so that when it needs to be changed in the future, someone other than the person who did the original work can understand the objective of the work, as well as how it was done.
Though a slave/slave configuration is a single step, a master/slave gateway configuration is made in two steps. The first step is to define the amount of I/O and parameter data, as well as the mapping of the data between the two networks. Then, if the gateway is for use with at least one Ethernet-based interface, the second step is to set up the Ethernet-based network interface with its IP address settings.
Just like effective communications require a common understanding of the words, language constructs, syntax and associated phrases, the same is true for industrial network communications. Fortunately, gateways are able to work as those effective interpreters — as long as the person setting them up has provided them the correct configurations (dictionaries) with which to work.
This column originally appeared in the June 2014 issue of Manufacturing AUTOMATION.