从事汽车软件开发，通信中间件绕不开，当前最火热的无非有 2 种：Some/IP 和 DDS。DDS 是一种分布式通信标准，有很多商业和开源的实现，Fast DDS 是其中的一种。它在 ROS2 中被应用，而 Apollo 中的 CyberRT 框架中也有它的身影。
讲 Fast DDS 之前先讲什么是 DDS。
DDS 是 OMG 组织发布的一种中间件协议和 API 标准，它将系统的组件集成在一起，提供业务和任务关键型物联网 (IoT) 应用程序所需的低延迟数据连接、极高的可靠性和可扩展架构。
DDS(Data Distribution Service,数据分发服务) 是一种以数据为中心的通信协议，用于分布式软件应用程序通信。
它描述了支持 数据提供者(Data Providers) 和 数据消费者(Data Consumers) 之间通信的通信应用程序编程接口 (API) 和通信语义。
要学习 DDS 就不能忽略它的模型：DCPS(以数据为中心的发布订阅模型)。
DCPS 有 3 个关键实体：
QoS 是一个非常重要的概念，DDS 使用 QoS 来定义 DDS 实体的行为特征。QoS 由单独的 QoS 策略（源自 QoSPolicy 的类型的对象）组成。
DDS 是一套标准，它有很多实现，有商业的，也有开源的。
商业：RTI 开源: Cyclone DDS、Fast-DDS
所以，Fast DDS 是一种开源的 DDS 标准实现，它由 ePromise 公司发布并维护。
先看看 Fast DDS 官方文档中的一张图。
DDS 是以数据为中心的通信模型，那么这个数据中心是什么呢？
我个人的理解是以 Topic 为代表的消息对象就是 DDS 中的数据中心。
通过 Topic 的纽带关系，可以将数据生成为数据消费对象连接起来，并且可以通过 QoS 执行通信服务质量策略。
在 DCPS 模型中，有 4 个基础的概念：
DDS 是一种通过信息，而 DCPS 是一个抽象的模型概念，实际上映射到具体的代码维度，则需要 DomainParticipants 作为容器去承载 Publisher、Subsriber、Topic 等等。
可以这样理解:
最后说明一下，如何理解 QoS 呢？
你可以联想到，假如你是写代码的，产品经理传递文件给你时的方法和需要你反馈的时效，以及测试人员传递文档给你要求的时效是不一样的。
当然，这里只是类比，为了帮助大家加深理解，真正的 DDS 不一定这样。
RTPS 是 Real-Time Publish Subscribe 的缩写，它是 DDS 的通信中间件，是发布-订阅模式，通信能力强大，支持 UDP/IP、TCP 及共享内存。
RTPS 是 DDS 通信的根基，它内部有一样重要的概念：
RTPS 中定义了一个 Domain 的概念，它定义了一个单独的通信平面。几个域可以同时独立地共存。一个域包含任意数量的 RTPSParticipant，即能够发送和接收数据的元素。
RTPSParticipants 使用 EndPoint 进行通信：
RTPSParticipant 可以有任意数量的写入器和读取器端点。
Topic 定义和标记正在交换的数据。主题不属于特定 DomainParticipant。DomainParticipant 通过 RTPSWriters 对 Topic 发布的数据进行更改，并通过 RTPSReaders 接收与其订阅的 Topic 相关的数据。
在 Fast DDS 中最基础的通信单元称为 Change，它表示在 Topic 下写入的数据的更新。RTPSReaders/RTPSWriters 在其 History 中注册这些 Change，History 是一种用作最近更改缓存的数据结构。
在 eProsima Fast DDS 的默认配置中，当您通过 RTPSWriter 端点发布更改时，会在后台执行以下步骤：
Change 将添加到 RTPSWriter 的 History 中。
RTPSWriter 将 Change 发送到它知道的任何 RTPSReaders。
接收到数据后，RTPSReaders 用新的 Change 更新他们的 History。
Fast DDS 支持多种配置，允许更改 RTPSWriters/RTPSReaders 的行为。修改 RTPS 实体的默认配置意味着 RTPSWriters 和 RTPSReaders 之间的数据交换流发生变化。此外，通过选择服务质量 (QoS) 策略，您可以通过多种方式影响这些历史缓存的管理方式，但通信循环保持不变。
前文说过 RTPS 是 DDS 的基础，实际上完整的 Fast DDS 架构分为 4 层：
Application 指的是采用 Fast DDS API 的各类应用。
DDS Layer 主要定义一个系统中不同的 Domain，在同一个 Domain 下 Topic 按规则通信。
Fast RTPS 是通信协调层，是下层 Transport 的抽象。
Transport 层处理底层 UDP、TCP、SHM(共享内存)。
要使用 Fast DDS 首先需要安装它，有 bin、Source、docker image 3 种方式，但 bin 和 docker image 需要到官网预留个人信息才能下载，所以，我们可以考虑源码下载。
要下载 3 份源码：
我选择的是在 ubuntu 下用 cmake 方式编译。
可以参考这个地址：DDS安装
当然，还要下载编译 Fast DDS Gen，它是一个工具，能够将 IDL 文件转换成 C++ 代码。
现在考虑写一个最基础的 DDS 应用。
我们首先需要知道一个最小的 DDS 应该包含什么。
消息数据通过 IDL 文件定义。
IDL 功能很强大，定义了基础数据类型、数组、窗器、map、枚举、注解等等。[3]
fastddsgen 可以将其转换成 c++ 数据结构体。
通过 fastddsgen 可以转换成 C++ 类。
现在我们可以编写一个简单的 IDL
然后可以通过 fastddsgen 快速生成代码。
最终会自动产生好几个代码文件。
FrankTestDDS.idl 被转换成 FrankTestDDS.cxx 和它应对的 .h 文件。
其它的 FrankTestDDSPubSubMain 之类是 fastddsgen 自动生成的，用于实现发布和订阅演示代码。
我们先观察 CMakeLists.txt。
我们可以发现，整个工程依赖于 fastcdr 和 fastrtps 两个库，之后，代表消息数据经 idl 转换后的 FrankTestDDS.cxx 被编译成库的形式。
这样后面编译的 FrankTestDDS 这个可执行文件就可以链接消息库，保证了应用代码和消息的解耦。
现在我要试验 FastDDS 的发布-订阅功能。我在生成的 FrankTestDDSPublisher.cxx 中添加了一些代码。
st 是我们的消息体，我将其中的 msg 赋值。
同时，我还得修改 FrankTestSubscriber.cxx 的代码。
现在，我们可以编译代码并尝试运行了。
mkdir build
cd build
cmake ..
make
然后，分别在两个终端中运行 publisher 和 subscriber
./FrankTestDDS publisher
./FrankTestDDS subscriber
我们可以看到，通信正常，这也说明我们可以开始通过 fast dds 干活了。
至于高阶内容，需要结合业务实际需求了，比如大量传输摄像头图片、点云数据、控制命令等等。我们得处理好相应的数据结构转换和 QOS 定义。这个在本文中就不展开了。
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
