您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
通信中间件 Fast DDS 基础概念简述与通信示例
 
作者:Frank
  180  次浏览      2 次
 2022-6-14
 
编辑推荐:
本文讲 Fast DDS 之前先讲什么是 DDS ,接着讲什么是 Fast-DDS,最后使用一个简单的 Fast DDS 示例,希望能够帮助大家。
本文来自于知乎, Frank909 ,由火龙果软件Alice编辑、推荐。

从事汽车软件开发,通信中间件绕不开,当前最火热的无非有 2 种:Some/IP 和 DDS。DDS 是一种分布式通信标准,有很多商业和开源的实现,Fast DDS 是其中的一种。它在 ROS2 中被应用,而 Apollo 中的 CyberRT 框架中也有它的身影。

讲 Fast DDS 之前先讲什么是 DDS。

1. 什么是 DDS ?

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

DDS(Data Distribution Service,数据分发服务) 是一种以数据为中心的通信协议,用于分布式软件应用程序通信。

它描述了支持 数据提供者(Data Providers) 数据消费者(Data Consumers) 之间通信的通信应用程序编程接口 (API) 和通信语义。

要学习 DDS 就不能忽略它的模型:DCPS(以数据为中心的发布订阅模型)。

DCPS 有 3 个关键实体:

  1. publication entities: 定义消息生成对象及相关属性
  2. subscription entities:定义消息消费对象及相关属性
  3. configuration entities:定义传输相关的属性如 Topic 类型,通信的 QoS(服务质量)。

QoS 是一个非常重要的概念,DDS 使用 QoS 来定义 DDS 实体的行为特征。 QoS 由单独的 QoS 策略(源自 QoSPolicy 的类型的对象)组成。

2. 什么是 Fast-DDS?

DDS 是一套标准,它有很多实现,有商业的,也有开源的。

商业:RTI 开源: Cyclone DDS、Fast-DDS

所以,Fast DDS 是一种开源的 DDS 标准实现,它由 ePromise 公司发布并维护。

3. 什么是 DCPS?

先看看 Fast DDS 官方文档中的一张图。

DDS 是以数据为中心的通信模型,那么这个数据中心是什么呢?

我个人的理解是以 Topic 为代表的消息对象就是 DDS 中的数据中心。

通过 Topic 的纽带关系,可以将数据生成为数据消费对象连接起来,并且可以通过 QoS 执行通信服务质量策略。

在 DCPS 模型中,有 4 个基础的概念:

  1. Publisher:它是负责创建和配置其实现的 DataWriters 的 DCPS 实体。 DataWriter 是负责实际发布消息的实体。每个 DataWriter 都有一个分配的 Topic,在该 Topic 下发布消息。
  2. Subscriber:它负责接收在其订阅的 Topic下发布的数据。它为一个或多个 DataReader 对象提供服务,这些对象负责将新数据的可用性传达给应用程序。
  3. Topic(话题):它是绑定发布和订阅的实体。它在 DDS 域中是唯一的。通过TopicDescription,它允许发布和订阅数据类型的统一。
  4. Domain(领域):这是用于链接所有发布者和订阅者的概念,属于一个或多个应用程序,它们在不同主题下交换数据。这些参与域的单个应用程序称为 DomainParticipant。 DDS 域由域 ID 标识。 DomainParticipant 定义域 ID 以指定它所属的 DDS 域。具有不同 ID 的两个 DomainParticipants 不知道彼此在网络中的存在。因此,可以创建多个通信通道。这适用于涉及多个DDS应用程序的场景,它们各自的 DomainParticipants 相互通信,但这些应用程序不得干扰。 DomainParticipant 充当其他 DCPS 实体的容器,充当发布者、订阅者和主题实体的工厂,并在域中提供管理服务。

DDS 是一种通过信息,而 DCPS 是一个抽象的模型概念,实际上映射到具体的代码维度,则需要 DomainParticipants 作为容器去承载 Publisher、Subsriber、Topic 等等。

可以这样理解:

  1. Domain 是项目组
  2. Topic 是项目生产过程各类相关产出物,如需求文档、概要设计、产品方案、测试用例等
  3. DomainParticipant 代表项目中不同的参与组织如UI小组、产品小组、开发小组、测试小组等等
  4. Publisher 和 Subscriber 代表不同小组中对外输出文档和接受信息的窗口角色
  5. QoS 代表不同的文档在各个小组流转时,双方对于文件传输状态的质量要求

最后说明一下,如何理解 QoS 呢?

你可以联想到,假如你是写代码的,产品经理传递文件给你时的方法和需要你反馈的时效,以及测试人员传递文档给你要求的时效是不一样的。

当然,这里只是类比,为了帮助大家加深理解,真正的 DDS 不一定这样。

