空間站有效載荷預測性維護支持系統(tǒng)設計

施建明王 功王 偉李緒志

(中國科學院空間應用工程與技術中心，北京 100094)

1 引言

空間站空間應用系統(tǒng)有效載荷設備包括信息管理、供配電、熱控、氮氣供應等共用支持設備、空間科學實驗和技術試驗機柜、艙內(nèi)外獨立載荷等。在空間站運營期，這些設施、設備長期運行，需要定期在軌維護、維修及系統(tǒng)升級。空間站有效載荷維修保障資源有限，修復性維修和定期維修精準性低、資源代價大，難以滿足空間站運行安全性、可靠性要求。預測性維護對設備進行狀態(tài)監(jiān)測、持續(xù)對監(jiān)測數(shù)據(jù)進行分析計算、評判設備的健康狀態(tài)、預測健康趨勢，為有效載荷制定更合理的維護維修計劃和備品備件上行方案。

NASA針對國際空間站任務開展了集成系統(tǒng)健康管理(Integrated System Health Management，ISHM)技術研究，并開發(fā)了狀態(tài)監(jiān)測工具軟件，用于航天飛機、ISS控制力矩陀螺、ISS主動熱控系統(tǒng)的狀態(tài)監(jiān)測任務。軟件的核心算法是K最近鄰(Knearest Neighbor，KNN)和聚類(Clustering)，這些算法和工具在航天器健康監(jiān)測上有較成功的應用。借鑒NASA的經(jīng)驗，余晟等提出一種基于推演式聚類學習算法的衛(wèi)星健康狀態(tài)監(jiān)視系統(tǒng)，并通過熱控分系統(tǒng)的測試數(shù)據(jù)對該系統(tǒng)的有效性進行驗證，能較好地完成狀態(tài)識別與評估。

有效載荷方面，NASA在科學實驗柜接口定義文檔中對有效載荷的健康和狀態(tài)數(shù)據(jù)的定義、數(shù)據(jù)傳輸、處理、顯示等進行了規(guī)定。中國空間站有效載荷設計了一定的在軌故障診斷功能，并將故障事件和傳感器參數(shù)等數(shù)據(jù)下行至地面。同時，也開展了預測及健康管理(Prognostic and Health Management，PHM)相關方法、算法研究與地面健康管理軟件開發(fā)工作，通過制冷機在軌數(shù)據(jù)、熱控子系統(tǒng)地面測試數(shù)據(jù)等進行了技術驗證。

有效載荷產(chǎn)品種類較多，故障模式與機理復雜，需要采用不同算法處理大量的監(jiān)測數(shù)據(jù)、訓練故障診斷和預測模型。為提升算法、模型及業(yè)務程序的開發(fā)和集成效率，各有效載荷產(chǎn)品應統(tǒng)一開發(fā)范式，解決標準不統(tǒng)一、接口不匹配、數(shù)據(jù)不一致等問題。且預測性維護技術相關方法、理論研究成果急需工程化的軟件和平臺來承載，并通過實測數(shù)據(jù)來實現(xiàn)技術驗證和迭代。為此，本文構建面向有效載荷的系統(tǒng)層預測性維護支持平臺，對核心的自動輔助建模軟件開展架構設計和基礎開發(fā)工作，為后續(xù)持續(xù)擴展和優(yōu)化打下基礎。

2 預測性維護支持系統(tǒng)方案設計

有效載荷產(chǎn)品自身集成了一定的在軌故障自檢測和診斷功能，對影響安全性和重要功能的異常狀態(tài)進行實時檢測，采用閾值判斷的方式來實現(xiàn)，適用于故障需要立即響應的場景。預測性維護支持系統(tǒng)能充分利用地面的存儲和計算資源，對有效載荷長期運行積累的大量數(shù)據(jù)開展分析，能完成在軌不便開展的趨勢分析、多維監(jiān)測數(shù)據(jù)聯(lián)合分析以及復雜機器學習模型的訓練、使用、評價與再訓練等任務。經(jīng)過實際數(shù)據(jù)充分驗證的算法和模型，還能用于在軌故障檢測功能和性能的升級。

