機(jī)載系統(tǒng)通用故障診斷軟件平臺設(shè)計(jì)

曹 琪, 柯 旭, 宋博文, 莫文靜

(航空工業(yè)成都飛機(jī)工業(yè)(集團(tuán))有限責(zé)任公司,四川 成都 610073)

機(jī)載設(shè)備是飛機(jī)上必不可少的功能保障系統(tǒng)、也是典型的復(fù)雜系統(tǒng)。各機(jī)載設(shè)備是否可以穩(wěn)定、有效地工作,直接決定了飛機(jī)能否可靠地正常運(yùn)行、完成任務(wù)并安全返航[1]。但隨著技術(shù)的發(fā)展與需求的提高,其智能化、綜合化的程度仍在不斷提高,其功能與結(jié)構(gòu)也更加復(fù)雜與多樣,導(dǎo)致單元之間的關(guān)聯(lián)關(guān)系錯(cuò)綜復(fù)雜,進(jìn)而使得機(jī)載設(shè)備在出現(xiàn)故障時(shí),故障不再以孤立形式存在,而更多的是呈現(xiàn)出關(guān)聯(lián)故障模式[2]。因此,當(dāng)故障發(fā)生后,如缺乏及時(shí)的故障檢測及隔離機(jī)制,將會(huì)造成系統(tǒng)失效,甚至導(dǎo)致難以承受的災(zāi)難性后果。

機(jī)載設(shè)備故障診斷平臺提供的主要服務(wù)是接收測試數(shù)據(jù),然后基于對象本體及專家提供的原始知識,或從數(shù)據(jù)提煉歸納出的知識進(jìn)行故障的推理判斷,得到可有效指導(dǎo)后續(xù)故障處理工作開展的診斷結(jié)果。

針對機(jī)載系統(tǒng)故障診斷,目前主流的故障診斷方法研究分為以下3類[3]。

① 基于多信號流圖模型的故障診斷方法。如文獻(xiàn)[4]和文獻(xiàn)[5]中基于故障樹模型的方法,分別針對自動(dòng)飛行系統(tǒng)和發(fā)動(dòng)機(jī)開展了故障診斷系統(tǒng)的研究,研究結(jié)果表明基于模型的故障診斷方法雖然可在一定程度上實(shí)現(xiàn)對新故障的預(yù)測,但預(yù)測結(jié)果易受模型本身影響,一旦模型構(gòu)建不全面或錯(cuò)誤,將直接導(dǎo)致診斷結(jié)果無效。

② 基于專家知識系統(tǒng)的故障診斷方法。該方法雖然可有效解決機(jī)載設(shè)備中的實(shí)際故障問題,如文獻(xiàn)[6]針對飛機(jī)航空電子設(shè)備建立了故障診斷的專家知識系統(tǒng),并通過規(guī)則推理及 Hash 算法實(shí)現(xiàn)了故障的快速檢索及定位,但其故障診斷的準(zhǔn)確率和效率易受知識庫知識的準(zhǔn)確性和知識庫規(guī)模的影響,尤其針對復(fù)雜系統(tǒng)的故障診斷,知識庫將隨系統(tǒng)規(guī)模的增加急劇擴(kuò)大并呈現(xiàn)復(fù)雜化狀態(tài),進(jìn)而導(dǎo)致診斷效率急劇下滑。

