基于B/S 的民用飛機結構修理方案平臺的設計與實現

馮蘊雯，嚴浩，路成，薛小鋒，徐志斌

（西北工業大學航空學院，西安710072）

0 引 言

飛機的結構修理是民用飛機日常維護工作的重要組成部分。在實際修理中，有時會遇到超出手冊范圍的修理情況。隨著航空營運人員機隊規模擴大以及老齡飛機數量的增加，民用飛機結構超手冊修理的情況也將不斷增加。以深圳航空為例，2013 年的超手冊修理為 20 項，2014 年為 38 項，2015 年 達 到 了 52 項 ，到 2018 年 平 均 每 2 天 就 要 實施一項超手冊修理。超手冊修理通常包括兩種情況：一種是手冊上對某一種結構損傷的修理方法沒有具體明確的說明；另一種是由于采用原生產工藝進行修理的成本較高，航空營運人在維修時不能按照原有工藝進行修理而需要采用替代方案。

航空營運人員發現結構損傷超出手冊范圍后，通?？梢酝ㄟ^以下途徑獲得修理方案：（1）自行制定維修方案報原始設備制造廠獲得批準；（2）將損傷詳細信息報原始設備制造廠獲得維修方案和批準。與自行制定維修方案相比，從設備制造廠獲得維修方案再實施修理工作會使得修理周期更長。

對飛機的重量、平衡、結構強度、性能、動力裝置工作、飛行特性沒有顯著影響的修理被認為是非重要修理。超手冊修理中也存在一部分情況是非重要修理。對于此類修理，由維修工程部門自行制定修理方案，并實施修理工作，既可以有效降低維修成本，又有利于縮短維修周期，使飛機能夠更快地恢復運營。但如果修理方案制定得不合理，將導致不當維修的情況發生。不當維修是導致飛行事故的主要或促成因素之一，而有合理計劃的維修是成功維修的關鍵。因此，在制定修理方案時，參考類似的成功修理方案，有助于維修工程人員更快制定出合理的維修方案。

孫建廈結合一線工程維修情況，詳細介紹了民用飛機結構超手冊修理的流程，針對超手冊修理存在時間跨度較長，容易受到人為因素干擾，信息重復填寫等問題，提出了建立相應信息化系統的需求和相關設想；余賓針對一線維修工程部門的需求，開發了飛機維修與工時管理系統，實現了人力資源管理、工時管理、維修經歷管理等功能；蔡鵬針對航空工業長飛公司維修工作的特點與現狀設計了飛機維修管理系統，提高了資源分配效率、壓縮了維修周期；閆偉在詳細分析了飛機維修技術狀態管理系統的業務和功能需求的基礎上，開發了飛機維修技術狀態管理系統；針對目前飛機維修管理的工作現狀，劉樹乾設計了基于B/S 的飛機維修管理系統，實現對飛機故障的記錄、維修和相關文件的管理，使飛機維修工作的效率和成本得到了改善。為了實現全球機隊有效管理和提供優質的后勤保障業務，波音公司開發了用以支持全球機隊安全運營的綜合管理平臺，并集成在其門戶網站上，該綜合管理平臺功能已趨于完善，主要包括：用以數據采集的模塊、用以可靠性管理的模塊、用以維修任務優化的模塊等；空客公司為了加強民用飛機全壽命周期管理和完善民用飛機管理體系，建立了全壽命周期管理平臺，將其嵌入空客公司門戶網站上，為航空企業用戶提供全方位的技術支持。

綜上所述，國外波音和空客公司在使用平臺技術支持民用飛機運營維護工作上，處于較為先進的地位。目前國內在使用信息化平臺技術支持飛機維修工作方面取得了很好的發展，其主要工作集中于記錄維修數據、分配維修任務、管理維修文件、簡化線下的工作流程等方面，但不能針對損傷信息直接為用戶提供修理方案，尤其是尚缺乏為超手冊結構修理工作提供可供參考的修理方案的功能。

本文通過對民用飛機結構修理工作的需求分析，設計基于B/S 的民用飛機結構修理方案平臺，通過實際演示操作，對平臺的主要功能模塊進行測試。

1 需求分析

1.1 業務流程分析

民用飛機的每一次修理工作，都必須滿足局方對適航性的相關要求。對于超手冊修理工作，如果不進行嚴格的管理和有效的控制，會降低航空器的可靠性，甚至影響飛行安全。因此，對于飛機結構的非重要修理，航空公司的維修工程部門在制定并實施修理方案的過程中，參考一些類似損傷的成功修理方案，將有利于保障修理方案滿足適航性要求。

修理方案平臺的核心任務是：在日常的修理工作中，將一些典型的損傷信息和修理方案內容存入數據庫，以便在需要形成新的修理方案時可以進行調用及數據交互；通過當前的損傷信息、電子化的修理方案等內容，給當前損傷推薦若干修理方案作為參考，且每一次的成功修理方案將為新的結構修理方案制定提供數據化支持。

結合平臺的使用確定修理方案的流程，如圖1所示。

圖1 使用平臺形成修理方案的流程圖Fig.1 Flow chart of using the platform to form the repair plan

（1）損傷信息的輸入：由用戶根據實際損傷情況輸入損傷信息，包含機型、結構部位、損傷尺寸、損傷類型等參數。

（2）審核損傷信息：由用戶對輸入的損傷信息內容進行審核，檢查輸入的損傷信息內容是否符合規范。滿足要求的損傷信息標記為“審核通過”，進入下一步流程。

（3）系統推薦參考修理方案：對于通過審核的損傷信息，程序會根據預先編寫的關聯條件推薦相應的若干條歷史修理方案。用戶可以對這些修理方案進行查看和選擇。

（4）形成初步修理方案：用戶對系統自動推薦的修理方案進行查看和選擇后，可選擇推薦的修理方案內容作為參考，然后結合修理準則、修理經驗和實際損傷情況形成初步修理方案。

（5）審核并確定修理方案：對形成的初步修理方案，再由用戶判斷其可行性。如果方案可行，則可以確定修理方案；如果不可行，則需要進一步考慮修理準則、修理經驗、實際損傷來重新確定修理方案。

1.2 功能需求分析

根據修理方案形成的流程，對平臺的具體功能進行分析。平臺應具備下述七種功能。

（1）信息輸入與管理

錄入結構修理數據庫中的信息包含損傷信息內容和修理方案內容。對輸入的信息，能夠對其進行刪除和修改等操作。

（2）數據檢索查看功能

在不同模塊頁面中能夠支持用戶輸入不同的條件進行單條件獨立查詢或多條件的關聯查詢功能，并能根據查詢條件顯示查詢的結果給用戶進行查看。

（3）數據輸出功能

可對查詢到的數據信息按照給定的格式進行編排，并能進行下載、打印、儲存等形式的輸出。

（4）管理技術文件

支持用戶上傳、下載、更新修理適航要求文件及標準規范文件等技術文件。

（5）修理數據的統計與分析

提供直觀的統計圖表顯示界面，對機型、部件等內容的維修數據進行統計。

（6）修理方案的推薦功能

結合損傷信息的內容，按照一定的關聯條件推薦相近的修理案例。

（7）用戶權限管理

平臺劃分出三種用戶角色：普通用戶、管理員、系統管理員。不同角色登錄后對應不同的功能頁面。

2 平臺設計

2.1 平臺的實現技術

選擇Java 語言作為該平臺后端程序的開發語言，以MySQL 數據庫作為后臺數據庫，前端和后端的開發主要在使用框架技術的基礎上進行。

后端的開發基于SpringBoot 框架。同時，整合Mybatis 框架作為數據的持久層。使用Spring-Security 作為安全框架，能有效防止“注入攻擊”“飽和攻擊”，保證系統具有較好的安全性，同時滿足用戶角色分配和權限劃分的業務需求。

前端的開發以Vue 框架為基礎，使用Vue 官方推薦的Axios 異步交互技術實現前后端數據交互，用來發送請求、接收數據。

2.2 平臺架構設計

平臺的開發總體上使用B/S 架構實現。這種模式能夠實現客戶端的統一，使得平臺功能的實現集中到服務器中，實現平臺開發、使用、維護的簡化，具有分布性強、維護方便、可擴展性好、開發簡單、共享性強的優勢。用戶在使用平臺時，只需要通過客戶端瀏覽器就可以訪問服務器端，客戶端基本不需要進行維護。

平臺中采用的B/S 架構形式為客戶端—服務器—數據庫，如圖2 所示。

圖2 B/S 架構使用的形式Fig.2 The form of B/S architecture

平臺設計思路有以下三點。

（1）可擴展性和獨立性

為方便平臺的開發以及后期可能的功能擴展，平臺中各功能模塊既保持一定的功能獨立性，又具有一定的數據關聯性。平臺中各模塊之間的功能是相對獨立的，它們之間通過數據內容來實現邏輯上的聯系，一個模塊程序出現異常不會影響其他模塊。

（2）安全性

系統需要具有較好的安全性，能夠有效防止注入攻擊、飽和攻擊等。用戶注冊時設置的密碼要經過加密，然后再存儲到數據庫中，即便是開發人員也不能直接獲取用戶的密碼內容。

（3）部署和使用方便

平臺開發完成后，通過Maven 工具打包，生成的.jar 文件可以快速部署到Windows 系統的服務器上，也可以部署到其他系統服務器，如Unix、Linux 系統的服務器，具有適用于多種服務器類型的特性。同時，用戶通過客戶端瀏覽器就可以直接使用平臺。

通過上述分析，對平臺系統架構進行整理，平臺系統架構如圖3 所示?；跇I務邏輯，平臺架構主要分為三層：表現層、邏輯層、數據層。表現層是客戶端展現給用戶的界面，主要完成用戶和后端程序的數據交互；邏輯層主要是處理前端發送的請求，然后按照業務邏輯對數據進行處理；數據層則負責操作數據庫，寫入和傳出數據。三層架構體現了“高內聚，低耦合”的開發設計思想。

圖3 平臺系統架構Fig.3 Platform system architecture

2.3 數據庫設計

2.3.1 權限劃分的庫表設計

數據模型是對系統實體類關系的映射。平臺中與權限劃分相關的實體有：用戶、用戶的角色、不同角色各自可以訪問的菜單頁面。需要通過五張表完整描述這三個實體之間的關系：用戶信息表、角色表、用戶角色關聯表、菜單表、菜單角色關聯表。表的關系模型如圖4 所示。五張表分別存儲用戶信息、角色信息、不同用戶和角色之間相關聯的外鍵信息、菜單信息以及不同菜單和角色之間相關聯的外鍵信息。

圖4 數據庫權限框架相關表的關系模型圖Fig.4 Relational model diagram of related tables in database authority framework

用戶通過前端頁面進行登錄時，向后端發送攜帶用戶名和密碼的請求，后端安全框架Spring-Security 根據前端傳入的數據查詢到用戶信息，并通過外鍵關系繼續得到用戶角色信息，以及角色對應的菜單信息。SpringSecurity 框架會對該用戶可以使用的后端接口進行授權，這就為不同的角色分配了不同的接口。同時，后端將用戶信息及其對應的菜單頁面信息返回前端，前端程序根據接收到的返回內容加載相應的Vue 組件即可實現不同菜單和頁面內容的展示。

2.3.2 修理方案推薦功能的庫表設計

不同材料結構的失效模式常常是不同的。例如飛機復合材料層合板和蜂窩加芯結構產生的損傷最主要是沖擊損傷，碳纖維蜂窩夾層結構損傷多表現為碳纖維織物與蜂窩芯的脫膠離層。不同的材料和結構損傷通常有其相對應的典型修理方案，材料與修理方案的設計和工藝是緊密聯系的。

因此，根據損傷信息和修理方案的內容，分別建立與之對應的數據庫表。損傷信息內容主要包括：飛機型號、飛機注冊號、飛機序號、ATA 章節號、飛行循環/小時、修理日期、損傷部件、結構分類、損傷成因、損傷類型、材料牌號、損傷尺寸、損傷發現方法、損傷等級以及結構描述、損傷描述、允許損傷尺寸的圖文信息。修理方案內容主要包括：修理方法、修理類型、損傷去除方法、損傷去除部分的尺寸、補片尺寸、緊固件參數、膠層參數、特殊工藝、表面防護以及完成修理后的檢查要求、修理圖紙等。針對損傷信息和修理方案的內容特點，考慮將損傷信息中的材料信息與修理方案中修理方法相聯系，建立損傷信息和修理方案關聯表，對應關系由實際工程案例得到，如表1 所示。

表1 損傷信息和修理方案關聯表Table 1 Damage information and repair plan association table

修理方案表、損傷信息表以及它們之間的關聯表的ER 關系圖如圖5 所示。材料牌號與損傷信息表中內容相聯系，修理方法和修理方案表中內容相聯系，就可以建立數據庫中損傷信息與修理方案之間的聯系。用戶選中一條損傷時，通過編寫三個表關聯的查詢語句，將材料信息作為條件傳入，查詢得到相應的修理方案，將其返回到前端頁面，就實現了根據損傷信息自動推薦修理方案的功能。在查詢語句中使用條件模糊匹配，可以擴大修理方案推薦的范圍。

圖5 修理方案和損傷信息ER 關系圖Fig.5 ER diagram of repair plan and damage information

2.4 功能模塊設計

根據業務流程和功能需求的分析，將平臺劃分為五個模塊：用戶管理模塊、修理數據建模模塊、修理知識文件管理模塊、修理數據管理模塊、修理數據統計分析模塊。平臺功能模塊結構如圖6 所示。

圖6 功能模塊結構圖Fig.6 Functional module structure diagram

系統管理員僅使用用戶管理模塊對管理員用戶和普通用戶進行管理；管理員用戶可使用所有模塊，并在用戶管理模塊中對普通用戶進行管理；普通用戶沒有用戶管理的權限，可使用其他功能模塊。

2.4.1 用戶管理模塊

用戶管理模塊包含三個子模塊，用戶信息、用戶管理、個人中心，用于實現用戶注冊登錄、用戶角色識別、用戶賬戶管理功能。個人中心模塊提供給用戶對個人信息進行編輯和修改。管理員用戶具有用戶信息模塊的使用權限，可以在該模塊中對普通用戶賬戶進行管理，包括編輯普通用戶電話信息、刪除普通用戶賬戶、關閉用戶登錄權限等操作。系統管理員用戶具有用戶管理模塊的使用權限，可以在該模塊中對普通用戶和管理員用戶賬戶進行管理。系統管理員賬戶在開發過程中直接存入數據庫，無法在平臺頁面中刪除其賬戶，因此可有效對其他用戶的賬戶進行管理。

2.4.2 修理數據建模模塊

修理數據建模模塊包含三個子模塊，數據庫信息模塊、損傷信息模塊、輸入審核模塊，數據庫信息模塊的功能是展示存入數據庫中飛機結構修理相關的通用修理原則和方法。用戶可以輸入數據庫序號、修理方法的內容查詢得到所需內容，也可根據需要新增相關內容。損傷信息模塊的功能為錄入損傷信息，需要錄入的信息與損傷信息數據庫表的內容相對應。在損傷信息錄入過程中，由于程序中設置了定時操作函數，頁面會自動定時提交和保存已填寫的損傷信息，以實現損傷信息數據的自動備份。損傷信息填寫完成后，在輸入審核模塊的頁面中會同步已填寫的損傷信息，需要管理員用戶進入輸入審核模塊對損傷信息進行審核。管理員可以先查詢得到所需的損傷信息，然后再進行審核。審核后的損傷信息會被標記為“審核通過”或“審核不通過”。

2.4.3 修理知識文件管理模塊

修理知識文件管理模塊包含一個子模塊：修理文件查看。該模塊用于用戶上傳、更新、下載和刪除修理相關技術文件。

2.4.4 修理數據管理模塊

修理數據管理模塊包含兩個子模塊：選擇修理方案、查看修理方案。在選擇修理方案模塊中，用戶可以查看系統根據損傷信息自動推薦的修理方案內容。同時，還可在查看方案的同時對每個方案進行評分，評分項包括修理效果、可操作性和經濟性三方面，具體有耐久性、氣動外形、功能性要求、修理成本、人員需求、修理時間、可檢性、可操作性、修理效果等內容。完成打分后可以根據分數為修理方案排序，方便用戶進行選擇，然后由用戶自行選擇修理方案，用戶也可以在該頁面中新增修理方案。完成修理方案的選擇后，進入查看修理方案模塊，用戶可以同時對損傷信息和對應選擇的修理方案內容進行查看，并將頁面中的損傷信息和修理方案信息以PDF 格式打印輸出，方便使用。

2.4.5 修理數據統計分析模塊

修理數據統計分析模塊包含一個子模塊：維修數據統計。該模塊用于對不同機型和損傷部件的修理次數進行統計，并將結果以柱狀圖和餅狀圖的形式進行展示。用戶可以對統計圖表進行操作，例如進行圖片的保存、數據導出、數據查看等。

