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

(航空工業(yè)成都飛機工業(yè)(集團)有限責任公司,四川 成都 610073)

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

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

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

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

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

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

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

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

1 需求分析

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

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

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

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

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

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

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

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

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

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

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

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

2 軟件設(shè)計

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

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

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

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

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

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

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

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

2.2 核心功能設(shè)計

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

圖2 軟件平臺功能模塊圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 交互設(shè)計

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

圖6 平臺交互示意圖

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

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

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

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

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

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

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

4.1 應(yīng)用實例

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

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

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

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

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

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

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

4.2 對比分析

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

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

5 結(jié)束語

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