4. 什么是 RTPS ?

RTPS 是 Real-Time Publish Subscribe 的缩写,它是 DDS 的通信中间件,是发布-订阅模式,通信能力强大,支持 UDP/IP、TCP 及共享内存。

RTPS 是 DDS 通信的根基,它内部有一样重要的概念:

  • Domain
  • RTPSParticipant
  • Topic
  • Attributes
  • Change
  • History
  • RTPSWriter
  • RTPSReader

RTPS 中定义了一个 Domain 的概念,它定义了一个单独的通信平面。几个域可以同时独立地共存。一个域包含任意数量的 RTPSParticipant,即能够发送和接收数据的元素。

RTPSParticipants 使用 EndPoint 进行通信:

  • RTPSWriter:能够发送数据的 EndPoint 端点。
  • RTPSReader:能够接收数据的 EndPoint 端点。

RTPSParticipant 可以有任意数量的写入器和读取器端点。

Topic 定义和标记正在交换的数据。主题不属于特定 DomainParticipant。DomainParticipant 通过 RTPSWriters 对 Topic 发布的数据进行更改,并通过 RTPSReaders 接收与其订阅的 Topic 相关的数据。

在 Fast DDS 中最基础的通信单元称为 Change,它表示在 Topic 下写入的数据的更新。 RTPSReaders/RTPSWriters 在其 History 中注册这些 Change,History 是一种用作最近更改缓存的数据结构。

在 eProsima Fast DDS 的默认配置中,当您通过 RTPSWriter 端点发布更改时,会在后台执行以下步骤:

  1. Change 将添加到 RTPSWriter 的 History 中。
  2. RTPSWriter 将 Change 发送到它知道的任何 RTPSReaders。
  3. 接收到数据后,RTPSReaders 用新的 Change 更新他们的 History。

Fast DDS 支持多种配置,允许更改 RTPSWriters/RTPSReaders 的行为。修改 RTPS 实体的默认配置意味着 RTPSWriters 和 RTPSReaders 之间的数据交换流发生变化。此外,通过选择服务质量 (QoS) 策略,您可以通过多种方式影响这些历史缓存的管理方式,但通信循环保持不变。

5. Fast DDS 和 RTPS 关系?

前文说过 RTPS 是 DDS 的基础,实际上完整的 Fast DDS 架构分为 4 层:

  • Application Layer
  • FAST DDS Layer
  • RTPS Layer
  • Tranport Layer

Application 指的是采用 Fast DDS API 的各类应用。

DDS Layer 主要定义一个系统中不同的 Domain,在同一个 Domain 下 Topic 按规则通信。

Fast RTPS 是通信协调层,是下层 Transport 的抽象。

Transport 层处理底层 UDP、TCP、SHM(共享内存)。

6. 一个简单的 Fast DDS 示例

要使用 Fast DDS 首先需要安装它,有 bin、Source、docker image 3 种方式,但 bin 和 docker image 需要到官网预留个人信息才能下载,所以,我们可以考虑源码下载。

要下载 3 份源码:

  • vendor
  • fast cdr
  • fast dds

我选择的是在 ubuntu 下用 cmake 方式编译。

可以参考这个地址: DDS安装

当然,还要下载编译 Fast DDS Gen,它是一个工具,能够将 IDL 文件转换成 C++ 代码。

现在考虑写一个最基础的 DDS 应用。

我们首先需要知道一个最小的 DDS 应该包含什么。

  • 消息.IDL
  • 数据发布器对应的.cpp
  • 数据接收器对应的.cpp
  • CMakeLists.txt

消息数据通过 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 定义。这个在本文中就不展开了。

 

 

   
180 次浏览       2
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践

最新活动计划
需求分析师能力培养 7-10 [北京]
基于 UML 和EA进行分析设计 7-22 [北京]
知识图谱建模与应用 7-19 [北京]
用户体验、易用性测试与评估 8-18 [北京]
软件开发过程中的项目管理 8-25 [北京]
微服务开发原理与实战 8-25 [北京]
 
最新文章
架构设计-谈谈架构
实现SaaS(软件及服务)架构三大技术挑战
到底什么是数据中台?
响应式架构简介
业务架构、应用架构与云基础架构
最新课程
软件架构设计方法、案例与实践
从大型电商架构演进看互联网高可用架构设计
大型互联网高可用架构设计实践
企业架构师 (TOGAF官方认证)
嵌入式软件架构设计—高级实践
更多...   
成功案例
某新能源电力企业 软件架构设计方法、案例与实践
中航工业某研究所 嵌入式软件开发指南
某轨道交通行业 嵌入式软件高级设计实践
北京 航天科工某子公司 软件测试架构师
北京某领先数字地图 架构师(设计案例)
更多...