空間站有效載荷在軌出現(xiàn)故障時，很多情況下無法通過自診斷功能獨立確認要更換的目標部件，即在軌可更換單元(Orbital Replaceable Unit，ORU)，而人工分析和排查往往費時費力。通過綜合分析有效載荷監(jiān)測數(shù)據(jù)，調(diào)用診斷模型，結合推理邏輯，能實現(xiàn)故障的快速準確定位，這是預測性維護支持系統(tǒng)的智能診斷功能。有效載荷包含有退化特征的產(chǎn)品，例如泵組、過濾器、電池、制冷機等，建立性能退化模型，持續(xù)跟蹤退化趨勢，預測剩余壽命，為備件保障和維修準備提供預測性指示。此外，還需定期對設備、分系統(tǒng)、系統(tǒng)開展基于監(jiān)測數(shù)據(jù)的健康評估，讓地面人員能全面掌握有效載荷健康動態(tài)。圖1為空間站有效載荷預測性維護支持系統(tǒng)的方案設計圖，由數(shù)據(jù)庫、自動輔助建模軟件、計算平臺、Web UI程序4個部分組成。

圖1 預測性維護支持系統(tǒng)方案Fig.1 Scheme of the predictive maintenance support system

2.1 數(shù)據(jù)庫

空間站有效載荷數(shù)據(jù)量大、來源多，為充分挖掘數(shù)據(jù)中對預測性維護有指導意義的信息，應統(tǒng)一規(guī)劃數(shù)據(jù)源。根據(jù)數(shù)據(jù)來源不同，分為研制階段產(chǎn)生的數(shù)據(jù)與運行階段產(chǎn)生的數(shù)據(jù)。以運行階段的數(shù)據(jù)為主要數(shù)據(jù)來源，根據(jù)需要提取研制階段的數(shù)據(jù)輔助分析。數(shù)據(jù)類型分為結構化數(shù)據(jù)和非結構化數(shù)據(jù)，針對不同數(shù)據(jù)類型選擇合適的數(shù)據(jù)庫。有效載荷監(jiān)測數(shù)據(jù)以時序數(shù)據(jù)為主，在工業(yè)大數(shù)據(jù)、工業(yè)互聯(lián)網(wǎng)領域，InfluxDB、OpenTSDB等是常用的開源時序數(shù)據(jù)庫軟件，可用于存儲與管理有效載荷狀態(tài)監(jiān)測數(shù)據(jù)。表1列出了預測性維護支持系統(tǒng)的數(shù)據(jù)源及相應的數(shù)據(jù)庫產(chǎn)品選型。

表1 預測性維護支持系統(tǒng)數(shù)據(jù)源Table 1 Data sources of PMSS

有效載荷運行狀態(tài)監(jiān)測數(shù)據(jù)以遙測、工程數(shù)據(jù)(下行的狀態(tài)監(jiān)測數(shù)據(jù))為主，包含了在軌診斷(例如機內(nèi)測試)給出的故障或異常狀態(tài)的指示量，在排除錯誤診斷的前提下，這些指示量可為數(shù)據(jù)標記提供重要的參考。數(shù)據(jù)通過天地通訊鏈路下行至地面，地面控制中心進行通訊管控，地面數(shù)據(jù)中心進行數(shù)據(jù)管理，預測性維護支持系統(tǒng)作為地面系統(tǒng)的一部分，提供非緊急故障的診斷、健康狀態(tài)長期跟蹤和預測等服務，允許一定的時間延遲。因此，數(shù)據(jù)庫可貼近業(yè)務端進行部署，以近實時的方式從數(shù)據(jù)中心獲取所需的數(shù)據(jù)。

2.2 自動輔助建模軟件

設計開發(fā)自動輔助建模軟件是為提供統(tǒng)一的有效載荷故障診斷和預測建模平臺，在此平臺上，建模專家和領域專家協(xié)作開展建模工作，把概率統(tǒng)計、信號處理、機器學習等數(shù)據(jù)建模技術同有效載荷產(chǎn)品知識和故障機理緊密結合起來，并進行快速迭代、集成與擴展。建模流程如圖2所示，具體步驟如下:

