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

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

0 引言

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

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

1 平臺技術(shù)架構(gòu)設(shè)計

根據(jù)項目情況，平臺設(shè)計采用通用的分層架構(gòu)，具體技術(shù)架構(gòu)如圖1。

圖1 平臺基本架構(gòu)

1.1 表示層

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

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

1.2 業(yè)務層

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

圖2 業(yè)務層模塊結(jié)構(gòu)圖

1.3 數(shù)據(jù)訪問層

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

圖3 數(shù)據(jù)訪問層模塊結(jié)構(gòu)圖

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

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

1.4 數(shù)據(jù)實體對象

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

1.5 數(shù)據(jù)層

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

1.6 公共部件

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

2 系統(tǒng)主要功能設(shè)計

2.1 維護規(guī)范

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

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

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

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

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

2.2 維護計劃

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

2.3 維護預警

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

2.4 故障記錄

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

2.5 維修申請審批

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

2.6 驗收結(jié)算

驗收結(jié)算主要實現(xiàn)維修維護的驗收，耗費材料和經(jīng)費的統(tǒng)計，以及對維修維護效果的評價。

3 接口設(shè)計

3.1 軟件內(nèi)部接口

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

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

3.2 軟件外部接口

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

風洞試驗運行接口包括試驗設(shè)備的狀態(tài)，包括：中壓氣源實時信息、高壓氣源實時信息、試驗時間、試驗次數(shù)、試驗持續(xù)時間等。其中獲取的風洞運行次數(shù)可以驅(qū)動維護保養(yǎng)流程。

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

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

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

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

4 運行界面

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

圖4 平臺運行主界面

圖5 平臺操作界面

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

5 平臺開發(fā)

維修維護自動化平臺使用SQL Server 2008數(shù)據(jù)庫，開發(fā)環(huán)境采用Visual Studio2012，開發(fā)語言采用C#。數(shù)據(jù)庫與系統(tǒng)部署于統(tǒng)一的服務器上，采用B/S架構(gòu)，各個用戶均可使用瀏覽器通過內(nèi)部網(wǎng)絡(luò)進行訪問和操作[11-12]。其業(yè)務申請流程設(shè)計如圖6所示，數(shù)據(jù)庫設(shè)計如圖7所示。

圖6 業(yè)務申請流程圖

圖7 數(shù)據(jù)庫設(shè)計圖

6 結(jié)果與分析

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

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

表1 系統(tǒng)性能指標情況

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

圖8 設(shè)備維修記錄

平臺運行以來，處理維修申請381條，通過外修并完成驗收185條，自修并記錄116條。設(shè)備故障自診斷接口傳送的裝備故障信息[13]，將風洞維修由人工事后填報轉(zhuǎn)變?yōu)樽詣犹崆鞍l(fā)現(xiàn)，大大提升了智能化水平。同時，維修自動化平臺將設(shè)備故障自診斷接口傳輸?shù)墓收献詣由删S修申請，主動發(fā)起維修審批流程，實現(xiàn)故障診斷、故障記錄、維修審批的一體化，提高了大型跨超聲速風洞維修維護的自動化水平。

7 結(jié)束語

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