面向嵌入式異構平臺的高實時通信中間件設計

李路野 丁琳琳 黎賀

（南京電子技術研究所 江蘇省南京市 210039）

為了適應未來裝備支持新功能、新算法快速迭代和應用的需求，要求應用軟件與底層操作系統(tǒng)和硬件解耦合，通信中間件屏蔽了底層分布式異構硬件環(huán)境的差異，提供統(tǒng)一標準的通信接口，已經(jīng)成為雷達開放式體系架構的核心組成部分[1]。

雷達信息處理領域對實時性要求很高，多一次數(shù)據(jù)的拷貝都可能會帶來單幀數(shù)據(jù)時延的增加。為了最小化數(shù)據(jù)傳輸帶來的時延，本文提出了一種零拷貝方法設計面向嵌入式異構平臺的通信中間件。同時，為了支持應用靈活部署在不同節(jié)點上，應用層采用同一種通信接口實現(xiàn)了節(jié)點內、節(jié)點間的高實時通信。

1 國內外研究現(xiàn)狀

公共對象請求代理體系結構(CORBA, Common Object Request Broker Architecture)規(guī)范[2]由對象管理組織(OMG, Object Management Group)提出，于1991年頒布了1.0 版本。CORBA 技術用于提供分布式對象之間的互操作性，支持信息交換，獨立于硬件平臺、編程語言和操作系統(tǒng)。不過CORBA 標準過于復雜，并沒有大范圍流行。

2004年，OMG 組織提出了數(shù)據(jù)分發(fā)服務（DDS，Data Distribution Service）規(guī)范[3]，它是在CORBA 和HLA 等標準的基礎上，制定的分布式系統(tǒng)實時通信中間件技術規(guī)范。DDS 模型建立了共享數(shù)據(jù)空間的概念，數(shù)據(jù)發(fā)布者發(fā)布的數(shù)據(jù)可以被任何應用使用。數(shù)據(jù)的發(fā)布者和訂閱者之間解耦合，無需知道彼此是否存在，也不用關注底層通信實現(xiàn)細節(jié)，具有以下通信特點：

（1）可擴展性，新的用戶可以很容易地加入系統(tǒng)中，而系統(tǒng)本身不需要做任何改動；

（2）匿名性，信息生產(chǎn)者和消費者互相不向對方暴露自己的身份信息；

（3）多點通信，一個事件可以同時被發(fā)送到多個信息消費者；

（4）可配置通信，以數(shù)據(jù)為中心來進行數(shù)據(jù)分發(fā)，并將資源狀況、對資源的期待程度、網(wǎng)絡狀況等都用QoS 參數(shù)來配置，大大增強了通信的實時性和靈活性。如圖1 所示。

圖1：DDS 發(fā)布訂閱機制

劉巍等[4]對國產(chǎn)化實時通信中間件DDS 在X86、PPC T4240 和國產(chǎn)化華睿2 號處理平臺上的性能進行了針對性的優(yōu)化，其中X86 平臺平均性能為美國同類產(chǎn)品RTI DDS 的2 倍。

DDS 目前的收數(shù)接口和發(fā)數(shù)接口標準決定了其發(fā)數(shù)需要等數(shù)據(jù)發(fā)完或將數(shù)據(jù)拷貝到發(fā)數(shù)緩沖區(qū)，收數(shù)需要將數(shù)據(jù)拷貝到用戶指定地址空間。在某些數(shù)據(jù)傳輸時延要求極為嚴苛的場景下，DDS 難以滿足實際需求。

2 系統(tǒng)架構

面向嵌入式平臺的高實時通信中間件系統(tǒng)架構主要包括底層適配層、通用層、用戶接口層，如圖2 所示。

圖2：通信中間件系統(tǒng)架構

通信中間件系統(tǒng)架構自底向上包括：

（1）底層適配層：該層主要對DSP、CPU 等不同硬件平臺上用到的SRIO、UDP 等通信協(xié)議進行封裝。

（2）通用層：信息庫模塊作為服務器節(jié)點，所有的發(fā)布訂閱信息都在信息庫模塊中完成握手匹配；通用發(fā)布、訂閱注冊模塊則是支持應用往信息庫發(fā)送注冊信息。