圖2 PHM建模流程Fig.2 PHM modeling process

1)定義建模對象和故障模式。根據(jù)有效載荷產(chǎn)品組成和FMEA報告等，建模專家和領域專家共同梳理出模型清單；

2)構建故障模式發(fā)生和處置場景，為建模提供應用依據(jù)；

3)對故障模式類型進行判定，包括預警類、診斷類及RUL預測類；

4)基于模型清單，對每個模型建立所需的輸入數(shù)據(jù)進行梳理，構建輸入數(shù)據(jù)集；

5)建立故障模型，包括用于故障預警的基線模型、用于故障診斷的特征識別模型、用于RUL預測的退化模型。

空間站有效載荷產(chǎn)品類型多樣、故障模式復雜、研制單位眾多，不同故障診斷、預測算法和模型應能以標準接口進行集成，并以統(tǒng)一范式實現(xiàn)。自動輔助建模軟件是預測性維護支持系統(tǒng)的核心部分，承載有效載荷數(shù)據(jù)智能分析、故障診斷與預測建模、模型優(yōu)化及管理的功能，第3節(jié)將對輔助建模軟件的設計進行詳細論述。

2.3 計算平臺

自動輔助建模軟件生成的模型，由計算平臺調(diào)用完成數(shù)據(jù)計算處理，并將結果輸出，包括異常預警信號、故障診斷結果、指標預報或RUL預測值等信息。當數(shù)據(jù)量不大時，可在單臺計算機或服務器上完成計算任務。隨著數(shù)據(jù)量的增大，需要并行計算甚至分布式大數(shù)據(jù)計算平臺，以提高計算速度，滿足業(yè)務需求。

根據(jù)異常預警、故障診斷、預報預測等業(yè)務特點的要求，分別采用實時計算、觸發(fā)計算、定時計算等策略來實現(xiàn)對數(shù)據(jù)的計算處理。

2.4 Web UI程序

界面程序將與狀態(tài)監(jiān)測和診斷相關的信息通過數(shù)據(jù)可視化的形式展示出來，包括基于2D、3D的設備畫面展示、基于儀表盤或圖表的數(shù)據(jù)展示等。UI界面顯示出的診斷、預測、預報等信息，可支持地面人員開展維護維修決策活動。

基于Web技術開發(fā)后端程序包括:①構建SpringBoot后端框架；②編寫數(shù)據(jù)庫訪問配置文件；③開發(fā)數(shù)據(jù)查詢與寫入程序。開發(fā)前端程序包括:①2D、3D顯示圖紙設計和代碼開發(fā)；②對圖元進行數(shù)據(jù)綁定配置，實現(xiàn)與后端測點的關聯(lián)。數(shù)據(jù)庫中的各類數(shù)據(jù)經(jīng)由后端程序查詢后，設置到前端圖元、圖標上，實現(xiàn)數(shù)據(jù)的實時呈現(xiàn)。

3 自動輔助建模軟件設計

設計開放式、層次化、可擴展的軟件架構，不同有效載荷產(chǎn)品研制方可在統(tǒng)一的架構上增量式開發(fā)算法和模型，匯聚成空間站有效載荷預測性維護的算法庫和模型庫。

3.1 層次化架構與軟件包設計

自動輔助建模軟件的層次化架構設計如圖3所示，由接口層、特征層、算法層、模型層、應用層5個層級構成。

圖3 自動輔助建模軟件架構Fig.3 Architecture of the AAMS

基于圖3所示的層次化架構，構建與架構一一匹配的軟件包，由代表各層軟件子包組成，程序文件分門別類地放置在設計好的路徑下，方便函數(shù)的調(diào)用和類的實例化。程序集成、擴展和升級在軟件包的統(tǒng)一管理下有序開展。由于涉及大量復雜的工程計算和智能建模，自動輔助建模軟件可采用Matlab、Python等進行開發(fā)，利用已有的框架或工具來構建定制化的算法庫和模型庫，提高開發(fā)效率。圖4所示的軟件包是基于Matlab環(huán)境設計的，一級軟件子包分為“＋api”、“＋features”、“＋algorithms”、“＋models”、“＋app”，其中“＋”不可或缺，其作用是將子包納入可執(zhí)行路徑下。

