Every digital system needs to integrate with its associated control system, typically over an Ethernet backhaul network. Though it has lower bandwidth than fiber's gigabit capacity, wireless is also an option for this "home stretch" between the field access point and the host. However, the physical layer and arguably the data link through transport layers are just one part of getting a message from the field sensor to the central I/O database(s). In all the discussions about wired versus wireless, the often overlooked and arguably most important part of the network, for connectivity at least, is the protocol, typically Layer 7 or Layer 8 of the OSI model.
Figure 1 illustrates why the open system interconnect (OSI) model, which effectively builds a protocol in layers similar to building each layer of a house from its foundation, is used by almost all protocols; as shown, the protocols can use wired, wireless or Ethernet packets with the same command set and functionality at the top layers, regardless of the physical layer used for transmission simply by defining the interface to the appropriate layer(s) below it.
Looking at the physical layer, "Field Comms" refers to the normally twisted pair wire for a fieldbus system, or in the case of wireless, the 802.15.4 communications, for the field sensor network. Since most fieldbus systems are simple networks with all the devices connected to a single port, layers 3 through 7 are normally blended into a single message management system. Shifting to an Ethernet protocol is therefore as easy as defining the interface between the user layer and the appropriate transport layer being used to manage the network transmissions.
Why, you might ask, is the protocol important? The simple reason is that if you have a single protocol you do not need to use gateways.
Now that we can change how the message is being sent, much like we can all talk over a telephone, whether it is cellular (wireless), voice over Internet protocol (VoIP ‒ Ethernet), or land line, and still understand each other or at least make the phone connection, the same can be done with the information generated by a protocol's user layer.
If we substitute the word "language" for "protocol" and continue with our phone analogy, two people can communicate with each other if we share the same language. However, if we do not speak a common language, we need a translator. Therefore, since a protocol is like a language, then a gateway is a translator. If any of you are multilingual, or have tried to translate something from one language to another, especially simultaneously, you can appreciate that doing so is not a trivial task. Yet as automation engineers, we think nothing of including multiple gateways in any of our networks, and then wonder why our system has communication problems.
The default protocol for any system is some variant of Modbus. Modbus is great because it is flexible and ubiquitous, however, because it is flexible, it also requires a significant amount of manual intervention to map information from one protocol to the appropriate memory registers in the gateway and host system. Manual intervention is another source for potential errors, so whenever possible, we certainly want to minimize it.
As a result, a much better option than a gateway is to stay within the protocol itself and avoid the gateway all together.
Fortunately, with HART/IP now available, it is possible for the two major wireless protocols used for process automation, WirelessHART and ISA100.11, to connect from end to end without the need for a gateway, thus making the home stretch less of an effort than it was in the past, while also providing access to all the information available from the protocol by reading the necessary device configuration file. An additional advantage of end-to-end connectivity is that the same configuration tool can be used for the device and host system, again with minimal human intervention. Sounds like a home run to me.