DDS（Data Distribution Service）数据分发服务-01简介

guoban

已于 2024-05-16 17:49:10 修改

阅读量1.1k

点赞数 15

分类专栏：通讯中间件文章标签：物联网

于 2024-05-16 11:06:57 首次发布

本文链接：https://blog.csdn.net/guoban/article/details/138900304

版权

通讯中间件专栏收录该内容

7 篇文章 1 订阅

订阅专栏

前言

随着嵌入式系统越来越复杂及承载的功能需求越来越多，嵌入式系统中流转的数据种类越来越多、频率越来越高、数据量越来越大，以自动驾驶为例，自动驾驶域控需要对图像、激光雷达、IMU、GNSS等多传感器的数据进行传输、融合、计算、保存等处理，因此如何高效、可靠、低延迟的传输及处理这些数据，是嵌入式软件设计时重点要考虑的。

基于上述原因，在开发嵌入式软件时，仅仅依靠操作系统原生IPC（如linux传统IPC），从性能、可靠性、可维护性等方面考虑，已越来越难以满足要求。因此，越来越多的通信中间件被设计出来，以满足各个行业各种应用场景下的通讯需求，比如ZeroMQ、DDS、Some/IP、Dbus等等。这些通讯组件各有特点，并且都已应用到多个行业，集成这些高性能通讯中间件，已经是嵌入式软件开发的趋势。
本文主要介绍常用通讯中间件之一：DDS的基本情况。

一、什么是DDS？

DDS：Data Distribution Service 数据分发服务，是新一代分布式实时通信中间件协议和API标准，采用发布/订阅体系架构，强调以数据为中心，提供丰富的QoS服务质量策略，以保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求。
DDS技术最早应用在美国海军系统，用于解决军舰系统复杂网络环境中大量软件升级的兼容性问题。在2003年被OMG（Object Management Group）组织纳入，并发布对应的技术标准，目的是为了满足现代实时系统的需求，在物联网、工业自动化、航空航天、国防等多个领域均得到广泛应用。
近年来，随着智能网联汽车的发展，汽车电子系统对车内通信传输性能、安全性和灵活性提出更高要求，越来越多的OEM开始采用DDS作为通信解决方案。在汽车领域，2018年Adaptive AUTOSAR引用了DDS，作为可选择的通信方式之一。目前国内已有主机厂开始研究，主要针对自动驾驶相关需求，工具方面，在汽车电子领域常用的工具厂商也在开发这部分内容。不仅是汽车领域引入DDS，在机器人开发领域，最新升级的ROS2也引入了DDS中间件来传递信息。

二、DDS标准架构

DDS已经是一套标准，由OMG组织发布和维护，2004年发布v1.0版本至今，已经过多次升级迭代。

关于OMG：OMG（Object Management Group）组织，是一个国际化的、开放成员的、非盈利的计算机行业标准协会，很多大家熟悉的标准(如uml)，都出自于OMG，DDS也是OMG组织推出的标准之一。

DDS协议框架图

DDS标准可以分为4个部分：核心规范、扩展规范、网关规范和API规范。

核心标准

DDS v1.4：DDS规范描述了以数据为中心的发布-订阅（DCPS）模型框架
DDSI-RTPS v2.5：RTPS（实时发布-订阅协议），属于传输层协议，实现数据传输功能
DDS-XTypes v1.3：定义了DDS数据类型系统以及DDS数据的序列化表示方法
DDS-Security v1.1：为DDS实现定义了安全模型和服务插件接口（SPI）架构

扩展规范

DDS-RPC v1.0：此规范定义了一个分布式框架，提供了独立于语言的服务定义以及使用DDS进行通信/远程过程他用。支持自动发现，同步和异步调用并可使用多种QoS
DDS-XML v1.0：此规范定义了用于表示DDS相关资源的XML语法，为QoS、DDS数据类型和DDS实体（DomainParticipants、Topics、Publishers、Subscriber、DataWriters和DataReaders）提供XSD模式文件
DDS-JSON v1.0：此规范定义了用于表示 DDS 相关资源的JSON语法，为 DDS 服务质量 (QoS)、DDS数据类型、DDS数据和 DDS 实体（DomainParticipants、Topics、Publishers、Subscriber、DataWriters和DataReaders）提供JSON模式文件