圖4 自動輔助建模軟件包組成Fig.4 The AAMS package

3.2 各層程序設計

3.2.1 接口層

接口層承載建模軟件與外部的接口程序，包括與數(shù)據(jù)庫的接口程序及與計算平臺的接口程序。通過與數(shù)據(jù)庫的接口，軟件可對數(shù)據(jù)庫進行讀寫操作，獲取所需的數(shù)據(jù)，并將處理后的輸出結果寫入數(shù)據(jù)庫。通過與計算平臺的接口和外部計算程序進行交互，使用外部計算資源，或由外部計算程序調(diào)用內(nèi)部的模型和算法。

在“＋api”文件夾下建立相應數(shù)據(jù)庫接口程序的二級子包，例如“＋InfluxDB”、“＋TSDB”等，包括數(shù)據(jù)庫配置文件、配置文件解析程序、數(shù)據(jù)查詢程序、數(shù)據(jù)寫入程序等。

為便于開發(fā)人員調(diào)用建模軟件包中的程序，在接口層提供相應的API(Application Programming Interface)。通過接口層，自動輔助建模軟件方便集成到預測性維護支持系統(tǒng)中，或移植到已有的運維平臺上去使用。

3.2.2 特征層

有些情況下，故障特征與原始監(jiān)測數(shù)據(jù)無直接的關聯(lián)，例如設備振動信號、聲音信號、圖像數(shù)據(jù)、工質(zhì)理化特性等。需要采用特征提取程序將原始數(shù)據(jù)轉化成相應的特征數(shù)據(jù)。

在建模軟件中設計特征層，將可能用到的特征提取程序歸于“＋features”路徑下。一般包括特征配置文件、配置文件解析程序、特征提取函數(shù)、特征提取腳本等。

通過特征提取出的中間數(shù)據(jù)可寫入到數(shù)據(jù)庫中，或保存在“＋features”下的FeatureData路徑下，便于統(tǒng)一管理。

3.2.3 算法層

在工業(yè)系統(tǒng)預測性維護場景中，數(shù)據(jù)驅動是當前的主流，在“＋algorithms”算法包中，除了數(shù)據(jù)清洗、預處理、聚類、分類、回歸等算法程序外，還有數(shù)據(jù)集構造、流程檢查等輔助性程序。在運營階段初期，大部分有效載荷處于正常狀態(tài)，通過聚類算法或回歸算法可學習健康基線，得到各種運行模式下的正常類簇或參數(shù)關聯(lián)模型。通過類簇識別、偏移量計算能發(fā)現(xiàn)異常征兆。隨著有效載荷出現(xiàn)退化或故障，提取特定窗口的多維監(jiān)測數(shù)據(jù)用于構造數(shù)據(jù)集。通過回歸算法能訓練相應的預測模型，用于預測未來健康退化趨勢和RUL；通過分類算法能訓練故障特征識別模型，用于故障診斷。

為提高算法開發(fā)和使用算法分析數(shù)據(jù)的效率，需設計一種標準化同時又具有彈性的數(shù)據(jù)處理機制，包括標準化算法類設計、彈性數(shù)據(jù)處理模板和可追溯的算法比對機制。

1)標準化算法類設計。首先，設計7個算法父類，分別是數(shù)據(jù)清洗算法Cleaner、數(shù)據(jù)預處理算法Preprocessor、聚類算法Clusteringer、分類算法Classifier、回歸算法Regressor、深度學習回歸算法(Long Short Term Memory，LSTM)、深度學習分類算法(Convolutional Neural Network，CNN)。每個父類下繼承了多個具體的算法子類，例如聚類下有Kmeans聚類、層次聚類、自組織映射等。其次，每個算法子類采用標準的框架設計，類的屬性為算法參數(shù)，類方法主函數(shù)是數(shù)據(jù)處理流程，包括數(shù)據(jù)輸入、算法參數(shù)設置文件導入、交叉驗證數(shù)據(jù)集構造(必要時)、核心處理模塊、結果整理和輸出。

