Conceptually, the IoT has been discussed at great lengths over the past few years. “Why IoT?” has been asked, use cases have been explored, and many implementations are underway. The shift from concept to implementation is now sparking new discussions.

Industrial users and systems integrators are asking the “what” and “how” of IoT, wondering what technology is best and how integration will work between various applications. These discussions extend to the manner in which connected devices communicate, both in “the fog” at “the edge,” and with higher-level systems and “the cloud.”

What are the open standards and protocols connecting assets within the Industrial Internet of Things (IIoT)? What are the pros and cons of the request/response and publish/subscribe protocol models? And how can you determine which methods or protocols best fit your Industry 4.0 needs? Let’s take a look.

Every industry and company has their own definition for the edge of their infrastructure.

Industrial IoT Challenge #1: Interoperability

Over the years, many different protocols have emerged in the Manufacturing Industry—leading to a myriad of communication interfaces that need to be supported within one environment.

These industrial protocols (which include DNP, Modbus, BACnet, and much more) were built to accommodate different requirements of various end users and industries. 77% of IoT Nexus survey respondents (Power Players in the Internet of Things: A report by IoT Nexus) say interoperability is the biggest challenge facing IoT.

It’s comparable to all of the different languages spoken on earth, and the communications problem that presents. In addition, every industry and company has their own definition for the “edge” of their infrastructure: Chances are, the interoperability challenge has turned your edge into a mess (possibly one of epic proportions).

Why Are There So Many Different Industrial Protocols?

There are technical and business explanations for this myriad of industrial protocols.

One technical reason is that different protocols have different use cases. Determining your protocol use case is like asking yourself, “Do I need the minivan or the Camaro?” and then buying the car that best fits your criteria. For example, the Modbus protocol is very lightweight with generic read/write access, while the EtherNet/IP protocol is heavier, but has much more functionality. The protocol you use depends on what you need.

One business reason is that a vendor offers a faster, easier, and more feature-rich protocol than an off-the-shelf solution. Other business reasons are geographic (for example, DNP3 was created to North American standards), focus (for example, industries with a narrow focus may miss the opportunity to see if it’s already been done), or the thinking that “I can do it better” (for example, the attitude that all existing protocols are bad, so I might as well start from scratch).

Just like there will never be one universal language spoken worldwide, there will never be just one IoT protocol.

Solving the Interoperability Conundrum

Will it ever be possible to use just one protocol across the industry? The harsh reality is that there are many reasons why that is unlikely.

Legacy equipment needs, different suppliers, and the many requirements of different factories and people with different needs and skill levels will make any universal protocol impossible in the near future.

Guest blog by Sam Elsner of Kepware at the occassion of LiveWorx 2017 where he will be speaking - more below
Guest blog by Sam Elsner of Kepware at the occassion of LiveWorx 2017 where he will be speaking – more below

IoT Protocols and Interoperability

The IoT seems to be following in the same footsteps as industrial protocols. There are many IoT protocols in existence—including DDS, HTTP, OPC UA, JMS, WCF, CoAP, and more—developed due to many of the same reasons as noted above.

For example, DDS is perfect for streaming very high-frequency machine data across a local process control network, but it may not be appropriate to share DDS data streams with every level of the organization’s network.

In contrast, HTTP is perfect for sharing data within and across various networks (including the public Internet) but its overhead is typically considered too great to be appropriate for high-speed data exchange between automation devices on a process control network.

Just like there will never be one universal language spoken worldwide, there will never be just one IoT protocol. That’s why it’s vital to do your homework and use the right protocols for your products and specific technical requirements. Seek solutions that will give you flexibility, and iterate upon them. Take a few steps forward and then assess, “Does this strategy add value?” You’ll be well on your way to Industrial IoT success.

About the Author

Sam Elsner is an Applications Engineer Manager at Kepware, a software development business of PTC. He has held positions in information technology and industrial automation for over a decade. During his six years at Kepware, he has worked with thousands of customers to design edge communication solutions for automated systems. Sam graduated magna cum laude from the University of Maine with a bachelor’s degree in Anthropology and a minor in Business Administration.