杜曉明，郭德興，朱 寧，姜相爭

（1.陸軍工程大學(xué)指揮控制工程學(xué)院，南京 210007；2.陸軍工程大學(xué)石家莊校區(qū)，石家莊 050003；3.解放軍72456 部隊，山東 濰坊 261305）

0 引言

隨著基于狀態(tài)的維修（Condition Based Maintenance，CBM）、故障預(yù)測與健康狀態(tài)管理（Prognostic and Health Management，PHM）等概念的提出，當(dāng)前裝備維修由以手冊為中心的事后檢測發(fā)展為以信息為中心的狀態(tài)監(jiān)測與分析，先進(jìn)的分析技術(shù)集成于裝備及其服務(wù)中，對應(yīng)系統(tǒng)亦被稱為賽博物理系統(tǒng)（Cyber-physical Systems，CPS）［1］。CPS 在裝備維修領(lǐng)域的典型應(yīng)用便是基于交互式電子技術(shù)手冊（Interactive Electronic Technical Manuals，IETM）的智能維修系統(tǒng)。IETM 擁有大量裝備基本原理、使用操作和維修保障等數(shù)據(jù)，可以構(gòu)成一個數(shù)字化的裝備信息空間，為裝備使用保障人員提供交互式的推理決策支持，因此，裝備故障診斷與修復(fù)是其中一項關(guān)鍵內(nèi)容。

目前，該方向研究的熱點之一是如何完善CBM/PHM 與IETM 系統(tǒng)的有機集成，以提高裝備故障診斷的高效性與準(zhǔn)確性。對此，學(xué)者Cooper 率先提出了基于IETM 和CBM 的自適應(yīng)診斷與單兵技術(shù)支持系統(tǒng)［2］，后續(xù)美軍給予重點關(guān)注，開發(fā)類似“虛擬維修系統(tǒng)”、“智能維修系統(tǒng)”［3］。美海軍在給V22 魚鷹飛機開發(fā)的綜合自動維修環(huán)境優(yōu)化系統(tǒng)（CAMEO）中實現(xiàn)了IETM 系統(tǒng)與其地面數(shù)據(jù)站的信息集成，F(xiàn)-22 戰(zhàn)斗機IETM 通過與其CBM 系統(tǒng)集成，實現(xiàn)5 級IETM 功能［4］。國內(nèi)李磊、吳永明等提出在現(xiàn)有IETM 框架下進(jìn)行功能擴展，實現(xiàn)與故障診斷系統(tǒng)和專家系統(tǒng)的融合［5-6］。Gang Niu 等則提出了模糊語義推理和狀態(tài)融合診斷相集成的IETM 智能維修系統(tǒng)［7］，上述系統(tǒng)或方法主要關(guān)注兩方面，一是加強CBM 與IETM 之間的數(shù)據(jù)共享，二是基于CBM 數(shù)據(jù)增強IETM 的推理能力。這些研究工作雖給出了CBM 與IETM 集成的不同思路與實踐，但還存在兩個方面不足：一是方法面向具體系統(tǒng)或開發(fā)商，系統(tǒng)緊耦合，接口協(xié)議、數(shù)據(jù)定義專用，缺乏普適性；二是集成定位較為籠統(tǒng)，沒有精準(zhǔn)區(qū)分其層次。為使基于IETM 的智能維修系統(tǒng)接口更具通用性和針對性，本文提出了一種符合OSA-CBM 規(guī)范的CBM 與IETM 集成框架，架構(gòu)將集成應(yīng)用分為4 個層次，支持分布式部署，能與各型CBM 子系統(tǒng)實現(xiàn)統(tǒng)一交互，有效解決系統(tǒng)間的緊耦合問題，顯著提升系統(tǒng)功能的重用性和多系統(tǒng)間的互操作性。

1 CBM 與IETM 集成框架

CBM 系統(tǒng)通過收集裝備運行參數(shù)，對數(shù)據(jù)進(jìn)行系統(tǒng)分析、處理和評估，查找裝備故障點或劣化點，評估裝備健康狀態(tài)，并給出維護(hù)建議。根據(jù)對裝備實施監(jiān)測評估的深度，CBM 系統(tǒng)應(yīng)用大致可分為以下3 個等級［8］：