网关规范

DDS-WEB v1.0：此规范定义了一个独立于平台的抽象交互模型，用于说明Web客户端应该如何访问DDS系统以及一组DDS到特定 Web 平台的映射，这些特定 Web 平台在标准Web技术和协议方面实现了平台无关模型 (PIM)
DDS-OPCUA v1.0：此规范定义了一个标准的、可配置的网关，它支持使用DDS的系统和使用OPCUA的系统之间的互操作和信息交换
DDS-XRCE v1.0：此规范定义了资源受限的低功耗设备向DDS域发布和订阅数据的协议。XRCE协议将XRCE客户端（Client）与DDS 代理（Agent）连接，该DDS代理充当连接至DDS域的网关

API规范

DDS C++ API（对应ISO/IEC C++ 2003）：为DDS中以数据为中心的发布-订阅（DCPS）的C++ API定义
DDS Java API（对应Java 5）：为DDS中以数据为中心的发布-订阅（DCPS）的Java定义

其他

IDL4 v4.2（ISO/IEC 19516:2020）：IDL（Interface Definition Language）接口定义语言，一种用于以独立于编程语言的方式定义数据类型和接口的语言。IDL不是DDS的标准，但DDS依赖于IDL
IDL4-JAVA：此规范定义了IDL4类型到Java语言的映射
IDL4-C#：此规范定义了IDL4类型到C#语言的映射

可以看到，DDS是一套包含了多个子规范的的协议标准，这些规范，有些同样是OMG发布和维护的，同时还依赖于其他组织的标准或者规范。其中最核心的就是DDS（DSCP模型）和RTPS，网上很多介绍也是主讲这两部分。
上述核心规范，可以在OMG官网找到，以DDS为例，截止2024.5.16，版本发布情况：
OMC官网：https://www.omg.org/index.htm

版本编号	发布时间	链接
v1.4	2015.3	https://www.omg.org/spec/DDS/1.4/
v1.2	2006.12	https://www.omg.org/spec/DDS/1.2/
v1.1	2005.12	https://www.omg.org/spec/DDS/1.1/
v1.0	2004.12	https://www.omg.org/spec/DDS/1.0/

以上章节内容参考：https://platforu.com/DetailsPage?id=17

三、DDS特点

以数据为中心

在这里插入图片描述
这张图展示了在DDS中，DataWriter和DataReader作为实际的通讯实体，并且数据是以主题为标识在DDS中进行流转。
DDS以数据为中心，个人感觉体现在（可能不太准确）：

协议设计上以数据为主体，比如对数据的传输由DataReader/DataWriter来实现，对数据的传输质量控制由QoS来实现，以数据作为主视角来设计DDS的模块
对于用户实际使用上，相比于其他通讯中间件，从API调用上，比如ZeroMQ，需要用户自己构建线程调用消息接收函数对消息进行处理。从Fast DDS的使用上，用户只需调用API发布，通过复写虚函数实现自己的消息接收函数，无需关注底层细节。

全局数据空间

看官方的介绍，个人理解如下（可能不太准确，有错误的话后续更新）：

相比MQTT的设计，MQTT有个后台broker，由broker来实现主题的路由及转发。那么在MQTT里面，对于某一个发布/订阅端来说，是不知道也不需要知道总线上有多少数据在流转。但DDS设计上是点对点通讯，没有后台服务器，对于发布/订阅端来说，需要有个“全局数据空间”，可以知道全局的数据信息，以便知道要向哪个应用程序订阅到数据。
在DDS域中，DDS为每个应用程序的在其本地构建了一个称为“全局数据空间”的本地数据存储。对于应用程序，更新远端应用节点的数据（实际上是DDS底层发送消息来更新远程应用节点的数据存储），但从操作上来说，就跟更新自身本地数据存储空间一样。
DDS通过“全局数据空间”，使得同个域内的各个应用程序（嵌入式、移动端、PC端），实现低延迟共享数据。

