(中國飛行試驗(yàn)研究院 測試所，西安 710089)

0 引言

試飛試驗(yàn)遙測監(jiān)控系統(tǒng)是實(shí)現(xiàn)飛行器機(jī)載數(shù)據(jù)的實(shí)時采集、傳輸、數(shù)據(jù)處理和實(shí)時監(jiān)控的重要設(shè)施，在保證試飛試驗(yàn)安全、完成試飛科目方面具有必不可少的重要作用，測試數(shù)據(jù)在監(jiān)控終端的實(shí)時、準(zhǔn)確、全面的顯示是確保試飛安全、提高試飛效率、縮短試飛周期的重要手段。現(xiàn)有的飛行試驗(yàn)遙測實(shí)時監(jiān)控系統(tǒng)主要有C/S、B/S兩種架構(gòu)，主要由遙測接收解調(diào)、遙測實(shí)時處理、監(jiān)控顯示三個部分構(gòu)成。C/S結(jié)構(gòu)采用服務(wù)器-客戶端模式，數(shù)據(jù)服務(wù)器接收、解析、轉(zhuǎn)發(fā)機(jī)載采集系統(tǒng)通過遙測系統(tǒng)傳輸來的試驗(yàn)機(jī)PCM調(diào)制碼流及視頻數(shù)據(jù)，客戶端通過Socket套接字進(jìn)行接收、處理及顯示。這種模式下，每一個飛行任務(wù)都需要一臺服務(wù)器進(jìn)行數(shù)據(jù)接收，各個服務(wù)器獨(dú)立運(yùn)行，飛行任務(wù)數(shù)據(jù)無法進(jìn)行集中管理，且服務(wù)器僅針對下行遙測鏈路設(shè)計(jì)，沒有對未來上行遙測鏈路的擴(kuò)充，監(jiān)控終端僅能顯示遙測系統(tǒng)的數(shù)據(jù)，無法接入其他數(shù)據(jù)源信息。UDP傳輸?shù)臒o連接、不可靠特性也造成了實(shí)時監(jiān)控系統(tǒng)數(shù)據(jù)包的丟失。B/S結(jié)構(gòu)使用WEB服務(wù)器實(shí)現(xiàn)對各個飛行任務(wù)數(shù)據(jù)的接收與分發(fā)，解決了C/S架構(gòu)下任務(wù)管理的問題，但是同時具有服務(wù)器依賴度高、實(shí)時性不強(qiáng)等問題。一旦服務(wù)器故障，將影響整個試飛試驗(yàn)的進(jìn)行。以上兩種監(jiān)控系統(tǒng)模式均不具備靈活的數(shù)據(jù)接入功能 ，導(dǎo)致分布于各地的異構(gòu)實(shí)時監(jiān)控系統(tǒng)由于數(shù)據(jù)包協(xié)議的不同無法進(jìn)行有效交互，無法滿足異地異構(gòu)監(jiān)控系統(tǒng)協(xié)同試飛任務(wù)監(jiān)控需求。另一方面，系統(tǒng)的一臺監(jiān)控終端僅能顯示一個試驗(yàn)機(jī)的PCM及視頻遙測數(shù)據(jù)，采用了面向目標(biāo)的設(shè)計(jì)思路，而不是面向數(shù)據(jù)的設(shè)計(jì)思路，無法滿足多機(jī)協(xié)同試飛監(jiān)控需求。系統(tǒng)缺少服務(wù)器狀態(tài)監(jiān)管、數(shù)據(jù)交互、服務(wù)質(zhì)量及數(shù)據(jù)實(shí)時性的管控，容錯率小。數(shù)據(jù)收發(fā)網(wǎng)絡(luò)出現(xiàn)問題后往往通過人工進(jìn)行檢查，效率低下。

針對以上問題，研究對象管理組織為異構(gòu)平臺提供的數(shù)據(jù)交互標(biāo)準(zhǔn)—數(shù)據(jù)分發(fā)服務(wù)規(guī)范DDS(data distribute service)進(jìn)行實(shí)時監(jiān)控系統(tǒng)的搭建[1]。 DDS可以實(shí)現(xiàn)異構(gòu)系統(tǒng)的數(shù)據(jù)實(shí)時交互、可靈活接入不同協(xié)議數(shù)據(jù)并提供Qos(quality of service，服務(wù)質(zhì)量)服務(wù)質(zhì)量控制，增強(qiáng)系統(tǒng)的擴(kuò)展性及靈活性[2]。基于DDS可以實(shí)現(xiàn)分布式多任務(wù)數(shù)據(jù)計(jì)算分發(fā)，解決C/S和B/S監(jiān)控系統(tǒng)模式下的任務(wù)管控、質(zhì)量控制、高可靠性[3]等問題，實(shí)現(xiàn)高質(zhì)量、低延遲的試飛數(shù)據(jù)傳輸。