一是加裝部分?jǐn)?shù)據(jù)采集器，或配備手持狀態(tài)檢測儀器，從裝備采集狀態(tài)數(shù)據(jù)，并由檢測人員根據(jù)裝備當(dāng)時狀態(tài)評估其工作狀態(tài)，確定維修方式。

二是內(nèi)置數(shù)據(jù)采集傳感器，其具有一定數(shù)據(jù)處理、狀態(tài)評估和報警功能。此類系統(tǒng)能在數(shù)據(jù)超過閾值，或在故障發(fā)生或即將發(fā)生時，進(jìn)行報警。此類警報可以故障代碼的形式出現(xiàn)，通過警報現(xiàn)象、故障代碼和數(shù)據(jù)值進(jìn)行故障隔離。

三是帶有智能化故障診斷裝置，不但能夠進(jìn)行故障報警，還能通過專家系統(tǒng)作出故障診斷，裝備健康評估，預(yù)測裝備壽命和未來的故障模式，給出維護(hù)建議。

根據(jù)CBM 系統(tǒng)實現(xiàn)等級的不同，IETM 與其集成的框架如圖1 所示，可分為4 個層次。

1）基于故障警報的集成。由CBM 系統(tǒng)提供警報現(xiàn)象或故障代碼，IETM 從CBM 中獲取裝備數(shù)值數(shù)據(jù)、特征值、狀態(tài)數(shù)據(jù)等數(shù)字形式的數(shù)據(jù)，基于IETM 故障數(shù)據(jù)模塊，以交互式故障診斷方式實現(xiàn)故障定位，并提供維修支持；

2）基于故障定位的集成。由CBM 給出故障定位信息，IETM 從CBM 中讀取故障代碼，基于IETM故障數(shù)據(jù)模塊中的故障數(shù)據(jù)報告，直接為CBM 系統(tǒng)提供維修程序支持；

圖1 IETM 同CBM 系統(tǒng)集成框架

3）基于維修決策的集成。依據(jù)CBM 系統(tǒng)提供的維修決策報告，通過IETM 維修過程數(shù)據(jù)模塊，直接提供維修所需的零部件、工具、人員、維修等級等卡包信息和維修程序信息；

4）基于狀態(tài)數(shù)據(jù)的故障預(yù)測集成。在裝備未發(fā)生故障時，通過IETM 過程數(shù)據(jù)模塊直接讀取CBM系統(tǒng)提供的狀態(tài)數(shù)據(jù)，如日志信息和健康信息等，由IETM 直接進(jìn)行故障預(yù)測，輔助裝備維修。

2 OSA-CBM 規(guī)范

為降低CBM 與IETM 系統(tǒng)在集成中的耦合度，提高互操作性，CBM 與IETM 之間的交互機制須有一種標(biāo)準(zhǔn)開放的協(xié)議，這樣既能實現(xiàn)IETM 與同一CBM 系統(tǒng)各組件之間的互操作和信息共享，又能實現(xiàn)IETM 與不同產(chǎn)商CBM 系統(tǒng)間的互操作，從而解決傳統(tǒng)集成過程中因不同標(biāo)準(zhǔn)重復(fù)開發(fā)通信框架的問題。

由MIMOSA 管理與發(fā)布的CBM 開放體系結(jié)構(gòu)（Open System Architecture for CBM，OSA-CBM）是實現(xiàn)CBM 系統(tǒng)互通互聯(lián)的國際標(biāo)準(zhǔn)［9］，它將CBM 系統(tǒng)的數(shù)據(jù)處理功能分為6 層，如圖2 左側(cè)所示，底3層與裝備狀態(tài)監(jiān)測密切相關(guān)，上3 層與人員判斷決策相關(guān)，每層功能塊可分布部署，亦可集中部署。它規(guī)范了CBM 數(shù)據(jù)處理模塊之間的數(shù)據(jù)交換機制，實現(xiàn)了與具體數(shù)據(jù)傳輸技術(shù)的脫耦，解決了不同供應(yīng)商提供的CBM 系統(tǒng)組件之間集成問題，免去了通信框架的重復(fù)開發(fā)。OSA-CBM 規(guī)范分為信息規(guī)范和通信規(guī)范，使用統(tǒng)一建模語言（UML）定義，可采用多種編程語言和中間件技術(shù)實現(xiàn)，供應(yīng)商和集成人員可采用與其環(huán)境相適配的技術(shù)來實現(xiàn)該標(biāo)準(zhǔn)。

