大型跨超聲速風洞維修維護自動化平臺的設計與應用

(1.中國空氣動力研究與發展中心高速所，四川 綿陽 621000; 2.北京航天測控技術有限公司，北京 100041)

0 引言

大型跨超聲速風洞是航空航天飛行器在定型和發展階段進行氣動試驗的重要設備。隨著空氣動力學技術的不斷發展和飛行器研制水平的提升，大型跨超聲速風洞試驗模擬能力日益精細，試驗設備向著更復雜、更智能、更集成的方向發展，相應的維護保養要求不斷提高，維修專業化程度不斷加深，原有維修維護管理水平急需提高[1-3]。同時，隨著國家對航空航天領域的大力投入，風洞試驗種類、試驗頻次均有大幅度提升，如某型跨超聲速風洞全年試驗車次就超過設計車次的3倍。大型跨超聲速風洞長周期滿負荷高強度運行成為常態，對設備安全穩定持續運行的要求越來越迫切，維修維護工作量急劇增加，維修維護的技術水平要求越來越高，維修響應時間要求越來越短，同時，維修人員還在不斷縮減。傳統依靠人工發現，人工申請和審批的維護維修管理模式和方式難以適應現實需要[4-6]。

為了提高大型跨超聲速風洞維修維護的自動化水平，減少人力資源投入，精準開展維修維護工作，加強管理效果，開發了一種基于B/S構架的維修維護平臺。該平臺立足高速所已有的辦公綜合管理系統，以現有人員和組織機構為基礎，利用設備臺賬數據庫，將參與風洞試驗保障的設備進行統一管理，梳理維修維護過流程，優化管理流程，利用自動化平臺的特點和優勢，更好地為風洞試驗提供有效保障。

1 平臺技術架構設計

根據項目情況，平臺設計采用通用的分層架構，具體技術架構如圖1。

圖1 平臺基本架構

1.1 表示層

UI是客戶端的用戶界面，負責從用戶方接收命令、請求和數據，將其傳遞給業務層進行處理，然后將結果以直觀的形式呈現給用戶。表示層中為了使用修改和保證頁面的一致性，結合MasterPage和WebUserControl使用。MasterPage的使用原則為：一般情況下，所有頁面繼承于主要的MasterPage，各個模塊中，如變化較大則使用子模塊的MasterPage，如只為局部變化，如子模塊菜單變化則使用WebUserControl來實現。

WebUserControl使用原則為：在兩個以上的地方使用的部分，采用WebUserControl。如子模塊菜單、常用查看視圖等。

1.2 業務層

業務層封裝了實際業務邏輯，包含數據驗證、事物處理、權限處理等具體業務實現的相關操作，是整個應用系統的核心。在業務層中，不能直接訪問數據庫，而必須通過數據訪問層。對數據訪問業務的調用，通過接口模塊IDAL來完成，與具體的數據訪問邏輯無關，層與層之間的關系就是松散耦合。如果需要修改數據訪問層的具體實現，只要不涉及到IDAL的接口定義，那么業務層就不會受到任何影響。業務層模塊結構如圖2所示。

圖2 業務層模塊結構圖

1.3 數據訪問層

數據訪問層是一個針對具體應用系統的專屬層，它為業務層提供與數據源交互的最小操作方式，僅僅是業務層需要的數據訪問接口，業務層完全依賴數據訪問層所提供的服務。這些服務負責從業務層接收數據或返回業務實體，它屏蔽了實際業務數據與機器存儲方式的差別。

圖3 數據訪問層模塊結構圖

在數據訪問層(DAL)中，采用DAL 拉口抽象出數據訪問邏輯，并以DAL 工廠作為數據訪問層對象的工廠模塊，而Model模塊則包含了數據實體對象。數據訪問層的模塊結構如圖3所示。

IBaseDAL是定義的數據訪問基類接口，包含各種常用的操作定義；因此BaseDAL就是要對各種操作的進行實現，實現接口越多，將來繼承類的重用程度就越高。通過泛型，可以實現強類型的函數定義。

1.4 數據實體對象

Model是將數據庫中的表直接映射成為業務數據對象，出于復用性，擴展性，性能等方面考慮，選用Model建模。實體層定義一個空的基類，其他實體類繼承之，主要是為了利用泛型操作。

1.5 數據層

數據層就是為數據源提供一個可供外界訪問的接口，我們選用一種能夠提供數據源無關的抽象數據訪問接口，并通過在其下掛接各種不同的數據接口來訪問數據源的數據層組件，以便移植到不同的數據源上。

1.6 公共部件