1 軟件設(shè)計(jì)原理

1.1 DDS通信模型

DDS是基于發(fā)布/訂閱模式[4]的通信模型。DDS將分布式網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)定義為主題(Topic),將數(shù)據(jù)的產(chǎn)生和接收對象分別定義為發(fā)布者(Publisher)和訂閱者(Subscriber)從而構(gòu)成數(shù)據(jù)的發(fā)布/訂閱傳輸模型結(jié)構(gòu)。各個節(jié)點(diǎn)在邏輯上無主從關(guān)系，在服務(wù)質(zhì)量策略(quality of servicepolicies)控制下建立連接。各個節(jié)點(diǎn)可通過全局?jǐn)?shù)據(jù)空間獲取其他節(jié)點(diǎn)的狀態(tài)信息。DDS 發(fā)布/訂閱模型如圖1所示。

圖1 DDS 發(fā)布/訂閱模型

DDS可實(shí)現(xiàn)分布式的監(jiān)控系統(tǒng)，發(fā)布者進(jìn)行試飛數(shù)據(jù)的接收與解析、定義話題并發(fā)布，監(jiān)控端的訂閱者可以訂閱自己所需要看的主題，這種模式可增強(qiáng)系統(tǒng)的計(jì)算能力及容錯率，QoS的靈活配置可對數(shù)據(jù)傳輸通道上的可靠性、傳輸優(yōu)先級、數(shù)據(jù)過濾進(jìn)行設(shè)置，不同于UDP傳輸?shù)臒o連接、無反饋[5]，DDS傳輸可以準(zhǔn)確獲得一次數(shù)據(jù)發(fā)送與接收狀態(tài)的所有信息，從而實(shí)現(xiàn)數(shù)據(jù)的高可靠性傳輸,因此軟件以DDS通信模型作為基礎(chǔ)通信模型，結(jié)合現(xiàn)有監(jiān)控系統(tǒng)數(shù)據(jù)傳輸特點(diǎn)實(shí)現(xiàn)基于DDS的多源數(shù)據(jù)實(shí)時監(jiān)控系統(tǒng)。

1.2 軟件編程方法

1.2.1 基于任務(wù)容器的試飛數(shù)據(jù)接收解算

傳統(tǒng)的試飛監(jiān)控模式中每一臺數(shù)據(jù)處理服務(wù)器對實(shí)時數(shù)據(jù)進(jìn)行接收解析，實(shí)際試飛試驗(yàn)中多個任務(wù)同時進(jìn)行，需要給多個任務(wù)分配計(jì)算資源，資源的分配由人進(jìn)行完成，硬件的故障以及人為因素很有可能導(dǎo)致數(shù)據(jù)接收異常。因此采用基于任務(wù)容器[6]的處理單元實(shí)現(xiàn)試飛數(shù)據(jù)的數(shù)據(jù)解算，任務(wù)的分配由管理端自動完成，任務(wù)在任務(wù)容器中并行，每一個任務(wù)可以進(jìn)行不同業(yè)務(wù)的處理。任務(wù)容器設(shè)計(jì)成自動為任務(wù)分配CPU邏輯核心，讓業(yè)務(wù)能夠獨(dú)占CPU進(jìn)行計(jì)算，提高任務(wù)處理的可靠性和實(shí)時性。

每一個計(jì)算節(jié)點(diǎn)均對應(yīng)一個任務(wù)容器，在計(jì)算飛行任務(wù)時，飛行任務(wù)管理端對各個容器狀態(tài)進(jìn)行分析，通過將任務(wù)分發(fā)給各個節(jié)點(diǎn)進(jìn)行計(jì)算實(shí)現(xiàn)穩(wěn)定的高性能分布式實(shí)時處理系統(tǒng)[7]。在管理端進(jìn)行任務(wù)容器、任務(wù)的管理及狀態(tài)信息顯示，管理端軟件可實(shí)時監(jiān)控各個計(jì)算節(jié)點(diǎn)的狀態(tài)并進(jìn)行任務(wù)的重新調(diào)整分配。管理端與計(jì)算節(jié)點(diǎn)通過DDS通信協(xié)議進(jìn)行交互，可以獲得彼此的狀態(tài)信息，如圖2所示。

圖2 任務(wù)容器示意圖

