裝備CBM 與IETM 智能維修系統的集成研究*

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

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

0 引言

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

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

1 CBM 與IETM 集成框架

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

一是加裝部分數據采集器，或配備手持狀態檢測儀器，從裝備采集狀態數據，并由檢測人員根據裝備當時狀態評估其工作狀態，確定維修方式。

二是內置數據采集傳感器，其具有一定數據處理、狀態評估和報警功能。此類系統能在數據超過閾值，或在故障發生或即將發生時，進行報警。此類警報可以故障代碼的形式出現，通過警報現象、故障代碼和數據值進行故障隔離。

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

根據CBM 系統實現等級的不同，IETM 與其集成的框架如圖1 所示，可分為4 個層次。

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

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

圖1 IETM 同CBM 系統集成框架

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

4）基于狀態數據的故障預測集成。在裝備未發生故障時，通過IETM 過程數據模塊直接讀取CBM系統提供的狀態數據，如日志信息和健康信息等，由IETM 直接進行故障預測，輔助裝備維修。

2 OSA-CBM 規范

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

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

2.1 信息規范

OSA-CBM 信息規范定義了傳輸的數據類型，主要有4 種，包括：結果數據（DataEvent）、配置數據（Configuration）、說明數據（Explanation）和擴展數據（Extensible）。

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

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

圖2 OSA-CBM 功能層與DataEvent 的關聯

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

2.2 通信規范

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

1）同步：客戶端通過調用向服務器申請數據，服務器直接返回數據，如通過HTTP 請求提取Web XML 模型數據。

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

3）服務：客戶端無需申請，就會被動地接收服務器發送的數據。

4）訂閱：客戶端需向服務器訂閱數據，服務器才定期或在出現警報時發送數據給訂閱者。

3 CBM 與IETM 集成接口

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

圖3 CBM 與IETM 系統集成接口模型

3.1 接口設計

3.1.1 訪問入口

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

3.1.2 數據隊列

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

3.2 接口通信模式

集成過程中，模塊間數據通信采用觀察者模式，模塊內數據通信采用生產者/消費者模式。

圖4 CBM 數據服務器的觀察者模式

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

CBM 模塊內和IETM 系統內部采用生產者/消費者模式，如圖5 所示，以解決數據接收與數據處理之間可能存在的阻塞問題。例如，當IETM 系統要提取CBM 模塊發送的數據時，IETM 的DataEventReceiver 接口負責從CBM 數據服務器模塊接收數據，是數據的生產者；IETM 邏輯引擎要基于接收的數據進行故障推理判斷，是數據的消費者；數據隊列則用于接收和處理數據的緩沖區。

圖5 IETM 系統的生產者/消費者模式

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

4 應用驗證

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

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

圖6 IETM 與CBM 系統集成應用框架原型

5 結論

CBM 與IETM 兩者都是裝備保障的重要支撐技術，CBM 在獲取裝備狀態數據、實施健康評估和維修決策輔助等方面具有優勢，但缺乏詳細的裝備保障數據支持，而IETM 卻能提供完備的裝備技術數據和保障過程數據，兩者的集成發揮了各自在裝備維修保障中的優勢。文中給出的集成框架既保證了IETM 能獲得CBM 提供的不同層面數據，也保證了集成的通用性和互操作性。框架后續的具體實現可采用各類中間件技術如CORBA、COM／DCOM、.NET、XML 等。框架結構具備的可重用特性，可大大減少兩系統間通信機制的開發時間，使開發者更能集中于CBM 系統和IETM 系統功能開發設計上。

圖7 CBM 與IETM 系統集成應用實例