2)彈性數(shù)據(jù)處理模板。建模時可采用單一算法處理數(shù)據(jù)，也可采用多算法串接的方式處理數(shù)據(jù)，并有不同算法、不同算法參數(shù)設置比對的需求。為不重復編寫算法代碼，且能靈活配置算法和設置算法參數(shù)，采用數(shù)據(jù)和算法分離的策略模式及多算法串接的模板模式。串接多算法形成數(shù)據(jù)處理流程后，調(diào)用流程檢查程序，確保所構造的流程符合數(shù)據(jù)分析處理的邏輯。

3)可追溯的算法對比機制。設計一種可追溯的比對機制，使得建模人員能快速完成模型批訓練、批測試，并回看不同算法參數(shù)設置下的模型評分，自動導出最優(yōu)的算法參數(shù)和模型。在標準算法類設計時考慮算法調(diào)參和比對問題，算法每次調(diào)用都會自動去讀取相應的參數(shù)設置文件，通過記錄每次參數(shù)設置及對應的評分來進行追蹤。

3.2.4 模型層

輔助建模軟件的模型層包括數(shù)據(jù)模型和機理模型?；诰垲?、分類、回歸等算法對數(shù)據(jù)進行處理所輸出的模型即數(shù)據(jù)模型:聚類模型是聚類分析得到的類簇信息，包括類簇的中心、半徑及其標記；分類模型是通過分類算法處理得到的模型，如決策樹(Decision Tree，DT)分類模型、支持向量機(Support Vector Machine，SVM)分類模型、淺層神經(jīng)網(wǎng)絡(Neural Network，NN)分類模型、卷積神經(jīng)網(wǎng)絡CNN分類模型等；回歸模型是通過回歸算法得到的模型，如線性回歸(Linear Regression，LNR)模型、非線性回歸(Nonlinear Regression，NLR)模型、關聯(lián)向量回歸(Relevance Vector Regression，RVR)模型、序列到序列LSTM回歸模型等。在“＋models”下建立ModelLearned路徑，將訓練好的模型保存在該路徑下，也可導出為標準數(shù)據(jù)格式的文件用于其他分析軟件或平臺。

與有效載荷產(chǎn)品層級一一對應，構建故障診斷和預測的機理模型。以有效載荷熱控系統(tǒng)為例進行說明，“＋models”下建立“＋ThermalControlSystem”二級軟件子包，所有熱控系統(tǒng)相關的模型層程序文件均放置在該路徑下。

首先，“＋ThermalControlSystem”下建立＠Component文件夾，在此文件夾中定義一個抽象的父類Component，在Component父類中定義熱控系統(tǒng)及其部件的通用屬性，例如名稱(Name)、設計參數(shù)(Design Param)、輸入數(shù)據(jù)(Input Data)、故障診斷和預測模型、診斷結果等屬性，其中，診斷結果屬性包含運行模式(Opt Mode)、健康基線(Base Line)、異常檢測結果(Is Anormal)、故障模式(Fault Mode)、健康狀態(tài)(Health Status)健康指標(Health Indices)等。

然后，構建熱控系統(tǒng)模型子類包:＠Thermal-ControlSystem、＠Pumppackage、＠Accumulator、＠Pipeline、＠Controller、＠Filter、＠Sensor等，涵蓋熱控的系統(tǒng)級模型和部件級模型。在子類方法中，編寫診斷模型或預測模型的建模邏輯函數(shù)，該函數(shù)調(diào)用算法進行建模，或者從已訓練好的模型庫中導入模型，并對數(shù)據(jù)模型和產(chǎn)品的實際故障進行關聯(lián)。例如，在＠ThermalControlSystem子類文件夾下構建ThermalControlSystem子類，在該子類方法中定義用于構建熱控系統(tǒng)健康狀態(tài)識別所用聚類模型的函數(shù)，該函數(shù)的主要功能是調(diào)用聚類算法(需要時增加數(shù)據(jù)清洗、預處理算法)處理輸入數(shù)據(jù)，得到聚類模型，并對設定的健康狀態(tài)和類簇進行關聯(lián)綁定。這樣，實例化ThermalControlSystem子類后，就可以通過調(diào)用相應的方法來完成針對具體業(yè)務的建模任務。