（3）用戶接口層：該層參考DDS 規(guī)范接口，提供通用的基于發(fā)布訂閱機制收發(fā)數(shù)的接口。

本文工作的設計亮點在于為用戶的收發(fā)提供了兩對接口，發(fā)數(shù)接口包括preWrite 和write，其中preWrite是從發(fā)數(shù)緩沖區(qū)先申請一塊空間，將未來要發(fā)的數(shù)據(jù)放在其中，處理過程的目的地址可直接使用該地址，減少了一次數(shù)據(jù)拷貝；write 接口則是等要發(fā)的數(shù)準備好之后調用。收數(shù)接口包括read 和postRead，其中read 是獲取數(shù)據(jù)地址，當用戶使用完之后，調用postRead 釋放數(shù)據(jù)所占用的地址空間，減少了一次數(shù)據(jù)從緩沖區(qū)拷貝到用戶地址空間的操作。

3 節(jié)點內基于共享內存的通信

在CPU 或DSP 的單個節(jié)點內部，兩個不同應用之間利用通信中間件進行數(shù)據(jù)傳輸時，底層可采用共享內存的方式，其收發(fā)數(shù)流程如圖3 和圖4 所示。

圖3：共享內存發(fā)數(shù)流程

圖4：共享內存收數(shù)流程

對于共享內存通信，每個CPU/DSP 節(jié)點內部有一塊數(shù)據(jù)緩沖區(qū)DataBuf 用于存放應用間待收發(fā)的數(shù)據(jù)；每個主題對應一個地址緩沖區(qū)AddrFifo，發(fā)端把數(shù)據(jù)準備好后，將數(shù)據(jù)首地址和長度寫入AddrFifo，收端則從AddrFifo 中獲取數(shù)據(jù)地址和長度。

基于共享內存的收發(fā)數(shù)過程中緩沖區(qū)狀態(tài)變化過程如圖5 所示。

（1）緩沖區(qū)狀態(tài)1 表示在調用memPreWrite 之前，數(shù)據(jù)緩沖區(qū)的空間未被占用；

（2） 緩沖區(qū)狀態(tài)2 是指在發(fā)數(shù)應用調用memPreWrite 之后，數(shù)據(jù)緩沖區(qū)DataBuf 分配了一塊空間（陰影區(qū)域），表示該空間已分配，不能被其它應用使用；

（3）緩沖區(qū)狀態(tài)3 是指發(fā)數(shù)應用將數(shù)據(jù)已經(jīng)寫入DataBuf（灰色區(qū)域）；

（4）緩沖區(qū)狀態(tài)4 是發(fā)數(shù)應用在調用memWrite 后，將對應的數(shù)據(jù)緩沖區(qū)首地址和長度寫入主題對應的地址緩沖區(qū)AddrFifo 中；

（5）緩沖區(qū)狀態(tài)5 是收數(shù)應用調用memRead 接口讀取地址緩沖區(qū)AddrFifo，并按照其中的首地址和長度去數(shù)據(jù)緩沖區(qū)DataBuf 中獲取數(shù)據(jù)并使用；

（6）緩沖區(qū)狀態(tài)6 是指收數(shù)應用在使用完數(shù)據(jù)后調用memPostRead 釋放對DataBuf 灰色區(qū)域的占用。

通過上述緩沖區(qū)狀態(tài)變化過程分析，數(shù)據(jù)從在應用A 中產(chǎn)生到應用B 中使用，沒有經(jīng)歷過數(shù)據(jù)拷貝，真正做到了零拷貝數(shù)據(jù)傳輸。而傳統(tǒng)的數(shù)據(jù)收發(fā)接口，即便同樣是基于共享內存，發(fā)數(shù)應用至少要將數(shù)據(jù)拷貝到發(fā)數(shù)緩沖區(qū)，然后收數(shù)應用將數(shù)據(jù)拷貝到應用申請的地址空間，至少多出兩次數(shù)據(jù)拷貝時間。

4 DSP節(jié)點間基于Rapid IO的通信

