裝備CBM 與IETM 智能維修系統(tǒng)的集成研究*

杜曉明，郭德興，朱 寧，姜相爭(zhēng)

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

0 引言

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

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

1 CBM 與IETM 集成框架

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

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

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

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

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

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

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

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

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

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

2 OSA-CBM 規(guī)范

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

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

2.1 信息規(guī)范

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

配置數(shù)據(jù)定義了CBM 功能模塊的輸入數(shù)據(jù)源、數(shù)據(jù)處理算法描述、數(shù)據(jù)輸出目標(biāo)模塊、數(shù)值的單位和閾值等元信息；說(shuō)明數(shù)據(jù)則對(duì)CBM 功能模塊如何生成輸出進(jìn)行了數(shù)據(jù)說(shuō)明；擴(kuò)展數(shù)據(jù)仍然不成熟，在規(guī)范中沒(méi)有很好地定義；結(jié)果數(shù)據(jù)則是由OSA-CBM 功能模塊生成的事件集或數(shù)據(jù)集，即裝備狀態(tài)監(jiān)測(cè)數(shù)據(jù)（如測(cè)量值），處理或評(píng)估過(guò)的結(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)換后的一個(gè)或多個(gè)有意義的特征值；SD 數(shù)據(jù)是將DM 數(shù)據(jù)與期望值進(jìn)行比較，得到的計(jì)算條件指標(biāo)［10］。HA、PA 和AG 數(shù)據(jù)分別是裝備當(dāng)前的健康狀況、未來(lái)故障預(yù)測(cè)以及維修建議等。

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

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

2.2 通信規(guī)范

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

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

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

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

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

3 CBM 與IETM 集成接口

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

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

3.1 接口設(shè)計(jì)

3.1.1 訪問(wèn)入口

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

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

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

3.2 接口通信模式

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

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

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

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

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

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

4 應(yīng)用驗(yàn)證

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

下頁(yè)圖7 顯示液壓故障模擬平臺(tái)在報(bào)警后的一類處理過(guò)程：IETM 系統(tǒng)連接CBM 數(shù)據(jù)處理服務(wù)系統(tǒng)，獲取平臺(tái)故障代碼及與相關(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ù)、實(shí)施健康評(píng)估和維修決策輔助等方面具有優(yōu)勢(shì)，但缺乏詳細(xì)的裝備保障數(shù)據(jù)支持，而IETM 卻能提供完備的裝備技術(shù)數(shù)據(jù)和保障過(guò)程數(shù)據(jù)，兩者的集成發(fā)揮了各自在裝備維修保障中的優(yōu)勢(shì)。文中給出的集成框架既保證了IETM 能獲得CBM 提供的不同層面數(shù)據(jù)，也保證了集成的通用性和互操作性?？蚣芎罄m(xù)的具體實(shí)現(xiàn)可采用各類中間件技術(shù)如CORBA、COM／DCOM、.NET、XML 等。框架結(jié)構(gòu)具備的可重用特性，可大大減少兩系統(tǒng)間通信機(jī)制的開(kāi)發(fā)時(shí)間，使開(kāi)發(fā)者更能集中于CBM 系統(tǒng)和IETM 系統(tǒng)功能開(kāi)發(fā)設(shè)計(jì)上。

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