They have been developed to ensure that data in motion flows correctly, reliably and with low latency. Here we describe both standards individually and how together they provide the building blocks to address the critical communication challenges amongst participating components of future vehicle architectures.
What is DDS?
In a distributed system architecture, middleware is the software layer between the operating system and applications. This layer simplifies the development of distributed systems by solving the mechanics of passing information across applications and system components.
DDS is a middleware protocol, connectivity framework and API standard for data-centric connectivity. The Object Management Group (OMG) publishes and maintains the family of specifications based on the DDS standard (see Figure 1).
Figure 1: Architectural overview of the OMG DDS standards family
The DDS communications layer is based on a software databus that runs via a publish/subscribe model. The DDS databus is a shared global space where data continuously flows to and from its intended and authorised recipient(s).
DDS is data-centric by design and built to accommodate data in motion from different sources without custom coding. In this shared global data space, the data serves as the interface between devices but is not necessarily stored anywhere. This enables real-time performance, offers scalability through routing, provides Quality of Service (QoS) policies affecting how data is transmitted and managed by all participants, and finally supports dynamic discovery and offers several approaches to data security (both data- and transport-oriented).
As an open standard, DDS offers the comprehensive capabilities that system designers need to build a future-proof IIoT architecture that allows for maximum flexibility and scalability.
It manages data in motion across software and hardware platforms while providing a flexible environment that keeps designs streamlined, easy to maintain and cost-effective.
What is TSN?
Application-facing interfaces and upper-level protocols are essential for developing complex system architectures. However, only so much can be done to guarantee sustained performance, safety and determinism at the level they operate. To support such characteristics lower in the stack, various standards have been defined by the IEEE 802.1 TSN Task Group. Its goal is to improve performance and provide deterministic services through IEEE 802 networks. The TSN standards are split into four groups – synchronisation, latency, reliability, and resource management (see Figure 2).
Figure 2: IEEE Time Sensitive Networking (TSN) standards
To achieve the desired performance, the TSN Task Group defines various tools for network bridges and end stations.
The foundation of many TSN features, such as traffic shaping and frame replication, is the IEEE 802.1Q standard. This standard introduces the concept of Virtual LAN (VLAN) tags. Each tag carries priority information of the frame it is tagging for use in the bridges and end stations in the system.
This priority information is captured in a field known as Priority Code Point (PCP) (Figure 3) which assigns a specific priority to the Ethernet frame. One of the core tasks of the software application engineer is to classify the application Ethernet traffic into eight possible priority values. The PCP value allows that frame to be subsequently mapped onto one of the up to eight possible traffic class (TC) queues that are physically present in an Ethernet egress stage.
Figure 3: IEEE 802.1Q traffic class queues
With Priority-Based Shaping (PBS), where strict priority is applied in transmission selection, the queue with the highest TC that contains an available frame will be selected for transmission. In case of multiple frames in the queue, the oldest frame present will go first. With PBS, the system can achieve a bounded worst-case latency for time-critical traffic when that traffic is mapped to the highest traffic class queue.
While the base IEEE 802.1Q standard assigns priority to specific traffic streams, amendments such as IEEE 802.1Qav and IEEE 802.1Qbv add traffic-shaping features to the Ethernet egress to enforce deterministic latency. The IEEE 802.1Qav standard, for example, helps avoid traffic bursts that can cause network congestion and possibly lead to packet loss. It introduces so-called credit-based shapers on the output of a subset of the queues. These shapers keep track of a credit per queue. This credit is based on the amount of data this queue is allowed to transmit per second. A non-negative credit is necessary for transmission. This credit increases while waiting for data from other queues to be transmitted, and it decreases while transmitting. It is reset to zero when both the queue is empty, and the credit is positive.
To ensure reliable behaviour in the network, the IEEE 802.1CB standard specifies mechanisms for seamless frame replication and elimination to achieve spatial redundancy. Frames are replicated and a sequence number is included in either bridge nodes or end nodes supporting the replication functionality. Each frame copy follows its own path. To prevent a single point of failure, this path must be disjointed from the path of the other frame. Duplicates are eliminated at a merge point, which again can be a bridge node or an end node.
DDS and TSN
The DDS and TSN standards impact three layers of the classic Industrial Internet Connectivity Framework (IICF) model (Figure 4). At the Framework and Transport layers, DDS provides software components with a rich Type System and application programming interfaces (APIs) to propagate instances of Types (Topics) in a transport and network-agnostic fashion. DDS works by translating Data Types and API calls into DDS interoperability real-time publish-subscribe (DDSI-RTPS) standard messages. Independent of the underlying transport, these messages travel through all types of transport media (from IP networks to shared memory regions) with built-in mechanisms supporting safety, reliability, interoperability and performant delivery.
TSN capable equipment operates at the Link layer to ensure reliable and deterministic network operation. It constantly monitors critical aspects of data frames, such as Virtual Local Area Network (VLAN) tags and source/destination Media Access Control (MAC) addresses, in order to identify time-sensitive data streams and apply various TSN mechanisms to achieve the associated user-configured QoS requirements. For example, it applies TSN techniques such as time synchronisation, bandwidth reservation, traffic prioritisation and channel redundancy.
Table 1: Basic DDS-TSN conceptual mappings
DDS TSN
DataWriter Talker
DataReader Listener
DataWriter / DataReader 1:1 match Stream
Participant’s Domain ID IEEE 802.1Q VLAN ID
TRANSPORT_PRIORITY QoS policy IEEE 802.1Q VLAN PCP
Application-level abstractions and data-oriented policies can leverage the large set of QoS policies offered by DDS and reach the link layer, where TSN operates, in the form of IEEE 802.1Q VLAN tags, including VLAN identifiers and PCP values. Table 1 illustrates one such example, showing how the transport priority of a DDS topic could be linked to the PCP value. Additional DDS QoS policies targeting safe and deterministic systems can then be enforced by TSN, as shown in the following examples.
Stream bandwidth management
When dealing with a high data rate or bursty interfering traffic, the system architect must manage the bandwidth of that data stream to limit its impact on the critical traffic. DDS and TSN can reduce traffic interference by limiting the maximum bandwidth utilised by the interfering stream on the shared network, allowing safety-critical traffic to go through. This leads to a smaller chance of the critical traffic to be affected by the interfering traffic, reducing the frequency by which a worst-case interference occurs. It can also prevent overloading links by limiting the bandwidth for interfering traffic.
This stream bandwidth management can be achieved on the DDS level by using the TIME_BASED_FILTER QoS policy, where DataReader parameters can be set for a minimum time interval between received frames, effectively de-bursting the traffic. However, this policy will only impact the data stream over the link if the DataWriter also follows the minimum separation, which only holds for specific cases.
To ensure this separation in traffic and to manage the stream bandwidth on the network level, IEEE 802.1Qav Credit-Based Shaping (CBS) can be applied to deburst the traffic. With a credit-based shaper, a maximum bandwidth can be reserved per egress queue. Even when the DataWriter sends data faster than planned in the intended reception period, the credit-based shaper can de-burst the data on the link, ensuring the interfering traffic will not exceed its link reservation.
Figure 4: Industrial Internet Connectivity Framework
Reliability requirement
DDS-TSN integration provides complementary functionality in reliability to ensure an application remains operational in the event of a link failure.
Reliability is the most obvious QoS policy to use on the transport level. This determines the level of reliability for a specific connection between the DataWriter and DataReader. The system will monitor whether the data sent by a DataWriter is received by a DataReader. In any case, there is no guarantee that the data will be received, as it could get lost in transit. With the DDS reliability policy enabled, the system can monitor that and attempt to compensate for lost data by resending a copy of that data as often as needed until the DataReader has received the data. This technique is effectively temporal redundancy, where the data is repeatedly transmitted over time to improve the odds of arrival.
Additionally, on the network level, spatial redundancy can replicate data along redundant physical paths to improve the odds that the data transmitted will arrive at its destination. As previously explained, the IEEE 802.1CB standard specifies seamless frame replication and elimination mechanisms to achieve this.
Conclusion
Data must flow correctly, reliably, and with extremely low latency to provide consistently optimal communication performance. DDS and TSN separately reach into the IICF network stacks from opposite ends, each bringing their own set of standards, tools and methodologies to the system architecture.
Converging DDS and TSN helps address the traditional trade-off between communications performance and determinism versus software modularity and scalability.
The DDS protocols work at the Framework and Transport levels of the stack, providing applications with a rich and extensible data type system, stable cross-vendor and language APIs, as well as a comprehensive family of QoS policies. As stated, however, DDS has limited control over network messages once the operating system or networking stack boundary is crossed. Here, TSN capable devices use TSN specified mechanisms to identify DDS data streams, assign different TCs and manage redundant channels, traffic shaping, and bandwidth reservation.
- For more information about DDS-TSN integration and how it addresses the challenges faced in in-vehicle and vehicle-to-X communication, please view the example of the Autoware.auto autonomous valet parking application from the white paper “Driving interoperability and performance in automotive systems with DDS and TSN”.
- You can also experiment with DDS and TSN integration directly using the open-source example at GitHub.
Author details: Lulu Chan is Systems Architecture Engineer, NXP, and Emilio Guijarro Cameros is Auto Applications Engineer, RTI
