面向资源有限设备的DDS通信中间件设计

代江涛，高 博，万嘉骏

(战略支援部队信息工程大学 信息系统工程学院,河南 郑州 450000)

在工业4.0的大背景下，物联网、车联网和边缘计算等技术迅速发展。随着应用场景的多元化，单一的设备或者系统已经不能够满足生产生活的需求，各个分布式的功能单元之间需要协同合作来完成复杂的任务[1]。在开发分布式应用的过程中，由于设备平台软硬件环境的差异，用户需要根据平台特性通过平台相关的专有化编程接口进行应用开发。应用与底层运行环境紧密耦合，导致分布式系统整体开发难度增加，应用可移植性较差[2-3]。

通信中间件屏蔽了底层复杂的网络编程操作和平台相关的应用编程接口，使用标准的编程接口为应用提供统一的编程模型，降低了分布式应用的开发难度[4]。数据分发服务(Data Distribution Service，DDS)是由对象管理组织(Object Management Group，OMG)提出的一种以数据为中心的发布-订阅式实时通信中间件规范，定义了分布式应用之间数据交换、行为交互和服务质量要求的标准，被称为新一代的系统集成中间件标准[5]。DDS以数据为中心的思想，适用于对数据处理能力要求较高的物联网场景，同时其拥有较高的实时性和灵活性，能够按照实际需求自定义用户数据格式或消息、扩展或删减功能。当前市场中大部分的DDS通信中间件专门为互联网业务设计[6]，系统较为庞大，而针对资源有限的嵌入式场景方面的研究较少。

eProsima公司遵循OMG组织的XRCE-DDS(eXtremely Resource Constrained Environments DDS)规范[7]，面向资源有限的设备提出了Micro XRCE-DDS解决方案。该方案采用客户端/服务端的通信模型，在资源有限的设备上运行定制的轻量级Micro XRCE-DDS客户端应用，在资源比较充足的设备上运行Micro XRCE-DDS代理应用，客户端和代理之间通过XRCE协议进行通信。Micro XRCE-DDS代理接收到客户端的数据后，将其转换为标准的RTPS协议，从而实现与标准的DDS应用的交互。各个客户端之间的发现、连接、通信均由代理应用完成。该方案通过将DDS的部分功能迁移到代理端，降低了客户端的资源需求，实现了DDS应用在嵌入式设备上的部署。但是代理的引入增加了额外的通信时间开销，降低了应用的实时性。此外，随着接入设备的增加，代理节点的负载也会不断增加，增加了数据传输的不确定性。

TinyDDS是专为无线传感器和执行器网络(Wireless Sensor and Actor Network，WSAN)设计的轻量化DDS通信中间件，符合OMG DDS的标准。面向MCU设备的TinyDDS依赖于TinyOS，使用nesC语言作为实现语言，能够为用户提供可配置的、基于任务和硬件事件的并发处理模型，适用于多节点的嵌入式传感器网络[8]。TinyDDS采用中心化的通信模型，各客户端的发现、通信必须经由代理进行中转，易造成代理节点繁忙，增加了丢包的可能性。此外，其与TinyOS深度耦合，可移植性较差。针对TinyDDS中心化的通信模型产生的问题，文献[9]基于TinyDDS设计了一种去中心化的DDS中间件，该中间件被称为Bloker-Less TinyDDS(BLTDSS)中间件。在数据传输过程中，不再经由代理，直接在本地获取路由信息，增加了通信的响应速度，同时去中心化的通信模型也将网络负载分散到各个节点，增加了网络的健壮性。但是由于采用了泛洪式的发现机制，导致在发现节点过程中，整个网络的负载较高，导致各个节点间建立连接的过程较为缓慢。因此，文献[10]提出了Hybrid TinyDDS(HyTDDS)中间件。该中间件采用混合式的通信模型。在节点发现过程中，使用中心化的通信模型，降低了网络负载，各个客户端通过代理获取与本节点有通信需求的其它客户端的订阅信息和网络位置信息，并保存到本地路由表中。在数据传输过程中，采用去中心化的通信模型，各个发布/订阅节点使用本地路由信息与远端节点通信。BLTDDS和HyTDDS均是基于TinyDDS改良后的中间件。虽然两者都解决了TinyDDS的通信模型引入的部分问题，但是无法解决其跨平台能力不足的问题。

