何旭 張國超 代中華

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

1 引言

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

2 系統(tǒng)總體設(shè)計

2.1 需求分析

聲納系統(tǒng)是一個典型的分布式實時系統(tǒng)，數(shù)據(jù)分發(fā)平臺是聲納系統(tǒng)中的一個重要組成部分，接收來自傳感器的戰(zhàn)場數(shù)據(jù)、系統(tǒng)內(nèi)部狀態(tài)數(shù)據(jù)和外部系統(tǒng)控制數(shù)據(jù)等，經(jīng)過數(shù)據(jù)校驗、處理后轉(zhuǎn)發(fā)給上級系統(tǒng)和系統(tǒng)內(nèi)部的各上網(wǎng)節(jié)點。數(shù)據(jù)分發(fā)平臺的網(wǎng)絡(luò)傳輸要求：

2.1.1 實時性 高吞吐

為實現(xiàn)對戰(zhàn)場環(huán)境感知，艦載裝備軟件必須通過傳感器接收、轉(zhuǎn)發(fā)大容量的戰(zhàn)場環(huán)境數(shù)據(jù)，這些數(shù)據(jù)具有高頻、數(shù)據(jù)量大、實時處理、接收處理順序等特點，同時為了保證各種戰(zhàn)術(shù)指標，數(shù)據(jù)傳輸模塊必須要在規(guī)定的時間內(nèi)完成相應(yīng)的處理，這就要求設(shè)計的系統(tǒng)要滿足高實時、高吞吐的要求。

2.1.2 可靠性

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

2.1.3 低耦合 可擴展性

圖1：DDS 中間件層次結(jié)構(gòu)

圖2：通訊架構(gòu)

圖3：軟件模塊關(guān)系圖

同一系統(tǒng)由于不同艦船的性質(zhì)或者在開發(fā)過程中增減內(nèi)部設(shè)備導(dǎo)致在編寫程序時經(jīng)常會遇到設(shè)備上網(wǎng)節(jié)點的增減帶來代碼重寫的情況，為減少應(yīng)用程序開發(fā)難度，需降低不同上網(wǎng)節(jié)點的耦合度，實現(xiàn)當(dāng)刪減網(wǎng)絡(luò)節(jié)點時，減少對其他節(jié)點的影響。

2.1.4 動態(tài)配置

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

2.2 總體設(shè)計

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

3 軟件實現(xiàn)

數(shù)據(jù)分發(fā)平臺基于國產(chǎn)中標麒麟系統(tǒng)、RTI DDS5.1.0，采用模塊化設(shè)計思想，將軟件分為主控模塊、串口通訊模塊、UDP通訊模塊、DDS 通訊模塊、數(shù)據(jù)處理模塊。各軟件模塊間接口關(guān)系如圖3 所示。

3.1 主控模塊

主控模塊是數(shù)據(jù)分發(fā)系統(tǒng)的控制中心，主要完成初始化并管理系統(tǒng)內(nèi)的軟硬件資源、創(chuàng)建并啟動各任務(wù)和信號量消息隊列、執(zhí)行系統(tǒng)時鐘任務(wù)等。當(dāng)軟件啟動/關(guān)閉時自動加載/卸載主控模塊。

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

QtConcurrent::run(com,&cCom::tcomRecv ); //創(chuàng)建串口數(shù)據(jù)接收處理任務(wù)

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

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

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

3.2 串口通訊模塊

串口模塊完成與系統(tǒng)內(nèi)部設(shè)備間的串口數(shù)據(jù)交互。在軟件啟動時，創(chuàng)建并激活串口發(fā)送、接收任務(wù)。串口接收任務(wù)定時查詢串口接收緩沖區(qū)數(shù)據(jù)并處理；

3.3 UDP通訊模塊

UDP 通訊模塊完成與系統(tǒng)內(nèi)部設(shè)備間的網(wǎng)絡(luò)數(shù)據(jù)交互。軟件啟動時創(chuàng)建、初始化udp 通訊對象、啟動接收任務(wù)、注冊DDS 轉(zhuǎn)發(fā)句柄，接收到數(shù)據(jù)后進行數(shù)據(jù)拼裝，根據(jù)目的設(shè)備選擇udp 句柄或者dds 句柄向外轉(zhuǎn)送。

3.4 DDS通訊模塊

dds 模塊完成與系統(tǒng)內(nèi)外部設(shè)備間的網(wǎng)絡(luò)數(shù)據(jù)交互。啟動時創(chuàng)建、初始化DDS 對象,配置相應(yīng)的QOS，注冊udp 轉(zhuǎn)發(fā)句柄，接收到數(shù)據(jù)后進行數(shù)據(jù)拼裝，根據(jù)目的設(shè)備選擇udp 句柄或者dds 句柄向外轉(zhuǎn)送。

3.5 數(shù)據(jù)處理模塊

圖4：性能測試

數(shù)據(jù)處理模塊對發(fā)送到分發(fā)平臺的數(shù)據(jù)報文進行檢查校驗，減少錯誤數(shù)據(jù)包向外發(fā)送，對確認無誤的數(shù)據(jù)包進行相應(yīng)的處理。

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

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

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

4 測試驗證

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

表1：測試環(huán)境

4.1 冗余切換測試

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

4.2 性能測試

考慮裝備軟件實際應(yīng)用的特點，性能測試對通訊過程的實時性、穩(wěn)定性進行驗證。實時性是裝備軟件通信系統(tǒng)最重要的指標，報文的發(fā)送接收需在指定的時間內(nèi)完成，否則超出時間完成也沒有意義甚至?xí)?dǎo)致系統(tǒng)錯亂。衡量實時性可以通過系統(tǒng)數(shù)傳時延(Latency)來衡量，發(fā)布端一直循環(huán)發(fā)數(shù)據(jù)，其中數(shù)據(jù)大小可以改變。接收端循環(huán)收到數(shù)據(jù)并進行數(shù)據(jù)的統(tǒng)計，控制數(shù)據(jù)長度變量。穩(wěn)定性是系統(tǒng)通信質(zhì)量的另一重要的指標，通過測量通訊過程中的丟包率衡量通訊穩(wěn)定性。測試中統(tǒng)一報文長度，通過控制報文數(shù)據(jù)量進行對比，測試結(jié)果如圖4 所示。

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

5 結(jié)束語

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