③ 基于數(shù)據(jù)驅(qū)動(dòng)的故障診斷方法。與上述2種定性分析方法不同的是該方法可實(shí)現(xiàn)對故障的定量分析,可結(jié)合主流的機(jī)器學(xué)習(xí)或深度學(xué)習(xí)算法直接處理大量的測試數(shù)據(jù),分析挖掘其潛在的特征,進(jìn)而實(shí)現(xiàn)機(jī)載設(shè)備潛在故障的有效識別與預(yù)測,如文獻(xiàn)[7]。此外,基于數(shù)據(jù)驅(qū)動(dòng)的故障診斷方法與上述2種方法相比,可有效降低對先驗(yàn)知識的依賴,但其樣本數(shù)據(jù)的質(zhì)量與大小直接決定所提取故障特征的有效性,特征無效將直接導(dǎo)致無法有效識別出潛在故障,且目前暫未有公開的機(jī)載設(shè)備故障診斷測試數(shù)據(jù)集,在實(shí)際應(yīng)用中須提前布局,采集機(jī)載設(shè)備故障數(shù)據(jù),因此故障診斷實(shí)現(xiàn)周期長,短時(shí)間內(nèi)無法快速投入現(xiàn)場使用。

而現(xiàn)有常用機(jī)載設(shè)備故障診斷軟件平臺大多僅針對特定對象選取上述方法之一設(shè)計(jì)實(shí)現(xiàn),存在診斷策略單一、診斷理論基礎(chǔ)弱、診斷知識復(fù)用性與共享性差和診斷平臺通用性低等問題。例如文獻(xiàn)[8]中的機(jī)載CPU板硬件故障診斷平臺設(shè)計(jì),可有效定位CPU板硬件故障;但其針對性較強(qiáng),知識復(fù)用性與共享性差,平臺很難通用化。已有的少量針對通用測試診斷平臺的相關(guān)研究中,多以通用測試為主,弱化了故障診斷部分,且平臺所支持的診斷方法單一。例如文獻(xiàn)[9]提出的一種基于模型的通用故障診斷平臺;文獻(xiàn)[10]提出的基于混合總線的機(jī)載電子設(shè)備通用測試診斷平臺設(shè)計(jì),其診斷方法主要是以數(shù)據(jù)驅(qū)動(dòng)為主,輔以專家系統(tǒng)模糊推理機(jī),雖然具有較強(qiáng)的可擴(kuò)展性與通用性,但診斷實(shí)現(xiàn)需要大量的高質(zhì)量數(shù)據(jù),即診斷結(jié)果的可解釋性易受數(shù)據(jù)規(guī)模大小以及數(shù)據(jù)質(zhì)量好壞的影響。因此在面對不同場景、不同對象的需求時(shí),上述通用診斷平臺均無法支持現(xiàn)場測試診斷人員根據(jù)實(shí)際需求快速選擇更有效的故障診斷方法,進(jìn)而導(dǎo)致平臺的通用性大打折扣。

因此,機(jī)載設(shè)備通用故障診斷平臺應(yīng)有機(jī)結(jié)合3類故障診斷方法,通過將基于模型和專家知識系統(tǒng)的診斷輸出作為基于數(shù)據(jù)驅(qū)動(dòng)的樣本數(shù)據(jù)基礎(chǔ),將基于數(shù)據(jù)驅(qū)動(dòng)的輸出反饋至知識庫,以提高診斷結(jié)果的質(zhì)量與平臺的通用性。為進(jìn)一步提高機(jī)載設(shè)備故障診斷水平,滿足關(guān)鍵裝備技術(shù)國產(chǎn)化需要,本文設(shè)計(jì)一款機(jī)載設(shè)備通用故障診斷軟件平臺,在搭載3種診斷方法的基礎(chǔ)上,實(shí)現(xiàn)對知識的科學(xué)管理、表示與復(fù)用共享,以及對故障的快速響應(yīng)與精準(zhǔn)定位。

1 需求分析

機(jī)載系統(tǒng)故障診斷,尤其是軍機(jī)的故障診斷與傳統(tǒng)大眾商品的故障診斷不同,其設(shè)計(jì)、生產(chǎn)和使用各階段的診斷方式不同,且不同機(jī)載設(shè)備的診斷方式差別也很大,為實(shí)現(xiàn)機(jī)載系統(tǒng)的通用故障診斷,要求診斷軟件整合多種診斷方法實(shí)現(xiàn)混合驅(qū)動(dòng)。