为了能够在嵌入式设备上部署DDS通信中间件，文献[11]提出了一种基于节点功能的DDS裁剪策略。当节点为发布者时，DDS中间件仅包含发布相关功能，当节点为订阅者时，DDS中间件仅包含订阅相关功能，从而降低了DDS中间件对资源的需求量，并提升了系统的响应速度。但是，这也造成了节点之间的不对称性，导致节点后期升级比较复杂。

从上文的分析中可以看出，当前针对嵌入式场景中的DDS通信中间件的研究主要从通信模型、功能裁剪等方面入手，有效解决了嵌入式设备计算、存储资源不足的问题，提升了系统的响应速度。但目前针对通信资源方面的研究较少，而其也是嵌入式设备受限资源之一。因此，本文基于DDS规范，结合嵌入式设备资源受限的特点，对其功能和传输协议进行精简化，并特别针对通信资源有限的问题，提出了一种基于卡尔曼滤波模型的对称式发布订阅通信机制，有效降低了通信资源的消耗。本文设计的DDS通信中间件使用C语言进行开发，具有良好的可移植性，并已经在STM32 + RT-Thread平台和X86 + Linux平台进行了测试验证。测试结果证明，本通信中间件能够在按照DDS规范为分布式应用提供基本交互服务的同时，提升系统的响应速度，减少通信带宽的占用。

1 DDS

1.1 分层架构

OMG制定的DDS规范详细描述了底层数据交互细节和应用编程接口(Application Programming Interface，API)信息[12]，并将其分为了如图1所示的两个层次：(1) 以数据为中心的发布订阅层(Data-Centric Publish-Subscribe，DCPS)。该层是DDS实现数据交互的基础层，负责完成数据的订阅、发布，按照约定的协议格式对数据进行构建或解析；(2) 本地数据重构层(Data Local Reconstruction Layer，DLRL)。该层是可选层，用于将DCPS层提交的字节型数据转换为特定格式的数据，方便用户访问。同时，对DCPS层的部分功能进行了封装，为用户提供了更加简易的操作接口。

图1 DDS分层架构Figure 1. DDS layered architecture

1.2 以数据为中心的发布订阅模型

DDS规范描述的各种成员对象被称为实体(Entity)。DDS以数据为中心的订阅-发布模型为分布式的应用节点引入了全局数据空间(Global Data Space，GDS)的概念。系统中对该空间中数据感兴趣的应用都可以接入其中。

DDS使用域(Domain)将网络划分为不同的逻辑分组，同一个域内的实体对象可以相互通信，不同域之间相互独立。DDS参与者(Participant)是承载其它实体对象的容器。每个参与者由发布者(Publisher)、订阅者(Subscriber)和主题(Topic)组成，并负责对这些实体的创建、删除和管理[13]。每个发布者至少与一个数据写入者(Data Writer)相关联，并负责创建、删除和管理数据写入者。相应地，每个订阅者至少与一个数据读取者(Data Reader)相关联，并负责创建、删除和管理数据读取者。数据写入者是数据发送的直接交互实体，负责将数据发送到全局数据空间中，供其它实体使用。数据读取者是数据接收的直接交互实体，负责在全局数据空间中获取所需数据。为了区分系统内的实体对象，使用全局唯一标识(Globally Unique Indentifier，GUID)对各个实体对象进行标记，该标识格式为{前缀，实体ID}，同一个参与者内部的各个实体拥有相同的前缀。DDS 中各个实体之间的关系及数据收发过程如图2所示。

图2 DDS数据分发模型Figure 2. DDS data distribution model

