Apollo：DDS与Fast-RTPS

DDS

是什么

• DDS全称是Data Distribution Service(数据分发服务)是一套通信协议和API标准，它提供了以数据为中心的连接服务,基于发布者-订阅者模型。
• DDS是一个中间件，它提供介于操作系统和应用程序之间的功能，使得组件之间可以互相通信。DDS集成系统中的各个组件，提供低延迟、高可靠性以及高扩展性体系结构，以适应商业级物联网(LOT)应用程序的需求
• DDS中间件是一个软件层，它将应用程序从操作系统、网络传输和低级数据格式的详细信息中抽象出来。以不同的编程语言提供了相同的概念和API，从而允许应用程序跨操作系统，语言和处理器体系结构交换信息。底层细节，如数据线格式、发现、连接、可靠性、协议、传输选择、QoS、安全性等都由中间件管理。
• Fast-RTPS是DDS的开源实现，借助它可以方便的开发出高效、可靠的分布式系统。

DDS到底有什么特别之处

下图展示了4个时代的数据通信方式：

• （第一代）点对点的CS（Client-Server）结构，这是大家最为熟悉的：一个服务器角色被许多的客户端使用，每次通信时，通信双方必须建立一条连接。当通信节点增多时，通信的连接数也会增多。并且，每个客户端都必须知道服务器的具体地址和所提供的服务。一旦服务器地址发生变化，所有客户端都会受到影响。
• （第二代）Broker模型：存在一个中间人，它负责初步处理大家的请求，并进一步找到真正能响应服务的角色，这就好像存在一个经纪人。这为客户端提供了一层抽象，使得服务器的具体地址变得不重要了。服务端地址如果发生变化，只需要告诉Broker就可以了。但这个模型的问题在于，Broker变成了模型的中心，它的处理速度会影响所有人的效率，这就好像城市中心的路口，当系统规则增长到一定程度，Broker终究会成为瓶颈。更糟糕的是，如果Broker瘫痪了，可能整个系统都将无法运转。
• （第三代）广播模型：所有人都可以在通道上广播消息，并且所有人都可以收到消息。这个模型解决了服务器地址的问题，且通信双方不用单独建立连接，但它存在的问题是：广播通道上的消息太多，太嘈杂，所有人都必须关心每条消息是否与自己有关。这就好像全公司一千号人坐在同一个房间里面办公一样。
• （第四代）DDS模型：这种模型与广播模型有些类似，所有人都可以在DataBus上发布和读取消息。但它更进一步的是，通信中包含了很多并行的通路，每个人可以只关心自己感兴趣的消息，自动忽略自己不需要的消息。

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

这个图之所以是沙漏形状是因为：两头的技术变化都发展很快，但是中间的却鲜有变化。
对比大家常见的Socker API，DDS有如下特点：

特性	Socket API	DDS
架构	TCP：点对点 UDP：点对点，广播，多播
平台独立	需要为不同硬件，操作系统和编程语言编写不同的代码	所有硬件，操作系统和编程语言使用相同的API
发现	需要硬编码IP地址和端口号	动态发现，无需关注端点所在位置
类型安全	没有类型安全，应用需要将字节流转换成正确类型	强类型安全，write()和read()针对特定数据类型
通信行为定制	需要通过自定义的代码来实现	通过QoS策略来完成
互操作性	不 支持	具有公认的互操作性的开放标准

DDS可以降低系统复杂度

• 对于分布式系统来说，有很多复杂的逻辑需要处理，比如：如何发现其他节点，保证消息的可靠性等

• 对于分布式系统来说，有很多复杂的逻辑需要处理，例如：如何发现其他节点，如何为每个节点分配地址，如何配置消息的可靠性等。这使得应用程序变得臃肿。
  而如果说通信的中间件能够完全处理好这些逻辑，则应用程序将可以集中处理自己的业务，变得更加敏捷。

• 下图是两种情况的对比：
  

• 如果考虑系统的演化，问题会更突出。

• 由于分布式系统中包含了很多的角色需要互相通信，随着角色数量的不断增长，其通信的通道数量也会以爆炸式的增长
  

• 而如果有统一的DataBuse，而即使新增了通信角色其通信模型也不会变得复杂。
  

DDS与RTPS

在DDS规范中，有两个描述标准的基本文档：