針對在地面環(huán)境(如總裝測試)中機(jī)載設(shè)備測試成本高、故障種類多、診斷排故難等問題,為提高診斷效率、準(zhǔn)確性與通用性,需要研制機(jī)載系統(tǒng)通用故障診斷平臺,具體要求如下。

① 支持多級的權(quán)限管理、允許用戶實(shí)現(xiàn)賬號信息的注冊、登錄和修改等功能;

② 支持對機(jī)載設(shè)備的結(jié)構(gòu)信息、故障信息、測點(diǎn)與測試信息進(jìn)行增、刪、改、查;

③ 支持多信號流圖(Multi-Signal Flow Graph,MSFG)的圖形化建模;

④ 支持故障模式、影響及危害性分析(Failure Mode Effects and Criticality Analysis,FMECA)文件的載入與自動(dòng)解析;

⑤ 支持基于模型生成故障-測試依賴矩陣(又稱D矩陣);

⑥ 支持對模型進(jìn)行測試性參數(shù)分析;

⑦ 支持基于TEAMS-RT算法的故障推理;

⑧ 支持專家規(guī)則的增、刪、改、查、在線編輯和綁定;

⑨ 支持可執(zhí)行任務(wù)的增、刪、改、查;

⑩ 支持離線上傳數(shù)據(jù)以執(zhí)行專家規(guī)則任務(wù),獲得基于專家知識的診斷結(jié)果,支持診斷結(jié)果的下載;

2 軟件設(shè)計(jì)

2.1 架構(gòu)設(shè)計(jì)

為提高機(jī)載系統(tǒng)故障診斷平臺的可擴(kuò)展性、降低機(jī)載系統(tǒng)測試診斷成本、提升診斷系統(tǒng)的通用性與診斷過程的可監(jiān)視性,系統(tǒng)設(shè)計(jì)采用B/S架構(gòu),將平臺前端與后端進(jìn)行解耦處理,可有效滿足基于云平臺的部署需求。其中平臺前端瀏覽器具有人機(jī)交互界面,提供外部數(shù)據(jù)導(dǎo)入、故障建模、診斷推理、診斷查詢等用戶指令的接收功能,與后端建立通信并將后端的響應(yīng)數(shù)據(jù)以可視化的形式反饋至用戶;后端服務(wù)器響應(yīng)前端請求,提供基于數(shù)據(jù)庫的數(shù)據(jù)存儲與管理、用戶管理、網(wǎng)絡(luò)通信、故障診斷業(yè)務(wù)邏輯與實(shí)現(xiàn)等功能,完成前端指令的執(zhí)行工作。故障診斷軟件平臺架構(gòu)如圖1所示,包含以下5層。

圖1 故障診斷軟件平臺架構(gòu)圖

① UI應(yīng)用層:為用戶提供作為平臺基礎(chǔ)與具備核心功能的人機(jī)交互界面,通過診斷知識、模型和結(jié)果的可視化配置,有效提供診斷過程的可監(jiān)視性。

② 數(shù)據(jù)交互層:提供前后端信息交互傳遞接口,以保證平臺的穩(wěn)定應(yīng)用。

③ 業(yè)務(wù)邏輯層:平臺功能實(shí)現(xiàn)的核心層,完成平臺的數(shù)據(jù)處理、診斷模型構(gòu)建和推理等工作,采用模塊化的方式構(gòu)建,減少了各功能之間的耦合程度,便于軟件維護(hù)。

④ 中間件層:提供后端框架引擎與基礎(chǔ)配置工具。

⑤ 數(shù)據(jù)層:以數(shù)據(jù)庫為主,獨(dú)立文件為輔,實(shí)現(xiàn)診斷知識、測試數(shù)據(jù)、診斷記錄、平臺信息等數(shù)據(jù)的存儲。

2.2 核心功能設(shè)計(jì)