在兩個DSP節(jié)點之間，數(shù)據(jù)收發(fā)采用Rapid IO協(xié)議，節(jié)點間的收發(fā)數(shù)流程如下。

（1）收發(fā)端基于主題進行開窗等初始化操作，窗口大小可配置，窗口地址由通信中間件統(tǒng)一管理；初始化時發(fā)端啟動發(fā)數(shù)任務，收端啟動收數(shù)任務。

（2）發(fā)端所在節(jié)點包含一個統(tǒng)一的數(shù)據(jù)緩沖區(qū)DataBuf_send 和地址緩沖區(qū)AddrFifo，如圖6 所示。

圖6：發(fā)數(shù)端的部件調用接口過程和發(fā)數(shù)任務流程

1.首先在數(shù)據(jù)緩沖區(qū)申請一段空間（srioPreWrite），存放將要發(fā)送的數(shù)據(jù),真實數(shù)據(jù)前會由中間件添加一個包頭，包括要發(fā)送的目的SRIO 號；

2.待數(shù)據(jù)放入數(shù)據(jù)緩沖區(qū)后，將該段數(shù)據(jù)的首地址和長度放入地址緩沖區(qū)AddrFifo 內（srioWrite）；

3.發(fā)數(shù)任務通過讀取地址緩沖區(qū)AddrFifo 中的地址列表逐個發(fā)數(shù)，發(fā)數(shù)的參數(shù)除了數(shù)據(jù)首地址和長度，還包括數(shù)據(jù)包頭中數(shù)據(jù)的目的SRIO；

4.發(fā)數(shù)完成后，會緊接著發(fā)送一個門鈴給收端。

（3）收端對應每個發(fā)數(shù)節(jié)點有獨立的收數(shù)緩沖區(qū)DataBuf_recv_i，（收數(shù)緩沖區(qū)直接在收窗映射的空間內創(chuàng)建，不再額外申請）對應每一個訂閱的主題各有一個地址緩沖區(qū)AddrFifo_j，如圖7 所示。

圖7：收數(shù)端收數(shù)過程

1.收端在收到門鈴之后，響應門鈴服務函數(shù)將門鈴號和門鈴值存放在DoorBellFifo 中，收數(shù)任務監(jiān)測DoorBellFifo，通過門鈴來源SRIO 號判斷收到的數(shù)據(jù)在哪個收數(shù)緩沖區(qū)；

2.讀取收到的數(shù)據(jù)包頭，獲取該數(shù)據(jù)對應的主題信息，將該段數(shù)據(jù)的首地址和長度存入相應主題在收數(shù)節(jié)點上對應的地址緩沖區(qū)；

3.部件通過srioRead 獲取AddrFifo_j 中相應數(shù)據(jù)的首地址和長度；

4.數(shù)據(jù)使用完畢后，通過srioPostRead 釋放數(shù)據(jù)空間。

DSP 節(jié)點間基于Rapid IO 的通信時，兩個節(jié)點上緩沖區(qū)的狀態(tài)變化過程如圖8 所示。

圖8：節(jié)點間通信時緩沖區(qū)狀態(tài)

在CPU 節(jié)點間通常采用UDP 網(wǎng)絡傳輸協(xié)議，整個通信過程與上文所屬DSP 節(jié)點間基于Rapid IO 的通信中間件設計原理基本一致，文中不再重復描述。

5 總結

針對雷達信息處理低時延需要，本文提出了一種嵌入式平臺高實時通信中間件設計，其主要具有2 個特點：

（1）從接口形式上來說，將收數(shù)和發(fā)數(shù)接口分別從一個設計為一對，確保要發(fā)送的數(shù)據(jù)直接在發(fā)數(shù)緩沖區(qū)中產(chǎn)生，接收的數(shù)據(jù)直接在接收緩沖區(qū)中使用，真正做到數(shù)據(jù)零拷貝、降低時延；

（2）從覆蓋的底層傳輸協(xié)議來說，支持節(jié)點內的共享內存和節(jié)點間的Rapid IO 傳輸，并且可以做到節(jié)點內和節(jié)點間傳輸協(xié)議的自適應，節(jié)省傳輸開銷。