• DDS Specification：描述了以数据为中心的发布-订阅模型。该规范定义了API和通信语义（行为和服务质量），使消息从消息生产者有效地传递到匹配的消费者。DDS规范的目的可以概括为：“能够在正确的时间将正确的信息高效，可靠地传递到正确的位置”。
• DDSI-RTPS：描述了RTPS（Real Time Publish Subscribe Protocol）协议。该协议通过UDP等不可靠的传输，实现最大努力（Best-Effort）和可靠的发布-订阅通信。RTPS是DDS实现的标准协议，它的目的和范围是确保基于不同DDS供应商的应用程序可以实现互操作。

DDS的通信模型

DDS是一个以数据为中心的中间件协议和API标准：

• Domain：代表一个通信平面，由Domain ID唯一标识，只有在同一个领域内的通信实体才可以通信
• Domain Participant：同一数据域内的通信成员
• Topic：是数据的抽象概念，由TopicName标识，关联相应数据的数据类型(DataType)，如果把车内所涉及的所有Topic集合在一起，这样就形成一个虚拟的全局数据空间“Global Data Space”，进一步弱化了节点的概念，所以域参与者已经不是节点的概念了
• DataWriter：数据写入者，类似缓存，把需要发布的主题数据从应用层写入到DataWriter中；
• DataWriter：数据写入者，类似缓存，把需要发布的主题数据从应用层写入到DataWriter中；
• Publisher：发布者，发布主题数据，至少与1个DataWriter关联，通过调用DataWriter的相关函数将数据发出去；
• Publisher：发布者，发布主题数据，至少与1个DataWriter关联，通过调用DataWriter的相关函数将数据发出去；

一个 Domain 可以创建多个 Publisher，每个 Publisher 可以创建多个 DataWriter，而一个 DataWriter 只能绑定一个 Topic

DDS提供了Qos控制的数据共享。应用程序通过发布和订阅topic进行通信。不同的DDS域彼此完全独立。DDS域之间没有数据共享。

全局数据空间

从概念上讲，DDS会看到一个本地数据存储，称为“全局数据空间”。。对于应用程序，全局数据空间看起来像是通过API访问的本地内存。您写入看起来像本地存储的内容。实际上，DDS发送消息以更新远程节点上的适当存储。您从看起来像本地存储的地方阅读。

在DDS域内，信息共享的单元是“主题”中的数据对象。该主题由其名称标识，数据对象由一些“键”属性标识。这类似于如何使用关键属性来标识数据库中的记录。这是概念图。DDS进行点对点通信，不需要服务器或云来代理数据。

总之，本地存储给应用程序带来了访问整个全局数据空间的错觉。这只是一种幻想；没不存在所有数据都存在的全局位置。每个应用程序仅在本地存储所需的内容，并且仅存储所需的时间。DDS处理动态数据；全局数据空间是一个虚拟概念，实际上只是本地存储的集合。在任何系统上运行的几乎所有语言的每个应用程序都以最佳本机格式查看本地内存。全局数据空间通过任何传输方式在嵌入式，移动和云应用程序之间共享数据，而与语言或系统无关，并且延迟极低。

动态发现（Dynamic Discovery）

DDS提供发布者和订阅者的动态发现。动态发现使您的DDS应用程序可扩展。这意味着应用程序不必知道或配置用于通信的端点，因为它们是DDS自动发现的。这可以在运行时完成，而不必在设计或编译时完成，从而为DDS应用程序实现真正的“即插即用”。

DDS与汽车行业

• 对于汽车行业来说，汽车开放系统架构（AUTomotive Open System ARchitecture）已经在AUTOSAR Adaptive Platform 18.03中包含了DDS协议。
• ROS2架构也以DDS为基础。
• 另外，DDS的实时特性可能特别适合自动驾驶系统。在这类系统中，通常会存在感知，预测，决策和定位模块，这些需要非常高速和频繁的交换数据。借助DDS，可以很好的满足它们的通信需求。
  

Fast-RTPS

FsatDDS的前身是Fast-RTPS，实现了许多 DDS 规范。它是一种高性能的实时发布订阅框架。

Fast-RTPS是eprosima对于RTPS的C++实现，这是一个免费开源软件，遵循Apache License 2.0。

Fast-RTPS支持平台包括：Windows, Linux, Mac OS, QNX, VxWorks, iOS, Android, Raspbian。