3.2.5 應用層

應用層是軟件的頂層，包括主程序及下屬的異常檢測、故障診斷、健康評估、健康指標合成、預測性分析等子程序。子程序各司其職，每個程序實現(xiàn)自己的單一職能。根據(jù)需求和場景的不同，預測性維護業(yè)務可對監(jiān)測數(shù)據(jù)開展實時分析診斷，輸出異常檢測和故障診斷結果；可在發(fā)現(xiàn)指標異常偏離基線后，對指標進行預測，并對可能的風險進行預警；可定期開展健康狀態(tài)評估；還可在健康狀態(tài)發(fā)生變化時開展RUL預測等。建立以業(yè)務流為主線的主程序，并調(diào)用下屬各子程序，應用層以類似于搭積木的方式靈活快速地搭建好特定的業(yè)務流程。

此外，還可開發(fā)圖形用戶界面應用(GUI App)，便于建模人員、領域專家開展離線數(shù)據(jù)分析和建模，并對后臺業(yè)務進行可視化的操控和實時分析結果查看。

4 開發(fā)與測試實例

4.1 采用策略模式分離數(shù)據(jù)和算法

在對產(chǎn)品狀態(tài)監(jiān)測數(shù)據(jù)進行處理時，經(jīng)常會遇到需要對數(shù)據(jù)施加不同算法的情形。聚類(Clustering)分析常用來識別設備的工作狀態(tài)，聚類算法有很多種，如Kmeans、Hierarchical Clustering(HC)、SOM(Self Organizing Map)等。在用聚類算法進行建模時，需要對比不同的算法，每種算法下面又有不同的算法參數(shù)需要設置。通過策略模式能將算法封裝起來，用戶可方便地選擇或替換算法，而算法也獨立于數(shù)據(jù)。圖5為采用策略模式開發(fā)聚類算法的統(tǒng)一建模語言(Unified Modeling Language，UML)圖。

圖5 策略模式分離算法和數(shù)據(jù)Fig.5 Separation between algorithm and data based on strategy pattern

各類之間通過如下的機制進行協(xié)作，以實現(xiàn)數(shù)據(jù)和算法的分離:

1)在PayloadDataSinglePro類對象中存放數(shù)據(jù)，而在Clusteringer子類對象中存放算法，PayloadDataSinglePro類的屬性strategyObj指向具體的Clusteringer子類對象，可以對該屬性的重新賦值來自由地更換算法；

2)PayloadDataSinglePro類對象把對具體的數(shù)據(jù)處理請求轉交給Clusteringer子類對象；

3)當轉交計算請求時，PayloadDataSinglePro類對象把自己作為一個參數(shù)傳遞給Clusteringer子類對象方法中action函數(shù)，從而使得子類對象擁有了計算所需要的數(shù)據(jù)。

4.2 結合策略模式和模板模式實現(xiàn)數(shù)據(jù)處理模板

當需要采用2個或2個以上算法串接來處理設備監(jiān)測數(shù)據(jù)時，就需要構造一種既符合數(shù)據(jù)處理流程邏輯，又可靈活配置算法的數(shù)據(jù)處理模板。不論數(shù)據(jù)如何變化，也不論數(shù)據(jù)處理流程如何改變，封裝好的算法類始終保持不變，只是每次處理所選的算法和算法組織順序有所不同。

采用多算法來處理數(shù)據(jù)有一套固定的流程，全流程處理遵循數(shù)據(jù)清洗、數(shù)據(jù)預處理、機器學習3個骨干步驟，這3個骨干步驟是不能顛倒順序的。另外根據(jù)數(shù)據(jù)處理目標的不同，數(shù)據(jù)處理流程有以下6種模板:①僅選擇數(shù)據(jù)清洗步驟中的多個算法；②僅選擇數(shù)據(jù)預處理步驟中的多個算法；③選擇跨數(shù)據(jù)清洗、數(shù)據(jù)預處理2個步驟中的多個算法；④選擇跨數(shù)據(jù)清洗、機器學習2個步驟中的多個算法；⑤選擇數(shù)據(jù)預處理、機器學習2個步驟中的多個算法；⑥選擇跨3個骨干步驟中的算法。這里假定機器學習算法一次處理只采用1種算法。

