DDS & TSN to Develop Single Hardware Solution for Real-Time Data | RTI

The Industrial Internet of Things (IIoT) works by leveraging real-time data from multiple sources to create smarter applications and systems. This requires syntactic interoperability – the ability to exchange structured data in a discoverable and unambiguous manner. It is a minimum requirement of the connectivity infrastructure for building IIoT components and systems. 

The Industrial IoT Connectivity Framework (IICF) by the Industrial Internet Consortium defines an IIoT connectivity stack and assigns the “Framework Layer” with the responsibility of providing syntactic interoperability for data exchange to the applications above, while hiding away the details of the underlying transports and networks (Figure 1). The framework layer is typically implemented in software, while the lowest layers are implemented in hardware.

Such an approach makes it easy for IIoT application and component developers to focus on defining and using structured data models, quality of service (QoS) for governing the data exchange, and security policies around data-objects, without having to worry about lower level details. Thus, using a connectivity framework reduces integration cost and time to market.

^{Figure 1. The IIC IIoT Connectivity Stack}

The need for a standardized connectivity framework layer is fairly well established in the operational technology (OT) space since the applications and components are typically built by an ecosystem of suppliers that all need to work together while meeting critical performance requirements. However, it is still a relatively new concept in the information technology (IT) space, where developers are used to building ad-hoc, application-specific data exchange layers in software, favoring familiarity over performance. The IICF identifies several IIoT software connectivity framework standards. Using a standardized software connectivity framework allows vertical industry communities to develop common shared data model repositories that further accelerate markets. 

For software integration and autonomy, the IICF identifies the Object Management Group® (OMG) Data Distribution Service (DDS) as a connectivity core standard. DDS is actually a family of software specifications that define a software databus for real-time systems, where latency, jitter, throughput, scalability and availability of data flows is critical. DDS supports not only time-sensitive OT communications requirements, but also IT communications needs; and thus, it is an ideal choice for building next-generation IIoT systems. In fact, adoption of DDS in IIoT applications and use cases continues to grow. Vertical market-focused software standards are emerging on top of DDS in automotive (with AUTOSAR Adaptive), robotics (with ROS2), smart grid (with OpenFMB), avionics (with FACE), medical (with OpenICE), military vehicles (with GVA), and so on.

For time-sensitive applications, hardware innovation continues below the network layer of the connectivity stack (Figure 1). Recently IEEE Time Sensitive Networking (TSN) standards have emerged to provide guaranteed packet transport with bounded low latency, low packet delay variation and low packet loss. TSN is a family of hardware specifications that are used together in a coordinated fashion. The basic components of TSN (Figure 2) include

1. Time synchronization: All devices that are participating in real-time communication have a common, synchronized understanding of time.
2. Scheduling and traffic shaping: All devices that are participating in real-time communication adhere to the same rules in processing and forwarding communication packets.
3. Selection of communication paths, path reservations and fault-tolerance: All devices that are participating in real-time communication adhere to the same rules in selecting communication paths and in reserving bandwidth and time slots, possibly utilizing more than one simultaneous path to achieve fault-tolerance.

^{Figure 2. Scheduled Real-Time Data Flows: DDS Topics Naturally Map to TSN Streams}

There has been a growing interest in IIoT communities – specifically in the industrial controls and automotive verticals – to leverage TSN. The Avnu alliance has emerged as a community focused on creating an interoperable ecosystem servicing the precise timing and low latency requirements of diverse applications using the TSN open standards through certification.

However, application and component developers are faced with a practical challenge: How to effectively use the capabilities of the TSN hardware (e.g., switches, end-nodes) in software applications that need to share and use the time-sensitive data?

To ease this challenge, the OMG recently announced the development of a DDS-TSN standard to enable software applications using the DDS databus to be deployed on, and leverage, TSN-enabled networks (Figure 3). This standardization effort will define rules for mapping DDS features onto TSN concepts in order to support the design, deployment and execution of DDS systems over TSN networks in a standardized fashion. By putting DDS on top of TSN, system architects and application developers can easily leverage the DDS software databus with the advanced networking capabilities of TSN to create a powerful distributed data-centric software integration framework with high determinism, reliability, scalability and availability properties.

^{Figure 3. A DDS-TSN Standard Enables a Complete Time-Sensitive IIoT Connectivity Stack with Simple High-Level Data-Oriented Interface for Application Developers}

It turns out that DDS and TSN are a natural fit and complement each other perfectly. The DDS family of specifications defines a software databus for software components higher on the IIoT connectivity stack, represented in Figure 1, whereas the TSN family of specifications defines the hardware interfaces and signaling at the lowest layers of the stack. Both are designed for time-sensitive applications. Both are horizontal standards, applicable to many vertical markets. Software components using DDS-defined datatypes and quality of service (QoS) policies, such as LATENCY_BUDGET, TRANSPORT_PRIORITY, RESOURCE_LIMITS that map directly to the parameters needed to configure a TSN network. In fact, TSN hardware can make it possible to enforce certain QoS policies such as LATENCY_BUDGET, that are anticipated by the DDS standard for time-sensitive applications, but are not enforceable without the specialized hardware, such as TSN. The TSN approach to one-to-many streams aligns naturally with data-centric publish-subscribe topic-based dataflows in DDS as seen in Figure 2.

This is exciting news for the IIoT community! With the advent of the DDS-TSN standard, IIoT networks will be able to converge towards a single commodity hardware solution for real-time exchange of all data. Software components would simply use the DDS software databus for communications (Figure 4), declaratively specifying the timeliness requirements of various data flows simply via the DDS-TSN QoS policies.

^{Figure 4. Applications Simply Configure the Time-Sensitive Data Flows Using the QoS Policies and Configuration Parameters Enabled by the DDS-TSN Standard}

The DDS-TSN solution would automate the enforcement of the time-sensitive requirements and selectively map the time-sensitive data flows to the TSN hardware behind the scenes, thus relieving the system architects and application developers of dealing with the complexity of configuring a TSN network.

A converged DDS-TSN connectivity stack would ease the development and integration of time-sensitive software components and systems in many verticals, including industrial controls, automotive, and intelligent transportation. The new standard is very much needed by the IIoT communities today to effectively reap the benefits of TSN. If you want to learn more or participate, please contact us at: TSN@rti.com.