2.1 信息規(guī)范

OSA-CBM 信息規(guī)范定義了傳輸?shù)臄?shù)據(jù)類型，主要有4 種，包括：結(jié)果數(shù)據(jù)（DataEvent）、配置數(shù)據(jù)（Configuration）、說明數(shù)據(jù)（Explanation）和擴展數(shù)據(jù)（Extensible）。

配置數(shù)據(jù)定義了CBM 功能模塊的輸入數(shù)據(jù)源、數(shù)據(jù)處理算法描述、數(shù)據(jù)輸出目標(biāo)模塊、數(shù)值的單位和閾值等元信息；說明數(shù)據(jù)則對CBM 功能模塊如何生成輸出進(jìn)行了數(shù)據(jù)說明；擴展數(shù)據(jù)仍然不成熟，在規(guī)范中沒有很好地定義；結(jié)果數(shù)據(jù)則是由OSA-CBM 功能模塊生成的事件集或數(shù)據(jù)集，即裝備狀態(tài)監(jiān)測數(shù)據(jù)（如測量值），處理或評估過的結(jié)果數(shù)據(jù)等。

結(jié)果數(shù)據(jù)的類型與CBM 功能模塊類型密切相關(guān)，不同功能層產(chǎn)生不同類型的結(jié)果數(shù)據(jù)，如圖2所示。DA 數(shù)據(jù)是被格式化的傳感器數(shù)據(jù)，此類數(shù)據(jù)具有一致的格式；DM 數(shù)據(jù)是由DA 數(shù)據(jù)轉(zhuǎn)換后的一個或多個有意義的特征值；SD 數(shù)據(jù)是將DM 數(shù)據(jù)與期望值進(jìn)行比較，得到的計算條件指標(biāo)［10］。HA、PA 和AG 數(shù)據(jù)分別是裝備當(dāng)前的健康狀況、未來故障預(yù)測以及維修建議等。

圖2 OSA-CBM 功能層與DataEvent 的關(guān)聯(lián)

通常情況下，CBM 系統(tǒng)由多個分系統(tǒng)分布部署，每個分系統(tǒng)可包含上面定義的一種或多種功能層，提供一個或多個功能層的接口，允許輸出一種或多種類型的數(shù)據(jù)。

2.2 通信規(guī)范

針對CBM 功能模塊之間數(shù)據(jù)傳輸、信息交換，OSA-CBM 規(guī)范定義了4 種通信類型，包括同步、異步、服務(wù)和訂閱。這些機制遵循客戶端-服務(wù)器調(diào)用訪問模式，即提供數(shù)據(jù)的CBM 功能模塊為服務(wù)器，而接收數(shù)據(jù)的CBM 功能模塊為客戶端。

1）同步：客戶端通過調(diào)用向服務(wù)器申請數(shù)據(jù)，服務(wù)器直接返回數(shù)據(jù)，如通過HTTP 請求提取Web XML 模型數(shù)據(jù)。

2）異步：客戶端數(shù)據(jù)申請與客戶端接收數(shù)據(jù)要通過兩次獨立的訪問完成。該機制允許任意數(shù)量的上層模塊在需要時建立與下層模塊的雙向連接，可設(shè)置有3 種通信模式，一是根據(jù)請求而返回數(shù)據(jù)；二是出現(xiàn)警報而返回數(shù)據(jù)，例如某參數(shù)超過閾值；三是全部推送，無需事先請求，下層模塊將每次收集的數(shù)據(jù)推送至所有連接的更高層模塊。

3）服務(wù)：客戶端無需申請，就會被動地接收服務(wù)器發(fā)送的數(shù)據(jù)。

4）訂閱：客戶端需向服務(wù)器訂閱數(shù)據(jù)，服務(wù)器才定期或在出現(xiàn)警報時發(fā)送數(shù)據(jù)給訂閱者。

3 CBM 與IETM 集成接口

