• 一、常见中间件模型介绍
  • 1.1 (第一代)点对点CS(Client-Server)模型
  • 1.2 (第二代)Broker(协商者)模型
  • 1.3 (第三代)广播(Broadcast)模型
  • 1.4 (第四代)以数据为中心的DDS(Data Distribution Service)模型
• 二、ROS2对中间件的需求
  • 2.1 DDS是什么
  • 2.2 DDS的应用场景
  • 2.3 ROS2使用DDS的原因
• 三、DDS初步介绍
  • 3.1 DDS的核心标准
  • 3.2 ROS2采用DDS的优点和缺点
    • 3.2.1 优点
    • 3.2.2 缺点
  • 3.3 DDS的供应商
  • 3.4 不同DDS性能对比
    • 3.4.1 延迟
      • 3.4.1.1 进程间
      • 3.4.1.2 进程内
      • 3.4.1.3 双主机
    • 3.4.2 吞吐量
      • 3.4.2.1 进程间
      • 3.4.2.2 进程内
      • 3.4.2.3 双主机

一、常见中间件模型介绍

中间件是一类提供系统软件和应用软件之间连接、便于软件各部件之间的沟通的软件，应用软件可以借助中间件在不同的技术架构之间共享信息与资源。中间件位于客户机服务器的操作系统之上，管理着计算资源和网络通信。

中间件根据拓扑结构可分为四种模型，分别是点对点CS(Client-Server)模型、Broker(协商者)模型、广播(Broadcast)模型、DDS(Data Distribution Service)模型，如下图所示。

四种拓扑结构的中间件模型

1.1 (第一代)点对点CS(Client-Server)模型

许多客户端连接到一个服务端，每次通信时，通信双方必须建立一条连接。当通信节点增多时，通信的连接数也会增多。每个客户端都需要知道服务器的具体地址和所提供的服务。一旦服务器地址发生变化，所有客户端都会受到影响。

最典型的就是TCP通信，当对方的IP地址和端口号发生改变，所有与该程序通信的节点都将受到影响。

1.2 (第二代)Broker(协商者)模型

这是一种消息中间件，特点是具有中心服务器。

面向消息的系统（消息中间件）是在分布式系统中完成消息的发送和接收的基础软件。消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。

当前业界比较流行的开源消息中间件包括：ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等，其中应用最为广泛的要数RabbitMQ、RocketMQ、Kafka 这三款。

中心服务器Broker统一负责初步处理所有人的请求，并进一步找到真正能响应服务的角色。这使得客户端可以不用关心服务器的具体地址。服务端地址如果发生变化，只需要告诉Broker就可以了。这个模型的特征也很明显，Broker作为核心，它的处理速度会影响所有节点的效率，当系统规模增长到一定程度，Broker将成为整个系统的性能瓶颈。对于资源相对吃紧的嵌入式系统，这个问题会更为突出。更糟糕的是，如果Broker发生异常，可能导致整个系统都无法正常运转。

最典型的就是ROS中存在的Master节点，如果该节点挂掉，所有ROS节点都将无法正常工作。

1.3 (第三代)广播(Broadcast)模型

所有人都可以在通道上广播消息，并且所有人都可以收到消息。这个模型解决了服务器地址的问题，且通信双方不用单独建立连接，但它存在的问题是：广播通道上的消息太多了，所有人都必须关心每条消息，无论是否与自己有关。

最典型的就是CANbus，CAN节点发送的消息帧会在CANbus上不停的广播，与其它CAN节点是否存在都没有关系，这样严重影响总线上的带宽。

1.4 (第四代)以数据为中心的DDS(Data Distribution Service)模型

这种模型与广播模型有些类似，所有人都可以在DataBus上发布和订阅消息。但它的先进之处在于，通信中包含了很多并行的通路，可以只关心自己感兴趣的消息，忽略不感兴趣的消息。

下图展示了DDS在网络栈中的位置，它位于传输层的上面，并且以TCP，UDP为基础。

这个图之所以是沙漏形状是因为：两头的技术变化都发展很快，但是中间的却鲜有变化。

二、ROS2对中间件的需求