2 轻量级 DDS 设计

2.1 软件架构设计

分层式软件架构设计方式能够保证各层次内部高度耦合，层与层之间实现解耦[14]。软件在迭代过程中，只需要替换相应层级内容即可，无需对其它层级内容更改，与嵌入式场景中应用需求多变的特点较为匹配。

如图3所示，在实际应用场景中，可以将引入本通信中间件的系统自下而上划分为4个层次：硬件层、支撑软件层、通信中间件层、应用层。硬件层包括处理器、通信总线、存储设备和其它片上控制器外设。支撑软件是系统运行的基础，包括设备驱动、操作系统和软件包等与设备密切相关的软件环境。通信中间件层是本文设计的核心，基于DDS规范的通信中间件，简化了通信细节，解耦了应用与底层软件环境的同时，向应用提供了统一的编程接口，方便应用的开发和迁移。应用层是用户需求功能的具体实现。

图3 系统分层架构Figure 3. Hierarchical system architecture

通信中间件层是本文设计的核心，其按功能可化分为5个主要模块：

(1)消息报文管理模块。负责将用户数据封装为UDP-RTPS协议类型的消息包，并解析接收到的UDP-RTPS消息包；

(2)动态发现模块。在节点应用运行过程中，周期性地发送动态加入报文，将本节点的位置信息和实体信息告知其它节点；

(3)节点信息管理模块。维护本节点订阅者、发布者信息和位置相关信息等；维护与本节点有通信需求的订阅者及其位置信息等；

(4)事件处理模块。解耦各个功能模块，处理各个模块产生的事件，并协调各模块之间的交互；

(5)数据模型库模块。用户根据实际场景，对数据建模后的模型库，通过模型预测更新数据，减少发送设备和接收设备之间的通信数据量。

2.2 功能裁剪

完整的DDS规范对通信协议和API接口进行了标准化，从通信层面的发现、连接、QoS、交互等到软件层面的实体对象、消息构建和接口定义等，均有较为详细地说明。因此完整的DDS通信中间件对资源有较高的要求。

为了能够在资源有限的设备上实现DDS中间件的部署，必须对其功能和协议进行裁剪。在深入研究DDS规范和物联网网络模型后，将QoS策略和RTPS协议作为主要优化对象。

DDS支持多达22种QoS策略，除了基于传输可靠性的策略，还有基于优先级、传输时间和资源限制等高级策略。多样化的QoS支持提高了应用的灵活性[15]，但同时也增加了应用程序对计算、存储资源的需求。在一般的中小型区域化网络环境中，嵌入式设备是主要的组成节点，基于可靠性的QoS策略可以满足大部分的应用需求。因此，本文针对嵌入式设备设计的DDS通信中间件仅实现基于可靠性的QoS策略。

DDS使用RTPS协议进行通信的数据报文被称为消息。消息由各种子消息组成，包括数据子消息、心跳子消息、时间戳子消息和数据分段子消息等。在嵌入式场景中，大部分节点发送的是通过传感器获取的短数据，仅需一个消息就可以完成传输，对于少量较长的数据，用户可以通过简单的分段机制，实现数据的传输。因此，将RTPS中与数据分段相关的数据段子消息、数据段NACK子消息和数据段心跳子消息略去，可减少协议栈处理过程中的分支判断次数，同时也减少了代码体积。

2.3 基于卡尔曼滤波模型的数据分发

2.3.1 数据分类

在嵌入式系统中，节点间进行通信的数据类型可以简单分为3类：传感器数据、控制命令数据和流数据。各种数据特性如下：

(1)传感器数据。该数据是现实环境中的某些物理量(温度、湿度等)经由专门的转换芯片处理后得到的数值表示，与现实环境有较强的相关性。该类数据一般为周期性数据，且相邻数据间存在联系，具有可预测性；

