面向嵌入式异构平台的高实时通信中间件设计

李路野 丁琳琳 黎贺

（南京电子技术研究所 江苏省南京市 210039）

为了适应未来装备支持新功能、新算法快速迭代和应用的需求，要求应用软件与底层操作系统和硬件解耦合，通信中间件屏蔽了底层分布式异构硬件环境的差异，提供统一标准的通信接口，已经成为雷达开放式体系架构的核心组成部分[1]。

雷达信息处理领域对实时性要求很高，多一次数据的拷贝都可能会带来单帧数据时延的增加。为了最小化数据传输带来的时延，本文提出了一种零拷贝方法设计面向嵌入式异构平台的通信中间件。同时，为了支持应用灵活部署在不同节点上，应用层采用同一种通信接口实现了节点内、节点间的高实时通信。

1 国内外研究现状

公共对象请求代理体系结构(CORBA, Common Object Request Broker Architecture)规范[2]由对象管理组织(OMG, Object Management Group)提出，于1991年颁布了1.0 版本。CORBA 技术用于提供分布式对象之间的互操作性，支持信息交换，独立于硬件平台、编程语言和操作系统。不过CORBA 标准过于复杂，并没有大范围流行。

2004年，OMG 组织提出了数据分发服务（DDS，Data Distribution Service）规范[3]，它是在CORBA 和HLA 等标准的基础上，制定的分布式系统实时通信中间件技术规范。DDS 模型建立了共享数据空间的概念，数据发布者发布的数据可以被任何应用使用。数据的发布者和订阅者之间解耦合，无需知道彼此是否存在，也不用关注底层通信实现细节，具有以下通信特点：

（1）可扩展性，新的用户可以很容易地加入系统中，而系统本身不需要做任何改动；

（2）匿名性，信息生产者和消费者互相不向对方暴露自己的身份信息；

（3）多点通信，一个事件可以同时被发送到多个信息消费者；

（4）可配置通信，以数据为中心来进行数据分发，并将资源状况、对资源的期待程度、网络状况等都用QoS 参数来配置，大大增强了通信的实时性和灵活性。如图1 所示。

图1：DDS 发布订阅机制

刘巍等[4]对国产化实时通信中间件DDS 在X86、PPC T4240 和国产化华睿2 号处理平台上的性能进行了针对性的优化，其中X86 平台平均性能为美国同类产品RTI DDS 的2 倍。

DDS 目前的收数接口和发数接口标准决定了其发数需要等数据发完或将数据拷贝到发数缓冲区，收数需要将数据拷贝到用户指定地址空间。在某些数据传输时延要求极为严苛的场景下，DDS 难以满足实际需求。

2 系统架构

面向嵌入式平台的高实时通信中间件系统架构主要包括底层适配层、通用层、用户接口层，如图2 所示。

图2：通信中间件系统架构

通信中间件系统架构自底向上包括：

（1）底层适配层：该层主要对DSP、CPU 等不同硬件平台上用到的SRIO、UDP 等通信协议进行封装。

（2）通用层：信息库模块作为服务器节点，所有的发布订阅信息都在信息库模块中完成握手匹配；通用发布、订阅注册模块则是支持应用往信息库发送注册信息。

（3）用户接口层：该层参考DDS 规范接口，提供通用的基于发布订阅机制收发数的接口。

本文工作的设计亮点在于为用户的收发提供了两对接口，发数接口包括preWrite 和write，其中preWrite是从发数缓冲区先申请一块空间，将未来要发的数据放在其中，处理过程的目的地址可直接使用该地址，减少了一次数据拷贝；write 接口则是等要发的数准备好之后调用。收数接口包括read 和postRead，其中read 是获取数据地址，当用户使用完之后，调用postRead 释放数据所占用的地址空间，减少了一次数据从缓冲区拷贝到用户地址空间的操作。

3 节点内基于共享内存的通信

在CPU 或DSP 的单个节点内部，两个不同应用之间利用通信中间件进行数据传输时，底层可采用共享内存的方式，其收发数流程如图3 和图4 所示。

图3：共享内存发数流程

图4：共享内存收数流程

对于共享内存通信，每个CPU/DSP 节点内部有一块数据缓冲区DataBuf 用于存放应用间待收发的数据；每个主题对应一个地址缓冲区AddrFifo，发端把数据准备好后，将数据首地址和长度写入AddrFifo，收端则从AddrFifo 中获取数据地址和长度。

