Eliminating Indecision About the Internet of Things

If you’ve been seriously exploring an Internet of Things (IoT) initiative for some aspect of your operations, you’ve encountered OPC UA (Unified Architecture) and DDS (Data Distribution Service). These two data communication technologies appear, at first glance, to accomplish many of the same tasks, which has led to quite a bit of concern and confusion in an industry weary from the fieldbus and Ethernet protocol wars.

The OPC UA and DDS technologies seemed to be yet another instance of competing approaches that would force users to choose one approach over another. For most users, the uncertainty about which one will eventually become the preferred industry standard causes them to sit on the sidelines to see which prevails—which can be a dangerous business strategy considering the speed at which the Internet of Things is changing business.

In an effort to remove this decision hurdle for industrial companies, the OPC Foundation (which supports OPC UA) and the Object Management Group (which supports DDS) have announced an agreement to develop an “OPC UA/DDS gateway” specification that will permit independent implementations of each technology to work together more easily, as well as an “OPC UA DDS profile” for integrated use cases.

Before explaining the OPC UA/DDS gateway and OPC UA DDS profile, it’s important to understand that both standards are already “largely complimentary and compatible,” according to OPC Foundation and Object Management Group (OMG)—meaning that much of the concern about selecting one technology over another is more hype than reality.

Perhaps the simplest way to understand the different approaches of both technologies—and why they are best viewed as “complimentary and compatible”—is to review their philosophies.

According to OPC Foundation, “OPC UA is an industrial communication architecture 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. Information about a system, its configuration, topology and data context (meta data) are exposed in the collective ‘address space’ of the individual OPC UA servers. Data can be accessed by authorized OPC UA clients that can see what is available and then choose what to access. Client/server, pub-sub and cloud protocols are integrated into OPC UA.”

OMG explains that DDS “provides location transparent, interoperable, secure, platform independent, real-time data sharing across any kind of network. DDS lets applications define and share user data with controlled Quality of Service (QoS), such as performance, scalability, reliability, durability and security. DDS hides network topology and connectivity details from the application, providing a data-sharing abstraction that scales from local area networks to fog and cloud computing. DDS defines a common data-centric information model so that applications can run plug and play with very little or no deployment configuration.”

Further differentiating the two are their applications. OPC UA is widely deployed for automation applications in manufacturing, process control, and power industries. DDS applications are used largely in medical, transportation, power and defense. As a result, outside of the power industry, there is little overlap in their applications—but even within the power industry their applications differ based on use.

As stated by OPC Foundation and OMG, “Because the focal applications and approaches for DDS and OPC UA are, in fact, quite different, most applications clearly fit better with one or the other. But, customers must choose a standard path now to implement a successful Industrial Internet of Things (IIoT) strategy.” This reality, coupled with a desire to not handicap industry’s progress around the IIoT, is why the DDS and OPC UA communities are working together to “provide a non-proprietary path to interoperability, regardless of the customer's choice of starting technology.”

Work by OMG and OPC Foundation on the OPC UA/DDS gateway is focused on developing a specification that will map DDS to the client/server and OPC UA UDP pub-sub paradigms to provide OPC UA/DDS interconnectivity. Using this specification, OPC UA UDP pub-sub will be able to use the gateway executing as a separate process to allow unmodified OPC UA and DDS applications to interoperate.

As for the OPC UA DDS profile also being developed by the two organizations, the goal is to add DDS as an additional communications model to OPC UA. In this way, DDS will “preserve its character and its integrity to ensure interoperability with existing DDS applications,” says OMG. Also, OPC UA will provide a way to configure and use the DDS entities (i.e., expose them in the OPC UA address space). Those entities will appear as specializations of the base OPC UA pub-sub information model and retain their configurability using the full DDS concepts and QoS.

For companies currently planning IIoT applications, the OPC Foundation and OMG recommend starting with OPC UA if your main challenge is out-of-the-box interoperability of semantic-rich data. If your challenge is creating interoperability using a data bus or message bus functionality, start with DDS.

The bottom line, as stated by OPC Foundation and OMG, is: “You should feel comfortable starting with the technology that makes the most sense to your application. You can then eventually use the other as need arises. In either case, our intent is to preserve your investment."