計(jì)算節(jié)點(diǎn)端由容器Container和任務(wù)Worker組成。Container是一個任務(wù)集合容器，用于對任務(wù)進(jìn)行添加刪除啟動停止等內(nèi)部管理工作，Container負(fù)責(zé)接收由管理端下達(dá)的控制指令和上報(bào)計(jì)算端信息。Worker是執(zhí)行具體業(yè)務(wù)的任務(wù)，所有業(yè)務(wù)邏輯代碼編寫在Worker任務(wù)內(nèi)，例如數(shù)據(jù)的接收、數(shù)據(jù)的解析和數(shù)據(jù)的處理等。Worker可被手動分配到單個或多個CPU核心當(dāng)中以調(diào)整不同的系統(tǒng)性能和并發(fā)性。對不同的Worker之間，容器Container提供數(shù)據(jù)的交互傳輸，用戶可以定義Worker的數(shù)據(jù)輸出和數(shù)據(jù)輸入。例如，將數(shù)據(jù)接收任務(wù)和數(shù)據(jù)處理任務(wù)如果定義至兩個不同的Worker之中[8]，數(shù)據(jù)接收任務(wù)需要額外將接收的數(shù)據(jù)定義為數(shù)據(jù)輸出，數(shù)據(jù)處理任務(wù)需要額外將接收的數(shù)據(jù)定義為數(shù)據(jù)輸入，便可進(jìn)行不同的Worker之間的數(shù)據(jù)交互。對于數(shù)據(jù)僅進(jìn)行單向流動并任務(wù)之間具有強(qiáng)耦合的任務(wù)，可通過將多個任務(wù)代碼寫入一個任務(wù)以減輕任務(wù)難度和提供傳輸效率。任務(wù)容器需要包含增加任務(wù)、開始執(zhí)行/停止某一個任務(wù)、開始執(zhí)行/停止所有任務(wù)、開始發(fā)送數(shù)據(jù)、停止發(fā)送數(shù)據(jù)、數(shù)據(jù)接收顯示等功能，使用一個類Container進(jìn)行描述。在創(chuàng)建飛行任務(wù)后，管理軟件首先獲得各個計(jì)算節(jié)點(diǎn)的信息，對其狀態(tài)進(jìn)行分析，然后將任務(wù)分配給資源豐富的節(jié)點(diǎn)，如果正在進(jìn)行任務(wù)處理的計(jì)算節(jié)點(diǎn)負(fù)載過載或者出現(xiàn)異常，管理軟件可以實(shí)時獲得節(jié)點(diǎn)信息并重新分配計(jì)算節(jié)點(diǎn)，增強(qiáng)了系統(tǒng)的魯棒性。

1.2.2 基于模板方法的解析算法架構(gòu)

異構(gòu)網(wǎng)絡(luò)聯(lián)合監(jiān)控情況下，需要在異構(gòu)遙測系統(tǒng)之間進(jìn)行數(shù)據(jù)接收和解析。在現(xiàn)有的C/S監(jiān)控模式下，不同監(jiān)控系統(tǒng)之間的數(shù)據(jù)協(xié)議是不同的，數(shù)據(jù)包結(jié)構(gòu)上的差異導(dǎo)致需要開發(fā)新的數(shù)據(jù)服務(wù)器軟件對數(shù)據(jù)流進(jìn)行接收和解析。每類協(xié)議需要配備一種協(xié)議解析模塊，新增一種數(shù)據(jù)源就需要開發(fā)相應(yīng)的解析模塊，為異構(gòu)網(wǎng)絡(luò)下的實(shí)時監(jiān)控帶來很大的工作量。

模板方法設(shè)計(jì)模式定義一個操作中的算法骨架，而將算法的一些步驟延遲到子類中，使得子類可以不改變該算法結(jié)構(gòu)的情況下重定義該算法的某些特定步驟。它是一種類行為型模式。因此對各種試飛遙測數(shù)據(jù)進(jìn)行分析，采用基于模板方法[9]的解析算法架構(gòu)使實(shí)時監(jiān)控系統(tǒng)具有接入任何軟件應(yīng)用接口的能力。

對監(jiān)控系統(tǒng)接入的各種數(shù)據(jù)的數(shù)據(jù)包協(xié)議進(jìn)行分析，發(fā)現(xiàn)其具有一定的共性，提取和提升這些共性，形成基類。當(dāng)有新的數(shù)據(jù)源接入時，僅需少量修改程序代碼，繼承基類對其數(shù)據(jù)包進(jìn)行解析，從而具有接入各個數(shù)據(jù)源的能力。

圖3 模板方法示意圖