基于共享内存的收发数过程中缓冲区状态变化过程如图5 所示。

（1）缓冲区状态1 表示在调用memPreWrite 之前，数据缓冲区的空间未被占用；

（2） 缓冲区状态2 是指在发数应用调用memPreWrite 之后，数据缓冲区DataBuf 分配了一块空间（阴影区域），表示该空间已分配，不能被其它应用使用；

（3）缓冲区状态3 是指发数应用将数据已经写入DataBuf（灰色区域）；

（4）缓冲区状态4 是发数应用在调用memWrite 后，将对应的数据缓冲区首地址和长度写入主题对应的地址缓冲区AddrFifo 中；

（5）缓冲区状态5 是收数应用调用memRead 接口读取地址缓冲区AddrFifo，并按照其中的首地址和长度去数据缓冲区DataBuf 中获取数据并使用；

（6）缓冲区状态6 是指收数应用在使用完数据后调用memPostRead 释放对DataBuf 灰色区域的占用。

通过上述缓冲区状态变化过程分析，数据从在应用A 中产生到应用B 中使用，没有经历过数据拷贝，真正做到了零拷贝数据传输。而传统的数据收发接口，即便同样是基于共享内存，发数应用至少要将数据拷贝到发数缓冲区，然后收数应用将数据拷贝到应用申请的地址空间，至少多出两次数据拷贝时间。

4 DSP节点间基于Rapid IO的通信

在两个DSP节点之间，数据收发采用Rapid IO协议，节点间的收发数流程如下。

（1）收发端基于主题进行开窗等初始化操作，窗口大小可配置，窗口地址由通信中间件统一管理；初始化时发端启动发数任务，收端启动收数任务。

（2）发端所在节点包含一个统一的数据缓冲区DataBuf_send 和地址缓冲区AddrFifo，如图6 所示。

图6：发数端的部件调用接口过程和发数任务流程

1.首先在数据缓冲区申请一段空间（srioPreWrite），存放将要发送的数据,真实数据前会由中间件添加一个包头，包括要发送的目的SRIO 号；

2.待数据放入数据缓冲区后，将该段数据的首地址和长度放入地址缓冲区AddrFifo 内（srioWrite）；

3.发数任务通过读取地址缓冲区AddrFifo 中的地址列表逐个发数，发数的参数除了数据首地址和长度，还包括数据包头中数据的目的SRIO；

4.发数完成后，会紧接着发送一个门铃给收端。

（3）收端对应每个发数节点有独立的收数缓冲区DataBuf_recv_i，（收数缓冲区直接在收窗映射的空间内创建，不再额外申请）对应每一个订阅的主题各有一个地址缓冲区AddrFifo_j，如图7 所示。

图7：收数端收数过程

1.收端在收到门铃之后，响应门铃服务函数将门铃号和门铃值存放在DoorBellFifo 中，收数任务监测DoorBellFifo，通过门铃来源SRIO 号判断收到的数据在哪个收数缓冲区；

2.读取收到的数据包头，获取该数据对应的主题信息，将该段数据的首地址和长度存入相应主题在收数节点上对应的地址缓冲区；

3.部件通过srioRead 获取AddrFifo_j 中相应数据的首地址和长度；

4.数据使用完毕后，通过srioPostRead 释放数据空间。

DSP 节点间基于Rapid IO 的通信时，两个节点上缓冲区的状态变化过程如图8 所示。

图8：节点间通信时缓冲区状态

在CPU 节点间通常采用UDP 网络传输协议，整个通信过程与上文所属DSP 节点间基于Rapid IO 的通信中间件设计原理基本一致，文中不再重复描述。

5 总结

针对雷达信息处理低时延需要，本文提出了一种嵌入式平台高实时通信中间件设计，其主要具有2 个特点：

（1）从接口形式上来说，将收数和发数接口分别从一个设计为一对，确保要发送的数据直接在发数缓冲区中产生，接收的数据直接在接收缓冲区中使用，真正做到数据零拷贝、降低时延；

（2）从覆盖的底层传输协议来说，支持节点内的共享内存和节点间的Rapid IO 传输，并且可以做到节点内和节点间传输协议的自适应，节省传输开销。