公共部件包括圖片上傳控件、消息對話框、分頁顯示控件、信息檢測等公共模塊。同時每個層根據需要建立工具類Common，用來處理整個系統公共部分。

2 系統主要功能設計

2.1 維護規范

維護規范是各類裝備的維護規則數據表，由裝備使用單位根據裝備特點、出廠說明書、使用經驗等制定。維護規范包含了裝備名稱、維護周期、維護器材、維護方法等全部內容，主要分為日常保養、一級保養、二級保養三類[7]。

日常保養由操作者進行的日常維護保養工作，包括擦拭設備、注油保養、潤滑清潔、緊固松動部位、消除細小故障等。一般周期為每天或每班次進行。

一級保養以操作工人為主進行，維修人員負責指導，按計劃對設備進行定期或定頻的維護。內容包括局部拆卸、檢查、清潔、調整配合間隙、緊固部位等。一般周期為3～6個月。

二級保養以維修工人為主、操作工人參加的定期或定頻維修，內容包括對設備進行局部解體檢查更換修復少量磨損零件、局部精度恢復，對潤滑系統清洗、換油等。一般周期為6～12個月。

三類保養的活動將記錄到檢查記錄中，該記錄以設備的標識為索引，可在臺帳管理模塊對某些設備的保養信息查詢。具體保養周期可以根據設備情況進行修訂，修訂后在維護規范中進行更新。

2.2 維護計劃

維護計劃是根據維護規范自動生成的，可顯示當天、當月、當季、當年各裝備的各級維護保養計劃，同時可以自動導出不同周期要求的計劃表格。各單位可以實時查看維護計劃的執行和完成情況，上級部門可實時統計整個部門的維護情況。

2.3 維護預警

維護預警是對即將或者已經到期的維護計劃進行提醒和消息推送，例如當二級保養時間還剩15天，二級維護使用頻次低于5%時，由系統將該部分作為預警信息推送到相應負責人或操作者的賬戶中，提醒相關人員及時維護。如果已經過期的維護計劃超過一定比例，還可以設置推送到其主管上級部門。

2.4 故障記錄

故障記錄來源主要有3個方面，一是各裝備自身故障診斷系統判斷出的故障，通過統一的接口連接到平臺上；二是裝備在使用過程中，由于性能、運行、測試等低于預期值，由平臺判斷為最終系統故障的；三是由操作人員發現，通過平臺的手動標記的故障。

2.5 維修申請審批

維修申請審批模塊主要是完成大、中、小、臨時性維修的申請，流程審批等。裝備出現故障時，由對應人員填寫設備維修申請單。維修申請表根據用戶權限和角色自動提供其所在單位內設備清單，當用戶選擇設備后，自動從臺賬導入其他信息。申請人、審批人等能夠實時查看審批流程和走向。申請、審批人權限根據具體規則制定，任何一級審批人未審核通過此次申請流程結束，超級管理員能夠管理人員權限和流程。維修申請時，調入臺帳中的設備維修歷史信息、存在資源等，供決策參考。

2.6 驗收結算

驗收結算主要實現維修維護的驗收，耗費材料和經費的統計，以及對維修維護效果的評價。

3 接口設計

3.1 軟件內部接口

維修維護自動化平臺以設備基本信息為基礎，主要分為維護保養和維修兩大部分。其中維修模塊主要立足設備的名稱、功能、所屬單位、歷史維修信息、價值、廠家等常規信息，調取設備基本信息庫的內容。維護保養立足維護規范模塊構建的基本規則進行數據讀取和生成，同時維護規則也是設備基本信息庫中包含的一個部分。因此與設備相關的所有數據均保存在數據庫中，通過索引方式可查找所有相關信息。

自動化平臺中的各種審批及入庫流程由流程引擎接口實現，該接口能夠滿足新增、刪除及上報審批等過程。

3.2 軟件外部接口

自動化平臺的外部接口包括：風洞試驗運行接口、設備故障自診斷接口、設備狀態接口、辦公綜合管理系統接口[8-10]。

風洞試驗運行接口包括試驗設備的狀態，包括：中壓氣源實時信息、高壓氣源實時信息、試驗時間、試驗次數、試驗持續時間等。其中獲取的風洞運行次數可以驅動維護保養流程。

設備故障自診斷接口包括：智能設備的故障診斷信息，安全系統預定的邏輯推理故障，風洞建立的健康管理系統得到的故障狀態、預測曲線、維修決策建議等。

