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
May 24, 2024
Could these creepy crawly robo-critters be the first step on a slippery road to a robot uprising coupled with an insect uprising?...
May 23, 2024
We're investing in semiconductor workforce development programs in Latin America, including government and academic partnerships to foster engineering talent.The post Building the Semiconductor Workforce in Latin America appeared first on Chip Design....

featured video

Why Wiwynn Energy-Optimized Data Center IT Solutions Use Cadence Optimality Explorer

Sponsored by Cadence Design Systems

In the AI era, as the signal-data rate increases, the signal integrity challenges in server designs also increase. Wiwynn provides hyperscale data centers with innovative cloud IT infrastructure, bringing the best total cost of ownership (TCO), energy, and energy-itemized IT solutions from the cloud to the edge.

Learn more about how Wiwynn is developing a new methodology for PCB designs with Cadence’s Optimality Intelligent System Explorer and Clarity 3D Solver.

featured paper

Achieve Greater Design Flexibility and Reduce Costs with Chiplets

Sponsored by Keysight

Chiplets are a new way to build a system-on-chips (SoCs) to improve yields and reduce costs. It partitions the chip into discrete elements and connects them with a standardized interface, enabling designers to meet performance, efficiency, power, size, and cost challenges in the 5 / 6G, artificial intelligence (AI), and virtual reality (VR) era. This white paper will discuss the shift to chiplet adoption and Keysight EDA's implementation of the communication standard (UCIe) into the Keysight Advanced Design System (ADS).

Dive into the technical details – download now.

featured chalk talk

Shift Left with Calibre
In this episode of Chalk Talk, Amelia Dalton and David Abercrombie from Siemens investigate the details of Calibre’s shift-left strategy. They take a closer look at how the tools and techniques in this design tool suite can help reduce signoff iterations and time to tapeout while also increasing design quality.
Nov 27, 2023
24,164 views