TSN
The combination with DDS
The Data Distribution Service (DDS) for real-time systems can be combined with the upcoming IEEE TSN standards. The result: a distributed and data-centric integration framework that offers high reliability and availability.
The DDS standard of the Object Management Group (OMG) is designed from the ground up to address the challenges of real-time communication. Time-Sensitive Networking (TSN) comprises a series of standards from the IEEE working group 802.1 of the Time-Sensitive Networking Task Group. The standards define mechanisms for transmitting time-sensitive data over Ethernet networks. There are several reasons why DDS and TSN can work well together. Fundamentally, both technologies provide one-to-many communication that supports different levels of reliability for different data streams.
DDS data flows and TSN streams
DDS revolves around an extensively typed publish/subscribe model in which DataWriters are responsible for updating certain data types, while DataReaders monitor these updates. A topic is an application-specific data type that determines what information a DDS package contains. Typical DDS systems consist of one to hundreds of topics. The combination of a DataWriter and its topic name can be described as the ID of a DDS data flow source. All matching DataReaders (one-to-many) act as sinks for this data flow.
Similar to here, there are talkers in TSN. These update one or more streams that deliver data to the connected listeners. Such streams are identified by their 'VLAN Tag ID'. The combination of a talker and its VLAN tag ID can be described as the ID of the source of a TSN stream.
This description shows how DDS data flows can be mapped directly to TSN streams. Most DDS systems today already make use of IP multicasting, so replacing this mechanism with communication via TSN streams is a logical step. At the application level, the impact would be minimal as the details of the underlying transport remain hidden from DDS users.
QoS in DDS and traffic classes in TSN
DDSs are also characterized by various quality of service settings. Their task is to instruct the middleware about the importance and urgency of the information in the various DDS data flows, among other things. In line with the data-centric approach - applications communicate with the data infrastructure, not with each other - the QoS settings are made individually for each data flow. Some of these are similar to the mechanisms that define the traffic classes in TSN. Examples of this are the QoS settings 'Deadline', 'LatencyBudget' and 'TransportPriority'. Further QoS settings at DDS level are suitable for making intelligent decisions when selecting the appropriate underlying TSN stream. By choosing the right QoS settings at DDS level, system designers can rely on the end-to-end data distribution behavior - from the producing application to the network stack, through the network and back to the consuming application.
Based on the 'Data Distribution Service for Real-Time System', DDS products have been designed and used for the implementation of such systems from the very beginning.
Existing DDS ecosystems are therefore suitable for use in application areas that are also addressed by TSN technologies, such as industrial automation and automotive applications.
Advantages of the DDS + TSN combination
What does DDS contribute in addition to TSN that makes the combination of both technologies worthwhile? Conversely, what makes it interesting for DDS users to use TSN as the underlying network?
The interaction models of DDS and TSN are quite similar: in both cases, they are basically technologies based on the one-to-many and publish/subscribe concept. If DDS is based on TSN, this results in a programming model with a higher degree of abstraction. DDS users develop their systems by producing or consuming extensively typed and predefined data elements. The data modeling constructs supported for this are also extensive and modern. Application developers see their data as constructs of native programming languages, while all subordinate mechanisms such as serialization and deserialization as well as network interactions are handled by the DDS middleware.
DDS consists of a series of open standards with the Object Management Group as the standardization body. The standards can be freely downloaded from the OMG website. In addition to the functional description of DDS, the specification includes a standardized API that application developers can use. When integrating DDS and TSN, the API can be used for easier familiarization, to reduce maintenance costs and as support from an off-the-shelf ecosystem.
Because DDS has evolved from large mission-critical systems, the necessary characteristics for reliable, operationally secure systems are maintained when DDS is added to a TSN network.
Many systems consist of different subsystems with different requirements and capabilities. However, not all of these subsystems require the strict real-time behavior offered by TSN. DDS makes it possible to reuse the same infrastructure in different subsystems and connect them to gateways while maintaining a consistent data model. Since DDS is not tied to specific operating systems or programming languages, it is suitable for different environments. In such cases, the data model and the rich ecosystem of DDS remain as a common theme. This in turn simplifies the incorporation of TSN into an existing system or design, as well as the expansion of an existing TSN-based system with additional subsystems with different non-functional requirements.
An application example
The management of a robot system via a DDS infrastructure is an application for which the use of TSN is suitable at a lower level. The integration of both technologies can take place at different stages of the system development process.
The example is about a system that controls a robot arm in a decentralized configuration. The controlling application therefore runs on a different machine than the robot itself. For analysis purposes and predictive maintenance, another machine monitors and duplicates the operation of the robot. All of these applications can trigger alarms as soon as irregularities are detected. All applications involved communicate via DDS (see application example above).
In DDS terminology, the name of the flow is the same as the topic name. The layout of the example system is shown in Figure 1.
System layout and time schedule
OMG DDS-XML defines a schema for defining DDS entities in an XML format, which enables a mechanism for the descriptive recording of system data flows. With additional tags, which still have to be defined by a new OMG DDS-TSN standard as a supplement to the existing DDS-XML schema, an identification of critical or non-critical data flows including their frequencies and bandwidths can be provided. Together with physical endpoint information that specifies which applications are running on which nodes, sufficient information is available. This can be fed to a TSN network scheduler so that it can calculate the various TSN flows with their tags as well as the timing and duration of the associated network time intervals. In TSN terminology, this means that a DDS-capable CUC tool (Central User Configurator) receives the DDS-specific information and converts it into an interaction with the CNC tool (Centralized Network Configurator) in order to obtain a calculated network schedule expressed in the standardized TSN format.
No information is made available to the TSN network scheduler for the DDS data flows marked as non-critical. This means that the associated data is transported in the remaining TSN best-effort time intervals.
In the case of the example system, this means that the corresponding update frequencies (e.g. 1 kHz) must be specified for the critical DesiredPos and ActualPos topics so that the network scheduler can take them into account. Although the alarm topic is also critical, it is not periodic. For this to work with the concept of pre-planned time intervals, an estimate of the required or desired allocated bandwidth and the maximum acceptable latency must be made in advance. This can be done using appropriate tools. The heartbeat topic is ultimately not critical, so no additional information is required.
Selection of TSN flows at runtime
For those DDS topics that contain critical information, each DDS DataWriter is classified as a TSN talker and each DDS DataReader as a TSN listener. In addition, the DDS middleware is able to select the correct VLAN tag in each case, providing the QoS offered by TSN at the network level. DataWriters and DataReaders for non-critical topics communicate their data via the TSN best-effort time intervals. In the example system, the headers of the network packets for the critical topics DesiredPos, ActualPos and Alarm must therefore be provided with the correct tags for the Ethernet level, as specified by the TSN flows calculated in the previous step. The DDS infrastructure is responsible for this. Such a mechanism is not necessary for the heartbeat topic, as this is not a critical flow.
Automatic configuration
Figure 2: Roles in the TSN system configuration: The most important DDS interfaces include the CUC-CNC user/network protocol and the CUC-TSN endpoint interface.
© RTIIn addition to instrumenting the DDS middleware, it is also necessary to configure the various TSN-capable elements of the network equipment so that they match the DDS data flows. This task could be performed by the CUC and CNC, whereby the CNC either informs all network switches directly about the schedule or the CNC provides the CUC with the necessary information. In addition, the CUC instructs the network interfaces (see Fig. 2). In the example system, the network interface cards for the machines on which the controller, arm, twin and alarm UI processes run must be informed about the calculated time intervals for the respective topics. The TSN-capable switch must also be instructed accordingly.
DDS-TSN standardizations
The Object Management Group has recognized the need for a standardized concept for the combination of DDS and TSN and has already begun to define the various aspects of such an integration. It is expected that this will also include aspects for defining standard mechanisms for the operation of a DDS runtime infrastructure on a TSN network. It may also require the description of a standardized process for deriving TSN network scheduling information from DDS system descriptions. Once such open standards are available and accessible to all, both DDS and TSN vendors can develop their integration solutions in a portable and vendor-independent manner.
You might also be interested in
Wago gears up for Time Sensitive Networking (TSN)
In the future, Ethernet TSN will enable continuous communication in machine and plant engineering without gateways and interruptions. Wago is launching two new automation systems on the market for the SPS, with which users can take advantage of all...
read more...Arrive in reality!
Time Sensitive Networking has firmly established itself in the vocabulary of the automation industry. All well-known suppliers have started activities to evaluate or even introduce TSN. But where exactly are the goals for the use of TSN and what is...
read more...OPC UA and DDS combined
To date, OPC UA and DDS have often been presented as competitors. Competitors that will both be based on the Ethernet standard TSN. - However, the key to successful automation in the future lies in a combination of the three standards DDS, OPC UA...
read more...The interaction of Ethernet TSN, OPC UA and 5G
Only the reliable and structured interaction of all units in an ant colony ensures its survival. Data communication in a modern industrial network works no differently in a figurative sense.
read more...Where there are still problems with 5G
5G in automation - a hot topic at the moment. How quickly can we actually expect 5G to be used in industry? What obstacles still need to be overcome? Thomas Schildknecht summarizes the key points in this interview.
read more...Data pipeline ASi-5
High data width, short cycle times, improved integration of intelligent sensors and actuators using IO-Link and cloud connectivity via OPC UA - ASi-5 makes AS-Interface fit for the requirements of digitalization.
read more...OPC UA - a must for the industry (Part 2)
OPC UA is regarded as the new communication standard for industrial automation. Part 1 explained why a new communication technology is needed in automation and described the OPC UA methods. Part 2 deals with the OPC UA pub/sub methods and the power...
read more...OPC UA, MQTT and co.
The Industrial Internet of Things (IIoT) covers very different areas of application. The available connectivity technologies and standards are just as diverse as the application areas. How can the right technology be filtered out in each case?
read more...The question of licenses
Will OPC UA in combination with TSN become 'the' standard for industrial communication? What role do licenses play in this question and what part does OSADL play?
read more...