為了捕獲CBM 系統(tǒng)的結(jié)果數(shù)據(jù)，IETM 系統(tǒng)同樣需遵循OSA-CBM 規(guī)范。本文選擇訂閱通信機制作為IETM 同CBM 系統(tǒng)集成的數(shù)據(jù)傳輸接口，并采用基于組件的框架設(shè)計方法，將IETM 系統(tǒng)和CBM系統(tǒng)內(nèi)部處理功能和接口功能相分離，如圖3 所示。在集成接口模型中，定義了訪問入口和數(shù)據(jù)隊列兩類組件。

圖3 CBM 與IETM 系統(tǒng)集成接口模型

3.1 接口設(shè)計

3.1.1 訪問入口

訂閱通信機制下的訪問入口有兩種類型：即數(shù)據(jù)服務(wù)入口DataEventServer 和數(shù)據(jù)接收入口DataEventReceiver，如圖3 所示。DataEventServer 是CBM 服務(wù)器模塊向CBM 客戶端模塊提供數(shù)據(jù)的訪問接口，DataEventReceiver 是CBM 客戶端模塊接收CBM 服務(wù)器模塊數(shù)據(jù)的接口，接口設(shè)計采用觀察者模式。DataEventServer 提供了添加和刪除觀察者對象DataEventObserver 的功能，每個DataEventServer可關(guān)聯(lián)任意數(shù)量的觀察者。CBM 客戶端模塊為獲取服務(wù)端推送的數(shù)據(jù)，須通過DataEventServer 接口提供的觀察者注冊功能，成為DataEventServer 的一個觀察者。成功注冊后的觀察者包含了對客戶端模塊中DataEventReceiver 接口的一個鏈接，待服務(wù)器模塊準(zhǔn)備好數(shù)據(jù)時，即可觸發(fā)DataEventReceiver 通知提取數(shù)據(jù)。

3.1.2 數(shù)據(jù)隊列

IETM 模塊可視為OSA-CBM 服務(wù)器的數(shù)據(jù)客戶端，負(fù)責(zé)接收來自于CBM 系統(tǒng)模塊內(nèi)處理生成的數(shù)據(jù)，數(shù)據(jù)類型覆蓋6 類不同功能層模塊。為保證數(shù)據(jù)處理與數(shù)據(jù)收發(fā)能夠并行進(jìn)行，在集成接口模型中引入數(shù)據(jù)隊列概念，以實現(xiàn)CBM 服務(wù)器與IETM 系統(tǒng)間的高效通信。當(dāng)服務(wù)端有數(shù)據(jù)準(zhǔn)備完畢或有警報時，則將相應(yīng)數(shù)據(jù)事件（dataEvent）插入到CBM 服務(wù)端數(shù)據(jù)隊列，并通知IETM 系統(tǒng)接收數(shù)據(jù)，IETM 系統(tǒng)通過DataEventReceiver 接口接收服務(wù)端推送的數(shù)據(jù)，并將其置于IETM 客戶端數(shù)據(jù)隊列。

3.2 接口通信模式

集成過程中，模塊間數(shù)據(jù)通信采用觀察者模式，模塊內(nèi)數(shù)據(jù)通信采用生產(chǎn)者/消費者模式。

圖4 CBM 數(shù)據(jù)服務(wù)器的觀察者模式

CBM 功能模塊與IETM 系統(tǒng)間的數(shù)據(jù)通信采用觀察者模式，如圖4 所示。在該模式中，IETM 系統(tǒng)模塊根據(jù)所要數(shù)據(jù)需求，確定要連接訪問的CBM服務(wù)器模塊類型， 并通過該模塊提供的DataEventServer 接口注冊為該服務(wù)器模塊的一個數(shù)據(jù)觀察者DataEventObserver。當(dāng)CBM 服務(wù)器模塊準(zhǔn)備好新數(shù)據(jù)或某狀態(tài)值超過閾值發(fā)出警報時，DataEventServer 就會在觀察者池中找到已訂閱的觀察者對象，如IETM 系統(tǒng)，通知其提取數(shù)據(jù)。IETM 系統(tǒng)在得到數(shù)據(jù)更新事件后，判斷該數(shù)據(jù)是否在其感興趣的主題列表中，如是，則會使用關(guān)聯(lián)的DataEventReceiver 接口提取相關(guān)數(shù)據(jù)。