為有效提升故障診斷平臺的通用性,設(shè)計(jì)了模型、數(shù)據(jù)、專家知識驅(qū)動(dòng)的混合診斷方法,軟件平臺功能模塊如圖2所示,這樣用戶可以根據(jù)診斷需求自由選擇1個(gè)或多個(gè)診斷方法,以更好地服務(wù)于不同機(jī)載設(shè)備的多樣輸入輸出形式。此外,為提升軟件平臺的適用性,設(shè)計(jì)了必要的輔助管理功能,包括用戶管理和診斷結(jié)果管理。

圖2 軟件平臺功能模塊圖

2.2.1 基于多信號流圖模型的故障診斷模塊

鑒于多信號流圖[11]可清晰表示故障與測點(diǎn)關(guān)系,可直接用于故障診斷,且在文獻(xiàn)[12]和文獻(xiàn)[13]中應(yīng)用多信號流圖實(shí)現(xiàn)了對多種機(jī)載設(shè)備的有效診斷,因此將其作為核心模塊之一,軟件主要通過多信號流圖建模以及TEAMS-RT算法[14-15]實(shí)現(xiàn)?；诙嘈盘柫鲌D模型的故障診斷流程如圖3所示。

圖3 基于模型的故障診斷流程

傳統(tǒng)的多信號流圖建模需要技術(shù)人員根據(jù)診斷對象的系統(tǒng)結(jié)構(gòu)與原理分析手動(dòng)建模,本文為提高建模效率,充分利用系統(tǒng)設(shè)計(jì)時(shí)提供的故障模式、影響和危害分析FMECA文件,通過FMECA載入模塊快速實(shí)現(xiàn)故障模式提取,以省去煩瑣的建模過程,讓技術(shù)人員更關(guān)注于信號傳遞、故障模式之間的關(guān)系,提高建模效率。技術(shù)人員利用多信號流圖建模模塊與已載入的FMECA故障信息,以信號、部件故障與測點(diǎn)為主要元素建立多信號流圖,即完成模型的構(gòu)建。

基于建立的多信號流圖,測試性分析模塊將其轉(zhuǎn)化為D矩陣,并計(jì)算相關(guān)測試行參數(shù)。一般地, D矩陣的行對應(yīng)一個(gè)故障模式,列對應(yīng)一種測試或一個(gè)測點(diǎn)。對于復(fù)雜系統(tǒng),綜合考慮效率與計(jì)算成本,診斷推理模塊基于測試結(jié)果,應(yīng)用TEAMS-RT算法對生成的D矩陣進(jìn)行分析,實(shí)現(xiàn)對故障模式的判斷。

2.2.2 基于專家知識系統(tǒng)的故障診斷模塊

專家推理機(jī)[16]可將傳統(tǒng)的專家知識轉(zhuǎn)換為數(shù)條計(jì)算機(jī)可執(zhí)行的機(jī)載設(shè)備故障診斷規(guī)則,具備靈活、精準(zhǔn)、執(zhí)行速度快等優(yōu)勢。

本文將構(gòu)建IF-THEN專家推理機(jī)作為本模塊實(shí)現(xiàn)的核心,同時(shí)為有效提高知識的復(fù)用性,設(shè)計(jì)了基于Python函數(shù)的統(tǒng)一規(guī)則編輯模板,可利用專家規(guī)則編輯模塊提供的濾波、閾值比較、邏輯組合判斷等功能,快速將抽象的專家知識編輯為診斷規(guī)則,并將其存儲至規(guī)則庫集中管理?；趯＜抑R系統(tǒng)的故障診斷流程如圖4所示。

圖4 基于專家知識系統(tǒng)的故障診斷流程

