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

李路野 丁琳琳 黎賀

（南京電子技術研究所 江蘇省南京市 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 傳輸，并且可以做到節點內和節點間傳輸協議的自適應，節省傳輸開銷。