航電系統(tǒng)并行檢測過程與檢測設備解耦方法

劉艷芳，呂江花,*，馬世龍，黎濤

1.北京航空航天大學 計算機學院，北京 100083 2.北京航空航天大學 軟件開發(fā)環(huán)境國家重點實驗室，北京 100083

航空電子系統(tǒng)(簡稱航電系統(tǒng))是飛機為完成正常的飛行任務或其他特定任務(如預警、氣象探測、通信導航識別等)而設計的電子系統(tǒng)[1]。隨著航電系統(tǒng)逐漸向數(shù)字化、綜合化和模塊化方向發(fā)展，系統(tǒng)中越來越多的硬件功能被軟件實現(xiàn)所取代，航電系統(tǒng)正逐漸向軟件密集型系統(tǒng)演變[2-4]。從系統(tǒng)結構來說，航電系統(tǒng)是典型的大型復雜分布式系統(tǒng)，由多個分系統(tǒng)組成，各分系統(tǒng)又由多個部署在不同計算機上的計算機軟件配置項(Computer Software Configuration Item，CSCI)，是指滿足最終使用功能的可進行單獨配置管理的軟件集合)組成。在研制過程中，系統(tǒng)以軟件配置項的形式被外包提供，并最終通過集成各軟件配置項形成整個系統(tǒng)。這些軟件配置項在使用或升級改造過程中難免會出現(xiàn)因系統(tǒng)軟件配置項的相關安裝文件、執(zhí)行文件等被篡改或者軟件配置項更新時版本號與版本不匹配引起軟件配置項不一致和不完整的問題。這些問題都將使得航電系統(tǒng)相應軟件配置項無法正常運行，最終導致系統(tǒng)運行出現(xiàn)問題。

另一方面，航電系統(tǒng)軟件安全可靠運行需要適配的軟件運行環(huán)境資源支撐。根據(jù)文獻[4]，當前典型的綜合模塊化航電(Integrated Modular Avionics,IMA)系統(tǒng)體系結構自頂向下可抽象為應用軟件層(即航電系統(tǒng)應用軟件或軟件配置項)、操作系統(tǒng)層、模塊支持層和硬件資源層共4層。其中，下面3層(即操作系統(tǒng)層、模塊支持層和硬件資源層)共同為應用軟件層提供服務支撐，被稱為航電系統(tǒng)的軟件運行環(huán)境。航電系統(tǒng)的軟件運行環(huán)境為航電系統(tǒng)運行提供各類資源，如操作系統(tǒng)API(Application Program Interface)、內存、CPU、存儲空間等。由于航電系統(tǒng)是安全攸關系統(tǒng)，其運行環(huán)境的適配性對航電系統(tǒng)安全可靠運行至關重要。

因此，需要對航電系統(tǒng)的軟件配置項一致性和軟件運行環(huán)境適配性進行檢測以保證航電系統(tǒng)運行的正確性和可靠性。檢測不同于測試，測試側重于對被測系統(tǒng)功能和性能方面的評估和驗證，而檢測是對被測系統(tǒng)的健康性檢測，是對經(jīng)測試后的被測系統(tǒng)做進一步驗證。檢測又分為靜態(tài)檢測和動態(tài)檢測，其中，動態(tài)檢測是在航電系統(tǒng)運行時通過采集運行時相關數(shù)據(jù)進行分析。靜態(tài)檢測則是在航電系統(tǒng)非運行時，對系統(tǒng)(從配置級)進行檢測以保證航電系統(tǒng)能正常啟動和運行。因此，靜態(tài)檢測是航電系統(tǒng)正確運行的前提保證。本文主要考慮航電系統(tǒng)的靜態(tài)檢測問題。

在當前批量航電系統(tǒng)大量投入使用的背景下，采用自動化檢測技術[5-7]已成為這類復雜系統(tǒng)檢測的必然趨勢。自動化檢測過程一般是檢測任務發(fā)送檢測指令給檢測設備，檢測設備根據(jù)檢測指令對被測系統(tǒng)執(zhí)行檢測并從被測系統(tǒng)獲取所需要的檢測數(shù)據(jù)，然后發(fā)送給檢測任務進行分析和研判的過程。對于航電系統(tǒng)來說，當前檢測面臨的問題具體表現(xiàn)為：① 檢測過程與檢測設備之間耦合，檢測設備與被測航電系統(tǒng)之間耦合，檢測人員需為每個被測系統(tǒng)配置專用的檢測設備，并需要給新配置的檢測設備編寫驅動程序，檢測通用性和易用性受限；② 檢測安全性要求高，內置檢測軟件受限，檢測過程中不允許出現(xiàn)對系統(tǒng)的任何更改、駐留和泄露等行為；③ 檢測任務繁重，檢測周期短，檢測頻率高，檢測人員需要在較短的時間內完成對多個航電系統(tǒng)的檢測工作，例如起飛前、降落后都需要進行頻繁的日常檢測。其中，問題①的解決有助于問題②的解決，也有助于推動問題③的解決。因此，本文聚焦于問題①的解決。

設備協(xié)同是檢測過程與檢測設備解耦的有效方法。特別是當前計算機技術高速發(fā)展，航電系統(tǒng)檢測逐漸由單機檢測模式轉變?yōu)槎啾粶y系統(tǒng)并行檢測模式，檢測系統(tǒng)需要具有通用性，即獨立于具體檢測數(shù)據(jù)、具體被測系統(tǒng)和具體檢測設備，這就要求檢測系統(tǒng)能夠支持各種被測系統(tǒng)和檢測設備的動態(tài)加入和退出，同時能夠動態(tài)協(xié)同各檢測設備對被測系統(tǒng)進行并行檢測，因此，檢測設備協(xié)同的動態(tài)性和開放性是航電系統(tǒng)并行檢測中檢測過程與具體檢測設備解耦合的關鍵問題。

基于上述問題，本文在自動化檢測語言[8]的基礎上，提出一種航電系統(tǒng)并行檢測分層框架，支持檢測設備與被測系統(tǒng)解耦合，以提高檢測系統(tǒng)的通用性。通過這種分層框架也保證了檢測過程的安全性。在此基礎上，定義檢測設備協(xié)同機制，解決檢測過程與檢測設備耦合的問題，從而支持多個航電系統(tǒng)并行檢測。最后通過實際案例應用和實驗對比驗證本文所提方法的有效性。