設備狀態接口是為了對維修維護的過程信息進行自動識別，避免手動操作而設置的一類硬件信息讀取記錄，既可以是設備本身自帶的，也可以是RFID監控信息等。如將部分電器設備的通電運行與日常維護相結合，將部分機械的運轉信息與一級保養相結合，將關鍵部件的拆卸或口蓋開啟信息與二級保養相結合，當對應的事件發生或信號傳遞時，平臺自動記錄相關的操作，并視為相應的維護已經發生，實現智能化。

辦公綜合管理系統提供了人員和組織機構的基礎信息，供自動化平臺直接使用，包括部門信息、用戶信息、角色權限、日志等。實現單點登錄信息接口，輔助完成登錄用戶的認證。

外部接口根據實際需要和系統成熟度開放不同權限，如對用戶和部門信息提供只讀權限，平臺不能修改；對設備的故障診斷信息和健康管理系統開放故障報警、維修建議、故障消除等的讀寫權限，可根據當前維修流程執行結果自動更新系統狀態。

4 運行界面

軟件界面設計總體要求是友好、簡潔、方便。使用人員不需要操作培訓和用戶手冊就能快速上手使用。軟件頁面布置和主要控件外觀形式與原有管理系統和日常辦公軟件風格保持一致。軟件界面具有操作自動提示功能，對重要內容或參數在輸入錯誤時，進行簡潔的提示，方便操作人員及時改正。平臺運行主界面和操作界面分別如圖4和圖5所示。

圖4 平臺運行主界面

圖5 平臺操作界面

在自動生成的維護計劃和故障列表中，具有權限的操作人員可以進行添加、刪除、修改等。在顯示詳細內容時，以列表的形式進行，列表字段可以由系統管理員進行配置。系統管理員可以按照固定格式批量導入或導出數據。所有需要用戶修改定制的內容均提供界面或接口，不允許用戶直接修改或查詢數據庫，容錯機制設置合理，即使由于用戶誤操作也不會造成數據丟失和系統崩潰。

5 平臺開發

維修維護自動化平臺使用SQL Server 2008數據庫，開發環境采用Visual Studio2012，開發語言采用C#。數據庫與系統部署于統一的服務器上，采用B/S架構，各個用戶均可使用瀏覽器通過內部網絡進行訪問和操作[11-12]。其業務申請流程設計如圖6所示，數據庫設計如圖7所示。

圖6 業務申請流程圖

圖7 數據庫設計圖

6 結果與分析

平臺建成后，在部分用戶中進行了前期測試和試運行，測試涵蓋了全部用戶角色，模擬了所有工作流程，并進行了20名用戶的并發處理。經過試運行后，結合反饋意見，對相關流程進行了優化，修改程序Bug共150處。正式上線運行后，具體性能指標見表1，2018年維護計劃及完成情況見表2，設備具體維修記錄見圖8。

通過自動化平臺，建立了346套分系統的三級維護規范，每年生成維護計劃超過6000余次，推送維護預警信息545次，確保了維護的及時性，避免工作疏忽和遺漏。其中，通過設備狀態接口自動識別的維護工作占40%，平臺的自動化功能完善，符合要求，但由于系統設備自身硬件限制，自動化程度還有很大的提升空間。

表1 系統性能指標情況

表2 2018年維護計劃及完成情況

圖8 設備維修記錄

平臺運行以來，處理維修申請381條，通過外修并完成驗收185條，自修并記錄116條。設備故障自診斷接口傳送的裝備故障信息[13]，將風洞維修由人工事后填報轉變為自動提前發現，大大提升了智能化水平。同時，維修自動化平臺將設備故障自診斷接口傳輸的故障自動生成維修申請，主動發起維修審批流程，實現故障診斷、故障記錄、維修審批的一體化，提高了大型跨超聲速風洞維修維護的自動化水平。

7 結束語

大型跨超聲速風洞維修維護自動化平臺立足現有的管理流程和使用模式，借助信息化工具，通過對信息采集、傳輸、交換和分析，以系統消息和可視化界面，實現了維修維護的自動登記、記錄、提醒和統計。利用信息化的手段，使維修維護的檢測手段更加先進，在大型風洞中，實現了根據使用時間和使用頻次相結合進行維護保養的新模式。但是，在維修維護的自動化過程中，部分操作依賴外部接口傳輸的數據，特別是在維修維護過程和維修維護記錄中，部分老舊設備不能提供準確有用的信息，通過配置單獨的信號檢測設備將增加系統成本，而通過人工進行登記又會降低自動化水平，在下一步工作，將探索兩者之間的平衡關系。同時，隨著健康管理、智能故障診斷的系統的不斷發展，如何將平臺信息與這些系統進行有效連接，互為補充、互相促進，也是下一步研究重點。