Fast-RTPS具有以下优点：

• 对于实时应用程序来说，可以在Best-Effort和可靠通信两种策略上进行配置。
• 即插即用的连接性，使得网络的所有成员自动发现其他新的成员。
  模块化和可扩展性允许网络中设备不断增长。
• 可配置的网络行为和可互换的传输层：为每个部署选择最佳协议和系统输入/输出通道组合。
• 两个API层：一个简单易用的发布者-订阅者层和一个提供对RTPS协议内部更好控制的Writer-Reader层。

Fast-RTPS概述

git clone https://github.com/eProsima/Fast-RTPS.git

Fast-RTPS提供了两个层次的API：

• Publisher-Subscriber层：RTPS上的简化抽象
• Writer-Reader层：对RTPS断点的直接控制

相较而言，后者更底层。两个层次的核心角色如下图所示：

Publisher-Subscriber层为大多数开发者提供了一个方便的抽象。它允许定义与Topic关联的发布者和订阅者，以及传输Topic数据的简单方法。

Writer-Reader层更接近于RTPS标准中定义的概念，并且可以进行更精细的控制，但是要求开发者直接与每个断点的历史记录缓存进行交互

Fast RTSP是并发而且基于事件的。每个参与者都会生成一组线程来处理后台任务，例如日志记录，消息接收和异步通信。

事件系统使得Fast RTPS能够响应某些条件并安排定期活动。用户中几乎不用感知它们，因为这些事件大多数仅仅与RTPS元数据有关。

对象与数据结构

下面是Fast-RTPS实现中的核心结构。

Publish-Subscriber模块

RTPS标准的高层类型。

• Domain：用来创建，管理和销毁Participants。
• Participant：包括Publisher和Subscriber，并管理它们的配置
  • ParticipantAttributes：创建Participant的配置参数。
  • ParticipantListener：可以让开发者实现Participant的回调函数。
• Publisher：在Topic上发布数据的对象。
  • PublisherAttributes：创建Publisher的配置参数。
  • PublisherListener：可以让开发者实现Publisher的回调函数。
• Subscriber：在Topic上接受数据的对象。
  • SubscriberAttributes：创建Subscriber的配置参数。
  • SubscriberListener：可以让开发者实现Subscriber的回调函数。

RTPS模块

RTPS的底层模型。包含下面几个子模块：

• RTPS Common
  • CacheChange_t：描述Topic上的变更，存储在历史Cache中。
  • Data：Cache变化的负载
  • Message：RTPS消息
  • Header：RTPS协议的头信息
  • Sub-Message Header：标识RTPS的订阅消息
  • MessageReceiver：反序列化和处理接受到的RTPS消息
  • RTPSMessageCreator：构建RTPS消息
• RTPS Domain
  • RTPSDomain：用来创建，管理和销毁底层的RTPSParticipants。
  • RTPSParticipant：包括Writer和Reader。
• RTPS Reader
  • RTPSReader：读者的基类。
  • ReaderAttributes：包含RTPS读者的配置参数。
  • ReaderHistory：存储Topic变化的历史数据。
  • ReaderListener：读者的回调类型。
• RTPS Writer
  • RTPSWriter：写者的基类。
  • WriterAttributes：包含RTPS写者的配置参数。
  • WriterHistory：存储写者的历史数据。

配置Attributes

上面的数据结构中看到了许多Attributes后缀的类名。这些类包含了对协议或者对象的配置参数，很多特性都需要设置这些属性来完成。

这些类的定义基本都位于下面三个文件夹中：

• include/fastrtps/attributes
• include/fastrtps/rtps/attributes
• include/fastdds/rtps/attributes

Fast RTPS支持非常多的配置参数，并且参数的结构常常是嵌套的。

通过代码去配置这些参数会产生很多啰嗦的代码，而且最大的问题在于：每次更改配置参数都需要重新编译。这个问题并非Fast RTPS才有，只要包含大量配置参数的软件都会这样的问题。通常的解决方法就是：提供文本格式的配置文件的方式来配置参数。因此对于Fast-RTPS来说，除了支持通过代码配置参数，它也支持通过XML文件的方式来进行配置。

有了配置文件之后，在代码中直接读取就好了，例如：

Participant *participant = Domain::createParticipant("participant_xml_profile");
1