1 相關工作

目前，針對航電系統(tǒng)的檢測技術主要有自動測試系統(tǒng)(Automatic Test System，ATS)、機內自檢(Built-in Test，BIT)、預測與健康管理(Prognostics and Health Management，PHM)等。其中，ATS通過測試系統(tǒng)主任務計算機控制自動地完成各種模式的激勵、相應信號的采集、存儲和分析，進而實現(xiàn)被測單元(Unit Under Test，UUT)狀態(tài)的自動監(jiān)控、性能的自動測試和故障的自動診斷。到目前為止，ATS的發(fā)展共經(jīng)歷了專用設備、模塊化設計和通用標準化3個階段，應用領域也正在由最初的海、陸、空軍專用向各軍通用和軍民通用發(fā)展。特別是，在下一代ATS(即NxTest)計劃被提出之后，自動測試系統(tǒng)的研制都以NxTest計劃中的各種規(guī)范為參考正在從接口和總線等硬件通用逐漸向軟硬件通用發(fā)展。在通用自動測試系統(tǒng)發(fā)展中，國外尤以美國和法國為代表的自動測試系統(tǒng)技術上最為成熟，如美國洛克希德·馬丁公司研制的加固型自動支持系統(tǒng)(Consolidated Automated Support System,CASS)，法國宇航公司推出的ATEC6系列通用測試平臺和SESAR3000系列通用測試平臺。中國也有一些自主研制的ATS，例如可視化測試程序集成環(huán)境軟件GTest、自動測試系統(tǒng)軟件平臺TestCenter等，主要用于自動化測試。在自動化檢測方面成果較少，更多的是采用BIT或者PHM技術進行分析和預測。

BIT技術是為了提高檢測效率在系統(tǒng)內部設計了硬、軟件或利用本身部分功能部件完成對其自身的故障檢測、故障定位(對于單一的外場可換單元)、錯誤診斷等[9]。從20世紀70年代常規(guī)BIT被首次提出后，BIT技術的發(fā)展又經(jīng)歷了基于人工智能的BIT和針對功能板級、分系統(tǒng)級和系統(tǒng)級的分級BIT兩個階段。PHM技術是對BIT技術和狀態(tài)(健康)監(jiān)控能力的進一步拓展，包括“預測”和“健康管理”兩個部分，其中預測是根據(jù)現(xiàn)在或歷史狀態(tài)記錄預測性地診斷部件或系統(tǒng)完成其功能的狀態(tài)；健康管理是根據(jù)診斷/預測信息、可用資源和使用需求對維修活動作出適當決策[10]。目前，這兩種技術已被廣泛應用于航電系統(tǒng)自動化檢測中，但在實際應用中他們存在各自的不足。如BIT技術是內嵌在被測系統(tǒng)內部的，理論上其規(guī)模一般被要求不能超過被測系統(tǒng)的10%[11]，工程實踐中有所放寬，但一般也不超過20%[12]，這在一定程度上限制其功能，另外，也存在測試和診斷能力差、虛警率較高等問題。PHM則由于數(shù)據(jù)獲取困難，其虛警率一直達不到理想狀態(tài)，PHM也存在開發(fā)周期長、成本高等不足。也正因此，當前對BIT技術和PHM技術的研究以提高其檢測和診斷準確率作為發(fā)展重點。

近幾年本文作者所在研究團隊一直致力于航電系統(tǒng)自動化檢測方面工作并取得了初步的研究成果[13]，研制了針對單機環(huán)境下的自動化檢測系統(tǒng)[14]，并已列裝。在新的武器裝備發(fā)展形勢下，需要研制分布式自動化檢測系統(tǒng)，能夠支持對不同型號飛機的航電系統(tǒng)進行并行檢測，提高檢測效率。在這種情況下，檢測系統(tǒng)需要能夠獨立于具體檢測設備，檢測設備與具體被測系統(tǒng)之間也需要解耦合。

在設備解耦方面，雷婉琦[15]將每類儀器設備的調用流程封裝為DLL并采用虛擬儀器軟件結構(Virtual Instrument Software Architecture,VISA)標準調用各儀器設備的DLL，可解決測試系統(tǒng)與主流儀器設備之間的耦合問題，缺乏對專用但非主流儀器設備的調用，另外也無法支持對儀器設備的動態(tài)協(xié)同。Helms和Tacha[16]將測試系統(tǒng)分層并抽象得到測試設備調用層，通過在測試設備調用層提出一種用戶靈活自定義和裁剪策略解決測試系統(tǒng)和陳舊測試設備之間的耦合問題。另有一些研究采用設備協(xié)同的方法解決設備耦合問題。比如，Mcmullen和Reichherzer提出一種基于本體的統(tǒng)一設備模型[17]，采用本體抽象描述不同類型設備，與具體設備類型解耦，但是缺乏對設備能力的描述。在信息設備資源共享協(xié)同服務(Intelligent Grouping and Resource Sharing,IGRS)標準[18]中，將每種設備根據(jù)其擁有的共享資源被抽象為一個IGRS設備類型，各IGRS設備通過通用的IGRS設備交互協(xié)議實現(xiàn)設備間協(xié)同交互，解決了應用和資源與具體設備類型耦合的問題，但缺乏對設備的統(tǒng)一描述。Hamadache和Lancieri提出一種適用于計算機支持的協(xié)同工作(Computer Supported Cooperative Work,CSCW)系統(tǒng)的協(xié)同模型[19-20]，將設備看作資源，通過設備在協(xié)同工作中可扮演的角色及其能力抽象描述不同類型設備資源，并給出設備協(xié)同規(guī)則，但缺乏對設備交互能力的描述。在設備協(xié)同建模語言方面，典型的有WS-BPEL[21]、YAWL[22]、BPMN[23]等，但大多是將設備服務封裝為Web服務，通過擴展已有工作流建模語言實現(xiàn)設備協(xié)同，缺乏對設備操作和設備協(xié)同執(zhí)行機制的描述，故難以實現(xiàn)設備間的直接協(xié)同，基于這類設備協(xié)同建模語言的應用系統(tǒng)與設備間的耦合度高、靈活性和開放性差。本文作者所在研究團隊通過總結現(xiàn)有設備協(xié)同系統(tǒng)及其關鍵技術，針對大規(guī)模設備協(xié)同應用的特點，提出了適用于大規(guī)模設備協(xié)同應用領域的流程建模語言[24]，通過抽象設備操作和定義設備操作的解釋執(zhí)行機制實現(xiàn)設備協(xié)同過程的自動化[25]，研制了航天器自動化測試系統(tǒng)[26]。然而，面向航天器自動化測試的設備協(xié)同語句并不能直接應用于航電系統(tǒng)自動化檢測。一方面，因為航電系統(tǒng)與航天器本身不同，航天器主要由電子元器件和硬件設備構成，而航電系統(tǒng)逐漸向軟件密集型系統(tǒng)發(fā)展；另一方面，執(zhí)行的任務不同，航天器測試是面向系統(tǒng)或組成部件功能和性能的測試，而本文中航電系統(tǒng)檢測是對系統(tǒng)的健康性檢測。這些使得其檢測模式不同，對應的設備協(xié)同機制不同，檢測安全性需求也不完全一樣。

