After the long era of fieldbuses, Time Sensitive Networking (TSN) is ushering in a new phase of industrial communication. This raises questions: Will TSN prevail in the long term? Can previous investments be safeguarded and existing system components and applications continue to be used? Will it be possible to combine future innovative technologies and meet increasing requirements? When do you have to decide - and what happens if you decide too early or wrongly?

System architects and developers like to keep all options open when combining TSN standards with the data-centric Data Distribution Service (DDS) standard.

Internet applications today are integrated using higher-level middleware (Layer 5 and 6) and connectivity framework technologies such as MQTT, DDS, OPC UA, HTTP/REST. These middleware technologies isolate the applications from the details of networking and make it possible to create distributed systems that are robust and can evolve over time. They facilitate the creation and sharing of data models and support communication patterns such as publish-subscribe and remote service calls that simplify application development.
However, many hard real-time systems have not been able to take advantage of these advances. This is because the middleware and network technologies could not provide the level of performance or determinism - such as limited latency and jitter - that the application required. Therefore, dedicated solutions had to be used, including specialized industry protocols and custom network hardware.
However, the combination of DDS and TSN can change this picture and provide the best of both worlds.

The best of both worlds

TSN provides a unique technology that enables real-time traffic to be delivered over Ethernet. It enables the definition of timing requirements for each flow and the configuration of network paths, including switches, to ensure that the requirements are met. It also provides isolation for different flows so that real-time traffic is not disrupted by other communications on the same network. However, as the technology is at a low level in the configuration stack, applications need to configure the flows, packet sizes, frequencies, priorities and network endpoints. While this is possible for simple applications for some nodes and flows, it becomes extremely complex and confusing for more complex systems.

DDS provides an ideal technology for integrating applications that consist of separate components. It is closer to the application and provides a higher-level interface in terms of topics, application data types and application-relevant QoS, for example reliability, durability, priority and deadlines. It also takes care of lower level details such as endpoint discovery and communication path setup. While DDS uses efficient binary protocols, it cannot guarantee deterministic behavior because it does not control the lower-level network layers. It must therefore live with what the underlying network, for example UDP/IP, can provide.

How does DDS work?

In a data-centric architecture, applications do not communicate with each other. A data bus implements a data-centric release that finds the right future data by filtering, such as the RTI Connext Databus.

© RTI

DDS is an open and international standard managed by the Object Management Group (OMG) that deals directly with data-centric publish-subscribe middleware for real-time systems. DDS provides comprehensive fine-grained control of real-time quality of service ( QoS ) parameters, including reliability, bandwidth control, delivery deadlines and resource limits.

Fundamentally, DDS is designed to address the challenges of real-time communication.
communication. The data-centric DDS publish-subscribe model (DCPS) connects anonymous information producers (publishers) with information consumers (subscribers). DDS defines a communication relationship between publishers and subscribers. Communication is decoupled in space (nodes can be anywhere), in time (nodes and topics) and in data flow. DDS explicitly manages the communication data models or types used for communication between endpoints.
It is therefore a data-centric technology that, like a database, provides a data-centric store and understands the content of the managed information. DDS is all about the data. This is why it is often referred to as a data bus, like the data bus of the RTI Connext DDS software (see picture above).
At its core, DDS implements a connectionless data model with the ability to publish and subscribe to data with the desired QoS. The data bus automatically detects and connects publisher and subscriber applications. No configuration changes are required to add a new intelligent machine to the network (see image below).

How does TSN work?

Both the data bus and the database make system integration considerably easier and support greater scalability, higher reliability and interoperability of the applications.

© RTI

Time Sensitive Network refers to a series of standards from the Time Sensitive Networking IEEE 802.1 working group. The standards define mechanisms for the time-sensitive transmission of defined data via Ethernet networks. Each standard specification can be used on its own and is usually self-sufficient. When used in a coordinated manner, TSN will be able to develop its full potential as a communication system.
The three basic components include:

1. time synchronization: all participating devices in real-time communication have a common, synchronized understanding of time.
2. scheduling and traffic shaping: All devices participating in real-time communication adhere to the same rules when selecting communication paths and reserving bandwidth and time slots, possibly with more than one simultaneous path to achieve fault tolerance.
3. selection of communication paths, path reservations and fault tolerance: time understanding

Advantages of combining DDS and TSN

Reiner Duwe is Sales Manager EMEA at Real-Time Innovations (RTI).

© RTI

There are several reasons why DDS and TSN work well together. Basically, both technologies offer 'one-to-many' communication that supports different levels of reliability for different data streams. DDS has been explicitly defined as a standard for real-time systems and has proven itself in numerous critical applications. DDS and TSN are suitable for meeting the high requirements of industrial automation and the automotive sector.
Why is a combination of DDS and TSN worthwhile? Why can DDS users benefit from using TSN as the underlying network and how can DDS help realize the full potential of TSN?
While the interaction models for DDS and TSN are quite similar - both are basically one-to-many publish/subscribe technologies - the use of DDS in addition to TSN results in a programming model at a higher level of abstraction.

Higher level of abstraction

DDS users develop their systems by producing or consuming strongly typed, predefined data elements. The data modeling constructs supported for this are diverse and modern.
Application developers see their data in the constructs of the native programming languages, while the middleware handles all subordinate mechanisms such as de-/serialization or network interactions.

Uniform approach

TSN system configuration: The most important DDS interfaces include the CUC-CNC user/network protocol and the CUC-TSN endpoint interface.

© RTI

Many systems consist of a combination of subsystems with different requirements and capabilities. Not all subsystems require hard real-time behavior as provided by TSN. DDS makes it possible to reuse the infrastructure in different subsystems and enable a seamless connection through gateways while maintaining a consistent data model.
DDS acts independently of the operating system and programming language and can be used as such in different environments (see image).
Here, the connecting element between the subsystems is the data model and the diverse ecosystem of DDS. This simplifies the task of introducing TSN into an existing system or design or extending TSN-based systems with additional subsystems with different non-functional requirements.

DDS-TSN standardization

The OMG has recognized the need for a standardized approach for the combination of DDS and TSN - a corresponding standard definition is in progress. Included here are aspects such as the definition of standard mechanisms for running a DDS runtime infrastructure over a TSN network or the description of a standardized process for deriving TSN network planning information from DDS system descriptions.
Such open standards, available to all, will enable DDS and TSN providers to develop their integration solutions in a portable, interoperable and manufacturer-independent manner.