在这之后，如果需要调整配置，只需要修改配置文件，不用在改动代码，自然也不用重新编译。这对于项目部署是很重要的。

Domain

RTPS中的通信参与者之间，通过Domain进行隔离。

同一时刻可能会有多个Domain同时存在，一个Domain中可以包含任意数目的消息发送者和接收者。

其结构如下图所示：

开发者可以通过domainId来指定参与者所属Domain。

如果没有指定，默认的domainId = 80。

发现

作为DDS的实现，Fast-RTPS提供了Publisher和Subscriber自动发现和匹配的功能。在实现上，这分为两个步骤来完成：

• Participant Discovery Phase （PDP）：在这个阶段，参与者互相通知彼此的存在。为了达到这个目的，每个参与者需要定时发送公告消息，公告消息通过周知的多播地址和端口发送（根据domain计算得到）
• Endpoint Discovery Phase （EDP）：在这个阶段，Publisher和Subscriber互相确认。为此，参与者使用在PDP期间建立的通信通道，彼此共享有关其发布者和订阅者的信息。 该信息包含了Topic和数据类型。为了使两个端点匹配，它们的Topic和数据类型必须一致。 一旦发布者和订阅者匹配，他们就发送/接收数据了。

这两个阶段对应了两个独立的协议：

• Simple Participant Discovery Protocol：指定参与者如何在网络中发现彼此。
• Simple Endpoint Discovery Protocol：定义了已经互相发现的参与者交换信息的协议。

Fast-RTPS提供了四种发现机制：

• Simple：这是默认机制。它在PDP和EDP阶段均使用RTPS标准，因此可与任何其他DDS和RTPS实现兼容。
• Static：此机制在PDP阶段使用Simple Participant Discovery Protocol。如果所有发布者和订阅者的地址以及端口和主题信息是事先知道的，则允许跳过EDP阶段。
• Server-Client：这种发现机制使用集中式发现结构，由服务器充当发现机制的Hub。
• Manual：此机制仅与RTPSDomain层兼容。它禁用了PDP阶段，使用户可以使用其选择的任何外部元信息通道手动匹配和取消匹配RTPS参与者，读者和写者。

不同的发现机制具有一些共同的配置：

传输控制

Fast-RTPS实现了可插拔的传输架构，这意味着每一个参与者可以随时加入和退出。

在传输上，Fast-RTPS支持以下五种传输方式：

• UDPv4
• UDPv6
• TCPv4
• TCPv6
• SHM（Shared Memory）

默认的，当Participant创建时，会自动的配置两个传输通道：

• SHM：用来与同一个机器上的参与者通信。
• UDPv4：同来与跨机器的参与者通信。

当然，开发者可以改变这个默认行为，通过C++接口或者XML配置文件都可以。

SHM要求所有参与者位于同一个系统上，它是借助了操作系统提供的共享内存机制实现。共享内存的好处是：支持大数据传输，减少了数据拷贝，并且也减少系统负载。因此通常情况下，使用SHM会获得更好的性能。使用SHM时，可以配置共享内存的大小。

网络通信包含了非常多的参数需要配置，例如：Buffer大小，端口号，超时时间等等。框架本身为参数设置了默认值，大部分情况下开发者不用调整它们。但是知道这些默认值是什么，在一些情况下可能会对分析问题有所帮助。

与UDP不同，TCP传输是面向连接的，因此，Fast-RTPS必须在发送RTPS消息之前建立TCP连接。TCP传输可以具有两种行为：充当TCP服务器或充当TCP客户端。服务器打开一个TCP端口以侦听传入的连接，然后客户端尝试连接到服务器。服务器和客户端的概念独立于RTPS概念，例如：Publisher，Subscriber，Reader或Writer。它们中的任何一个都可以用作TCP服务器或TCP客户端，因为这些实体仅用于建立TCP连接，而RTPS协议可以在该TCP连接上工作。

fast-DDS

源码与编译

• 官网: https://www.eprosima.com/index.php/company-all/news/146-fast-rtps-is-now-fast-dds
• API地址: https://fast-dds.docs.eprosima.com/en/latest/

源码：https://github.com/eProsima/Fast-DDS

1

参考

https://blog.csdn.net/shoufei403/article/details/124394224?spm=1001.2014.3001.5506#t4
http://www.kuazhi.com/post/315061.html
http://www.kuazhi.com/post/315061.html