2 檢測系統(tǒng)框架

航電系統(tǒng)是典型的安全攸關系統(tǒng)，因其檢測安全性要求高，對航電系統(tǒng)(特別是投入使用的航電系統(tǒng))進行檢測一般需要借助外置檢測設備通過其指定接口進行檢測。為此，本文在不影響被測系統(tǒng)正常運行的情況下部署檢測跳轉機(以下簡稱跳轉機)作為外置檢測設備。一方面，為檢測任務端訪問被測系統(tǒng)提供安全訪問接口，對被測系統(tǒng)子網(wǎng)上的任何設備進行檢測都必須通過跳轉機操作子網(wǎng)上被測主機完成；另一方面，從被測系統(tǒng)獲取的檢測數(shù)據(jù)(如軟件配置項文件數(shù)據(jù))在跳轉機完成計算后才反饋給檢測任務端，以保證被測系統(tǒng)的數(shù)據(jù)不直接傳輸?shù)綑z測任務端。

另外，被測航電系統(tǒng)組織結構復雜，規(guī)模龐大，且運行平臺異構多樣，例如，操作系統(tǒng)有VxWorks、Linux、Windows等3種，處理器有單核、多核等多種，而不同型號飛機的航電系統(tǒng)差異性更大，航電系統(tǒng)的這些特征使得檢測任務復雜性增加。在當前批量航電系統(tǒng)并行檢測需求背景下，為屏蔽被測系統(tǒng)的差異性和檢測任務的復雜性，本文在檢測任務端和跳轉機之間增加一個邏輯檢測設備，用于將復雜檢測任務轉換為對被測系統(tǒng)檢測的基本操作序列，并激勵檢測設備執(zhí)行檢測。

基于此，本文設計航電系統(tǒng)并行檢測系統(tǒng)分層框架，如圖1所示，由檢測任務端、邏輯檢測設備、跳轉機和被測系統(tǒng)4層組成。整個檢測系統(tǒng)框架又可按照圖中虛線分為前后端兩部分，前端由檢測任務端和部分邏輯檢測設備功能組成，主要完成檢測任務分解、并行調度與管理等；后端由邏輯檢測設備的另外部分功能、跳轉機和被測系統(tǒng)組成，主要通過邏輯檢測設備、跳轉機和被測主機之間協(xié)同交互完成檢測工作，以及采樣結果收集和研判。后端為前端的并行調度提供支持，本文重點關注后端。下面對后端各設備之間的交互過程作進一步介紹。

圖1 航電系統(tǒng)并行檢測系統(tǒng)分層框架Fig.1 Layered test system framework for parallel testing of avionics systems

被測系統(tǒng)即為被測航電系統(tǒng)軟件及其軟件運行環(huán)境，軟件運行環(huán)境實際為被測航電系統(tǒng)所在被測主機。被測系統(tǒng)為一個航電系統(tǒng)的多個分系統(tǒng)或者多個航電系統(tǒng)。對被測系統(tǒng)的檢測是通過跳轉機與被測系統(tǒng)中的被測主機交互完成。被測主機開放指定的接口供檢測使用，稱為被測主機的檢測API。被測主機與跳轉機之間的交互主要包括：從跳轉機接收文件一致性檢測請求和資源狀態(tài)適配性檢測激勵，執(zhí)行自身相應的檢測API，并響應被測文件數(shù)據(jù)和資源狀態(tài)數(shù)據(jù)給相應的跳轉機。

跳轉機通過對外提供檢測API來支持檢測，在檢測過程中從邏輯檢測設備接收文件一致性檢測請求或軟件運行環(huán)境資源狀態(tài)適配性檢測請求，對于文件一致性檢測請求，跳轉機執(zhí)行文件一致性檢測相關檢測API，首先與被測文件(軟件配置項文件和操作系統(tǒng)關鍵文件)所在的被測主機建立SSH-2(Secure SHell version 2)連接，然后從相應被測主機下載被測文件到本地進行特征計算；對于軟件運行環(huán)境資源狀態(tài)適配性檢測請求，跳轉機執(zhí)行另一類檢測API繼續(xù)向被測主機轉發(fā)該類請求。同時，也接收從被測主機發(fā)送來的被測文件數(shù)據(jù)和資源狀態(tài)數(shù)據(jù)，以及將采樣數(shù)據(jù)或者特征數(shù)據(jù)發(fā)送給邏輯檢測設備。

邏輯檢測設備也通過檢測API與跳轉機進行交互，對于檢測任務中不同的被測項目(如軟件配置項檢測、操作系統(tǒng)關鍵文件檢測或主機系統(tǒng)資源狀態(tài)檢測等)，邏輯檢測設備調用不同的檢測API。若進行文件一致性檢測，邏輯檢測設備發(fā)送文件一致性檢測相關的檢測API激勵跳轉機執(zhí)行一致性檢測API；若對其他軟件運行環(huán)境進行資源狀態(tài)適配性檢測，邏輯檢測設備發(fā)送資源狀態(tài)檢測相關的檢測API激勵跳轉機執(zhí)行另一類檢測API。