(2)控制命令数据。由于某些事件或中断的发生，应用产生的控制指令信息的数值表示，例如灯开关、舵机转速等。该类数据需要较强的可靠性，以保证控制命令及时、准确地到达目标节点，调整目标节点工作状态，确保整个系统正常稳定运行；

(3)流数据。需要顺序、连续到达的大批量数据序列，例如视频、音频等。该类数据的传输要求尽快到达，并且允许一定的丢包率。

通过对嵌入式系统中3类数据特征的分析，可以看出3类数据在QoS要求、可预测性和连续性方面存在差异。对于控制命令数据和流数据，其不存在可预测性，仅对QoS具有特定要求，因此使用一般的发布/订阅方式即能够满足需求。对于传感器数据，由于其存在可预测性，因此可以使用某种模型来描述数据，这也是本设计的重点。

2.3.2 卡尔曼滤波

现实环境中的物理量一般为随时间变化的连续值。在实际环境中，传感器由于其自身的测量误差，测量得到的环境数据与真实的数据存在偏差，因此通常需要额外的数据处理算法对数据进行处理，得到较为准确的最优估计值。卡尔曼滤波算法由于实现简单和良好的估计性能，被广泛用作嵌入式系统中的数据修正算法[16]。

卡尔曼滤波算法适合用于对线性系统的估计，其状态空间模型可由预测方程和观测方程进行描述。对于离散数据，一般表示形式如式(1)和式(2)所示。

x(k)=F(k,k-1)x(k-1)+

B(k,k-1)u(k-1)+q(k)

(1)

z(k)=H(k)x(k)+r(k)

(2)

其中，x(k)表示第k个样本的状态；F(k,k-1)为从k-1到k时刻的状态转移矩阵；x(k-1)为第k-1个样本的状态；B(k,k-1)为k-1到k时刻的输入增益矩阵；u(k-1)为k-1时刻的输入向量；q(k)为k时刻的系统过程噪声；z(k)为k时刻的观测状态；H(k)为k时刻的转换矩阵；r(k)为k时刻的观测噪声。

在嵌入式系统中，传感器数据一般为周期性的离散数据，且具有较好的线性，适合由卡尔曼算法进行处理。同时，为了进一步简化模型，可以将式(1)中的输入相关项略去，之后由卡尔曼滤波算法相关理论[17]可得到如下方程：

(1)预测方程为

x(k|k-1)=F(k,k-1)x(k-1|k-1)

(3)

P(k|k-1)=F(k,k-1)P(k-1|k-1)FT(k,k-1)+Q(k)

(4)

(2)更新方程

(5)

x(k|k)=x(k|k-1)+K(k)(z(k)-H(k)·

x(k|k-1))

(6)

P(k|k)=(I-K(k)H(k))P(k|k-1)

(7)

其中，x(k|k-1)为根据k-1时刻的状态得到的k时刻的先验估计；x(k|k)为k时刻的最优状态估计；P(k|k-1)为k-1时刻到k时刻的预测误差协方差矩阵；Q(k)为过程误差协方差矩阵；P(k|k)为k时刻的滤波预测误差协方差矩阵；R(k)为观测误差协方差矩阵；I为单位矩阵。上述方程在卡尔曼滤波算法的执行过程中不断迭代，每次迭代后获得当前样本的最优估计值并更新模型。

2.3.3 基于卡尔曼滤波模型的发布/订阅

由式(3)可知，卡尔曼算法可以根据上一时刻样本状态的最优估计x(k-1|k-1)获得当前时刻样本的先验估计x(k|k-1)。若某传感器数据允许δ的误差，即k时刻样本的最优估计x(k|k)与当前时刻样本的先验估计x(k|k-1)存在如下关系

|x(k|k)-x(k|k-1)|≤δ

(8)

此时，可以将当前样本的最优估计值近似等价于当前时刻样本的先验估计，即

x(k|k)=x(k|k-1)=

F(k,k-1)x(k-1|k-1)

(9)

由式(9)可以看出，当允许存在δ的误差时，当前时刻的状态仅与上一时刻的状态和状态转移矩阵有关，不再与观测值相关。