在對不同機(jī)載設(shè)備進(jìn)行診斷應(yīng)用時(shí),先通過規(guī)則庫管理模塊檢索所需規(guī)則,再利用專家規(guī)則綁定模塊將規(guī)則與實(shí)際測點(diǎn)綁定。為完成機(jī)載系統(tǒng)的復(fù)雜診斷需求,專家規(guī)則綁定模塊可對測點(diǎn)綁定多條規(guī)則,從而完成專家推理機(jī)的構(gòu)建?；谝褬?gòu)建的專家推理機(jī),診斷結(jié)果監(jiān)視模塊對機(jī)載設(shè)備的測試數(shù)據(jù)進(jìn)行推理分析,并將診斷結(jié)果以表格形式進(jìn)行可視化展示與存儲。

2.2.3 基于數(shù)據(jù)驅(qū)動(dòng)的故障診斷模塊

鑒于數(shù)據(jù)驅(qū)動(dòng)可只基于數(shù)據(jù)本身潛在的故障特征實(shí)現(xiàn)設(shè)備的異常檢測與故障預(yù)測,無須依賴先驗(yàn)知識,可作為基于模型與基于專家知識診斷方法的補(bǔ)充。尤其在現(xiàn)場技術(shù)人員對機(jī)載設(shè)備結(jié)構(gòu)與原理知識掌握不足、專家知識缺乏的情況下,可直接利用該模塊提供的功能完成設(shè)備的故障預(yù)測。基于數(shù)據(jù)驅(qū)動(dòng)的故障診斷流程如圖5所示。

圖5 基于數(shù)據(jù)驅(qū)動(dòng)的故障診斷流程

對于測試數(shù)據(jù),為方便存儲與管理,設(shè)計(jì)數(shù)據(jù)的上傳與管理模塊實(shí)現(xiàn)對測試數(shù)據(jù)的自動(dòng)載入和集中管理。對于診斷算法,由于機(jī)載系統(tǒng)的測試數(shù)據(jù)特點(diǎn)不同,其診斷算法多種多樣,為有效提高診斷算法的復(fù)用性,需要對診斷算法的輸入格式進(jìn)行規(guī)范化處理,為提高基于數(shù)據(jù)診斷的可擴(kuò)展性,設(shè)計(jì)訓(xùn)練與測試腳本載入模塊,對不同測試數(shù)據(jù)加載多種類型的診斷算法,以滿足不同機(jī)載設(shè)備的診斷需求。

訓(xùn)練模型與模型管理模塊基于已載入的測試數(shù)據(jù)與診斷算法進(jìn)行算法模型的訓(xùn)練,進(jìn)而得到診斷模型?；诘玫降脑\斷模型,執(zhí)行測試與結(jié)果管理模塊完成對機(jī)載設(shè)備的異常檢測與故障預(yù)測。

2.2.4 用戶管理模塊與診斷結(jié)果管理模塊

機(jī)載系統(tǒng)種類多、數(shù)量大且異常復(fù)雜,需要多專業(yè)協(xié)同工作與管理,為保證平臺的有序運(yùn)行,需要使用用戶管理模塊。平臺管理者按需通過用戶增、刪、改、查模塊添加新用戶,通過角色管理模塊完成用戶的角色設(shè)置,通過權(quán)限管理模塊完成角色權(quán)限設(shè)置,支撐數(shù)據(jù)、腳本、模型和結(jié)果的共享,提高診斷效率。

為方便共享診斷知識,設(shè)計(jì)診斷結(jié)果管理模塊對診斷數(shù)據(jù)進(jìn)行統(tǒng)一管理。一方面設(shè)計(jì)診斷報(bào)告生成模塊,以規(guī)范輸出診斷報(bào)告;另一方面設(shè)計(jì)平臺使用記錄模塊與診斷結(jié)果歷史記錄模塊,將使用記錄與診斷結(jié)果緩存至后端服務(wù)器,以備故障知識的查詢或故障復(fù)現(xiàn)使用。

2.3 交互設(shè)計(jì)

為保證機(jī)載系統(tǒng)故障診斷過程中數(shù)據(jù)的有效傳遞和平臺的正常運(yùn)行,系統(tǒng)設(shè)計(jì)平臺內(nèi)外部交互方式如圖6所示。