上述檢測系統(tǒng)分層框架可為航電系統(tǒng)并行檢測建立設備協(xié)同交互與統(tǒng)一訪問機制，進而支持檢測過程與檢測設備解耦合。

3 檢測數(shù)據(jù)表征與檢測設備協(xié)同

在以上檢測系統(tǒng)分層框架下的設備交互過程中，各設備既要根據(jù)交互信息選擇執(zhí)行不同的操作，又要運行著其內部常規(guī)程序以維護自身的狀態(tài)，他們之間需要協(xié)同工作才能確保整個系統(tǒng)安全可靠運行。另外，檢測過程涉及的設備類型和功能各不相同，設備數(shù)目眾多。為使得基于上述檢測系統(tǒng)框架的檢測過程與檢測設備解耦合，能夠更好地支持并行檢測，后端對應的檢測過程中需要能夠動態(tài)協(xié)同各設備執(zhí)行檢測。下面首先抽象定義檢測數(shù)據(jù)類型，在此基礎上，給出設備協(xié)同語句及其解釋執(zhí)行機制。

3.1 檢測數(shù)據(jù)類型

在設備協(xié)同執(zhí)行檢測過程中需要輸入被測系統(tǒng)相關參數(shù)和輸出檢測結果數(shù)據(jù)等，為使得檢測具有通用性，本文將這些數(shù)據(jù)類型進行封裝得到設備類型、被測系統(tǒng)參數(shù)類型、采樣結果類型和檢測標準類型等抽象數(shù)據(jù)類型。下面給出這些數(shù)據(jù)類型的形式定義。

3.1.1 設備類型

基于上述檢測系統(tǒng)分層框架抽象定義設備類型DT，由設備類別標識DCla、設備標識Dname、設備基本操作Dopers、設備所屬網(wǎng)關Dgt組成，形式為

DT=(DCla,Dname,Dopers,Dgt)

其中：DCla取值可為“邏輯檢測設備”、“跳轉機”或“被測主機”；Dname為具體設備的標識；Dgt的取值根據(jù)上述檢測系統(tǒng)分層架構來確定，邏輯檢測設備無設備所屬網(wǎng)關，跳轉機的設備所屬網(wǎng)關是其上層的邏輯檢測設備，被測主機的設備所屬網(wǎng)關是其上層的跳轉機；Dopers是Dname所指設備支持的檢測基本操作的集合。本文將一個檢測基本操作定義為一個檢測API，設備在被激勵下通過調用自身的檢測API實現(xiàn)對被測系統(tǒng)的檢測。檢測API的形式定義為

定義1檢測API(TAPI)。將TAPI定義為一個五元組(Nametapi,Itin,Itout,Btin,Btout)。其中：Nametapi為TAPI的名稱；Itin為TAPI的輸入接口，定義為輸入?yún)?shù)序列，即{IP1,IP2,……,IPm}；Itout為TAPI的輸出接口，定義為輸出參數(shù)序列，即{OP1,OP2,……,OPn}；Btin為輸入接口Itin的約束集合；Btout為輸出接口Itout的約束集合。

針對航電系統(tǒng)軟件配置項一致性檢測和軟件運行環(huán)境資源狀態(tài)適配性檢測，本文設計了被測主機檢測API、跳轉機檢測API和邏輯檢測設備檢測API共3類，部分檢測API如表1所示。

在檢測系統(tǒng)的擴展應用中，可根據(jù)所要進行的檢測項目增加跳轉機和被測主機的檢測API，從而支持更多檢測項目。

3.1.2 被測系統(tǒng)參數(shù)類型

被測系統(tǒng)參數(shù)類型抽象定義檢測過程中所需要的描述被測航電系統(tǒng)及其軟件運行環(huán)境的相關參數(shù)的類型，用TestedAS表示被測系統(tǒng)、TestedSubsys表示組成被測系統(tǒng)的分系統(tǒng)、TestedHost表示包含的被測主機、TestedCSCI表示被測軟件配置項、TestedOSKeyFile表示被測主機的操作系統(tǒng)關鍵文件、TestedSysRes表示被測軟件運行環(huán)境資源，則被測系統(tǒng)參數(shù)TPT的相關形式定義為

TPT：:= TestedAS | TestedSubsys | TestedHost | TestedCSCI | TestedOSKFile | TestedSysRes

TestedAS：:= (ASID,ASModel,ASPlaneID,TestedSubsys+)

TestedSubsys：:= (SubsysID,ASID,TestedHost+)

TestedHost：:= (HostID,ASID,SubsysID,HostDetail)

TestedCSCI：:= (CSCIID,ASID,SubsysID,HostID,CSCIConf+)

CSCIConf：:= (ConfID,ConfType,ConfFilePath,ConfExcludePath)

TestedSysRes：:= (ASID,SubsysID,HostID,SysRes*)

SysRes：:= (CpuRes,MemRes,DiskRes,NetIntRes,ProcessRes,LogRes)

其中：HostDetail可根據(jù)實際系統(tǒng)具體定義，比如可為主機訪問用戶名、密碼、操作系統(tǒng)類型等；TestedOSKeyFile的定義同TestedCSCI。

表1 部分邏輯檢測設備、跳轉機和被測主機檢測APITable 1 Part of test API for tested host,test gateway devices,and logic test device

3.1.3 采樣結果類型

采樣結果數(shù)據(jù)主要指跳轉機采樣獲得的軟件配置項文件或操作系統(tǒng)關鍵文件的特征數(shù)據(jù)，以及軟件運行環(huán)境資源狀態(tài)數(shù)據(jù)。不同的檢測項目獲得的采樣結果數(shù)據(jù)類別和含義不同。本文定義采樣結果類型TRT為由結果類別標識TRstc、采樣結果名稱Trstname和采樣數(shù)據(jù)內容TrstData組成的三元組，形式為