在基于DDS的通信系统中，发布者负责观测传感器数据，并将观测数据发送至订阅者。结合上文的分析，若某时刻订阅者本地存储有上一时刻的最优估计数据，且数据允许一定的偏差，则当前时刻的最优估计可直接由上一时刻的最优估计数据得出，无需观测数据信息，即当前时刻，节点间可以不进行数据的传输。这样操作不仅节约了通信带宽，还降低了设备的能耗。

基于以上推论，本文在DDS中间件中，引入了一种基于卡尔曼滤波模型的发布订阅机制，在保证数据更新率的同时，降低了数据的传输量。

为了保证订阅者和发布者数据的同步更新，需要在两端部署相同的卡尔曼模型。发布者每次获得观测数据后，通过检验当前模型预测误差是否在允许范围内，决定是否向订阅者传送数据，算法伪代码如下所示：

Input:x:当前时刻传感器观测值

Input:δ:传感器数据容错门限

1:x′=由模型估计得到的传感器预测值；

2: if |x-x′| ≤δthen

3: 丢弃当前时刻传感器观测值x；

4: else

5: 根据当前时刻传感器观测值x更新模型；

6: 将当前传感器观测值x传送至订阅端；

7: end if

订阅者一般通过预测模型得到的预测值更新传感器数据。如果接收到发布者发送的新数据，代表当前模型预测精度不够，需要使用新数据更新模型，伪代码如下所示：

Input: flag:发布端数据到达标志

Input:x:订阅端收到的当前时刻传感器观测值

1: if flag == true then

2: 根据当前时刻传感器观测值x更新模型；

3: else

4: 由模型估计得到的传感器预测值x′；

5: 将传感器当前值更新为x′；

6: end if

2.4 基于QoS的单队列模型

在通信网络中，为了保证发送方和接收方数据的正常交互，通常需要在双方引入缓存队列。常见的缓存队列模型有多对列和单队列模型。从文献[18～19]中对多队列调度算法的分析可以看出，多队列模型需要较多的存储资源，而且调度算法的实现也较为复杂，不适合在计算能力较差的设备上部署。因此，本文基于精简后的两种DDS QoS策略，提出了一种基于QoS策略的单队列模型。该模型能够在占用较少内存资源和计算资源的情况下，最大程度地保证可靠类消息的传输，该算法的详细伪代码如下所示：

Input: msg:用户消息

Input:msgLen: 用户消息

Input:msgQoS: 用户消息QoS

1: Queue =发送队列；

2: ReplacedNode = 队列中被新消息替换的非可靠消息节点；

3: if msgQoS == Reliable then

4: if Queue已满 then

5: repeat

6: 从队列头部遍历非可靠消息节点ReplacedNode；

7: until ReplacedNode能够容纳msg；

8: 将ReplacedNode替换为msg；

9: else

10: 将msg插入Queue尾部；

11: end if

12: else

13: if Queue已满 then

14: 丢弃当前消息；

15: else

16: 将msg插入Queue尾部；

17: end if

18: end if

在基于QoS策略的单队列模型中，当发送缓冲空间充足时，新产生的所有用户消息按照顺序插入队列。一旦发送缓冲空间不足时，该算法将队列中的非可靠消息替换为新的可靠类消息，并将新的非可靠消息直接丢弃，避免因队列空间不足而导致可靠类消息丢失的情况发生。

3 测试验证

3.1 测试平台搭建

为了测试本文设计的轻量级DDS通信中间件的基本功能，搭建了由一台PC和一块STM32组成的硬件平台，两者之间通过网线直接连接。由于STM32使用百兆网连接PC，因此两者之间的最大数据传输速率为100 Mbit·s-1。其具体软硬件环境信息如表1所示。

表1 测试平台环境