在探索下一代ROS通信系统的选项时，最初的选项是改进ROS 1的传输系统或者使用诸如ZeroMQ、谷歌的Protocol Buffers和zeroconf（Bonjour/Avahi）等组件库来构建新的中间件。但是，除了那些需要从头开始或部分从头开始构建中间件的选项之外，还考虑了其他已有的端到端中间件。在研究过程中，一个脱颖而出的中间件就是DDS。

2.1 DDS是什么

DDS是OMG组织在2004年发布的中间件协议和应用程序接口（API）标准，它为分布式系统提供了低延迟、高可靠性、可扩展的通信架构标准。它将系统的组件集成在一起，提供业务和任务关键型物联网 (IoT) 应用程序所需的低延迟数据连接，具有极高的可靠性和可扩展架构。

OMG（Object Management Group）成立于1989年，是一个开放性的非营利性的计算机行业标准联盟。OMG多年来致力于为工业分布式系统提供可互操作的，可移植的，可复用的软件标准。很多我们熟知的标准都来自OMG，比如UML（Unified Modeling Language），CORBA（Common Object Request Broker Architecture）等。

OMG组织发布的只是DDS标准，而标准的实现是由各个DDS提供商完成，其中有商用的如RTI，也有开源的如Object Computing的OpenDDS、eProsima的FastDDS。

2.2 DDS的应用场景

DDS最早应用于美国海军，用于解决舰船复杂网络环境中大量软件升级的兼容性问题，后来扩展至航空、航天、船舶、国防、金融、通信、汽车等领域，包括作战系统、船舶导航和控制系统、船舶防御系统、无人机驾驶系统和地面控制系统、装甲车辆控制系统、仿真和培训系统、雷达处理和空中交通管理系统、金融系统等。

DDS的应用场景

2018年，DDS首次被引进AUTOSAR AP，作为可选择的通信方式之一。2018年3月，DDS的主要提供者RTI公司宣布，AUTOSAR AP的最新版本（版本18-03）已经具有DDS标准的完整网络绑定。

百度Apollo的自动驾驶框架Cyber RT的底层使用了开源的DDS，将DDS作为最重要的通信机制。与此相对应的是，Xaver、Orin等面向自动驾驶的SOC芯片上也都预留了DDS接口，英伟达的Xavier自带的Driver.OS中便采用了FastDDS或OpenDDS这样的开源DDS。

2.3 ROS2使用DDS的原因

使用像DDS这样的端到端中间件的好处是，需要维护的代码要少得多，可以让ROS2开发人员腾出手专注机器人开发。

DDS中间件的行为和确切规范已经提炼到文档中。除了系统级文档，DDS还具有推荐用例和软件API。有了这个具体的规范，第三方可以审查、审计和实施具有不同程度互操作性的中间件。这是ROS从未有过的特性，除了wiki中的一些基本描述和参考实现外。此外，如果要从现有软件库构建新的中间件，则无论如何都需要创建这种类型的规范。

三、DDS初步介绍

3.1 DDS的核心标准

DDS的核心标准分为两种，分别是API标准和协议(Protocol)标准，即DCPS规范和DDSI-RTPS规范。

• DCPS规范：API标准保证了不同DDS实现的应用程序的可移植性。

• DDSI-RTPS规范：协议标准保证了不同厂家的DDS可实现互操作性。

DDS 规范的开发始于 2001 年。它由软件框架公司 Real-Time Innovations (RTI) 和法国国防公司Thales Group开发。2004 年，对象管理组(OMG) 发布了 DDS 1.0 版。1.1 版于 2005 年 12 月发布，1.2 版于 2007 年 1 月发布，1.4 版于 2015 年 4 月发布。

RTPS协议 2.0 版于 2008 年 4 月发布，2.1 版于 2010 年 11 月发布，2.2 版于 2014 年 9 月发布，2.3 版于 2019 年 5 月发布。

下图从下往上可分为三层，分别是网络通信协议层、DDS层、应用程序层，其中红白线框内是DDS的核心标准.

DDS的核心标准

DDS的核心标准包括：

• DDS v1.4 - 描述了用于分布式应用程序通信和集成的以数据为中心的发布-订阅(DCPS)模型；

• DDSI-RTPS v2.3 - 定义了实时发布-订阅交互通信协议(RTPS)；（v2.3是2019年发布，Fast-DDS目前2022.11采用的仍然是v2.2）