TRT = (TRstc,Trstname,TrstData)

式中：TRstc為文件采樣結果或資源狀態(tài)采樣結果類別；Trstname為具體的采樣結果文件名稱；TrstData的類型因TRstc的不同而不同。當TRstc取值為文件采樣結果類別時，TrstData為CSCIAS類型；當TRstc取值為環(huán)境資源狀態(tài)采樣結果類別時，TrstData是Status-SCR類型。這里，

1)CSCIAS為航電系統(tǒng)軟件配置項或操作系統(tǒng)關鍵文件特征類型，定義為由文件名稱NameCSCI、文件特征集合CONF和對外提供的應用程序接口集合CAPI組成的三元組，形式化定義為

CSCIAS= (NameCSCI,CONF,CAPI)

式中：CONF由軟件配置項或操作系統(tǒng)關鍵文件名稱NameCONF和文件屬性指標集合PVCONF組成，即CONF=(NameCONF,PVCONF)，PVCONF是PVconf的集合，PVconf又由文件屬性Pconf和文件屬性值Vconf共同定義，即PVconf = (Pconf,Vconf)；CAPI定義類似TAPI。

2)Status-SCR為軟件運行環(huán)境資源狀態(tài)類型，由軟件運行環(huán)境資源名稱NameSCR、資源屬性狀態(tài)集合PVSCR和資源對外提供的應用程序接口集合RAPI組成，其形式化定義為

Status-SCR = (NameSCR,PVSCR,RAPI)

式中：PVSCR為PVscr的集合，PVscr由環(huán)境資源屬性Pscr和資源屬性值Vscr共同定義，即PVscr = (Pscr,Vscr)；RAPI的定義也與TAPI類似。

3.1.4 檢測標準類型

檢測標準類型抽象定義被檢測文件的標準特征數(shù)據(jù)集和被測軟件運行環(huán)境資源狀態(tài)的標準值或取值范圍。檢測標準類型TST定義為由檢測標準類別標識TStdc、檢測標準名稱TStdname、標準創(chuàng)建時間TStdCDate和檢測標準數(shù)據(jù)TStdData組成的四元組，形式為

TST=(TStdc,TStdname,TStdCDate,

TStdData)

式中：TStdc為字符串類型，取值可為文件標準類別或軟件運行環(huán)境資源狀態(tài)標準類別；TStdname為字符串類型，指具體檢測標準的名稱；TStdCDate的格式為“YY-MM-DD:hh-mm-ss”；TStdData的定義與TStdc的取值有關，若TStdc取值為文件特征標準類別，TStdData為CSCIAS類型；若TStdc取值為運行環(huán)境資源狀態(tài)標準，TStdData則是Status-SCR類型。

3.2 設備協(xié)同語句

根據(jù)上述檢測系統(tǒng)分層框架及設備交互過程，基于前述檢測數(shù)據(jù)類型設計如下設備協(xié)同語句。

1)跳轉機設備檢測API請求語句JumpTAPIReq

該語句用于請求合適的跳轉機執(zhí)行檢測API以獲取軟件配置項文件和操作系統(tǒng)關鍵文件采樣數(shù)據(jù)。JumpTAPIReq可定義為函數(shù)JTAPIReq(被請求跳轉機檢測API,被請求檢測API參數(shù)列表,執(zhí)行返回)，其中，執(zhí)行返回又表示為二元組<被請求跳轉機,執(zhí)行回令>。例如，邏輯檢測設備請求跳轉機執(zhí)行檢測操作Jtapi，Jtparas為Jtapi所需的參數(shù)，請求結果返回給Rt，則JumpTAPIReq可形式化表示為

JumpTAPIReq：:= JTAPIReq(Jtapi,Jtparas,Rt)

這里，請求成功時Rt值為被請求到的跳轉機標識和執(zhí)行回令值1；否則，返回的被請求跳轉機值為空，執(zhí)行回令值為0或其他初始值(為區(qū)分設備協(xié)同請求不成功原因，可設置一個非1和0的初始值)，具體見3.3節(jié)中語句執(zhí)行過程。

2)跳轉機設備數(shù)據(jù)請求語句JumpDataReq

該語句用于獲取跳轉機設備上的文件采樣數(shù)據(jù)的特征數(shù)據(jù)。JumpDataReq可定義為函數(shù)JDataReq(被請求跳轉機,被請求數(shù)據(jù)參數(shù),執(zhí)行返回)，其中，執(zhí)行返回為二元組<被請求數(shù)據(jù),執(zhí)行回令>。例如，邏輯檢測設備向被請求跳轉機Jdn請求參數(shù)Jsparas對應文件的特征值，請求結果返回給Rt，則JumpDataReq可形式化表示為

JumpDataReq：:= JDataReq (Jdn,Jsparas,Rt)

該請求語句執(zhí)行成功時Rt值為返回的參數(shù)Jsparas對應數(shù)據(jù)和執(zhí)行回令值1；否則，被請求參數(shù)Jsparas的返回值為空，執(zhí)行回令值為0或者不變，詳見3.3節(jié)。

3)設備檢測API與數(shù)據(jù)交互語句DevTAPICol

該語句用于請求合適的跳轉機激勵被測主機執(zhí)行被請求設備檢測API從而獲得該主機的環(huán)境資源狀態(tài)數(shù)據(jù)。DevTAPICol可定義為函數(shù)DTAPICol(被測主機,被請求Tapi,Tapi參數(shù)列表,執(zhí)行返回)，其中，執(zhí)行返回定義為二元組<被請求資源數(shù)據(jù),執(zhí)行回令>。例如，邏輯檢測設備請求合適的跳轉機向被測主機Thost發(fā)送激勵,請求Thost執(zhí)行檢測操作Htapi，Htapi所需參數(shù)為Htparas，請求結果返回給Rt，則DevTAPICol可形式化表示為

DevTAPICol::=DTAPICol(Thost,Htapi,

Htparas,Rt)

交互成功時，Rt的值為返回的被請求資源狀態(tài)數(shù)據(jù)和回令值1；交互不成功時，資源請求結果為空，執(zhí)行回令值為0或者不變。

