Industry 4.0, the smart factory, Industrial Internet of Things—these terms all describe the continuous modernization of our world’s factories. The driving force behind this industrial revolution is the introduction and expansion of automated systems to perform tasks typically done by humans. What happens when more than one of these machines is operating independently on the factory floor, but is part of a larger system? How can manufacturers ensure synchronicity while increasing efficiency and maintaining a sufficient level of safety? The answer is a multitude of programmable logic controllers (as shown in Figure 1) coordinating everything through the use of industrial communications protocols. The resulting industrial communications network is the backbone of the smart factory.

Figure 1: typical PLC using 10/100Mbps Ethernet for communication
A communications protocol, in its simplest terms, is a set of rules to where two or more nodes in a network must adhere in order to properly communicate with each other. Think of it like a language: if one person only speaks Spanish and the other only speaks German, direct communication will be very difficult. A protocol essentially gives the nodes participating in the network an ability to speak the same language.
There are many different kinds of protocols: some optimized for speed, others for long-distance communication and various other use cases. Industrial automation requires protocols that optimize for speed and determinism—the case of industrial Ethernet meaning it operates in a completely predictable manner in the time domain.
In industrial automation, some protocols use serial buses while others utilize Ethernet. Industrial Ethernet protocols are popular because of the speeds and robustness available. EtherNet/IP®, PROFINET, EtherCAT, OPC UA, CC-Link IE, SERCOS III, Mechatrolink III, High-Availability Seamless Redundancy (HSR), Parallel Redundancy Protocol (PRP), and Powerlink are just some protocols available on today’s market. EtherNet/IP, PROFINET, and EtherCAT are currently the leaders, making up roughly 63 percent of the industrial Ethernet market according to HMS’s 2017 market report.
The multitude of available industrial protocols has caused some fragmentation in the market. No one protocol is significantly better than the other, and there are different industry leaders backing different protocols. Additionally, some protocols are better suited for certain applications than the others. As a result, the industry has had a hard time settling on just one. It’s simply a matter of preference in many cases. Adding to the complexity, factories aren’t always built at once with equipment from a single vendor. In many cases, factories repurpose production-line equipment from other factories to save costs, since industrial equipment is built to last many years. A combination of old and new equipment increases the likelihood that all machines in a factory don’t communicate via the same protocol, which causes fragmentation even within a single factory.
This fragmentation has led automation equipment manufacturers to release multiple versions of their products, each supporting a different protocol, and has increased the need for gateways between networks. This can be expensive for manufacturers if they have to develop application-specific integrated circuits for each of the protocols that they want supported in their end product. Fortunately, some solutions are flexible enough to support multiple protocols, and some even integrate the applications processor with an industrial communications solution.
Industrial equipment manufacturers have increasingly requested multiprotocol support as they strive to keep up with the fragmented market while keeping development costs low. Another reason why multiprotocol support is increasing in importance is factories are bridging the upper layers of the factory, which might be communicating via OPC UA, and the lower layers, which could be communicating via EtherCAT. A microprocessor with multiprotocol support can enable a manufacturer to develop these gateways to bridge both layers or a single main board that they can copy across several products, each supporting a different protocol. This greatly reduces the additional development costs necessary to support multiple protocols, which is why it is such a favored solution to the fragmentation.
Another more forward-looking solution is the introduction of a set of standards collectively known as time-sensitive networking (TSN). TSN provides a common base layer that makes it easier for different protocols to coexist. Although TSN is still under definition, a number of standards have already been published by the TSN Task Group within the Institute of Electrical and Electronics Engineers (IEEE) 802.1 Working Group. Table 1 lists the published standards along with a brief description of what they are.
Standard |
Alias |
Description |
IEEE 802.1AS/Rev1588v2 |
Timing and synchronization |
Provides Layer 2 time synchronization |
IEEE 802.1Qbv |
Time aware shaper |
Runs the 8 port output queues of a bridge on a rotating schedule. Blocks all ports except one based on a time schedule in order to prevent delays during scheduled transmission. |
IEEE 802.1Qbu |
Frame preemption |
This just adds 802.1Qbr to 802.1Qbv. It allows for the interruption of non-time critical frames to allow time critical frames to pass through. |
IEEE 802.1Qca |
Path control and reservation |
Discovers the network by collecting topology information from the nodes in order to find redundant paths through the network and to ensure redundancy in the future. |
IEEE 802.1CB |
Redundancy |
Messages are copied and communicated in parallel over disjoint paths and then the redundant duplicates are removed at the receiver end. |
IEEE 802.1Qci |
Per-stream filtering and policing |
Filters frames on ingress ports based on arrival times, rates and bandwidth to protect against excess bandwidth usage, burst sizes as well as against faulty or malicious endpoints |
IEEE 802.1Qch |
Cyclic queuing and forwarding |
Collects packets according to their traffic class and forwards them in one cycle. Provides a simple way to use TSN if controlled timing is desired, but reducing latency isn’t important |
Table 1: Published TSN standards as of June 2018. (Image Credit: IEEE 802)
Not all published standards will be implemented in a TSN network. Ultimately, there will be a subset of standards the market will adopt as “standard TSN,” but it is still early to tell what that subset may be. Currently, it appears that IEEE 802.1AS (Time Synchronization) and IEEE 802.1Qbv (Time Aware Shaper) are two of the favorites for TSN, which can be implemented over 100 Mbps Ethernet. However, its real benefit comes when it runs at gigabit speeds.
Many of the top protocols already have plans to move toward TSN, with PROFINET the most advanced in this respect. PROFINET and PROFIBUS International have announced that they will move to TSN in future versions of PROFINET, which will be called PROFINET@TSN. There was already a demo at Hannover Messe 2018, with multiple boards based on the Texas Instruments Sitara™ AM5728 processor running PROFINET@TSN. The EtherCAT Technology Group and Open DeviceNet Vendor Association have also announced plans to incorporate TSN into their protocols.
Like multiprotocol support, TSN support ultimately comes down to the component level. Automation equipment must have TSN-enabled hardware inside to support it, either through external switches or integrated features within a system on chip (SoC), as shown in the Sitara processor’s programmable real-time unit-industrial communication subsystem (PRU-ICSS) in the PROFINET@TSN demo.
One key point I’ll bring up again is that TSN is still not fully defined, which means manufacturers looking to get ahead of the curve and future-proof for TSN must be wary of the hardware used to base their solutions. They must ensure their TSN switch is flexible enough to adapt changing standards or risk having outdated equipment.
I discussed TSN and multiprotocol support in this article, but there are even more areas of industrial communication to explore, such as the connection of a factory to the cloud, or the communication between a motor drive and a servo motor. The future of the industrial revolution is bright, and I look forward to expanding on other areas in future articles.
Filed Under: Industrial automation