Picking from a plethora of protocols

The present version of the IEC 61158 standard includes 19 different protocols. However, while at an ISA meeting recently, I was approached by a Japanese organization about the addition of another, so I believe we will soon be up to 21 protocols in a single standard — and this is only for industrial processes.

There are also multiple standards for other industries. With so many options, how do you decide which one to use?

Despite the “fieldbus wars” of the mid-1990s that resulted in the amalgamated IEC 61158 standard, each protocol in that standard was developed from a specific industry and has continued to remain strong in the vertical niche or sector from which it came. Therefore, one of the primary considerations when selecting a protocol for your project is whether it is designed for your application. Does it address items such as response time/baud rate (real time is different for a process storage tank or temperature reading than it is for a multi-axis robot), network length, area classification and packet size (an indicator of its ability to support discrete as well as analog signals)?

Of course, if you already have one or more protocols (hopefully not more than two) in use at your facility, that is also a big factor in the decision process because you not only have to have the infrastructure in place, but you also need staff familiar with and trained in how to maintain and make effective use of the protocol’s features.

You also need to consider what protocols are supported by your present control system, since a direct interface is always much better than needing to use a gateway. A gateway is effectively a “translator” that converts one protocol or language to another. As we know, with any translation, it is never perfect or without the potential for misunderstandings. Gateways also require configuration and, though they are very reliable, are another potential source of failure in your system.

Geography also plays a factor in the decision process because some standards have predominance in that market in certain parts of the world — e.g., electrical distribution SCADA systems are divided into DNP3 in North America and IEC 61850 in most of the balance of the world. On a smaller or more regional scale, you also need to consider the level of local support for the protocols being considered, since certain parts of a country may have many multi-national companies that support a protocol from another part of the world (i.e., a European pharmaceutical manufacturer in the Eastern Seaboard) rather than the North American market-leading protocol for that industry, for example.

Another consideration I include in my deliberations is whether the protocol supports an “Ethernet version” so that, if desired, I can migrate to an Ethernet packet-based network, especially for the backhaul or “controller-to-controller” communications. Then I can also use that Ethernet infrastructure, including the Internet (assuming I have the appropriate cyber security configurations on the network), if desired. Fortunately, most protocols support Ethernet, including the newly released HART/IP.

Once you have converted to an Ethernet packet, it is now possible to send the resulting information wirelessly using the same IEEE 802.11 infrastructure that we use in our homes or public places. Then, if you are using wireless for your backhaul and have the necessary infrastructure in place to support the next wireless step of industrial networks, you can bring your wireless network to your field sensors (not to replace wires, but rather to provide measurements that are not feasible with wired devices). Unfortunately, there are few such products on the market yet, though many innovations in the RFID and SAW (Surface Acoustic Wave) sensor field may soon change that.

Having gone “full circle” from wired field-level networks back to field-level wireless networks, I may not have answered the initial question of how to select the protocol for your project, but hopefully I provided you with some guidance on the associated thought processes used during the initial Front-End Engineering Design (FEED) to help you narrow the list down to what protocols are worth considering further.