基于DDS中間件的數據分發平臺的設計與實現

何旭 張國超 代中華

(上海船舶電子設備研究所 上海市 201108）

1 引言

隨著我國對海軍裝備的投入，艦載裝備朝著信息化發展，裝備系統面臨軟件開發周期越來越短、系統組成越來越復雜、不同設備間傳輸規模越來越大、數據傳輸定制性越來越高的現狀。傳統基于套接字的編程方式越來越無法滿足現有的通訊需求，為了適應通訊層面的變化，國外裝備軟件開始廣泛使用DDS 以數據為中心的通訊新架構。2004年對象管理組織發布第一版基于發布/訂閱結構的通訊規范[1]，如圖1，DDS 中間件位于頂層應用軟件和底層系統中間[2]，獨立于操作系統和編程語言,屏蔽底層通訊細節[3]，極大地方便異構設備間的通訊，簡化軟件開發細節。目前應用范圍十分廣泛，包括軍事、航天航空、金融交易以及工業自動化等領域[4]。

2 系統總體設計

2.1 需求分析

聲納系統是一個典型的分布式實時系統，數據分發平臺是聲納系統中的一個重要組成部分，接收來自傳感器的戰場數據、系統內部狀態數據和外部系統控制數據等，經過數據校驗、處理后轉發給上級系統和系統內部的各上網節點。數據分發平臺的網絡傳輸要求：

2.1.1 實時性 高吞吐

為實現對戰場環境感知，艦載裝備軟件必須通過傳感器接收、轉發大容量的戰場環境數據，這些數據具有高頻、數據量大、實時處理、接收處理順序等特點，同時為了保證各種戰術指標，數據傳輸模塊必須要在規定的時間內完成相應的處理，這就要求設計的系統要滿足高實時、高吞吐的要求。

2.1.2 可靠性

某些傳感器傳過來的實時環境數據對可靠性要求并不高，即使出現丟包也不會對整個系統造成影響，但對于諸如命令、武器控發等報文，可靠性就尤為重要，這些關鍵數據不僅不能出現丟包現象，并且對于報道接收順序也極為敏感。

2.1.3 低耦合 可擴展性

圖1：DDS 中間件層次結構

圖2：通訊架構

圖3：軟件模塊關系圖

同一系統由于不同艦船的性質或者在開發過程中增減內部設備導致在編寫程序時經常會遇到設備上網節點的增減帶來代碼重寫的情況，為減少應用程序開發難度，需降低不同上網節點的耦合度，實現當刪減網絡節點時，減少對其他節點的影響。

2.1.4 動態配置

由于各上網節點的任務功能有差別，對于傳感器數據看重是其實時性，而命令、狀態數據則更多的是保證收方可靠地接收，這就要求裝備軟件能夠動態配置數據傳輸的方式，以便軟件能快速升級維護。

2.2 總體設計

作為一個典型的分布式復雜系統，聲吶系統由大量的異構設備組成，包括類Linux 和類VxWorks 計算機、DSP、FPGA 等硬件設備、公共計算服務設備等。數據分發平臺是作為聲吶系統的通訊核心進行設計，它需要完成系統內部多類型數據的適配轉換，對系統內部各設備的上網節點的中轉，對顯控軟件、傳感器、數據庫等的控制，產生波形控制數據，作為聲吶系統唯一與外部系統通信的平臺完成對內部數據的向外轉發。對數據分發平臺設計時,考慮到盡量不去修改復雜設備已有的成熟設計，對這些設備軟件依舊通過傳統套接字或者串口獨立進行通訊，但向外轉送時使用DDS 中間件。同時為減少轉發時的相互干擾并保持系統內外部模塊間的獨立運行，將通訊通道分為內部域和外部域分別進行DDS 通訊，具體通訊設計如圖2 所示。

3 軟件實現

數據分發平臺基于國產中標麒麟系統、RTI DDS5.1.0，采用模塊化設計思想，將軟件分為主控模塊、串口通訊模塊、UDP通訊模塊、DDS 通訊模塊、數據處理模塊。各軟件模塊間接口關系如圖3 所示。

3.1 主控模塊

主控模塊是數據分發系統的控制中心，主要完成初始化并管理系統內的軟硬件資源、創建并啟動各任務和信號量消息隊列、執行系統時鐘任務等。當軟件啟動/關閉時自動加載/卸載主控模塊。

isError = iniitialize(); //資源的初始化

QtConcurrent::run(com,&cCom::tcomRecv ); //創建串口數據接收處理任務

QtConcurrent::run(socket,&cUdpSocket::udpTask ); // 啟動內部udp 通訊任務

QtConcurrent::run(dds ,&cDDS::internalTask );// 啟動內部DDS通訊任務

QtConcurrent::run(dds,&cDDS:: externalTask );//啟動外部DDS通訊接收任務

3.2 串口通訊模塊

串口模塊完成與系統內部設備間的串口數據交互。在軟件啟動時，創建并激活串口發送、接收任務。串口接收任務定時查詢串口接收緩沖區數據并處理；

3.3 UDP通訊模塊

UDP 通訊模塊完成與系統內部設備間的網絡數據交互。軟件啟動時創建、初始化udp 通訊對象、啟動接收任務、注冊DDS 轉發句柄，接收到數據后進行數據拼裝，根據目的設備選擇udp 句柄或者dds 句柄向外轉送。

3.4 DDS通訊模塊

dds 模塊完成與系統內外部設備間的網絡數據交互。啟動時創建、初始化DDS 對象,配置相應的QOS，注冊udp 轉發句柄，接收到數據后進行數據拼裝，根據目的設備選擇udp 句柄或者dds 句柄向外轉送。

3.5 數據處理模塊

圖4：性能測試

數據處理模塊對發送到分發平臺的數據報文進行檢查校驗，減少錯誤數據包向外發送，對確認無誤的數據包進行相應的處理。

amendData(pAmendedBuf,pRecvBuf,recvSize,DEVICE_RECORD)//校驗數據

SetFuncMap(pFuncMap);//配置處理函數指針

pFuncMap[packFlag]((char*)&gRecRecvBuあ.buあer[0]);//使 用 相應函數處理

4 測試驗證

為保證滿足裝備硬性需求，對本設計進行驗證。驗證包括功能性測試和性能測試兩部分。同時使用Windows 端模擬器代替設計階段尚缺的設備。測試環境下所采用的配置如表1 所示，其中數據分發平臺基于國產架構開發。

表1：測試環境

4.1 冗余切換測試

本文的功能測試是指對兩臺功能一致的設備通過配置QOS，設置不同的優先級，進行網絡切換。顯示控制軟件是系統人機交互的重要節點，正常情況下，兩臺顯控設備各自發布訂閱專屬的數據報文，現考慮當遇到突發情況，某一主顯控設備發生故障（測試時直接斷電處理），無法正常發送人機交互數據，從顯控設備應立即進行軟件層面資源重組，配置主設備相應的交互模塊，數據收取設訂閱從設備發布的主設備數據。而當主設備恢復了正常運行，數據收取設備恢復訂閱主設備發布的數據。對比傳統模式的通訊，當某上網節點發生故障時，其他接受節點將得不到任何數據。因此，以數據為中心的通訊模式極大地降低了系統因故障而發生癱瘓的風險性。

4.2 性能測試

考慮裝備軟件實際應用的特點，性能測試對通訊過程的實時性、穩定性進行驗證。實時性是裝備軟件通信系統最重要的指標，報文的發送接收需在指定的時間內完成，否則超出時間完成也沒有意義甚至會導致系統錯亂。衡量實時性可以通過系統數傳時延(Latency)來衡量，發布端一直循環發數據，其中數據大小可以改變。接收端循環收到數據并進行數據的統計，控制數據長度變量。穩定性是系統通信質量的另一重要的指標，通過測量通訊過程中的丟包率衡量通訊穩定性。測試中統一報文長度，通過控制報文數據量進行對比，測試結果如圖4 所示。

從測試結果可以看出，傳輸時延與數據長度呈現正相關，報文長度在1024 字節以內，時延控制在100us 以內，當長度超過1024字節，傳輸時延明顯增加。同時可靠傳輸相對于盡力傳輸，時延增加明顯，這是因為可靠傳輸在內部通信細節上增加了應答等處理步驟，保證數據不丟包，這會使得數據在處理傳輸過程中有一定的時間開銷。在穩定性測試中可靠傳輸在不同速率條件下，均實現了傳輸不丟包，而盡力傳輸為追求傳輸性能，在報文量超過2000 條/秒是，丟包率大幅上升。在實際應用中，需根據不同設備的通訊需求選擇切合的QOS、合理劃分報文長度。同時時延、丟包率等傳輸性能還與CPU 性能、網絡帶寬等有關，全面國產化后還應對傳輸性能進行進一步的測試。

5 結束語

本文簡要介紹了DDS 中間件，詳細分析數據分發平臺的需求，確定了采用以DDS 混合udp 的通訊架構，在軟件層面上對各個模塊進行詳細的功能講解和代碼實例,最后對平臺進行功能、性能的測試，測試表明，本設計能有效滿足系統需求。以數據為中心的DDS 中間件應用在分布式的通訊網絡中展現出優于套接字的獨特優勢，通過選用豐富的DDS 策略適應數據傳輸在性能、可靠性、耦合度多方面的需求，同時也大大降低軟件開發周期。