The Plague of Confusion in the Industrial IoT

The Industrial Internet of Things (IIoT) is the most important technical revolution of our lifetime. But the IIoT is sick.

Why do I say that? The coming importance is obvious. Today, hospitals, factories, transportation hubs and power plants run essentially the same way they did 25 years ago. But, by combining exploding processor capabilities with easy networking, the Industrial IoT will bring intelligence to nearly every industry on the planet. Analysts estimate that its economic impact will be larger than the Internet, mobile phones and apps, and the cloud. Combined.

The disease plaguing the IIoT isn't so obvious. The disease is confusion.

A half-dozen "connectivity standards" make similar-sounding claims despite vastly different capabilities. There are over 400 "IoT platforms" that sound the same but nonetheless do not compete. "Analytics" range from mathematical algorithms that monitor one data stream to predict part failures to Big Data optimizers for entire plants. And while we're at it, what’s "real time"? What does "security" really mean? Even common terms like "edge" have many meanings to different people. Nearly every term has multiple definitions.

Of course, confusion always reigns in a new market. But it's worse when the stakes are high. And the stakes have never been higher. These industrial systems require huge investment. It takes many years to design an autonomous car, a new renewable-capable power grid or an entire new healthcare architecture. Setting off in the wrong direction can ruin companies. The only thing worse is waiting, because delay will almost certainly ruin companies. The result? Paralysis. And this dysfunction is so widespread that it's not at all unfair to call it a plague.

Let’s take one example: what's a "software architecture"? That’s not always obvious. For instance, two of the most important connectivity standards in the Industrial IoT are OPC UA and DDS. Their proponents call them "software architectures." But they mean completely different things.

There really are few similarities. OPC UA is pervasive in manufacturing. DDS runs power plants, autonomous cars, medical systems, hyperloop, air traffic control, ships, defense, wind turbines, intelligent robotics, particle accelerators, mining systems, oil drilling, even fish farms…but DDS is not used in manufacturing. The lack of overlap is striking.

The application area is just one difference. Many products support OPC UA, including dozens of types of hardware devices and software like HMIs and historians; no products support DDS. They are opposites. OPC UA is object-oriented; DDS is data-centric. Opposites. The OPC UA data model is hierarchical; the DDS data model is relational. Opposites. Most DDS users are software engineers; essentially no OPC UA users are software engineers. Opposites. The only thing they do in common is send bytes around. But other than that, these technologies have nothing in common. They are, well, opposites.

This is not because of marketing positioning or historic origins. This is because the markets are fundamentally different, and value propositions must match the market needs. Technicians and industrial engineers build manufacturing workcells by combining components. OPC UA excels at that. Teams of software engineers build Intelligent edge systems. DDS is great for that. The value propositions are, like everything else, complete opposites. So, OPC UA is in manufacturing because there is little custom software. DDS is not in manufacturing because there are no software engineers in manufacturing. OPC UA and DDS simply do not compete with each other, because the industries have very dissimilar needs and people.

Nonetheless, even practitioners in the field often don’t understand this, for the simple reason that they only see their own narrow slice of the universe. For OPC UA, a "software architecture" is a technology for integrating products, both hardware and software, with little custom software. For DDS, a "software architecture" is a technology that supports custom software development. Opposites. Without a wider view, communications are communications, it seems they do the same thing, and the plague of confusion spreads.

Fortunately, there is a cure for this disease. Confusion is a disease of isolation. The best antidote is interaction.

Consortia can make a difference. RTI is a member of 16 different efforts, and very active in about 10. I’m honored to be the Vice Chair of the IIC*, the largest of them all. Other RTI personnel sit on the board, chair the DDS group and OPC UA gateway at the OMG, chair the Communications Working Group at OpenFog, drive the DDS effort at AUTOSAR (automotive), and contribute extensively to FACE (avionics), ROS (robotics), ARM (robotics), MDPnP (medical), SEPA (power), and more. Through all of these efforts, we strive to resolve confusion.

Many of these consortia have made great progress with initial designs, and those designs show the results of interaction. The IIC, for instance, publishes vocabulary, and reference architecture, as well as connectivity, security, analytics and business process frameworks. OPAF is applying the relatively mature FACE architecture for avionics to process control. ROS and AUTOSAR now have bindings to DDS. The OMG has a standard gateway for connecting OPC UA to DDS. These efforts show the power of respect for other technologies.

These ongoing efforts to increase interaction across technology boundaries improve clarity. Results of the interactions help users differentiate and select the technology that fits best. So, the heat of confusion in the industry is dropping. Perhaps the fever is nearly ready to break.

P.S: For more information, I summarized some of the results of the industry consortia in my recent eBook. For practical guidance on selecting the right connectivity technology for your application, tune into the upcoming webinar: The Rise of the Robot Overlords: Clarifying the Industrial IoT. Part 2: How to Choose the Right Connectivity Technology.

* To avoid breaking up the flow of the text, here are the Acronyms in this blog: