民用航空發動機維修工程分析平臺設計與實現

蔣平，王向輝，宋利，龔艷，包麗，余濤

（1.中國航發商用航空發動機有限責任公司，上海200241）

（2.上海市慧程航空科技有限公司 技術部，上海200241）

0 引 言

隨著國內外航空發動機的使用和維修需求不斷提高，國際發動機制造廠家（通用電氣、普惠、羅羅等）均建立了維修保障服務體系，在維修工程、技術出版物、航材保障等專業開展了大量工作，這些措施既提升了發動機產品的客戶服務質量，又降低了發動機產品全壽命周期維修保障成本［1］。此外，中國民航局也制定了相關規范，要求航空器制造廠家建立相應的運行支持體系，用以保證其航空器及發動機的運維水平［2-3］。

國內關于維修工程分析方法和平臺的研究雖然起步較晚，但范圍廣、速度快，涵蓋了軍用飛機、民用飛機和船舶等多個領域。關于候選項的研究，敬軍等［4］結合船舶的4A需求對S3000L規范中候選項的判定方法進行了優化和完善，提出了一種覆蓋貨架產品、標準件和散裝件的候選項判定方法。計劃維修分析方面，柏文華［5］以MSG-3為指導思想，結合S3000L規范構建了大飛機的維修大綱工作流程，以支持主制造商和供應商開展維修工程分析工作，該方法與國際機型的維修工程分析工作［6］相一致；夏哲［7］將MTA方法結合國產民用飛機研制經驗進行了實踐和應用，提出了國產民用飛機維修工程分析的工作程序和方法。維修工程分析數據和維修成本方面，蔣慶喜［8］以MSG-3規范為基礎，對維修數據進行了研究，以指導維修工程分析的編制和應用。對于維修工程分析的研究，主要以S3000L、S4000P、MSG-3等標準/規范開展［9-12］。而在維修數據收集和優化方面，徐 小 芳 等［13］、Hong Sheng等［14］提 出 了 多 種RCM數據優化方法以提高產品維修性，包括試飛階段維修數據收集和優化。

不難看出，基于S3000L的維修工程分析工作通過一整套系統的流程和方法，規范了維修工程分析的工作內容和輸出數據，是提高產品保障性、派遣可靠度的重要工作指南。因此，維修工程分析也日益成為發動機綜合后勤保障服務的核心業務，對于發動機技術出版物和航材工程等專業的工作開展至關重要。而維修工程分析平臺作為維修工程分析和維修任務制定的重要載體和信息化工具，對于確保航空發動機維修工程設計的合理性、規范性具有重要意義。而當前維修工程信息化平臺主要圍繞綜合保障設計、維修計劃制定等工作，在航空發動機維修工程分析領域的應用較為薄弱［15-17］。

對于航空發動機維修工程分析，發動機制造廠家又面臨以下兩個問題：（1）在民用航空發動機維修工程分析領域，維修工程專業多以MTTR、MTBR等維修性指標為依據開展發動機的維修性設計和分配工作［18-19］，這些工作相對側重產品的設計指標，無法直接滿足航空器制造廠家的維修工程分析要求，也難以指導航空公司制定具體的維修方案和維修任務。因此，發動機制造廠家必須先建立符合維修工程分析的技術方案，再將其應用到平臺上。（2）在平臺應用方面，OmegaPS等雖然滿足了航空器維修工程分析的基本要求，但對于航空發動機維修工程分析，又有兩點不足：①缺乏對S系列規范的有效融合，難以滿足技術出版物等專業的需求，在服役數據的收集和優化管理上也存在問題；②對于航空發動機維修工程分析，在技術參數方面缺乏針對性，需要做二次開發和梳理工作。

為了確保航空發動機維修工程分析工作及其數據的完整性和可持續發展，本文以S3000L、S4000P等規范為基礎開展民用航空發動機維修工程分析平臺的設計和開發工作，并以發動機燃控系統為例來驗證平臺的可操作性；通過維修工程分析平臺的研制和驗證，完善航空發動機維修工程分析工作的技術要求。

1 基于標準的分析平臺設計

1.1 平臺開發需求分析

維修工程分析是維修支援體系的基礎和核心，是對發動機產品維修要求進行約束、確定維修對象、維修程序、維修資源、維修費用的基礎，為維修培訓、航材管理、技術出版物、工具設備提供基礎輸入。其目的是通過產品研制數據，解決維修什么、怎么維修、何時維修、在哪維修、怎么維修經濟等重要問題。維修工程分析平臺作為維修工程分析的載體，其開發需求應結合發動機使用和維修分析工作中的各項內容進行具體分析。

平臺開發需求分析工作的開展，首先以S3000L［20］、S4000P［21］規范為基礎，結合航空發動機維修工程展開深入研究，維修工程分析涵蓋如下內容：

（1）維修工程分析活動選擇：依據維修工程分析總體要求進行維修工程分析活動選擇，滿足發動機產品維修類客戶服務產品開發需要；

（2）頂層工作流程開發、確定分析方式：明確各項工作內容，并進行流程控制；

（3）維修工程分析活動基本流程定義：針對每項分析活動定義基本的分析流程；

（4）內外部接口/輸入輸出關系定義：給出維修工程分析內部接口關系，給出維修工程與航材管理、技術出版物、維修培訓等維修類客戶服務產品研發間的接口關系；

（5）維修工程分析源數據清單梳理：針對各項維修工程分析活動，給出源數據清單；

（6）MEA候選項清單編制方法：針對各項維修工程分析活動給出候選項編制方法；

（7）MEA頂層架構適用性評估：針對發動機產品設計屬性及維修類客戶服務產品需求，進行適用性評估。

同時，參考國內外已有航空維修工程實踐經驗，以及國內民航產品研制項目經驗，結合國內航空產品設計理念及變化趨勢，研究規范在民用航空發動機維修工程分析上的具體應用，并適當剪裁。平臺的主要功能需求包括但不限于：

（1）候選項定義和分析；

（2）產品綜合保障分析——故障模式影響分析；

（3）排故需求分析；

（4）使用相關分析。

此外，還結合維修工程分析的工作內容，開展計劃維修任務模塊的需求分析。各模塊的初步需求以及功能目標如表1所示。

表1 發動機維修工程分析平臺需求Table 1 Platform requirements about engine maintenance engineering analysis

1.2 平臺功能設計

前期需求分析工作主要基于S3000L、S4000P、ATA 2200等規范開展，并結合維修工程分析總體要求和工程人員的實際使用需求開展平臺設計。維修工程分析平臺的功能模塊和核心功能架構如圖1所示。

圖1 模塊化設計Fig.1 Interface of module

各模塊的功能如下：

（1）候選項選擇模塊：主要實現對發動機系統候選項與系統標準規范間的關聯與確認、候選項分析、變更等具體功能。

（2）計 劃 維 修 分 析（Schedule Maintenance Analysis，簡稱SMA）模塊：主要實現維修重要項目、結構重要項目、區域重要項目的分析工作，包括項目選擇、確認、分析、匯總以及報告編制等功能。

（3）綜合保障分析故障模式影響分析（Logis‐tic Support Analysis Failure Mode and Effect Anal‐ysis，簡稱LSA FMEA）模塊：主要實現候選項FMEA數據整理、FMES、任務分析和報告編制等功能。

（4）損傷及特殊事件分析（Damage and Spe‐cial Events Analysis，簡稱DSEA）模塊：主要實現特殊事件項目創建、任務分析、任務合并以及報告編制等功能。

（5）后勤相關使用分析（Logistics Related Op‐erations Analysis，簡 稱LROA）模 塊：主 要 實 現LRO任務創建、任務分析和報告編制等功能。

（6）排故分析（Trouble Shooting Analysis，簡稱TSA）模塊：主要實現排故需求創建、任務分析、排故程序制定和排故分析報告編制等功能。

（7）維修任務分析（Maintenance Task Analy‐sis，簡稱MTA）模塊：主要實現維修任務導入、維修任務合并、頻次計算和優化、MTA分析報告編制等功能。

（8）修理級別分析（Level of Repair Analysis，簡稱LORA）模塊：主要實現修理級別創建、修理級別分析和決策、LORA分析報告編制等功能。

（9）直接維修成本（Direct Maintenance Costs，簡稱DMC）模塊：主要實現維修項目目標值分析、預測，子系統成本分析和發動機運營成本分析等功能。

除維修工程分析核心功能外，平臺還包括標準管理、權限管理、基礎數據配置、項目管理、質量控制、源數據管理、文檔管理等功能，實現維修工程分析全過程規范化、過程監控可視化、構型與數據管理集成化，保證了分析數據的完整性、準確性、有效性，最終確保數據存儲、傳輸、使用的安全和準確。

2 基于B/S架構的平臺開發和實現

維修工程分析平臺的開發采用B/S架構。該模式可以實現客戶登錄端口的統一管理，并將平臺功能的實現集中到主服務器中，確保數據的安全。采用B/S架構還具有功能權限開放靈活、維護便捷、擴展兼容性良好的優勢，便于平臺后期的持續優化。

2.1 平臺的技術架構

維修工程分析平臺基于MVC模式將整個系統分為表示層、業務層、基礎架構層和數據庫層，如圖2所示。

圖2 維修工程分析平臺架構Fig.2 Architecture of maintenance engineering analysis platform

各層的實現方式如下：

（1）表示層：采用并列形式展示系統管理、基礎數據管理、維修工程分析等功能模塊，表示層采用形式化表達方式構建交互界面，便于維修工程分析人員準確、簡潔地定位分析工作。表示層還包括系統登錄、任務分派、維修工程會議等工作界面。

（2）業務層：是將各分析模塊具體分析方法和算法模型封裝到具體模塊中，結合工作流程和數據驅動，業務層還包括各類分析報告的生成。業務層主要包括產品分解、分析工具模塊兩類業務。產品分解基于產品型號、構型、區域和功能等對發動機產品進行候選項分解。分析工具模塊則包括具體的各維修工程分析模塊。

（3）基礎框架層，平臺的中間層：通過軟件工程產品分解模型組件和各類分析數據報表等將維修工程人員填寫的信息存儲到數據層的表單中。基礎框架層實現了工作流引擎、日志組件等基礎功能。

（4）數據庫層：采用關系型數據庫和開源大數據構成，用于存儲平臺中產生的發動機維修工程分析數據，包含發動機型號信息、構型信息、維修需求信息、工程數據等。數據層還可以通過符合S3000L數據庫協議的各類報表模板、過濾器加工、存儲、輸出標準化、規格化的維修工程分析數據。

2.2 平臺的實現

平臺采用B/S架構中較為先進的SPA架構開發，其前后端互相分離。前端使用HTML 5、JavaS‐cript、AngularJS、Bootstrap技術實現功能，使用瀏覽器作為容器及運行環境；后端采用符合REST規范的WebAPI提供微服務，以HTTP協議和JSON格式的數據與前端進行交互。底層數據庫可支持關系型數據Oracle、My SQL、SQLServer和大數據平臺Hadoop，也可支持關系型數據庫+大數據的復合架構。

平臺采用JAVA語言開發，技術路線的設計思想按照MVC設計模式，分為三層架構，應用web服務層，提供頁面與用戶進行人機交互，javaee層提供后臺邏輯，為前臺頁面提供數據支撐。數據層采用關系型數據庫，對結構化數據進行表存儲。

基于SPA架構下開發的應用，具有界面響應快、界面美觀、功能易于擴展、支持移動終端等特點。開發完成的平臺可在不同網絡狀態的設備上進行操作和數據處理，滿足了多用戶、多終端的維修工程分析工作需求。通過平臺實施，為維修工程分析人員提供高效率的維修工程分析過程。維修工程分析平臺典型工作界面如圖3所示。

圖3 維修工程分析平臺典型工作界面Fig.3 Interface of platform about engine maintenanceengineering analysis

3 平臺測試和樣例驗證

3.1 測試過程

平臺的功能測試主要包括三大步驟：（1）項目管理測試，（2）候選項管理模塊測試，（3）分析模塊測試（以LSA FMEA模塊為例）。

用戶登錄平臺后，首先進入項目管理界面（如圖4所示），在項目管理中實現如下功能：

圖4 項目管理界面Fig.4 Interface of program management

（1）分析計劃管理、會議計劃管理等功能，全面實現基于分析程序的任務動態分配與提醒、計劃動態定義、任務完成情況監控、行動項定義與監控等。

（2）各子功能間應建立強關聯關系，實現數據集成管理。

（3）項目監控功能與候選項管理、會議管理、構型管理等功能強關聯，能夠有效控制源數據、會議、候選項等觸發的計劃變更。

（4）具有高級篩選功能，具備不同維度、不同利益相關方及其不同層級的報表輸出功能。

（5）應配置適用的維修工程分析工作程序、分析指南等，其中計劃維修需求開發工作流程應基于型號政策與程序手冊等定義。

（6）實現基于流程的角色、權限定義與變更，實現不同利益相關方及其不同層級的工作任務指派與變更。

項目創建成功后，導入對應的發動機產品數據以便進行候選項選擇。候選項管理模塊與項目監控模塊、維修工程分析各模塊等強關聯。候選項分析的功能包括：①實現候選項選擇與分類邏輯、分析活動選擇邏輯的配置及變更；②實現SNS的批量導入，并提供SNS手動修改功能；③實現SNS的候選項選擇與分類，選擇與分類過程符合質量管理要求；④實現候選項選擇的分析活動選擇，分析活動選擇過程符合質量管理要求；⑤實現候選項變更管理，變更管理符合構型管理要求。

候選項選擇完成后，用戶可進入正式的維修工程分析過程，LSA FMEA分析界面如圖5所示。

圖5 LSA FMEA分析界面Fig.5 Interface of module for LSA FMEA

（1）實現基于SNS的LSA系統樹構建與手動修改；

（2）實現系統描述內容的編制，包括文字與插圖；

（3）實現工程FMEA/FMECA的批量導入與手動修改；

（4）配置綜合保障分析故障模式（Logistic Support Analysis Failure Mode，簡稱LSA FM）定義邏輯，自動生成LSA FM編號，LSA FM與FMEA FM自動關聯；

（5）實現LSA FM頻率的自動計算；

（6）實現FM探測能力等級及虛警率等級定義，支持地面支援設備（Ground Support Equip‐ment，簡稱GSE）需求識別、測試性設計反饋等。

3.2 基于燃油分配子系統的樣例驗證

以發動機燃油分配子系統（73-11）為對象在維修工程分析平臺（原型系統）開展工程分析測試。發動機燃油分配子系統包含五個部件，如圖6所示，分別為燃油泵、燃油過濾模塊、噴油嘴、燃油供給總管和燃油供給管路。

圖6 樣例：燃油控制系統Fig.6 The sample about fuel control system

通過將對應的部件設為候選項，分別開展LSA FMEA分析、MTA分析等工作。

首先，登錄并創建型號項目，然后導入對應的發動機產品型號數據。基于產品結構分解得到可用于維修任務分析的候選項。

第二步，選擇對應的候選項，候選項包括燃油泵、燃油過濾模塊、噴油嘴、燃油供給總管和燃油供給管路，對候選項進行初步分析。

第三步，對燃油分配子系統開展FMEA分析，具體包括：LSA系統樹構建、故障模式分組、故障模式探測方法分析、故障模式定位方法分析、報表生成。

第四步，將FMEA分析數據導出到MTA，開展MTA分析，將維修任務分解為作業步驟進行詳細分析，用以確定各項產品支援工作所需的資源要求，包括維修任務的確認、任務編排、工序、工作頻度、建議工時，以及各項工作所需的維修資源（如備件、保障設備、技術手冊、維修人員數量及技術等級）。

第五步，維修任務匯總，針對燃油分配子系統不同故障原因導致的相同維修任務進行匯總。最終得到燃油分配系統的維修任務匯總清單，如表2所示。

表2 維修任務匯總Table 2 Summary of maintenance task

4 結 論

（1）航空發動機維修工程分析平臺設計以使用需求和S3000L等規范為基礎，該平臺的研制表明航空發動機客戶服務維修產品開發技術有了重大提升，為發動機產品全壽命周期的綜合保障數據收集、優化等工作奠定了良好的信息化基礎。

（2）維修工程分析平臺的設計工作重點在于在數據設計上應符合標準中對各元素的定義。在此基礎上，業務方面也需要結合不同類型的航空發動機維修工程的分析需求進行細化和定制。

（3）在S系列規范/標準融合的背景下，維修工程分析的工作成果將作為技術出版物、航材管理等工作的重要輸入。平臺未來的開發和優化應綜合考慮不同業務領域所用標準的數據交換需求，確保維修工程分析的成果轉化更加高效、準確。