3 測 試

3.1 測試過程

登錄系統后，首先進入修理數據建模模塊，然后選擇數據庫信息子模塊，在查詢功能區輸入相關查詢條件，即可查詢得到數據庫中相關的通用修理方法內容，如圖7 所示。

圖7 數據庫信息模塊查詢功能圖Fig.7 Diagram of query function of database information module

如需新增修理方法，點擊頁面左下方“新增錄入”按鈕，在彈出窗口中填寫新增的修理方法內容，填寫完成后點擊提交即可，如圖8 所示。

圖8 數據庫信息模塊新增錄入功能圖Fig. 8 Diagram of new input function of database information module

切換菜單頁面，進入損傷信息填寫頁面，如圖9 所示。用戶在頁面上方填寫基本損傷信息，包括：方案名稱、編號、飛行型號、飛機注冊號等相關內容。點擊右上方“基本信息錄入”按鈕，隨后頁面會顯示該條基本損傷信息。選中頁面列表中該條損傷信息，點擊右側操作欄中“填寫損傷信息”按鈕，頁面打開完整損傷信息填寫頁面，如圖10 所示。填寫損傷信息描述、可允許損傷尺寸等內容，并上傳損傷相關圖片后，完成損傷信息的填寫。

圖9 損傷信息模塊頁面圖Fig.9 Diagram of damage information module

圖10 損傷信息錄入功能圖Fig.10 Diagram of damage information entry function

切換菜單欄，進入輸入審核頁面，用戶可在該頁面中對上一步填寫的損傷信息進行查看和審核。審核結論通過后，方可進入下一步選擇和查看推薦修理方案的操作。在該頁面中，用戶也可在查詢功能區中輸入相關條件對損傷信息進行篩選，如圖11 所示。

圖11 輸入審核頁面查詢功能圖Fig.11 Diagram of Input review page query function

切換菜單欄，選擇修理數據管理模塊，進入選擇修理方案頁面，該頁面列表中會顯示通過審核的損傷信息。用戶選中一條損傷信息后，點擊右側操作欄中的“選擇修理方案”按鈕，頁面會彈出根據損傷信息推薦的相關修理方案，如圖12 所示。點擊修理方案信息右側“查看”按鈕，用戶可對修理方案詳細內容進行查看，并根據修理效果、可操作性、經濟性等內容對該條修理方案進行打分，如圖13 所示。用戶可以根據打分結果選擇一條修理方案。

圖12 推薦及選擇修理方案功能圖Fig.12 Diagram of Recommending and selecting repair plan

圖13 修理方案打分功能圖Fig.13 Diagram of grading repair plan

切換菜單欄，進入查看修理方案模塊，如圖14所示。選擇一條損傷信息，點擊右側操作欄中“查看修理方案”按鈕，頁面彈窗打開損傷信息和對應選擇的修理方案內容，如圖15 所示。在彈出頁面的底部，點擊“PDF 打印”，即可將損傷信息和修理方案內容輸出到本地計算機中，為用戶指定修理方案提供支持。

圖14 查看修理方案頁面圖Fig.14 Page of checking repair plan

圖15 查看修理方案功能圖Fig.15 Diagram of checking repair plan

3.2 測試結果

根據3.1 節中對各功能模塊的測試操作可知，平臺各模塊功能正常、可操作。平臺的人機界面友好，擴展性良好，操作簡單方便，并能夠根據損傷信息自動推薦出數據庫中存儲的若干修理方案，實現了根據損傷信息自動推薦修理方案的核心功能，達到預期目標。

4 結 論

（1）本文基于B/S 架構的民用飛機結構修理方案平臺，實現了民用飛機結構損傷信息的和修理方案的電子化，可以根據損傷信息中的材料牌號信息自行為用戶推薦相關的成功修理方案作為參考，對維修工程單位制定超手冊修理方案提供有效支持。

（2）平臺在開發過程中，主要以模塊化的形式來實現各項功能，每個功能模塊之間只通過數據關聯，而代碼是相對獨立的，增加了平臺的容錯性和健壯性，也便于后期擴展其他功能。

（3）在將來的使用中，可以根據工程實際需要擴展功能模塊、優化數據庫結構和內容，優化修理方案的推薦算法，更好地為修理方案的制定提供支持。