QoS

DDS提供灵活的服务质量(QoS)策略，可配置数据传输的可靠性、系统传输负载、安全性等。支持多种QoS策略，每种策略都可以应用在不同的DDS角色上，而针对同一角色，可单独使用一种QoS，也可以组合使用多种QoS策略。

动态探测

DDS可动态探测到发布者和订阅者。这意味着应用程序不必知道或配置通信端点，因为它们是由DDS自动发现的，并且是在运行时完成，从而为DDS应用程序实现真正的“即插即用”。DDS的动态探测机制不只是搜索到端点接入，DDS的动态探测机制可检测到端点是发布数据、订阅数据，还是两者兼而有之，可确认发布或订阅的数据类型、通信特征和订阅者请求的通信特征。DDS可以动态探测到本地或者跨网络的远程参与者。

可伸缩架构

OMG DDS体系结构被设计为可从小型设备扩展到云以及用于非常大的系统。DDS通过扩展数千或数百万参与者，以超高速传输数据，管理数千个数据对象，并提供极高的可用性和安全性来实现物联网。DDS通过在一个单一的标准通信层中吸收大部分复杂性来简化分布式系统的开发。

安全性

DDS包括为信息分发提供身份验证、访问控制、机密性和完整性的安全机制。DDS Security使用分散的点对点架构，在不牺牲实时性能的情况下提供安全性。

以上章节参考：：https://www.dds-foundation.org/what-is-dds-3/

四、DDS框架概述

DDS在软件架构中的层次

按官方定义，DDS是一个中间件，在软件架构中关系如下图：
DDS软件架构图
DDS处于操作系统和应用程序之间，为应用程序屏蔽了操作系统、底层网络传输和数据格式的细节，允许应用程序跨操作系统、编程语言和处理器体系结构交换信息。底层细节，如传输链路、对端搜索、发现、连接、可靠性、协议、传输选择、QoS、安全性等，都由DDS中间件管理。用户只需关注数据本身：如按照自身业务来定义数据格式，以及要转发给谁。

DDS通讯框架

可以简单认为DDS通讯框架包含两个最主要内容：DSCP模型和QoS策略

DSCP模型

在这里插入图片描述
DSCP（Data-centric Publish-Subscribe）模型，其实就是定义了数据发布者和数据订阅者之间的交互方式。这个模型定义参与通讯的角色、传输的内容及格式等内容。下面对DSCP模型中各个角色进行解释：

Domain：DDS域，可以理解为一个通讯平面，由Domain ID唯一标识，用于标识一个或多个DomainParticipant，只有在同个域的DomainParticipant才允许通讯
DomainParticipant：域参与者，是域中的一个实体（可以具象为一个设备，或者设备中的一个进程），是数据发布者、订阅者和主题的创建和管理者，负责管理DDS中的实体对象和通信配置
Publisher/Subscriber：发布者/订阅者，由DomainParticipant创建，发布者负责将数据发布到特定的主题（Topic）中，而订阅者则通过订阅相关主题来接收所需的数据
DataWriter/DataReader：数据写入/读取者，由Publisher/Subscriber创建，DataWriter负责将数据写入到特定的主题中，而DataReader负责从主题中读取相应的数据
Topic：主题是DCPS中定义数据传输的逻辑分类和组织单元。它可以看作是一种数据的标签，用于区分不同类型的数据

可以看出有如下包含关系：Domain->Participant->Publisher/Subscriber->DataWriter/DataReader

在这个模型中，向“全局数据空间“写入数据的一方称为Publishers和DataWriter，同样地，在”全局数据空间“中读取数据的一方称为Subscriber和DataReader，下图中展示了它们之间的逻辑关系。除了DCPS模型，DDS标准中还定义了一套完整的应用程序接口（API），该接口标准是与平台无关的，这意味着不论应用程序使用什么开发语言，或运行在什么平台之上，只要DDS中间件的实现符合DDS标准，那么相关的应用程序即可实现不同平台间的移植。