4)結果研判語句TresultJdg

該語句用于請求邏輯檢測設備對采樣結果數(shù)據(jù)與檢測標準進行比較。TresultJdg可定義為函數(shù)TRJdg(采樣結果數(shù)據(jù),被測項目標準,執(zhí)行返回)，其中，執(zhí)行返回又表示為二元組<研判結果,執(zhí)行回執(zhí)>。例如，邏輯檢測設備將采樣結果數(shù)據(jù)Td與相應的被測文件或資源標準Ts進行比較研判，將執(zhí)行返回賦給Rt，則TresultJdg可形式化表示為

TresultJdg：:= TRJdg(Td,Ts,Rt)

式中：研判結果的取值可根據(jù)被測項目具體情況而定，如可為“軟件配置項正?！薄ⅰ败浖渲庙椚笔А?、“主機磁盤空間不足”、“異?！钡取?/p>

本文的面向航電系統(tǒng)并行檢測的設備協(xié)同語句DAPICol可表示為

DAPICol：:= JumpTAPIReq | JumpDataReq |

DevTAPICol | TresultJdg

上述設備協(xié)同語句將邏輯檢測設備、跳轉機和被測主機的檢測API封裝為基本檢測單元，這些基本檢測單元可獨立執(zhí)行，在功能上是完整的，且在檢測實施過程中具有高復用性，可被看作是檢測執(zhí)行過程中的最小可執(zhí)行檢測單元，在本文中定義為檢測原子。檢測原子封裝了基本的檢測設備協(xié)同行為，因此，檢測原子ASTAtom可表示為

ASTAtom：:= ASTAname[DAPICol]

這樣，復雜的檢測任務就可通過使用常用程序設計語言中的串行、并行、循環(huán)、條件等語句復合調用不同的檢測原子來自動實現(xiàn)。

3.3 設備協(xié)同語句的執(zhí)行過程

設備協(xié)同語句的執(zhí)行是由邏輯檢測設備發(fā)起，激勵跳轉機、被測主機執(zhí)行其自身的檢測API實現(xiàn)相應檢測功能的過程，因此，下文從邏輯檢測設備、跳轉機和被測主機3層闡述各設備協(xié)同語句的執(zhí)行過程。

3.3.1 邏輯檢測設備層設備協(xié)同語句的執(zhí)行

在協(xié)同跳轉機和被測主機執(zhí)行檢測過程中，邏輯檢測設備主要完成以下功能：① 向合適跳轉機發(fā)送檢測請求；② 接收來自跳轉機的檢測數(shù)據(jù)；③ 將采樣結果數(shù)據(jù)與檢測標準進行比對研判。針對上述各設備協(xié)同語句，下面給出邏輯檢測設備層的執(zhí)行過程：

1)若執(zhí)行的語句為JTAPIReq(njtapi,pjtapi,r)，邏輯檢測設備選擇合適的跳轉機建立SSH-2連接，將被請求檢測操作njtapi及所需參數(shù)pjtapi發(fā)送給所選跳轉機執(zhí)行被請求檢測操作。跳轉機執(zhí)行完該TAPI后，邏輯檢測設備從跳轉機接收執(zhí)行返回r，包括執(zhí)行該TAPI的跳轉機標識和執(zhí)行回令。

2)若執(zhí)行的語句為JDataReq(dj,pjsamp,r)，邏輯檢測設備向指定跳轉機dj發(fā)送pjsamp數(shù)據(jù)的請求，然后接收執(zhí)行返回r，即被請求數(shù)據(jù)和執(zhí)行回令。

3)若執(zhí)行的語句為DTAPICol(dthost,nhtapi,phtapi,r)，邏輯檢測設備選擇合適的跳轉機，通過該跳轉機將被請求檢測操作nhtapi及所需參數(shù)phtapi發(fā)送給被測主機dthost，請求dthost執(zhí)行檢測操作，然后接收執(zhí)行返回r，即采樣結果和執(zhí)行回令。

4)若執(zhí)行的語句為TRJdg(ptd,pts,r)，邏輯檢測設備將ptd對應的采樣結果數(shù)據(jù)和pts對應的標準進行比對，完成研判并返回r。

3.3.2 跳轉機層設備協(xié)同語句的執(zhí)行

跳轉機在與其他設備協(xié)同執(zhí)行檢測過程中主要完成以下功能：① 從邏輯檢測設備接收檢測請求，② 對被請求的設備檢測API進行安全性檢查，③ 調用自身的檢測API執(zhí)行檢測，④ 激勵被測主機執(zhí)行檢測API，⑤ 從被測主機接收采樣數(shù)據(jù)，⑥ 向邏輯檢測設備返回請求結果和執(zhí)行回令。跳轉機層的各設備協(xié)同語句的執(zhí)行過程如下：

1)若從邏輯檢測設備接收到的是跳轉機檢測API請求(njtapi,pjtapi,r)，首先對被請求的檢測操作njtapi進行安全性檢查，然后根據(jù)參數(shù)pjtapi與被測主機建立SSH-2連接，并調用njtapi下載相應的被測文件數(shù)據(jù)到本機，最后向邏輯檢測設備發(fā)送執(zhí)行返回r。

2)若接收到的是跳轉機數(shù)據(jù)請求(dj,pjsamp,r)，讀取被請求跳轉機dj上的文件采樣數(shù)據(jù)pjsamp并調用跳轉機檢測API計算其特征，然后刪除跳轉機上的被測系統(tǒng)文件數(shù)據(jù)，最后返回r。

3)若接收到的是設備檢測API和數(shù)據(jù)交互請求(dthost,nhtapi,phtapi,r)，首先對被請求的設備nhtapi進行安全性檢查，然后通過SSH-2連接向被測主機dthost請求執(zhí)行檢測操作nhtapi并發(fā)送參數(shù)phtapi，最后從被測主機接收采樣獲得的資源狀態(tài)數(shù)據(jù)，并返回r。

3.3.3 被測主機層設備協(xié)同語句的執(zhí)行

