feature article
Subscribe Now

Collaboration Between OPC UA and DDS

How Are These Protocols Different? How Are They Similar?

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

8 thoughts on “Collaboration Between OPC UA and DDS”

  1. Pingback: In Vitro ADME
  2. Pingback: hash thuisbezorgd
  3. Pingback: additional reading
  4. Pingback: Coehumanl

Leave a Reply

featured blogs
Mar 28, 2024
'Move fast and break things,' a motto coined by Mark Zuckerberg, captures the ethos of Silicon Valley where creative disruption remakes the world through the invention of new technologies. From social media to autonomous cars, to generative AI, the disruptions have reverberat...
Mar 26, 2024
Learn how GPU acceleration impacts digital chip design implementation, expanding beyond chip simulation to fulfill compute demands of the RTL-to-GDSII process.The post Can GPUs Accelerate Digital Design Implementation? appeared first on Chip Design....
Mar 21, 2024
The awesome thing about these machines is that you are limited only by your imagination, and I've got a GREAT imagination....

featured video

We are Altera. We are for the innovators.

Sponsored by Intel

Today we embark on an exciting journey as we transition to Altera, an Intel Company. In a world of endless opportunities and challenges, we are here to provide the flexibility needed by our ecosystem of customers and partners to pioneer and accelerate innovation. As we leap into the future, we are committed to providing easy-to-design and deploy leadership programmable solutions to innovators to unlock extraordinary possibilities for everyone on the planet.

To learn more about Altera visit: http://intel.com/altera

featured chalk talk

Industrial Internet of Things (IIoT)
Sponsored by Mouser Electronics and Eaton
In this episode of Chalk Talk, Amelia Dalton and Mohammad Mohiuddin from Eaton explore the components, communication protocols, and sensing solutions needed for today’s growing IIoT infrastructure. They take a closer look at how Eaton's circuit protection solutions, magnetics, capacitors and terminal blocks can help you ensure the success of your next industrial internet of things design.
Jun 14, 2023
32,945 views