圖6 平臺交互示意圖

平臺內(nèi)部交互指通用故障診斷平臺前端瀏覽器與后端服務(wù)器之間的通信,綜合考慮機(jī)載系統(tǒng)故障診斷過程的可監(jiān)視性和診斷結(jié)果的可檢索性,設(shè)計(jì)實(shí)現(xiàn)2種內(nèi)部通信模式,具體包括:① 基于Axios的前后端異步通信模式,該模式由前端主動(dòng)發(fā)起,主要用于服務(wù)器端數(shù)據(jù)的拉取、前端指令的提交與響應(yīng)等,基于該模式可有效滿足指令、信息或文件的雙向流通;② 基于WebSocket的前后端實(shí)時(shí)通信模式[17],以支撐完成故障診斷推理的實(shí)時(shí)交互。

平臺外部交互指診斷平臺與外部環(huán)境的交互,主要表現(xiàn)為用戶與平臺前端的交互。鑒于基于模型或知識的機(jī)載系統(tǒng)故障診斷需依賴大量的專家先驗(yàn)知識,以及基于數(shù)據(jù)驅(qū)動(dòng)的機(jī)載系統(tǒng)故障診斷需依賴大量測試數(shù)據(jù),為有效減少數(shù)據(jù)處理時(shí)間、提高故障診斷效率,外部交互設(shè)計(jì)預(yù)留支持.json、.xlsx和.py等格式文件的數(shù)據(jù)交換接口,以支持內(nèi)外部數(shù)據(jù)的自動(dòng)解析與轉(zhuǎn)換。診斷平臺前端接收用戶數(shù)據(jù)上傳指令,從本地讀取用于機(jī)載設(shè)備故障診斷模型建模所需的FMECA文件與專家知識等,自動(dòng)解析成平臺所需的數(shù)據(jù)形式,并在瀏覽器界面展示,以便用戶查看并檢查數(shù)據(jù)的正確性。

3 3種診斷方法間的關(guān)系

3種診斷方法彼此獨(dú)立,在合適的條件下,可并行完成不同機(jī)載設(shè)備或診斷需求的故障診斷任務(wù)。當(dāng)熟悉機(jī)載設(shè)備結(jié)果與原理、但測試數(shù)據(jù)不充裕時(shí),可優(yōu)先選擇基于多信號流圖模型的診斷方法完成對機(jī)載設(shè)備的故障診斷。

3種診斷方法相互聯(lián)系,生成的診斷結(jié)果可以相互利用,如圖7所示。在機(jī)載系統(tǒng)的診斷應(yīng)用中,為有效保證診斷結(jié)果的可靠性、提升診斷效率,平臺支持3種方法的串聯(lián)組合使用。如針對以多信號流圖模型為主的機(jī)載系統(tǒng)故障診斷應(yīng)用中,為有效提升診斷效率與診斷結(jié)果的準(zhǔn)確性,可通過基于專家知識系統(tǒng)的故障診斷模塊與基于數(shù)據(jù)驅(qū)動(dòng)的故障診斷模塊實(shí)現(xiàn)對測試數(shù)據(jù)的預(yù)處理,將其轉(zhuǎn)換為符合TEAMS-RT算法輸入的標(biāo)準(zhǔn)數(shù)據(jù)格式,再結(jié)合多信號流圖生成的D矩陣,從而有效完成機(jī)載設(shè)備的故障診斷。

圖7 3種方法之間的關(guān)系示意圖

4 應(yīng)用實(shí)例與對比分析

4.1 應(yīng)用實(shí)例