在本文的檢測執(zhí)行過程中，被測主機主要協(xié)同跳轉機完成檢測，被測主機需要向檢測系統(tǒng)開放相應接口，一方面，支持檢測系統(tǒng)下載被測系統(tǒng)文件；另一方面，支持執(zhí)行部分被測主機操作命令以讀取其資源狀態(tài)數(shù)據(jù)。本文將讀取被測主機資源狀態(tài)數(shù)據(jù)的操作封裝為被測主機檢測API。在設備協(xié)同過程中，被測主機在跳轉機的激勵下執(zhí)行被請求的檢測API采樣獲取自身的資源狀態(tài)數(shù)據(jù)，并返回給跳轉機。

本文設備協(xié)同語句中，邏輯檢測設備動態(tài)協(xié)同跳轉機執(zhí)行檢測的協(xié)同機制是在保證檢測任務正確運行的前提下，對其中的檢測API序列的執(zhí)行順序進行合理安排，并不會改變檢測任務。因此，應用本文方法執(zhí)行檢測仍然能夠保證整個檢測任務的完備性。

4 系統(tǒng)實現(xiàn)與實驗分析

本文將所提方法應用到某型預警機任務電子系統(tǒng)的并行檢測中，設計并實現(xiàn)了一個通用預警機任務電子系統(tǒng)并行檢測系統(tǒng)，系統(tǒng)架構如圖2所示，由檢測配置子系統(tǒng)、檢測執(zhí)行子系統(tǒng)和檢測評估子系統(tǒng)構成。

檢測配置子系統(tǒng)通過圖形化界面為檢測人員提供檢測任務編制和生成環(huán)境，檢測任務按照實際檢測需求可分為不同的檢測模式，例如一鍵檢測模式或定制化檢測模式。一鍵檢測又稱為快速檢測，是對被測系統(tǒng)所有檢測項目進行檢測；定制化檢測則是根據(jù)檢測人員需要對指定的檢測項目進行檢測。

檢測執(zhí)行子系統(tǒng)調用本文的檢測設備協(xié)同語句并行執(zhí)行檢測任務，同時對檢測任務的執(zhí)行過程進行監(jiān)控。

檢測評估子系統(tǒng)則是通過對檢測過程中生成的采樣結果數(shù)據(jù)進行研判并生成檢測報告，方便檢測人員維護保障航電系統(tǒng)，以及追溯問題。

圖3為本文實現(xiàn)的通用預警機任務電子系統(tǒng)并行檢測系統(tǒng)的檢測執(zhí)行界面示例。

圖2 通用預警機任務電子系統(tǒng)并行檢測系統(tǒng)架構Fig.2 Architecture of parallel test system for early warning mission electronic system

最后，應用本文的并行檢測系統(tǒng)和文獻[14]中的自動化檢測系統(tǒng)(單機檢測系統(tǒng))對某預警機任務電子系統(tǒng)進行檢測驗證本文方法的應用效果。該被檢測系統(tǒng)由顯控分系統(tǒng)、指揮控制分系統(tǒng)、雷達分系統(tǒng)等7個分系統(tǒng)組成，總共包含75個軟件配置項節(jié)點，組成系統(tǒng)的所有軟件配置項部署在17臺被測主機上，被測主機中，顯控分系統(tǒng)中的主任務計算機運行Red Hat Linux操作系統(tǒng)，顯控分系統(tǒng)中的操作員工作站和電子偵查分系統(tǒng)中的主控計算機運行Windows 2000操作系統(tǒng)，其他設備運行VxWorks操作系統(tǒng)。為此，設計如下3種檢測方案進行實驗：

1)單機-串行-耦合：應用1套單機檢測系統(tǒng)串行檢測被測系統(tǒng)中的每個被測主機，檢測系統(tǒng)中的跳轉機與被測主機耦合，檢測人員需為運行不同操作系統(tǒng)的被測主機選擇不同的檢測接口，由1位檢測人員操作。

2)單機-并行-耦合：應用3套單機檢測系統(tǒng)并行執(zhí)行檢測，跳轉機與被測主機耦合，1套用于檢測運行Linux操作系統(tǒng)的被測主機，1套用于檢測運行Windows操作系統(tǒng)的被測主機，另1套用于檢測運行VxWorks操作系統(tǒng)的被測主機，相同操作系統(tǒng)的多臺主機被串行檢測，每套單機檢測系統(tǒng)由1位檢測人員操作。

3)本文-并行-解耦：應用1套本文實現(xiàn)的系統(tǒng)執(zhí)行相同檢測任務，通過邏輯檢測設備協(xié)同3臺跳轉機的不同檢測API對所有被測主機執(zhí)行并行檢測，由1位檢測人員操作。

在以上3種檢測方案中，通過相同配置的跳轉機對被測主機執(zhí)行檢測，跳轉機的軟硬件環(huán)境均為：Intel?CoreTMi5-3337U處理器，1.80 GHz主頻，4 GB內存和Linux操作系統(tǒng)。

實驗過程中，統(tǒng)計3種檢測方案的檢測花費時間和檢測任務執(zhí)行結果并進行比較分析。

4.1 檢測時間對比

采用上述3種檢測方案分別執(zhí)行檢測，方案1在各階段花費時間為串行檢測17個被測主機在相應階段的花費時間之和；方案2在各階段花費時間為3套單機檢測系統(tǒng)在每組的相應階段花費時間的最大值；方案3在各階段花費時間為執(zhí)行整個檢測任務在各階段實際花費時間。表2為每種檢測方案執(zhí)行5次檢測在檢測配置、檢測執(zhí)行和檢測評估3個階段的平均檢測花費時間。