1.2.3 基于序列化和活躍度檢查的任務(wù)派發(fā)機(jī)制

序列化是將對象的狀態(tài)信息轉(zhuǎn)換為可以存儲或傳輸?shù)男问降倪^程。在序列化期間，對象將其當(dāng)前狀態(tài)寫入到臨時或持久性存儲區(qū)。以后，可以通過從存儲區(qū)中讀取或反序列化對象的狀態(tài)，重新創(chuàng)建該對象。軟件在對任務(wù)的創(chuàng)建中，采用面向?qū)ο蟮乃枷?，使用類描述一個任務(wù)的執(zhí)行方式。

任務(wù)管理端通過序列化將新建的任務(wù)發(fā)送給計(jì)算節(jié)點(diǎn)進(jìn)行處理[10]，計(jì)算節(jié)點(diǎn)首先通過反序列化、實(shí)例化形成任務(wù)對象，然后將其添加至任務(wù)容器，實(shí)現(xiàn)任務(wù)的執(zhí)行。

在實(shí)時監(jiān)控中，計(jì)算節(jié)點(diǎn)有可能出現(xiàn)故障，因此軟件需要發(fā)現(xiàn)故障及重新分配任務(wù)節(jié)點(diǎn)的能力。通過在DDS通信數(shù)據(jù)中加入計(jì)算節(jié)點(diǎn)的狀態(tài)信息，在進(jìn)行任務(wù)派發(fā)的過程中，管理端通過與各個節(jié)點(diǎn)進(jìn)行通信，獲得各個計(jì)算節(jié)點(diǎn)的活躍度信息[11]，獲得整個系統(tǒng)的硬件狀態(tài)信息及任務(wù)處理狀態(tài)，如硬盤容量、CPU使用狀態(tài)、內(nèi)存使用情況等，管理端可以監(jiān)控各個計(jì)算節(jié)點(diǎn)的狀態(tài)實(shí)現(xiàn)任務(wù)的最優(yōu)分配。當(dāng)某個計(jì)算節(jié)點(diǎn)因意外突然異?；蛘哧P(guān)閉的情況下，管理軟件自動進(jìn)行計(jì)算節(jié)點(diǎn)的重新分配，保障實(shí)時任務(wù)的持續(xù)進(jìn)行。任務(wù)派發(fā)流程如圖4所示。

圖4 任務(wù)派發(fā)機(jī)制

1.3 軟件結(jié)構(gòu)及運(yùn)行流程

軟件結(jié)構(gòu)如圖5所示，采用分布式結(jié)構(gòu)的主從模式[11]，計(jì)算節(jié)點(diǎn)軟件分布于各個計(jì)算機(jī)客戶端，任務(wù)管理軟件進(jìn)行任務(wù)的管理及分配，并將相關(guān)數(shù)據(jù)存儲于數(shù)據(jù)庫中，數(shù)據(jù)傳輸采用DDS通信協(xié)議，解析出來的數(shù)據(jù)最終通過兼容模式軟件傳輸給監(jiān)控畫面。

圖5 軟件結(jié)構(gòu)

軟件運(yùn)行流程如圖6所示，在試飛任務(wù)準(zhǔn)備階段，通過配置帶頭信息、交換機(jī)地址等信息創(chuàng)建數(shù)據(jù)接收任務(wù)。管理節(jié)點(diǎn)會自動將任務(wù)分別給各個計(jì)算節(jié)點(diǎn)進(jìn)行執(zhí)行，計(jì)算節(jié)點(diǎn)對數(shù)據(jù)進(jìn)行相應(yīng)結(jié)算后可通過兼容數(shù)據(jù)處理軟件實(shí)現(xiàn)試飛數(shù)據(jù)對監(jiān)控畫面的驅(qū)動，從而完成試飛實(shí)時監(jiān)控任務(wù)。

圖6 軟件運(yùn)行流程

2 實(shí)現(xiàn)及性能測試

2.1 軟件實(shí)現(xiàn)展示

管理軟件界面如圖7所示，管理軟件實(shí)現(xiàn)對任務(wù)的分發(fā)與集中管理，并實(shí)時監(jiān)測各個計(jì)算節(jié)點(diǎn)的運(yùn)行狀態(tài)，提高試飛監(jiān)控系統(tǒng)的可靠性與穩(wěn)定性。

圖7 管理軟件界面

計(jì)算節(jié)點(diǎn)運(yùn)行界面如圖8所示，計(jì)算節(jié)點(diǎn)會顯示PCM帶頭信息及心跳字，用于判斷數(shù)據(jù)接收狀態(tài)。

圖8 計(jì)算節(jié)點(diǎn)界面

