Success-Plan Services
Fernando Garcia
One of the most important challenges that system designers and system integrators face when deploying complex Industrial Internet of Things (IoT) systems is the integration of different connectivity solutions and standards.
At RTI, we are constantly working to accelerate the Industrial IoT revolution. Over the past few years we have developed standard connectivity gateways to ensure that DDS systems can easily integrate with other core connectivity frameworks. This year, we have been working on a standard OPC UA/DDS Gateway, a bridge between two of the most well-known Industrial IoT communication frameworks. We are excited to announce that this gateway was just adopted by the Object Management Group (OMG).
OPC UA/DDS Gateway Specification
Last year the OMG and the OPC Foundation announced a collaborative strategy for the DDS and OPC UA Connectivity Standards. Following that announcement, the OMG issued a Request for Proposals (RFP) for the definition of a standard OPC UA/DDS Gateway to enable transparent interoperability between DDS and OPC UA applications.
We took on the challenge and put together a 140-page proposal with input from DDS and OPC UA users and vendors, which was voted on and adopted at the March OMG Technical Meeting. This blog post provides an overview of the new specification and describes the prototypes that we have developed to validate the new standard.
Specification Overview
The goal of the OPC UA/DDS Gateway specification is to enable DDS and OPC UA applications to interoperate transparently using the native mechanisms of each specific framework. In practice, this implies solving two separate problems:
- Building an OPC UA to DDS Bridge to enable DDS applications to operate in the AddressSpace of an OPC UA Server using standard DDS data-centric publish-subscribe capabilities and the RPC over DDS mechanisms.
- Building a DDS to OPC UA Bridge to enable OPC UA Client applications to participate as first-class citizens in the DDS Global Data Space using standard OPC UA Services.
OPC UA to DDS Bridge
The OPC UA to DDS Bridge enables DDS applications to read, write and subscribe to information in the AddressSpace of an OPC UA Server. This side of the Gateway fulfils some of the use cases for which we have seen a need in the community. For example, it makes it possible to integrate OPC UA-enabled devices into larger systems of systems that require the scalability and QoS capabilities of DDS. Figure 2 illustrates these kind of deployments where a couple of DDS applications subscribe using the DDS-RTPS wire protocol to information provided by two OPC UA Servers that use the OPC UA Binary Protocol.
The behavior of the OPC UA to DDS Bridge is quite simple. On one side, the Gateway instantiates an OPC UA Client capable of connecting to a Server and performing a set of actions using OPC UA Services (e.g., using the Attribute Service Set to Read and Write, and using the Subscription and MonitoredItems Service Sets to subscribe to data changes and events). On the other side, the Gateway instantiates a set of DataReaders and DataWriters capable of handling the required interactions with the DDS side.
The specification divides the information that is exposed to DDS applications into two categories:
- Service Set Mappings - provides DDS Services equivalent to most of the standard OPC UA Services using the mechanisms defined in the OMG RPC over DDS specification. These mappings make it possible for DDS requesters to invoke services, such as Read or Write to perform the equivalent OPC UA Service operations or to invoke the Browse Service to navigate the AddressSpace of the server.
- Subscription Model Mapping - provides DDS applications with a simplified mapping of the OPC UA Server. This mapping allows system integrators to combine MonitoredItems for one or multiple subscriptions into DDS Topics, providing a powerful way to model how the information is transmitted and consumed by DDS applications.
To facilitate the labor of system integrators, we have defined an XML syntax to configure the OPC UA to DDS Bridge. The snippet below shows a simple OPC UA/DDS Gateway configuration file.
<dds>
<types>
<struct>...</struct>
</types>
<ddsopcua_gateway name="MyGateway">
<opcua_connection>...</opcua_connection>
<domain_participant>...</domain_participant>
<opcua_to_dds_bridge>
<service_set>...</service_set>
<subscription>
<opcua_input>...</opcua_input>
<dds_output>...</dds_output>
<dds_output>...</dds_output>
<dds_output>...</dds_output>
<mapping>...</mapping>
</subscription>
</opcua_to_dds_bridge>
</ddsopcua_gateway>
</dds>
The configuration file is organized as follows:
- It defines the DDS types that describe the DDS Topics that will be created as a result of the mappings specified in the configuration file. These can be used across OPC UA/DDS Gateway configurations, which may be deployed in different processes or machines.
- It defines a Gateway instance that instantiates an OPC UA to DDS Bridge (it could also contain a DDS to OPC UA Bridge). On one side, this bridge uses an OPC UA Connection (which instantiates an OPC UA Client to connect to a Server), and a DomainParticipant on the other side (which handles the creation of DDS entities).
- It configures the Service Sets that we want to expose to DDS applications (e.g., the Attribute Service Set to enable one-shot reads or writes of information in the AddressSpace of the OPC UA Server).
- It configures a set of OPC UA Inputs (i.e., Subscriptions to OPC UA MonitoredItems) and DDS Outputs (Publication of DDS Topics). Inputs and Outputs can be combined so that the MonitoredItems specified in an Input can be assigned to a field of one or more DDS Outputs. This process is handled by the assignments within the Mapping section.
DDS to OPC UA Bridge
The DDS to OPC UA Bridge enables OPC UA Client applications to participate as first-class citizens in the DDS Global Data Space. This side of the Gateway also fulfils the rest of the use cases that we have discussed with DDS and OPC UA Users. For example, it makes it possible for existing OPC UA Clients and tools to browse the Topics and Instances that DDS applications are exchanging in different DDS Domains, and even to configure tailored subscriptions to members of those Topics. Figure 3 illustrates these kinds of deployments, where OPC UA Client applications access – using the OPC UA Binary Protocol – information that DDS applications provide using their native DDS-RTPS wire protocol.
In a nutshell, the DDS to OPC UA Bridge defines an OPC UA information model to represent the DDS Global Data Space. That is, it defines a set of Objects and Variable Nodes to represent DDS Domains, Topics, Instances and DataTypes. We deploy this information model in an OPC UA Server embedded into the Gateway. This Server provides all of the standard mechanisms to enable Clients to browse the information in the DDS Global Data Space and read, write or subscribe to information using the appropriate OPC UA Service Set.
In the specification, we have also defined XML syntax to configure the DDS to OPC UA Bridge, which allows system integrators to decide which parts of the DDS Global Data Space are represented in the AddressSpace of the OPC UA Server and therefore exposed to OPC UA Clients. The snippet below shows a simple OPC UA/DDS Gateway configuration file.
<dds>
<types>
<struct>...</struct>
</types>
<ddsopcua_gateway name="MyOtherGateway">
<opcua_server>...</opcua_server>
<domain_participant>...</domain_participant>
<domain_participant>...</domain_participant>
<dds_to_opcua_bridge>
<domain>
<topic_group>...</topic_group>
<topic>...</topic>
</domain>
<domain>
<topic_group>...</topic_group>
</domain>
</dds_to_opcua_bridge>
</ddsopcua_gateway>
</dds>
The configuration file is organized as follows:
- In the case of the OPC UA to DDS Bridge, it defines the DDS Data Types that will be instantiated by the OPC UA/DDS Gateway configuration.
- It defines an OPC UA Gateway instance that instantiates the DDS to OPC UA Bridge. In this case, the bridge uses an OPC UA Server, which is configured above, and a set of DDS DomainParticipants to access the DDS Global Data Space.
- It configures the DDS Domains that will be represented in the AddressSpace of the OPC UA Server.
- It configures the DDS Topics that will be represented in the AddressSpace of the OPC UA Server. Topics can be either explicitly selected or chosen via Topic Groups, which provide syntax to specify regular expressions on the Topic name, type name, etc.
Prototypes and Demos
To develop the specification, test the feasibility of our solution, and gather feedback from users and vendors, we have developed a number of prototypes and demos that we have shown at different conferences and trade shows.
Last year, we presented our first prototype at Embedded World and Hannover Messe. We built our prototype on RTI Routing Service, one of the best known RTI services, which provides a pluggable API to build adapters to bridge different connectivity technologies. We focused on the mapping of the OPC UA Subscription Model to DDS and the configuration mechanisms to enable that mapping.
This year, we will be demoing the other side of the Gateway at Hannover Messe. We will present a simple prototype of the OPC UA/DDS Gateway that is capable of exposing information in the DDS Global Data Space through an embedded OPC UA Server. We will show that it is possible for a generic OPC UA Client application to subscribe to information in the DDS Global Data Space by simply using native OPC UA Services.
If you are attending Hannover Messe, stop by our booth in the IIC pavilion (Hall 8 #C24) to see the live demo! If you can’t make it, we will be posting more details about the new demos soon, so stay tuned!
OPC UA/DDS Gateway as a Core Connectivity Gateway
To conclude, we want to emphasize the importance of the OPC UA/DDS Gateway in the context of the Industrial IoT revolution.
Last year, the Industrial Internet Consortium released the Industrial Internet Connectivity Framework (IICF), a reference architecture that defines a set of criteria for evaluating connectivity technologies and introduces a novel approach to solve the Industrial IoT connectivity challenge.
As we explained in a previous blog post, the IICF introduces the concept of core connectivity standards that are chosen as a baseline for specific functional domains, which pose domain-specific technical requirements and tradeoffs. To evaluate these standards, the IICF defines an assessment template for connectivity solutions according to well-defined criteria in terms of business (e.g., purpose, maturity or stability), usage (e.g., architecture, security or safety), functionality (e.g., data modeling, communication patterns or APIs, QoS capabilities), and implementation (e.g., performance or scalability considerations). Based on these criteria, the IICF identified and recommended four core connectivity standards: DDS, OPC UA, HTTP/Web Services and oneM2M.
Choosing a baseline core connectivity standard for a specific functional domain simplifies the Industrial IoT connectivity challenge, as legacy systems and other connectivity technologies can be integrated into broader systems through domain-specific gateways. However, complex Industrial IoT systems often span across functional domains and require the integration of different core connectivity frameworks. To address this issue, the IICF introduces the concept of core connectivity gateways (see Figure 4). Core connectivity gateways must be based on standards and preserve the syntactic structure of data to ensure transparent interoperability.
RTI is fully invested in the development of standard connectivity gateways. This year we have focused on the OPC UA/DDS Gateway to build a bridge between two of the most well-known communication frameworks of the Industrial IoT. In RTI Connext DDS 5.3.0 we introduced the first General Access Release of RTI Web Integration Service: the first standard connectivity gateway. This new service, based on the OMG Web-Enabled DDS specification, allows web applications running on a browser to participate as first-class citizens in the DDS Global Data Space.
We believe that interoperability is key to the success of the Industrial IoT, and will keep working to help companies realize the Industrial Internet revolution.