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

0 引言

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

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

1 軟件設計原理

1.1 DDS通信模型

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

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

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

1.2 軟件編程方法

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

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

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

圖2 任務容器示意圖

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

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

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

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

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

圖3 模板方法示意圖

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

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

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

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

圖4 任務派發(fā)機制

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

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

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

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

圖6 軟件運行流程

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

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

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

圖7 管理軟件界面

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

圖8 計算節(jié)點界面

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

圖9 兼容模式軟件

2.2 性能測試

2.2.1 實時性測試

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

圖10 實時性能測試流程圖

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

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

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

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

圖11 實時性測試比較

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

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

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

3 結(jié)束語

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

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