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

1.3 邏輯引擎的工作機(jī)制

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

圖2 邏輯引擎功能結(jié)構(gòu)圖

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

圖3 基于過程數(shù)據(jù)模塊的交互式故障推理原理

2 交互式故障推理

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

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

(1)遍歷過程數(shù)據(jù)模塊，按照過程數(shù)據(jù)模塊所表達(dá)的邏輯關(guān)系，解析并執(zhí)行過程數(shù)據(jù)模塊中的所有節(jié)點(diǎn)。

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

(3)評估表達(dá)式，在進(jìn)行條件判斷和分支選擇時，邏輯引擎會評估表達(dá)式的是否，作為執(zhí)行條件節(jié)點(diǎn)或分支節(jié)點(diǎn)的依據(jù)。

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

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

經(jīng)過排故單元后還是不能將故障排除，那么可以通過領(lǐng)域?qū)＜业倪h(yuǎn)程支持幫助排故。領(lǐng)域?qū)＜腋鶕?jù)故障信息提出解決方案，用于指導(dǎo)排故人員再次通過IETM進(jìn)行交互式故障推理。

經(jīng)過排故單元成功排除故障后，用戶可以在IETM平臺中反饋評價交互式診斷推理過程，同時如果IETM平臺集成了故障知識庫、維修知識庫和工具儀器庫，則根據(jù)故障推理、維修過程更新對應(yīng)的知識庫，而領(lǐng)域?qū)＜倚纬傻囊?guī)則案例也可以存儲至知識庫中進(jìn)行統(tǒng)一分析管理，更新后的知識庫為下一次的故障推理提供不斷優(yōu)化的推理邏輯流程，從而持續(xù)提升故障推理的成功率。

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

3 在IETM中的功能實(shí)現(xiàn)和示例

將基于過程數(shù)據(jù)模塊的交互式故障推理應(yīng)用于IETM瀏覽平臺中，構(gòu)建了輔泵故障的診斷過程數(shù)據(jù)模塊，執(zhí)行的輔泵故障診斷后得到本次故障隔離流程如圖4所示。

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

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

3 結(jié)論

隨著IETM在裝備綜合保障中應(yīng)用的不斷推廣，特別是過程數(shù)據(jù)模塊的使用，提高了故障推理及維修的交互性和準(zhǔn)確率。同時，由于基于過程數(shù)據(jù)模塊的推理機(jī)制在實(shí)際的推理過程中不需要頻繁訪問數(shù)據(jù)庫，具有較好的獨(dú)立性，使得推理過程相對簡潔清晰。然而，因?yàn)榻换ナ焦收贤评淼膶?shí)現(xiàn)需要邏輯引擎來完成，所以邏輯引擎的處理效率和準(zhǔn)確性對完成交互式故障推理起決定性作用，后期將對邏輯引擎的處理效率和準(zhǔn)確性開展進(jìn)一步研究。