首先設計一個數(shù)據(jù)處理基類PayloadDataPro，將固定的處理步驟封裝在PayloadDataPro的templateMethod方法中，然后設計6個數(shù)據(jù)處理子類PdConcretePro1～PdConcretePro6，與上述6種數(shù)據(jù)處理模板一一對應。為子類能夠自由選擇算法，在PayloadDataPro的屬性中定義strategyObj，使得基類擁有策略對象，以聚類算法Clusteringer為例，該設計的UML如圖6所示。PayloadDataPro類中的templateMethod要聲明成封裝的方法(Sealed)，在基類中約定固定的數(shù)據(jù)處理流程，保證子類不會違反順序，3個骨干步驟的方法要聲明成抽象(Abstract)和訪問受保護(Access=protected)，以此固定接口且強制要求子類必須實現(xiàn)相應骨干步驟。PdConcretePro子類實現(xiàn)3個骨干步驟具體數(shù)據(jù)處理流程，方法聲明為protected，以保證這些方法只能被內(nèi)部的方法templateMethod調(diào)用。

圖6 結合策略模式與模板模式構建有效載荷數(shù)據(jù)處理流Fig.6 Payload data processing flow constructed by strategy pattern and template pattern

4.3 數(shù)據(jù)分析與建模測試

采用公開的燃料電池耐久性試驗數(shù)據(jù)來測試自動輔助建模軟件的可用性，電池堆的總輸出電壓Utot反映設備的性能或健康狀態(tài)，隨著時間積累，Utot呈現(xiàn)下降的趨勢，燃料電池性能逐漸退化。主要開展以下2方面的測試:①對比KMeans算法和HCClustering算法，測試算法更換和調(diào)參模式；②先采用MidFilter中值濾波算法進行數(shù)據(jù)清洗，后采用Kmeans或HC聚類算法進行聚類，檢驗數(shù)據(jù)處理流程的設計。

采用4.1、4.2節(jié)中的開發(fā)策略，開發(fā)出算法類、數(shù)據(jù)處理類等程序，然后編寫相應的測試腳本，對電池數(shù)據(jù)進行建模分析。以MidFilter＋HC為例進行說明，如表2所示。

表2 數(shù)據(jù)分析與建模測試腳本Table 2 Testing script for data analysis and modeling

在執(zhí)行聚類分析時，程序自動讀取參數(shù)設置文件，實現(xiàn)不同參數(shù)下的模型訓練，當需要更改算法時，只需要對測試腳本做簡單的更改即可，例如將聚類算法改成Kmeans算法，將表2程序的第4行改為mlStrategy=MachineLearning.KMClustering()即可。

評分采取Calinski-Harabasz(CH)準則，CH指標通過計算類中各點與類中心的距離平方和來度量類內(nèi)的緊密度，通過計算各類中心點與數(shù)據(jù)集中心點距離平方和來度量數(shù)據(jù)集的分離度，CH指標由分離度與緊密度的比值得到。CH越大代表著類自身越緊密，類與類之間越分散，即更優(yōu)的聚類結果。

表3展示了聚類分析不同算法或算法組合和不同參數(shù)設置下的評分，其中采用中值濾波加Kmeans且分類數(shù)為4時得到的聚類模型最佳。

表3 聚類分析評分結果Table 3 Scores of data clustering with different algorithms

5 結論

本文提出了一種可行的預測性維護支持系統(tǒng)框架，設計了自動輔助建模軟件架構，并進行了基礎開發(fā)，解決了相關算法、模型和業(yè)務程序開發(fā)缺少統(tǒng)一標準的問題。已開發(fā)出算法庫，建模人員無需重復編寫算法代碼即可快速完成常見數(shù)據(jù)驅動故障診斷和預測建模工作，能提高大量數(shù)據(jù)處理和建模時的效率。此外，通過外部接口定義和接口程序，自動輔助建模軟件易于部署，與系統(tǒng)其他模塊的集成也十分便利。