以某型號無人機(jī)大氣數(shù)據(jù)系統(tǒng)為例,應(yīng)用本文平臺完成實(shí)際故障的診斷,以充分驗(yàn)證平臺的有效性。此案例以基于模型的故障診斷為主體方法,使用規(guī)則推理機(jī)和基于數(shù)據(jù)驅(qū)動(dòng)的故障診斷方法為TEAMS-RT算法提供測試向量,最終依靠TEAMS-RT算法得到診斷結(jié)果。詳細(xì)故障診斷流程如圖8所示。其中最右側(cè)通路為基于模型的故障診斷,中部通路為數(shù)據(jù)驅(qū)動(dòng)部分,左側(cè)通路為規(guī)則推理部分。事實(shí)上,在一些其他情況下,也可以直接對規(guī)則推理機(jī)或數(shù)據(jù)驅(qū)動(dòng)方法的結(jié)果賦予意義,直接作為故障診斷結(jié)果,如圖8中的(A)、(B)位置所示。

圖8 某型號無人機(jī)大氣數(shù)據(jù)系統(tǒng)的故障診斷流程

在建模方面,本案例選擇了靜壓引氣管測壓孔堵塞、靜壓受感器開路等11個(gè)常見的重要部件故障模式,以及靜壓機(jī)內(nèi)測試、總溫探頭人工檢測等13個(gè)可執(zhí)行的測試進(jìn)行分析,然后通過軟件平臺的多信號流圖建模模塊完成了機(jī)載大氣數(shù)據(jù)系統(tǒng)的多信號流圖模型構(gòu)建,模型與軟件界面如圖9所示。

圖9 機(jī)載大氣數(shù)據(jù)系統(tǒng)多信號流圖建模與軟件界面

其中TEAMS-RT算法的輸入來源包括:① 基于多信號流圖建模模塊自動(dòng)生成D矩陣。② 多渠道診斷得到的布爾測試向量組,該向量組包括結(jié)合實(shí)際情況,通過構(gòu)建含有13個(gè)規(guī)則的推理機(jī),對傳感器已接收數(shù)據(jù)進(jìn)行邏輯、門限等判斷,輸出基于專家知識系統(tǒng)模塊診斷的布爾測試向量;針對長時(shí)間的無標(biāo)簽數(shù)據(jù),采用獨(dú)立森林異常檢測算法進(jìn)行檢測,得到基于數(shù)據(jù)驅(qū)動(dòng)模塊診斷的布爾測試向量和外部導(dǎo)入平臺的其他布爾測試向量。

此案例生成的D矩陣與測試診斷結(jié)果如圖10所示。測試結(jié)果表明,平臺基于已生成的測試向量組與D矩陣執(zhí)行TEAMS-RT算法成功將故障定位至靜壓引氣管路泄漏,這將充分證明研究設(shè)計(jì)的機(jī)載系統(tǒng)通用故障診斷軟件平臺的實(shí)際有效性。

圖10 D矩陣與測試診斷結(jié)果圖

4.2 對比分析

從平臺所支持的診斷策略、是否支持診斷知識共享,以及平臺的適用范圍即平臺通用性3個(gè)方面對提出的平臺與現(xiàn)有的機(jī)載設(shè)備故障診斷平臺進(jìn)行比較,對比結(jié)果如表1所示。本文設(shè)計(jì)的故障診斷平臺不僅支持多策略的組合診斷,也支持不同診斷策略間診斷知識的共享與復(fù)用,可有效提升機(jī)載系統(tǒng)故障診斷平臺的通用性與診斷效率。

表1 本文平臺與現(xiàn)有機(jī)載設(shè)備故障診斷平臺對比表

5 結(jié)束語

針對機(jī)載系統(tǒng),本文設(shè)計(jì)實(shí)現(xiàn)了一種通用故障診斷軟件平臺。該平臺通過搭載模型、數(shù)據(jù)、專家知識驅(qū)動(dòng)的3種可獨(dú)立或組合運(yùn)行的故障診斷方法,可有效滿足不同機(jī)載設(shè)備的診斷需求,提高機(jī)載設(shè)備的故障診斷效率,為后續(xù)機(jī)載系統(tǒng)的通用故障診斷測試研究提供了平臺技術(shù)支撐。