如表2所示，同樣執(zhí)行上述檢測任務，采用方案2通過3套單機檢測系統(tǒng)并行執(zhí)行檢測比1套單機檢測系統(tǒng)串行檢測所花費平均總時間減少20分鐘，檢測效率提升30%；而采用本文系統(tǒng)通過3臺跳轉機并行執(zhí)行檢測所花費平均總時間比1套單機檢測系統(tǒng)減少39分鐘，檢測效率提升59%。由此可見，同樣通過3臺跳轉機并行執(zhí)行相同檢測任務，應用本文方法解耦后執(zhí)行并行檢測所花費平均總時間比未解耦的情況下執(zhí)行并行檢測所花費平均總時間又減少了19分鐘，檢測效率又提升了29%，而且，檢測人員減少了2/3。進一步比較相同檢測階段3種方案的平均檢測時間不難發(fā)現(xiàn)，檢測時間減少最為明顯的是檢測執(zhí)行階段。這是因為，本文實現(xiàn)的檢測系統(tǒng)應用檢測設備協(xié)同機制實現(xiàn)了檢測過程與跳轉機的解耦合，可以動態(tài)協(xié)同跳轉機對被測主機執(zhí)行并行檢測，提高了跳轉機的利用率和設備協(xié)同的自動化程度。

表2 應用3種檢測方案執(zhí)行檢測任務平均花費時間對比Table 2 Comparison of average test time of executing test task by three test schemes mm

為了進一步驗證本文方法的有效性，從上述被測系統(tǒng)中隨機抽取1、3、6、9、12和15臺被測主機，并保證被測主機為3臺以上時運行各操作系統(tǒng)的被測主機至少包含1臺。然后采用上述3種檢測方案對被測主機上的軟件配置項和軟件運行環(huán)境資源狀態(tài)進行檢測，每種方案進行6組實驗，每組實驗重復5次。3種方案的平均檢測執(zhí)行時間變化曲線如圖4所示。

從圖4可見，隨著被測主機數(shù)不斷增多，3種檢測方案在檢測執(zhí)行階段的平均花費時間都在不斷增加。其中，方案1在檢測執(zhí)行階段的平均花費時間隨被測主機數(shù)增加最快，方案2的平均檢測執(zhí)行時間增幅比方案1明顯下降，而方案3的平均檢測執(zhí)行時間增加又明顯比方案2緩慢。由此可見，隨著被測主機或者被測系統(tǒng)增多，相對于方案1和方案2來說，應用本文方法將檢測過程與檢測設備解耦后執(zhí)行并行檢測花費檢測執(zhí)行時間減少的優(yōu)勢更加明顯。

綜上實驗表明，與單機檢測系統(tǒng)串行執(zhí)行檢測相比，本文方法支持下的檢測系統(tǒng)執(zhí)行并行檢測使得檢測時間減少一半以上，檢測效率提升一倍以上。在對多被測主機(特別是不同運行平臺的被測主機)進行檢測時，與應用3套單機檢測系統(tǒng)在未解耦的情況下執(zhí)行并行檢測相比，應用本文方法支持下的檢測系統(tǒng)執(zhí)行并行檢測，減少檢測人員消耗的同時進一步減少了檢測時間和提高了檢測效率。

圖4 3種檢測方案的平均檢測執(zhí)行時間變化曲線Fig.4 Average test executing time curves of three test schemes

4.2 檢測任務執(zhí)行結果對比

上述3種檢測方案中，由于方案2是方案1中的被測主機按照操作系統(tǒng)不同分為3組進行檢測，并未分解檢測任務，因此，這里只給出方案1和方案3完成整個檢測任務的執(zhí)行結果對比，如圖5所示。每一個軟件配置項對應一個采樣結果數(shù)據(jù)文件，每一臺被測主機的CPU和內存對應一個采樣結果數(shù)據(jù)文件，硬盤和進程分別對應一個采樣結果數(shù)據(jù)文件，采樣結果文件數(shù)為以上所有采樣結果文件總數(shù)。發(fā)現(xiàn)異常數(shù)包括和標準不一致的軟件配置項文件數(shù)和不適配的被測主機資源數(shù)。連接不成功數(shù)是檢測系統(tǒng)未連接上的被測主機數(shù)。

從圖5可知，通過本文方法協(xié)同跳轉機執(zhí)行上述檢測任務獲得的采樣結果文件數(shù)、發(fā)現(xiàn)異常數(shù)和連接不成功的被測主機數(shù)都與使用單機檢測系統(tǒng)執(zhí)行檢測任務獲得的結果相等。由此可見，本文的設備協(xié)同語句完全執(zhí)行了被分解后的檢測任務，即本文方法將檢測過程與檢測設備解耦后仍然保證了檢測任務執(zhí)行的完備性。

本文所提檢測設備協(xié)同方法及實現(xiàn)的并行檢測系統(tǒng)已經(jīng)應用到某電子科學研究院的多型號預警機任務電子系統(tǒng)檢測中，可以支持多系統(tǒng)同時檢測，能夠確保檢測過程的安全性。在并行檢測應用中，每個被測系統(tǒng)包含軟件配置項70～90個，被測主機15～24臺，被測主機操作系統(tǒng)3種之多。檢測系統(tǒng)通過檢測設備協(xié)同方法動態(tài)協(xié)同調用合適的跳轉機實現(xiàn)了對多個被測系統(tǒng)(和被測系統(tǒng)中的多個分系統(tǒng))的并行檢測，與傳統(tǒng)的檢測方法相比，改變了檢測工作模式，減少了人員消耗，提高了檢測效率。

圖5 2種方案的檢測任務執(zhí)行結果對比圖Fig.5 Comparison of results of executing test task through two test schemes

5 結 論

針對當前航電系統(tǒng)并行檢測面臨的檢測設備與具體航電系統(tǒng)耦合、檢測過程與具體檢測設備耦合、檢測安全性要求高以及檢測任務繁重等問題，本文給出一種適用于航電系統(tǒng)并行檢測的檢測過程與檢測設備解耦方法。

1)給出了一種檢測分層框架，支持檢測設備與被測航電系統(tǒng)解耦合，提高了檢測系統(tǒng)的通用性。通過這種分層框架也可保證檢測過程的安全性。

2)給出了設備協(xié)同語句及其設備協(xié)同機制，實現(xiàn)了航電系統(tǒng)并行檢測中檢測過程與檢測設備解耦合，從而可以更好地支持多個航電系統(tǒng)并行檢測。

3)實際應用和對比實驗表明，本文方法的引入使得航電系統(tǒng)檢測工作模式改變，檢測人員消耗減少，檢測效率得到提高，同時也保證了檢測過程的安全性。