• IDL v4.2 - 定义了IDL，一种用于以独立于编程语言的方式定义数据类型和接口的语言。这不属于DDS标准，但DDS依赖于它。

DDS规范总共有四个正式版本，如下表所示：

其中1.4版本相较于1.2版本最大的变化是将1.2版本中的可选部分（第八章 数据本地重建层）去除。

RTPS规范总共有四个正式版本，如下表所示：

其中2.3版本相较于2.2版本主要修改了以下部分：

8.2.1中Participant类与Endpoint类关系由2.2版本中的无关系变为组合关系；Participant类增加guidPrefix成员变量，Endpoint类增加endpoint成员变量；
8.2.3 RTPS CacheChange类增加inlineQoS成员变量；
8.2.4 RTPS Entity类增加了同一参与者内部端点组的GUID信息，主要是指Publisher和Subscriber的GUID；同时Endpoint类也继承Entity类；
8.2.5 RTPS Participant类与Endpoint类之间增加了一个Group类；
8.3.2关于数据类型定义添加了GroupDigest_t类型；
8.3.3 RTPS消息组成结构部分去除NoKeyData以及NoKeyDataFrag类型；
8.3.4 RTPS消息接收器（RTPS Message Receiver）增加对HeaderExtension的依赖；
8.3.5 RTPS子消息元素（RTPS SubmessageElements）增加了KeyHashPrefix、KeyHashSuffix以及GroupDigest数据类型的支持；将2.2版本的Flags数据类型改为StatusInfo类型；将SerializedPayload以及SerializedPayloadFragment类型合并为SerializedData类型；
8.3.7.2 Data报文类型添加NonStandardPayloadFlag字段；
8.3.7.3 DataFrag报文类型添加NonStandardPayloadFlag及KeyFlag字段；
8.3.7.4 Gap报文类型添加GroupInfoFlag、gapStartGSN以及gapEndGSN字段；
8.3.7.5 Heartbeat报文类型添加GroupInfoFlag、currentGSN、firstGSN、lastGSN、writerSet以及secureWriterSet字段；
8.4.7.1 RTPS Writer类增加dataMaxSizeSerialized成员变量；RTPS Writer类的new_change方法增加inlineQos参数。
8.4.7.2 RTPS StatelessWriter类去除resendDataPeriod数据成员；
8.4.7.5 RTPS ReaderProxy类增加remoteGroupEntityId成员；
8.4.10.4 RTPS WriterProxy类增加dataMaxSizeSerialized和remoteGroupEntityId成员；
8.4.12.1 Best-Effort StatefulReader 行为变换图改变；
8.4.13.4 Participant Message Data数据组成添加kind字段；
8.4.15.7 在HeartbeatFrag和NackFrag报文中增加count；
8.5.3.2 SPDPdiscoveredParticipantData数据类型增加domainId、domainTag 和builtinEndpointQos字段；
8.7.5 添加Group Ordered Access实现；
9.3.1.2 EntityId_t添加Writer Group和Reader Group实体ID类型；
9.6.3 In-line QoS增加PID_GROUP_COHERENT_SET、PID_GROUP_SEQ_NUM、PID_WRITER_GROUP_INFO以及PID_SECURE_WRITER_GROUP_INFO等字段支持；
10 数据串化封装增加CDR2_BE、CDR2_LE、PL_CDR2_BE、PL_CDR2_LE、D_CDR_BE、D_CDR_LE和XML 等版本字段。

图片参考：https://www.bilibili.com/video/BV12z4y167w2
核心规范参考：https://www.platforu.com/DetailsPage?id=17
fast-dds的RTSP规范：https://www.eprosima.com/index.php/products-all/eprosima-fast-dds

3.2 ROS2采用DDS的优点和缺点

3.2.1 优点

发布/订阅模型：简单解耦，可以轻松实现系统解耦
性能：在发布/订阅模式中，与请求/回复模式相比，延迟更低，吞吐量更高。
远程参与者的自动发现：此机制是 DDS 的主要功能之一。通信是匿名的、解耦的，开发者不必担心远程参与者的本地化。
丰富的 Qos 参数集，允许调整通信的各个方面：可靠性、持久性、冗余、寿命、传输设置、资源......
实时发布订阅协议 ( RTPS )：该协议几乎可以通过任何传输实现，允许在 UDP、TCP、共享内存和用户传输中使用 DDS，并实现不同 DDS 实现之间的真正互操作性。

