Some time back, we addressed the many standards and would-be standards and proprietary formats populating the IoT space. Because there are so many, it’s easy, when faced with two arbitrary protocols, to assume either that they compete or that they are orthogonal. But, as it turns out, they may do what appears, on the surface, to be the same thing, but with application-based differences that make them neither competitive nor orthogonal, but complementary.

I waded into this when the Open Platform Communications (OPC) Foundation and the Object Management Group (OMG) announced a collaboration project establishing cooperation between the OPC Foundation’s Unified Architecture (OPC UA) and OMG’s Data Distribution Service (DDS).

In their announcement, they described general characteristics that suited each protocol, and then they described the different industries to which they applied.

• “OPC UA provides client-server interaction between components such as devices or applications. DDS is a data-centric ‘bus’ for integration and peer-to-peer data distribution.” To my ear, it wasn’t clear that those two characteristics obviously applied to different applications; it seemed easy to imagine that many apps would need both, or that they might simply be different solutions to the same problem.
• “Currently, OPC UA is widely deployed in automation for manufacturing, process control, and power. DDS key applications are in medical, transportation, power, and defense.” First, it surprised me that DDS wasn’t used so much in industrial; we’ll come back to that. But there also wasn’t a clear motivation as to why each industry had its preference. It’s not uncommon for industry dominance to be due not so much to technical differences, but rather to coincidences of marketing and sales focus, so I had a hard time figuring out what fundamental technical characteristic made this anything other than dividing up markets.

So I was able to have a conversation with Thomas Burke, President and Executive Director of the OPC Foundation, on the OPC UA side, and Stan Schneider, CEO of RTI, a big DDS player, on the DDS side. And as I posed my general questions, one thing jumped out immediately due to my unfortunate phrasing of the industry-dividing question.

They were very clear that there was no dividing going on. Why would they be so resolute on that point? Because dividing up markets is a clear violation of anti-trust law. I wasn’t actually suggesting illegal activity, but a phrase like “dividing up industries” is going to trigger a very defensive reaction because, well, in that direction there be dragons.

So with that out of the way, we continued to discuss the characteristics that established an application as well suited for OPC UA or for DDS. What was interesting was that I was seeing the distinctions as rather subtle, while, to them, the differences are “vast” – and finding a way of articulating that gulf has turned out to be difficult.

Before teasing out these distinctions, let’s be really clear about one thing: the confusion here is not about whether OPC UA and DDS are similar or different. In fact, in some regards, they couldn’t be more different.

• OPC UA is a networking protocol (largely client-server, although adopting a pub/sub model as well). It is aware of the network topology and has an “address space” that supports a plug-and-play environment. It manages the data glut through aggregation and abstraction.
• DDS, by contrast, is a data model. Unlike OPC UA, which exposes the network, DDS hides the network, making device types and topology transparent. In other words, you get the data without having to deal with how the data got there. It manages the data glut through filtering.

Those are very different characteristics, and yet I could still envision them addressing the same applications, only with very different philosophies. Kind of like CoAP vs. MQTT, where one uses a RESTful approach, with internet-style programming, while the other acts more like an embedded protocol programmed in C/C++.

It’s worth spending a moment on the “data glut” thing. Both systems take as input data from sensors or other inputs. And there’s lots of data. So if you’re trying to learn something from that data, you need a way to manage the overload. The focus with OPC UA is to turn lower-level data “into information,” a somewhat cloudy distinction that generally means raising the level of abstraction and taking us away from the level of the lowly data point.

But with DDS, you may well be interested in low-level data points, but select ones. So filtering – much as is done with a database query – is how those data riches are managed. Presumably aggregation and abstraction are possible too, but they simply become part of the data model, in the same manner that database tables can handle aggregation and calculations.

Different approaches vs. different applications

Given that these protocols look so different but seem to provide similar capabilities, this is where our conversation dove a layer deeper to tease out critical distinctions. Let’s start with OPC UA. There seem to be two key characteristics here. One is that it’s for non-time-critical applications. This gets a little confusing, since the release itself describes OPC UA as for “…platform independent, high performance, secure, reliable, and semantic interoperability between sensors, field devices, controllers, and applications at the shop-floor level in real-time as well as between the shop floor and the enterprise IT cloud.” [Emphasis mine.] We’ll come back to the real-time thing in a sec. But both gentlemen with whom I spoke agreed on the non-time-criticality aspect.

The other way of looking at OPC UA is that its prime purpose is not so much to support the close interworking of the equipment within the network, but rather to expose the data that those devices generate for use in other applications. So it’s a picture of a relatively static configuration with data flowing up and out for use by app programmers.

DDS, on the other hand, is for applications requiring short-loop, real-time, reliable, distributed exchange of data. In this case, the data may well be used within the network to help operate the network. It applies to setups having a complex data model and a dynamic network that supplies and consumes the data. The key words here are “complex” and “dynamic.”

In a hospital setting, for instance, devices are moving from room to room. At one moment their data may be associated with Wally Pike; ten minutes later, that same machine may be pumping out data related to Crystal Glass. But users of the data can simply focus on Wally’s or Crystal’s data without having to worry about which device the data came from.

Other applications that they list for DDS – transportation, including automotive and fleet management, power, and defense – also have this dynamic character, in contrast to the more static configurations managed by OPC UA.

As an example of where the two protocols can work together in the same application, that same hospital where DDS is managing the operational data may also employ OPC UA for equipment diagnostics, calibration, and maintenance.

Let’s come back now to the real-time question, since that was at the root at some of my confusion. Given DDS’s focus on short-loop, real-time data production and consumption, it sounds like a perfect candidate for use in an industrial setting, where data can be used for control feedback. And yet OPC UA, not DDS, dominates in this area. Why would that be?

There are two bits of nuance that explain this. First, OPC UA isn’t being used in the control feedback loops for pieces of equipment. Instead, it’s used more for sharing non-time-critical information for use in staging materials and other higher-level coordination efforts.

So why wouldn’t it coexist with DDS for the feedback loops? Well, that’s because industrial folks have been doing control since long before the IoT – or even M2M. Programmable logic controllers (PLCs) have handled that role for as long as I’ve been in the business. You could argue that, if you were starting a manufacturing floor completely from scratch, DDS might have a home there. But given the prevalence of PLCs that are working and have been working for years, DDS is not about to come in and replace them.

In other words, there’s an incumbent technology that handles what would be natural for DDS, and it’s not viewed as being up for replacement by DDS. One of those, “If it ain’t broke…” things.

So there you go. It still takes, to my mind, a lot of words to articulate this. Short, pithy descriptions, like “DDS is about data, OPC UA is about information” just don’t quite hack it, because, well, one person’s data may be another person’s information. Dayta/tomayta/tomahta. Kind of.

The collaboration noted in the announcement will establish a bridge between the two protocols so that a single app can address data or information available in either one via only one side. Rather than having to write programs using two setups that may appear to be completely unaware of each other, data will be able to flow from one into the other.

More info:

DDS

OPC UA