Both OPC UA and DDS are important to the future of the Industrial Internet of Things (IIoT). While the technologies are essentially complementary, there is significant confusion in the market about how they relate to each other, causing unnecessary political noise and technical conflict. This document outlines both technology and market positioning for DDS and OPC UA. It serves as a basis for a common recommendation to the market by both the OMG DDS and OPC Foundation OPC UA communities.
Market and Application Positioning
The organizations agree that the two standards are largely complimentary and compatible. By communicating this, we want to eliminate market confusion and end-user anxiety, thus resulting in broader and faster market adoption of both standards. This is a win-win scenario for the market and both standards.
Market focus
Currently, OPC UA is widely deployed in automation for manufacturing, process control, and power. DDS key applications are in medical, transportation, power, and defense. Today, there is little overlap in application. Even when used in the same market (e.g. power) the use-cases are quite different. 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. As adoption grows, we expect both to find use in more common markets and in more common systems. However, we expect the difference in use case will remain.
In general, both technologies expect to retain their focus. There is no implication of exclusion; rather, this focus is a practical decision to ensure the technologies are well suited to their respective primary use cases. We are working together to span all industrial applications and use cases, while allowing immediate progress with current technology.
Technology philosophy
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. OPC UA allows SoA based easy “plug and produce” scenarios. The information about the system, its configuration, topology, and data context (the meta data) are exposed in the collective “address space” of the individual OPC UA servers. This data can be accessed by authorized OPC UA clients that can see what is available, and choose what to access. OPC UA truly supports timeless durability as new networking technology is developed it can be plugged into OPC UA seamlessly. Client/Server, Pub/Sub and cloud protocols are integrated into OPC UA.
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 simple yet powerful data-sharing abstraction that scales from local area networks to fog and cloud computing. It can support even large fan out and sub-millisecond latency. DDS defines a “common data-centric information model” so that applications can run “plug & play” with very little or no deployment configuration. System configuration details are deemphasized to ease redundancy and interoperability.
Examples:
As a rough example, in an automation system, a controller may have 500,000 variables internally. The OPC UA server could expose 5000 of these variables to be available for an HMI. The HMI can then select a subset of these variables. In parallel, the controller also offers 50 variables for MES and 100 for analytics in the cloud. OPC UA is optimized to expose and exchange data and information including live data, alarming and historical data. It lets clients browse data, whether simple or complex, and subscribe to servers with exception-based distribution. Device manufacturers like Robots, Smart Cameras, Smart Meters, RFID-Readers can model their functional information and behavior such that generic clients like an MES systems (e.g. SAP) can discover and orchestrate the services. Building an autonomous network of smart OPC UA enabled devices and applications results in highly flexible production with fully secured integration.
As a DDS example, consider a medical equipment manufacturer building many types of devices and applications that must cooperate in real time to monitor and control the care of thousands of patients from anywhere. Devices may include surgical robotics with fast feedback loops, shared video streams going to many different users, and interfaces to mobile (e.g. ambulance), fog, and cloud (e.g. analytics, records) systems. The DDS “global data space” provides a powerful integration environment that automatically finds the right data and sends each application exactly and only what it needs to operate, while enforcing per-stream delivery timing, reliability, redundancy control, and security.
DDS strives for data integration flexibility across many types of systems. It adapts well, for instance, to intelligent in-vehicle autonomous control systems that need to read sensors, assess the situation, and actuate control. It can connect edge to fog and cloud to monitor and control devices in a smart city. It can connect extensive networks of devices into locally-controlled smart power grids. It can manage thousands of tracks in a radar system, and connect multiple radars into an intelligent air-traffic control system.
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 IIoT strategy. Thus, by working together, the DDS and OPC UA communities provide a non-proprietary path to interoperability, regardless of the customer’s choice of starting technology.
Technology Combinations
We are already working together on integration. We are pursuing two ways for the technologies to work together:
- A “OPC UA/DDS gateway” specification that will permit independent implementations to work together more easily.
- A “OPC UA DDS Profile” for integrated use cases
OPC UA/DDS Gateway
Both organizations agreed on efforts to create a bi-directional bridge between OPC UA and DDS. This specification will map DDS to the client/server and lightweight OPC UA UDP pubsub paradigms. This will provide easy OPC UA/DDS inter-connectivity.
OPC UA UDP pubsub will be able to use the gateway executing as a separate process to allow unmodified OPC UA and DDS applications to interoperate. Also, the interoperability offered by the gateway will not be limited to pub-sub. It will extend to the other aspects of OPC UA, such as method invocation and address space browsing.
OPC UA DDS Profile
Experts in both OPC UA and DDS are working on a specification for an “OPC UA DDS pubsub” profile. The goal is to add “DDS” as an additional “communications model” to OPC UA.
DDS will preserve its character and its integrity to ensure interoperability with existing DDS applications. OPC UA would provide an “OPC UA” way to configure and use the DDS entities (i.e. expose them in the OPC UA Address Space). Those entities would appear as specializations of the base OPC UA publish subscribe information model and retain their configurability using the full DDS concepts and QoS.
A key goal is that applications built with the OPC UA DDS pubsub will communicate seamlessly with DDS-only applications. DDS will map or extend its type system to accept the OPC-UA types. The map may extend to the data model (types) the topics, QoS, etc. With this, the existing DDS mechanisms will continue to be able to record, visualize, route, and otherwise process messages with data that originate from an OPC UA Server that acts as a Publisher. In addition, data that originates from DDS applications will be consumable by OPC UA applications.
Usage FAQ
Where do I start?
When the OPC UA DDS pubsub profile and the OPC UA/DDS gateway are available, applications may in principle use either technology and then interoperate. So, your work done in one standard will be automatically leveraged by the other. You should feel comfortable starting with the one 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.
To be clear: we recommend that you start with OPC UA if your main challenge is out-of-the-box interoperability of semantic-rich data. Start with DDS to interoperate using a data bus or message bus functionality.
Should I use the OPC UA DDS pubsub profile, or just use DDS or OPC UA directly?
Use of the OPC UA DDS pubsub profile may be more complex than using DDS or OPC UA by itself. It makes sense to use if visibility and accessibility of the OPC UA information and its semantic combined with DDS pubsub is desired.
For applications that have mainly a data-sharing or system integration requirement, we recommend starting with the DDS API.
For applications that want to provide services and semantics for other applications we recommend starting with OPC UA.
The OPC UA DDS pubsub model including the DDS profile is not yet available. Applications that want a combination of OPC UA and DDS can either start with OPC UA or DDS depending on their most urgent needs. The upgrade in either direction will be relatively easy with the OPC UA/DDS gateway or OPC UA DDS profile.
If I’m using OPC UA pubsub, which profile should I use?
The OPC UA UDP profile is a very simple and lightweight protocol option. It should be used by applications that need efficient multicast best efforts without filtering.
The OPC UA AMQP profile is designed to connect a substantial number of devices directly to IT cloud systems.
The OPC UA DDS profile adds much more capable pubsub functionality, such as guaranteed reliability, large-data fragmentation, caching, content and time filtering, etc., at the expense of additional complexity and code size. Use OPC UA DDS if you need more than the simple functionality of OPC UA UDP profile.