本文在PC上运行Ubuntu18.04操作系统，其上部署了一个发布者应用A和一个订阅者应用B。此外，本文在STM32开发板上运行RT-Thread微内核操作系统，其上部署了一个发布者应用C和一个订阅者应用D。所有应用均使用本文设计的通信中间件进行交互，应用部署情况如图4所示。

图4 测试应用部署Figure 4. Test application deployment

3.2 基本功能测试

3.2.1 发布订阅功能测试

应用A发布“ubuntu_topic”主题，应用C发布“stm32_topic”主题，应用B同时订阅“ubuntu_topic”和“stm32_topic”主题，应用D订阅“ubuntu_topic”主题。该测试能够验证节点内部和节点间的基本收发功能是否正常。测试步骤如下：

步骤1启动应用B，订阅 “ubuntu_topic”和“stm32_topic”主题；

步骤2启动应用D，订阅“ubuntu_topic”主题；

步骤3应用C，发布主题“stm32_topic”主题；

步骤4最后启动应用B，发布“ubuntu_topic”主题；

步骤5观察应用B和应用D窗口输出信息，确认应用之间是否正确建立连接并通信。

由表2可以看出，本文提出的轻量级DDS通信中间件能够为同设备节点和不同设备节点间的分布式应用提供自动发现、自动连接和正常通信服务。

表2 节点通信测试结果

3.2.2 WireShark抓包分析

在Ubuntu18.04中运行WireShark网络抓包工具，获取应用运行过程中产生的数据包，验证 RTPS 消息格式是否满足规范要求。本通信中间件对RTPS协议进行了裁剪，主要支持4种类型子消息的编解码，分别是数据子消息、心跳包子消息、AckNack 子消息和时间戳子消息。实际应用中通过4种子消息的组合，可以实现SPDP消息包、SEDP消息包、数据确认数据包和用户消息数据包等，能够满足嵌入式领域中的基本通信需求。

表3 WireShark抓包解析结果

从表3结果可知，WireShark能够正确识别出RTPS协议类型，表明RTPS消息报文头构建正常，同时可以看到各消息内部子消息均正常列出，说明子消息构建符合RTPS规范，本通信中间件能够与标准的DDS通信中间件进行交互。

3.3 基本指标分析

3.3.1 资源占用情况

图5展示了在STM32+RT-Thread微内核操作系统的软件环境下，内存占用和发布/订阅实体数量之间的关系。当发布/订阅实体数量为0时，代表RT-Thread及基础支持软件占用的内存量。从图5可以看出，当引入通信中间件后，内存占用增加了约50 kB。之后随着通信实体数目的不断增加，内存占用呈线性增加，且可估算出每增加一个通信实体，内存占用增加约5 kB，表明该中间件具有较好的内存可预测性，能够根据实际设备的资源情况指定通信实体数目，充分利用内存资源。

图5 内存占用与发布/订阅实体数量关系Figure 5. Relationship between memory consumption and the number of publish/subscribe entities

3.3.2 额外通信开销

为了评估本文设计的DDS中间件引入的额外通信开销，以传统的UDP作为比较项。实验中PC端发布者A发送2 000次固定长度的消息，STM32端订阅者D接收到每接收一次完整消息后，由STM32端发布者C将接收到的消息回传到PC端的订阅者B，并记录其回环时间。之后将消息长度变为原来的2倍，并重复上述步骤。本系列实验的消息长度范围为 2 ～ 32 768 Byte，QoS配置为尽力而为策略。

图6 UDP 和 DDS 不同长度消息回环测试Figure 6. Different length message loopback test of UDP and DDS

由图6可以看出，使用本文设计的轻量级DDS中间件的在各种长度数据包下的回环时间和使用传统的UDP方式的回环时间差距相近，具有较低的额外时间开销，能够满足上层应用的实时性需求。

3.4 性能对比评估

为了更加全面的分析本文设计的轻量级DDS通信中间件的优缺点，并为后续研究提供指导，实验中将Micro XRCE-DDS和Cyclone DDS作为比较对象，两者均为开源轻量级DDS项目。