实时性：DDS通过优化的内核机制，实现微秒级的数据传输；纯分布式的系统结构，保证系统内不存在影响实时性的瓶颈节点。DDS 实体被建模为类或类型化接口，允许提前分配内存而不是动态分配内存,可以更有效的对资源处理。
可靠性：DDS提供点到点的信息交互服务，从而保证整个系统服务不存在单点故障的风险；同时提供可靠传输策略，通过重发机制确保数据可靠地传输。
持续性：DDS可以通过相应的QoS为ROS提供数据历史的服务，新加入的节点也可以获取发布的所有历史数据。
灵活性：应用系统可以根据应用场景需求，灵活选择多种DDS提供的应用级QoS策略（例如可靠性传输、数据过滤、优先级排序等等），以满足系统的灵活性需求。
扩展性：DDS使用“订阅/发布”机制进行数据交互，建立全局的虚拟数据空间，在通信层面将应用逻辑与节点的物理信息解耦合，使系统能够方便的实现节点增减或系统本身的分割/合并，满足系统的扩展性需求；运行时由DDS自动发现并连接设备和应用程序，即插即用，无需系统管理或目录服务。
异构网络支持：DDS通过适配底层多种异构架构网络，对上层提供无差别的通信服务，使通信软硬件层对应用层完全透明。

3.2.2 缺点

使用端到端中间件的缺点是 ROS 必须在已有的设计中工作。如果设计没有针对相关用例或不灵活，则可能需要围绕设计工作。在某种程度上，采用端到端中间件包括采用该中间件的理念和文化，没那么简单。

API复杂，DDS 的灵活性是以复杂性为代价的。

系统开销相对较大

社区支持问题，但ROS2近两年来使用DDS后社区表现还是不错的。

3.3 DDS的供应商

OMG发布的只是DDS标准，而标准的实现是由各个DDS提供商完成，其中有商用的如RTI，也有开源的如Object Computing的OpenDDS、eProsima的FastDDS。

目前（2022.10）OMG 维护 DDS 供应商的活动 列表见下图。

OMG 维护 DDS 供应商

全球范围内，DDS市场份额最大的供应商（80%左右）的是成立于1991年的美国RTI公司（全称为Real-Time Innovations）。RTI作为OMG组织董事会的成员，主导了DDS标准的制定，从2004年开始负责主持DDS工作组的工作，目前已经成为这个行业的领导者，对DDS标准有足够的权威。

RTI开发的DDS品牌名为Connext,，因此又被称为Connext DDS。

FastDDS是由eProsima公司推出，由RTI原核心团队成员在欧洲创办，是在自动驾驶领域比较有影响力的开源DDS。eProsima供应商提供也直接访问 DDS 有线协议 RTPS 的实现。

OpenDDS 由Object Computing开发，它和FastDDS具有一定的相似性——两者都是基于RTPS实现的，面向数据的通信框架，遵循的是同一标准。这类框架的典型特征是去中心化，支持QoS机制，支持实时通信。但通常会绑定如protobuf等序列化工具。

CycloneDDS是由Eclipse基金会开发的。

3.4 不同DDS性能对比

这里对Fast RTPS、Cyclone DDS、OpenSplice DDS从进程间、进程内、双主机三种场景下的延迟和吞吐量对比测试

3.4.1 延迟

3.4.1.1 进程间

3.4.1.2 进程内

3.4.1.3 双主机

3.4.2 吞吐量

3.4.2.1 进程间

3.4.2.2 进程内

由于 Cyclone DDS 不提供进程内测试，eProsima 无法将第二种方案包括在吞吐量性能基准测试中。

3.4.2.3 双主机

结论：在所有测试的情况下，Fast RTPS所提供的延迟更短，吞吐量更高。

参考：

[译] Fast RTPS与Cyclone DDS与OpenSplice DDS对比测试：
https://www.jianshu.com/p/0e0f5ce6b4ce

DDS在自动驾驶中的地位，强烈推荐：
https://blog.csdn.net/usstmiracle/article/details/125498440
https://m.eefocus.com/automobile-electronics/515201
https://codeantenna.com/a/ofZLhMddDa