数据的发送过程，简单来说就是应用程序调用DataWriter对象提供的write方法，把数据传递给Publisher对象，而Publisher负责将数据在网络上发送出去。

数据的接收过程，简单来说就是Subscriber负责从网络上接收数据，并把它存储在对应的DataReader中。应用程序可以为对应的DataReader注册一个回调函数，或者使用DataReader提供的read和take方法来轮询DataReader中的数据。

除了上述这些概念之外，DCPS提供了多种策略来满足不同的发布和订阅需求。对于订阅方来说，DDS提供了以下两种基础策略：

Listen（监听）：订阅者可以使用监听方式来接收数据。它会一直等待，直到接收到数据为止。这种方式是阻塞型的，即订阅者在接收到数据之前会一直等待。
StatusCondition（状态条件）：使用Condition和Waitset（条件和等待集），订阅者可以实现异步数据访问。可以为一个或多个条件对象设置条件，然后等待条件满足或特定事件发生。这种方式是非阻塞的，订阅者可以继续执行其他操作，而不必一直等待。

通过选择适当的策略，订阅者可以根据不同的需求进行数据访问和处理。监听方式适用于需要及时响应并处理数据的场景，而条件和等待集方式适用于需要异步处理数据或等待特定条件发生的场景。

QoS策略

QoS（Quality of Service）是一种用于确定通信系统中信息传输质量的策略。QoS策略用于满足不同应用场景下对信息交互的特殊需求。DDS的QoS相当强大，与SOME/IP相比，DDS的QoS数量可谓相当丰富。目前，DDS提供了22种不同的QoS策略，它们可以独立或组合使用。通过定义和配置一系列QoS参数和策略，能够在数据传输过程中实现对带宽、延迟、可靠性和安全性等的控制和优化。

当定义一个QoS策略时，我们首先要了解他的含义和Value(配置值)的定义，需要注意的是QoS必须定义一个默认值。除此之外还有以下三点需要定义：

Concerns: 表示QoS可为哪些实体配置，包括：Topic, DataWriter, DataReader, Publisher, Subscriber, and DomainParticipant。
RxO: 兼容设置。YES即表示通信两端要求兼容，NO表示可独立配置，N/A表示该Qos只能在一端配置。
Changeable: Entity创建后是否可改变QoS配置，YES/NO。

在这里插入图片描述
可以对DDS的各个角色和主题，都配置相应的QoS策略。
Durability（持久性）：该策略用于确定数据的持久性存储方式。它可以设置为"VOLATILE"数据不进行永久储存，"TRANSIENT"数据保留在内存中，"TRANSIENT_LOCAL"数据保留在DataWriter的内存中，"PERSISTENT"数据将保存在永久存储中。在车载通信系统中，Durability可以确保重要数据在异常情况下不会丢失。同时，持久性存储还可以支持数据的历史记录和回放，为数据分析、故障排查等提供有力支持。根据具体应用场景和需求来灵活配置Durability，以实现最佳的持久性存储效果。
在这里插入图片描述

Reliability（可靠性）：该策略用于确保数据传输的可靠性。它可以设置为"BEST_EFFORT"或"RELIABLE"，前者表示尽力而为的传输，不保证可靠传输，数据可能会丢失或重复，适用于某些实时性要求较高的应用场景。后者表示数据以可靠的方式发送，保证数据的传输和接收的可靠性。数据不会丢失，确保所有订阅者都可以接收到相同的数据。我们可以依据对延时和可靠性的实际需求来进行选择。
在这里插入图片描述
Partition（分区）：该策略通过一组字符串来定义发布者和订阅者的分区。分区是一种逻辑上的划分，用于将数据发布者和数据订阅者按照一定的规则进行分组。当发布者和订阅者使用相同的分区标识符时，它们将进行匹配并允许进行数据交互。这样可以实现对数据的精确过滤，实现灵活的数据管理。