3.4.1 端到端延迟

端到端延时是评估系统响应速度的重要依据。在本实验中采用测量延时的经典方法。

E2E_delay=RTT/2

(10)

其中，RTT为从本节点发布者将数据提交到中间件开始，到本节点订阅者接收到远端发布者回传的数据为止所经过的时间。

在本实验中，所有的DDS测试流程如下：PC端发布者发送2 000次固定长度的消息。STM32端订阅者接收到每接收一次完整消息后，由STM32端发布者将接收到的消息回传到PC端的订阅者，并记录其回环时间。之后将消息长度变为原来的2倍，并重复上述步骤。本系列实验的消息长度范围为 2 ～ 16 384 Byte，QoS配置为尽力而为策略。

图7 不同DDS端到端延时对比Figure 7. End to end delay comparison of different DDS

由图7可以看出，Micro XRCE-DDS的端到端延时较高，主要原因是其基于代理的通信方式，使得所有数据的传输均需经过额外的数据通路和处理，增加了整体延时。Cyclone和本文设计的DDS均采用去中心化的设计方法，在短消息传输阶段，延时相近。此时的延时主要为系统任务调度和处理器开销带来的延时。随着数据量的不断增加，由于本文设计的DDS经过了功能裁剪，在协议解析过程中更加快捷，因此拥有更低的延时。

3.4.2 可建模数据传输

为了测试本文提出的基于卡尔曼滤波模型的对称式发布订阅机制对通信数据量的影响，设定如下场景及模型：

(1)场景为温度采集系统。温度保持在约25 ℃，发布端作为数据的采集和发送，以1 Hz的频率更新本地数据；订阅端负责对数据的收集和检测，数据更新率也为1 Hz，系统允许的最大数据误差为0.3 ℃，测试时间120 s；

(2)模型为卡尔曼模型，即F(k,k-1) = 1，H(k)= 1，Q(k) = 0.01，R(k) = 0.36，z(0)=

x(0|0) = 22.5。

测试结果如图8所示，X轴代表时间，Y主坐标轴代表当前温度的最优估计值，次坐标轴表代表通信信事件是否发生。在Y=1上的标记，代表发生了通信事件。由图8中可以看出，订阅者和发布者的最优估计值具有相同的变化趋势，且订阅端的误差在允许范围内，满足用户的数据精度需求。同时也可以看到，在120 s的测试时间内，共发生了56次的通信事件，降低了对通信带宽的需求。

图8 可建模数据更新及通信Figure 8. Updating and communication of modelable data

在该场景中，对于Micro XRCE-DDS和Cyclone DDS通信中间件，订阅者的数据更新均依赖于发布者发送的数据，因此在120 s的测试时间内共需触发120次通信事件。

综上所述，在该测试场景下，本文提出的基于模型的数据传输方式能够在保证数据精度的情况下，降低约50%的数据传输量。

4 结束语

本文在深入分析了DDS通信中间件的通信模型和交互消息格式后，结合嵌入式设备特点，对标准DDS功能进行了裁剪优化，使用C语言实现了一种可移植的、轻量化DDS通信中间件。该通信中间件引入了一种基于卡尔曼滤波模型的发布订阅机制，有效降低了通信中的冗余数据，节约了通信带宽资源。此外，使用基于QoS的单队列发送模型，降低了因为缓存空间不足导致可靠消息丢失的概率。经过在ARM和X86组成的异构平台上的部署测试，结构表明该通信中间件能够为分布式应用提供基本的DDS服务，支持自动组网、发布/订阅式数据传输、心跳检测和数据包确认机制，具有良好的响应速度且可以降低网络中的数据量，满足嵌入式应用通信的基本需求，为跨平台实时通信中间件的研究提供参考。在后续的研究中，将继续完善该通信中间件的功能，引入更加准确、高效的数据建模算法，并逐步扩展QoS策略，以满足嵌入式环境中对通信质量的多样化需求。