CBM 模塊內(nèi)和IETM 系統(tǒng)內(nèi)部采用生產(chǎn)者/消費者模式，如圖5 所示，以解決數(shù)據(jù)接收與數(shù)據(jù)處理之間可能存在的阻塞問題。例如，當(dāng)IETM 系統(tǒng)要提取CBM 模塊發(fā)送的數(shù)據(jù)時，IETM 的DataEventReceiver 接口負(fù)責(zé)從CBM 數(shù)據(jù)服務(wù)器模塊接收數(shù)據(jù)，是數(shù)據(jù)的生產(chǎn)者；IETM 邏輯引擎要基于接收的數(shù)據(jù)進(jìn)行故障推理判斷，是數(shù)據(jù)的消費者；數(shù)據(jù)隊列則用于接收和處理數(shù)據(jù)的緩沖區(qū)。

圖5 IETM 系統(tǒng)的生產(chǎn)者/消費者模式

數(shù)據(jù)隊列對象將IETM 系統(tǒng)內(nèi)部的數(shù)據(jù)處理功能與對外的數(shù)據(jù)通信功能相分離，以支持IETM 系統(tǒng)DataEventReceiver 接收新數(shù)據(jù)的過程與IETM 邏輯引擎處理數(shù)據(jù)的過程兩者可并行實施。

4 應(yīng)用驗證

基于上述集成框架及集成接口算法，以液壓故障模擬實驗平臺為基礎(chǔ)，構(gòu)建了IETM 系統(tǒng)與CBM系統(tǒng)的集成應(yīng)用框架原型，如圖6 所示。其中，振動信號采集系統(tǒng)與內(nèi)置信號采集系統(tǒng)實現(xiàn)OSA-CBM第一層功能，負(fù)責(zé)采集液壓平臺的振動、壓力、溫度、流量及轉(zhuǎn)速等信號，并經(jīng)網(wǎng)絡(luò)傳至CBM 數(shù)據(jù)處理服務(wù)器；服務(wù)器實現(xiàn)OSA-CBM 一層以上各功能模塊，包括信號處理、特征處理、故障報警及維修決策等；IETM 系統(tǒng)則根據(jù)狀態(tài)信號、故障代碼、維修決策指導(dǎo)實施故障修理。作為CBM 的客戶端，IETM既可獲得數(shù)據(jù)處理服務(wù)器提供的上層判斷決策數(shù)據(jù)，亦可直接獲取采集系統(tǒng)的底層狀態(tài)數(shù)據(jù)，自行展開故障推理。上述采集系統(tǒng)、CBM 服務(wù)器與IETM系統(tǒng)三者分布運行，但共同基于OSA-CBM 標(biāo)準(zhǔn)集成框架。

下頁圖7 顯示液壓故障模擬平臺在報警后的一類處理過程：IETM 系統(tǒng)連接CBM 數(shù)據(jù)處理服務(wù)系統(tǒng)，獲取平臺故障代碼及與相關(guān)裝備具體狀態(tài)參數(shù)，基于以上信息，IETM 輔助維修人員定位故障原因，并根據(jù)所鏈接的故障維修模塊，指導(dǎo)維修人員完成故障部件的更換。

圖6 IETM 與CBM 系統(tǒng)集成應(yīng)用框架原型

5 結(jié)論

CBM 與IETM 兩者都是裝備保障的重要支撐技術(shù)，CBM 在獲取裝備狀態(tài)數(shù)據(jù)、實施健康評估和維修決策輔助等方面具有優(yōu)勢，但缺乏詳細(xì)的裝備保障數(shù)據(jù)支持，而IETM 卻能提供完備的裝備技術(shù)數(shù)據(jù)和保障過程數(shù)據(jù)，兩者的集成發(fā)揮了各自在裝備維修保障中的優(yōu)勢。文中給出的集成框架既保證了IETM 能獲得CBM 提供的不同層面數(shù)據(jù)，也保證了集成的通用性和互操作性?？蚣芎罄m(xù)的具體實現(xiàn)可采用各類中間件技術(shù)如CORBA、COM／DCOM、.NET、XML 等?？蚣芙Y(jié)構(gòu)具備的可重用特性，可大大減少兩系統(tǒng)間通信機制的開發(fā)時間，使開發(fā)者更能集中于CBM 系統(tǒng)和IETM 系統(tǒng)功能開發(fā)設(shè)計上。

圖7 CBM 與IETM 系統(tǒng)集成應(yīng)用實例