基于過程數據模塊的裝備故障診斷技術研究

元素是過程數據模塊的主要內容，它決定了步驟、對話、外部應用請求、數據模塊引用和數據模塊中條件的順序，同時它定義了子元素、、、和的邏輯順序。

1.3 邏輯引擎的工作機制

在IETM平臺中，交互性的邏輯結構由過程數據模塊來描述，而交互功能的實現則需要邏輯引擎來完成。邏輯引擎是執行數據模塊過程的軟件部分，是程序腳本的解釋器，是由基于過程數據模塊的Schema來完成相應功能，如對元素進行處理，然后按處理的結果對內容進行排序。邏輯引擎在IETM的交互性和故障診斷中的功能主要體現在以下4個方面：遍歷過程數據模塊、維護變量狀態表、評估表達式、對話框呈現，如圖2所示[5]。

圖2 邏輯引擎功能結構圖

邏輯引擎從人機交互界面獲取輸入，對過程數據模塊進行遍歷，對得到的變量表達式進行表達式估值，同時進行對話框呈現，得出的計算結果用于邏輯判斷和維護變量表達式。邏輯判斷的輸出結果不是一個明確的裝備故障，那么將繼續根據人機交互進行下一個測試任務。

圖3 基于過程數據模塊的交互式故障推理原理

2 交互式故障推理

在IETM中進行故障推理，主要是利用故障推理信息單元來對裝備進行故障推理。故障推理信息單元是以故障類、程序類數據模塊為主構成的粒度更大的數據模塊，即故障推理過程數據模塊，其本質屬于過程數據模塊。基于過程數據模塊的交互式故障推理的過程是用戶在交互界面上通過對話框輸入故障現象，在IETM系統內部進行對應的變量賦值，因此IETM系統得到一個表征故障狀態的變量表達式，該表達式與系統中故障推理過程數據模塊的前置要求表達式進行匹配，根據運算結果激活相應的故障推理過程數據模塊，再按照激活的故障推理過程數據模塊中的邏輯流程進行推理，最后根據測試結果與診斷規則的運算結果決定是否已經定位故障或者還需要進行下一個測試任務。所有診斷規則中設置了包含賦值語句的結束要求，該結束要求在沒有定位故障時繼續測試，在定位故障后結束測試并進入排故單元。基于過程數據模塊的交互式故障推理原理如圖3所示。

故障推理過程數據模塊在設計上包含前置要求、鏈接單元、測試單元和排故單元。其中，前置要求給出了進入故障推理過程數據模塊所必須滿足的變量表達式；測試單元是對檢查任務以及測試結果狀態的描述，用于匹配診斷推理規則，從而定位故障；鏈接單元則提供了故障隔離、維修相關的文字、圖片、多媒體等信息。測試單元中核心功能是邏輯引擎，其負責執行過程數據模塊并給最終用戶提供交互式顯示功能，也是IETM與測試程序的接口軟件。該邏輯引擎的功能主要包含5個方面：

(1)遍歷過程數據模塊，按照過程數據模塊所表達的邏輯關系，解析并執行過程數據模塊中的所有節點。

(2)維護變量狀態表中變量的狀態，利用用戶輸入的信息或者測試程序返回的測試結果更新變量的值。

(3)評估表達式，在進行條件判斷和分支選擇時，邏輯引擎會評估表達式的是否，作為執行條件節點或分支節點的依據。

(4)給最終用戶展示IETM內容，如：對話框、系列操作步驟、一個引用的完整數據模塊等。

(5)與測試程序交換數據，可以接收測試程序返回的測試結果，也可以調用測試程序接口并發送必要的參數值。從用戶的角度來說，邏輯引擎引導用戶通過IETM中一系列連續的操作，這些操作代表著故障隔離過程的各個步驟。

經過排故單元后還是不能將故障排除，那么可以通過領域專家的遠程支持幫助排故。領域專家根據故障信息提出解決方案，用于指導排故人員再次通過IETM進行交互式故障推理。

經過排故單元成功排除故障后，用戶可以在IETM平臺中反饋評價交互式診斷推理過程，同時如果IETM平臺集成了故障知識庫、維修知識庫和工具儀器庫，則根據故障推理、維修過程更新對應的知識庫，而領域專家形成的規則案例也可以存儲至知識庫中進行統一分析管理，更新后的知識庫為下一次的故障推理提供不斷優化的推理邏輯流程，從而持續提升故障推理的成功率。

基于過程數據模塊的故障隔離方式之所以能高效發揮IETM的故障隔離及故障維修，是利用了過程數據模塊的交互性，基于故障特征和測試結果，結合用戶經驗進行全面系統的分析，通過內部程序流引導或根據用戶指令去獲取測試跳轉條件，逐步深入地推理、檢查，從而隔離定位故障。這種方式的優勢是有了用戶的實時參與，使得整個故障推理過程更加符合人的思維和推理習慣，因此這種故障診斷模式相比于通過篩選預先內置的有限故障模式相比，可以提高故障推理及維修的交互性和準確率。此外，這種模式預留了故障診斷流程的擴展接口，可以在使用中不斷優化已存在的診斷流程，而且也可以方便增加新的診斷流程，實現測試系統的自我豐富與完善。

3 在IETM中的功能實現和示例

將基于過程數據模塊的交互式故障推理應用于IETM瀏覽平臺中，構建了輔泵故障的診斷過程數據模塊，執行的輔泵故障診斷后得到本次故障隔離流程如圖4所示。

圖4 基于過程數據模塊的交互式故障推理示例

在圖4的執行過程中，用戶首先在平臺提供的全文檢索界面輸入“輔泵無法工作”關鍵詞，在檢索結果中選擇并啟動輔泵故障推理流程，然后根據“輔泵低壓報警燈持續閃爍”的故障特征去檢測右輔助泵壓力表是否在正常值0.8～1 MPa范圍內，發現檢測結果不在正常值范圍內，從而進一步指導用戶去檢查右輔泵，通過左右輔泵互換，啟動右機組，再次檢測右輔助泵壓力表是否在正常值0.8～1 MPa范圍內，此時檢測結果為少于0.8 MPa，提示用戶去檢查輪胎是否有損壞，當用戶未發現輪胎有破損，找到了本次故障的底事件，得到右輔泵體故障的推理結果，此時輸出故障隔離流程圖，最終結束測試進入下一步排故單元，再根據維修方案進行故障維修，從而完成整個故障推理及維修的全過程。

3 結論

隨著IETM在裝備綜合保障中應用的不斷推廣，特別是過程數據模塊的使用，提高了故障推理及維修的交互性和準確率。同時，由于基于過程數據模塊的推理機制在實際的推理過程中不需要頻繁訪問數據庫，具有較好的獨立性，使得推理過程相對簡潔清晰。然而，因為交互式故障推理的實現需要邏輯引擎來完成，所以邏輯引擎的處理效率和準確性對完成交互式故障推理起決定性作用，后期將對邏輯引擎的處理效率和準確性開展進一步研究。