數(shù)據(jù)接收界面如圖9所示，通過接受不同節(jié)點(diǎn)上的數(shù)據(jù)，可將飛行數(shù)據(jù)實(shí)時顯示與監(jiān)控畫面上。

圖9 兼容模式軟件

2.2 性能測試

2.2.1 實(shí)時性測試

系統(tǒng)實(shí)時性測試引入時間同步服務(wù)器，實(shí)時監(jiān)控系統(tǒng)通過接收、解析試飛遙測數(shù)據(jù)，將時間顯示于監(jiān)控畫面上，同時得到時間同步服務(wù)器發(fā)來的時間信息，通過比較兩個時間，得到數(shù)據(jù)處理延遲，從而完成實(shí)時性能測試。實(shí)時性能測試流程如圖10所示。

圖10 實(shí)時性能測試流程圖

2.2.2 帶寬受限情況下數(shù)據(jù)傳輸性能測試

對交換機(jī)端口進(jìn)行帶寬設(shè)置，在受限帶寬狀態(tài)下對采用基于任務(wù)容器的多源數(shù)據(jù)實(shí)時監(jiān)控技術(shù)的監(jiān)控系統(tǒng)的數(shù)據(jù)傳輸性能進(jìn)行測試，遙測數(shù)據(jù)帶寬為10 M。分別設(shè)置交換機(jī)網(wǎng)口帶寬為100 M、50 M、20 M、10 M情況下，對基于任務(wù)容器的多源數(shù)據(jù)實(shí)時監(jiān)控系統(tǒng)和現(xiàn)有的基于Socket的監(jiān)控系統(tǒng)進(jìn)行測試。

2.3 測試結(jié)果與分析

如圖11為基于任務(wù)容器的多源數(shù)據(jù)實(shí)時監(jiān)控技術(shù)與現(xiàn)有監(jiān)控系統(tǒng)性能結(jié)果比較，可以看出基于任務(wù)容器的監(jiān)控系統(tǒng)由于其通信協(xié)議的優(yōu)勢，具有更好的實(shí)時性能，其數(shù)據(jù)處理時間延遲僅為30 ms以下，而現(xiàn)有的監(jiān)控系統(tǒng)，基于Socket編程通信，數(shù)據(jù)延遲高達(dá)50 ms。在不同帶寬下進(jìn)行測試，從圖12可以看出 ，在一定范圍內(nèi)帶寬的減少對采用基于任務(wù)容器的監(jiān)控技術(shù)的監(jiān)控系統(tǒng)數(shù)據(jù)處理性能影響不大。在帶寬很小的極端狀態(tài)下，系統(tǒng)仍可以進(jìn)行數(shù)據(jù)處理，數(shù)據(jù)延遲在可接受范圍內(nèi)，而現(xiàn)有監(jiān)控系統(tǒng)如圖13所示，在小帶寬的情況下，延遲高達(dá)10秒左右，系統(tǒng)已經(jīng)無法使用。

圖11 實(shí)時性測試比較

圖12 不同帶寬下的數(shù)據(jù)延遲

圖13 低帶寬下數(shù)據(jù)延遲比較

綜上可以得出，任務(wù)容器的多源數(shù)據(jù)實(shí)時監(jiān)控系統(tǒng)具有更好的數(shù)據(jù)傳輸性能，且提供任務(wù)的管理功能，便于操作。

3 結(jié)束語

針對現(xiàn)有遙測實(shí)時監(jiān)控系統(tǒng)存在的不足，在數(shù)據(jù)分發(fā)服

務(wù)中間件DDS的基礎(chǔ)上研究基于任務(wù)容器的多源數(shù)據(jù)實(shí)時監(jiān)控技術(shù)，經(jīng)過實(shí)際測試與使用，該系統(tǒng)運(yùn)行穩(wěn)定，不僅滿足數(shù)據(jù)實(shí)時性要求，而且可以接入時間服務(wù)器、天氣、地理等多源信號，支持不同的數(shù)據(jù)包解析，提高了系統(tǒng)的靈活性。與C/S架構(gòu)監(jiān)控模式相比，具有易于管理、穩(wěn)定性高、數(shù)據(jù)傳輸可靠等優(yōu)點(diǎn)。目前實(shí)時監(jiān)控系統(tǒng)逐漸走向智能化，基于任務(wù)容器的多源數(shù)據(jù)實(shí)時監(jiān)控系統(tǒng)提供了與云平臺傳輸數(shù)據(jù)的接口，未來可整合到基于云計(jì)算的分布式智能化監(jiān)控系統(tǒng)中。