By Joe Feeley, Editor in Chief
The choice between hardware-based protocol-converter appliances and using software is driven by a number of factors, says Roy Kok, vice president of sales and marketing, Kepware (www.kepware.com). "In the end, performance and cost will be the two final factors," he says, "but if high performance is required, an appliance such as a gateway box might not be good enough as they are typically less powerful than their workstation or server counterparts. The application could require a PC-grade platform with extra processing power and memory and a gateway software product."
The computing platform that runs the communications can affect latency if underpowered for the task at hand. "One of my assignments at Rockwell Automation was to look at advantages and disadvantages of protocol conversion and the impact on performance and the overall latency of end-to-end message delivery," says Tom Burke, president and executive director, OPC Foundation (www.opcfoundation.org). When a packet is transferred over a network, a period addressed as latency is the time during which the sender is waiting for the receiver to acknowledge that the packet has been received. One critical effect on overall latency is the bandwidth and the available network connection speed.
The latency of communication between the sender and receiver really depends on the processing delay of the corresponding hardware and software, coupled with the protocol conversion complexity. The latencies in a typical industrial automation application typically can run anywhere between 10 ms and several seconds, says Burke.
In many cases, the hardware or software decision is made based upon the plant equipment currently in use. "Software protocol conversion involves one important piece of hardware, a PC, which can be located either remotely or on the factory floor," states David Harris, vice president of marketing, Red Lion Controls (www.redlion.net). "This PC often will use multiple OPC software products to facilitate communications with disparate plant floor devices, with one software product required for each protocol used. An additional OPC product might be needed in order for OPC clients to share data amongst one another providing the protocol conversion."
Each OPC product must be purchased separately, says Harris, which could make this option costly. Within a PC-based platform, additional hardware and cost could be required if this solution is used to communicate with industrial networks beyond serial and Ethernet. "However, if a PC is already in use in the factory, it might already use the necessary hardware, making a software solution more cost-effective for some applications," Harris adds.
Often, machine-to-machine (M2M) protocol conversion can be just an extra task on an existing server—no special hardware required. "Many protocol converters are very basic in operation and don’t support the intricate nuances of a particular protocol; or they might not support the many forms of optimization that can be applied to communications," says Kok.
 "With the new technology of the OPC Unified Architecture we’ve now successfully used traditional hardware in which the OPC technology is natively embedded, eliminating the need for complex protocol conversion," says Burke.
For many industrial network protocols, the protocol conversion to the OPC UA standard is fairly straightforward, because we’re converting what is typically referred to as raw data in a very limited amount of information such as quality and timestamp, Burke says. "But as we have increased behavioral-type functionality that allows us to pass complex information, programs and commands from devices to applications, the amount of protocol conversion drastically increases."
Bernd Schuessler, business development manager, Pepperl+Fuchs (www.pepperl-fuchs.us) differentiates between transparent and non-transparent data and network conversions. "Profibus supports high-speed (up to 12 Mbaud), non-powered Profibus-DP as well as lower-speed (31.25 Kbaud), bus-powered Profibus-PA," says Schuessler. "The PLC or DCS can talk to both buses via a transparent segment coupler. The different physical layers are coupled via a DP/PA segment coupler, totally transparent to the host. The segment coupler automatically takes care of the conversion between the different media and bus speeds. No additional human intervention or data mapping is required, which makes this a traditional hardware conversion."
When using traditional remote I/O systems, a hybrid—hardware plus software—conversion is typically implemented. "This involves the transparent conversion of analog and discrete process I/O signals to an internal digital bus, which communicates to a gateway," says Schuessler. "The gateway is then connected to the external process bus system and the controller. In the controller, software is used to configure the physical I/O for process control. The configuration of the I/O in the controller requires minimal engineering and is typically standardized—that is, GSD, DD or DTM files."
On the other hand, when converting two totally different networks and protocols—for example, Profibus to Modbus—I/O mapping definitely is required. "Important status and diagnostic information might even be lost, and users might not get the full functionality out of the system," says Schuessler. "Manually mapping I/O data is time-consuming and adds to the overall project cost and complexity of a system. Sometimes there is simply no way around it."
Jim Toepper, product manager, industrial Ethernet infrastructure, Moxa (www.moxa.com) and a member of the ODVA working group for EtherNet/IP infrastructure, says Rockwell Automation decided to partner with Schneider Electric as it relates to protocols. "Initiatives for making DF1, Modbus ASCII/RTU, Modbus TCP and EtherNet/IP all interoperate have been underway for some time now," he says. "So now, more than before, we see Modbus devices and A-B devices operating smoothly side by side." This doesn’t mean plant engineers can just go and connect devices willy-nilly, he adds. "There are many products out there that facilitate this conversion from a simple Modbus Serial to Modbus TCP to more complex cross-protocol conversions such as DF1 to Profinet," says Toepper.
As with their software counterparts, many hardware protocol converters handle only a single protocol. One device can convert Modbus to DF1 and vice versa, but converting one of these protocols to or from MPI often will require an additional device. "Users that employ equipment made by many different manufacturers must maintain and configure several protocol converters to facilitate plant-floor communications, which can prove costly as well as time-consuming," says Harris. "One way to avoid this expense and hassle is to employ a single protocol converter capable of communicating with multiple protocols—in some cases, more than 200. This type of converter could allow several plant floor devices to connect and communicate at once."
