Real-Time Innovations (RTI) has been at the forefront of data-distribution-services (DDS) technologies. It’s a technology that can be used with the OPC Unified Architecture (UA) and time-sensitive networking (TSN) to deliver robust embedded systems, but the combination is relatively new.
I spoke with Brett Murphy, Senior Director of Business Development for the Industrial Internet of Things (IIoT) at RTI, and Costantino Pipero, Founder and Chief Technology Officer at Beeond, about these technologies.
Brett Murphy, Senior Director of Business Development for the IIoT, RTI
Costantino Pipero, Founder and CTO Beeond
Can you summarize the new architecture approach that you (RTI and Beeond) are proposing in regard to DDS, OPC UA, and TSN?
OPC UA is the prevalent technology in industrial automation for moving data and information from field devices to back-end applications. It offers a “client-server” model for applications (typically clients) to interact with a complex system (implemented as a set of servers). Importantly, it also allows introspection and control of the overall system through the OPC UA “Information Model” (IM).
DDS is a connectivity framework standard widely deployed across multiple industries under the IIoT umbrella. Fundamentally, DDS provides a publish-subscribe databus, an integration framework, for software applications. It serves as both a control bus and edge-to-cloud connectivity framework.
Beeond and RTI believe they can bring the best of both DDS and OPC UA together, combining OPC UA’s client-server model and domain information models with DDS’s proven, scalable publish-subscribe. We have captured the concept of a Converged SDK in a joint white paper. The converged solution can scale to thousands of nodes, eliminate dependence on servers, provide flexible physical-layer implementation (WAN, LAN, Multicast, TSN), and enable fine-grained security. With this design, both client-server and pub-sub will be based on years of field-proven technologies and standards with industry-leading capabilities.
What brought on the need for this type of solution?
Integration is a big challenge in large, industrial systems. In the past, industrial system integration focused on devices, networks and other hardware—the physical layer. Software was configured and contained within specific devices for the most part.
With the advent of the IIoT with its ubiquitous network connectivity and virtualization provided by edge/fog computing, the system integration challenge has moved up the technology stack to the software that runs on the physical layer. The functionality of the system is now defined by both the physical layer and the software above, but the system value and the integration challenge has shifted to the software.
OPC UA grew up in a world where the primary challenge was to integrate devices and hardware, and it does this well. A software application is contained within a single device, and the systems are smaller in scale (a manufacturing workcell) than what’s needed in the edge-to-cloud IIoT systems now entering deployment. DDS grew up in complex, software-centric systems. Applications are larger than a single compute node and have to be integrated via data-flow and service calls. Together they can uniquely streamline the integration challenge of upcoming industrial systems.
In brief, what’s the proposed architecture?
Beeond and RTI believe they can bring the best of both DDS and OPC UA together, combining OPC UA’s client-server model and domain information models with DDS’s proven, scalable publish-subscribe. We have captured the concept of a Converged SDK in a joint white paper (see figure). The converged solution can scale to thousands of nodes, eliminate dependence on servers, provide flexible physical-layer implementation, and enable fine-grained security.
A Converged SDK: On the left is the current client-server and publish-subscribe stack for OPC-UA. On the right is a proposal to integrate DDS as the publish-subscribe stack for a Converged SDK solution. (Source: RTI)
The OPC UA object-oriented model is merged with the DDS data-centric, publish-subscribe model. With this design, both client-server and pub-sub will be based on years of field-proven technologies and standards with industry-leading capabilities.
Why replace the new OPC UA publish-subscribe?
OPC UA pub-sub may address some use cases, so we aren't advocating "replacing" it everywhere. However, the pub-sub standard is designed mostly to connect workcell devices on local networks. It’s not designed to support extensive software development.
As systems become more intelligent, software will become more important in the final integration. DDS is designed for such use cases. The proposed design combines the familiar OPC UA client-server capability, the OPC UA information model, the proven DDS databus, and TSN's real-time networking.
What role will TSN play in this approach?
For deterministic data flow needs at the “edge” of industrial systems, the emerging TSN standard holds great promise. Replacing the myriad motion-control and safety system bus standards with a single, widely adopted TSN-based standard would open up the ecosystem for vendors and system integrators.
There’s still much work to be done, though. System-level configurations interfaces are still undefined, OS network stack mappings to the TSN Layer 2 standard need to defined, and TSN endpoint configuration interfaces to the system-level configuration tools are in their infancy. The DDS standards body (OMG) is defining a mapping of the DDS configuration model (QoS) to TSN. Initial implementations exist now, and customer proofs-of-concept are underway. DDS can be a publish-subscribe standard that spans deterministic, TSN-based edge networks back to the control centers and cloud instances.
What are your next steps with this proposed architecture?
Beeond and RTI developed the concept and high-level design for this Converged SDK architecture, and now we’re floating the concept as a white paper. We want other industry participants to join us in fleshing out the next level of detail to address specific use cases. We want to make sure the result works well. We imagine initial implementations would be a joint effort, and plan for the resulting design to be an open standard.