薛戰東 左澤軒
(上海飛機設計研究院,中國 上海 201210)
隨著民用飛機的復雜性、綜合和集成化的不斷提高,同時伴隨民機市場的競爭越來越激烈,飛機的安全性、測試性、故障診斷、故障隔離、故障預測和維護性等問題越來越受到飛機系統或設備供應商、飛機制造商(OEM)、特別是飛機客戶關注。現代民機上主要采用中央維護系統(簡稱為CMS)來分析、監控、診斷或預測飛機故障,以幫助維護人員工作,保證飛機持續適航性和運行安全,提高飛機的測試性、維護性和經濟性等。通過該功能可以降低對維護專業人員要求、減小/縮短飛機維護時間、提升飛機簽派率,最終降低飛機維護和運行成本以及提高飛機的經濟性,同時通過識別反復出現的故障和趨勢支持提高可靠性,防患于未然。
測試和調整功能(Test And Rigging,簡稱為TAR功能)是集成于CMS的一個必不可少的子功能,通過人機交互的模式實現各個成員系統(將使用TAR功能的飛機非航電機載系統稱為TAR功能成員系統)自身調整、自檢測(BIT)、詳細故障信息查看、清除歷史數據、軟件構型信息與系統狀態信息查看等。TAR功能各成員系統需基于自身系統復雜和重要程度以及自身特點,決定并負責實際實現各自系統的TAR功能。CMS作為該功能的集成者,主要為各系提供通用、統一的交互方式和入口,并顯示測試和調整結果。由于該功能采用交互的方式、各成員系統TAR功能相對獨立且具體負責邏輯實現,通常將與各系統相關的TAR功能稱為各系統TAR功能。
中國民用運輸類飛機起步晚,且發展比較緩慢,國內對于TAR功能的認識、驗證以及對CCAR25部相關適航條款的符合性等需要進一步研究。為此,本文詳細闡述空氣管理管理TAR功能及其一種驗證方法,以為后續其他民用運輸類飛機項目TAR功能設計、驗證和符合性方法提供參考和建議。
飛機空氣管理系統(AMS)由氣源系統、空調系統、壓調系統和機翼防冰系統組成,空氣管理系統控制器(后續簡稱為控制器)為上述四個子系統的綜合集成控制器,負責整個空氣管理系統的控制和監控。
AMS TAR功能一般在飛機處于地面且制冷組件不工作的情況下才可以使用,以保證飛機和系統安全性。該功能相對于其他成員系統的TAR功能相對簡單,不包含Rigging和從LRU的NVM (Non-Volatile Memory)數據下載和清除功能,主要包含兩方面的內容:測試系統參數和IBIT(Initiated Built-in-test)。其中,IBIT包含控制器IBIT以及CPCS/ECS/WAIS/BAS IBIT。測試的系統參數舉例如下:
a)活門命令/位置狀態信息;
b)傳感器數據,若傳感器超出范圍將顯示“--”;
c)開關選擇狀態信息,若開關位置錯誤將顯示“--”;
d)控制器軟件構型以及其內部壓力傳感器溫度;
e)飛機狀態信息,比如飛機型別,控制器識別、軟件運行模式和貨艙加熱器選裝。
一般,AMS控制器與CMS之間按照ARINC 604協議進行通訊傳輸和處理以實現AMS TAR功能,通訊架構見圖2。隨著綜合化、模塊化航電系統的發展,CMS軟件和集成后的TAR功能XML將駐留在航電系統綜合處理機柜(Intermediate Processing Cabinet:IPC)的通用處理模塊中,CMS相關功能信息顯示在多個功能顯示器(Multifunction Display:MFD)上。AMS TAR功能通訊模式有兩種:
a)交互模式:控制器與CMS之間交互響應以執行測試操作和輸出構型信息;
b)自動模式:在控制器通道進入相應的具體測試操作或頁面后,控制器對應通道將自動自動更新MFD顯示的信息。
實現AMS TAR功能主要條件:
a)集成后的AMS XML:可以將其視為支持AMS TAR功能的機載數據庫,主要用于定義和提供TAR功能通訊和顯示的一些信息,比如LRU名稱、設備ID(Equipment ID),頁面名稱、組件名稱(Component Name)和組件類型(Component Type)等;
b)CMS軟件:集成CMS的所有功能,并在MFD上顯示;
c)AMS控制器及其所含軟件:AMS控制器軟件主要負責實現AMS控制和監控,其含具體AMS TAR功能邏輯實現。

圖2 AMS TAR功能通訊架構
通常,用于支持TAR功能的ARINC 604協議以及XML的開發集成工具由CMS供應商或飛機主制造商應提供,這樣可以確保TAR功能各成員系統能夠按照正確統一的要求開發XML和各系統軟件相關TAR功能代碼。AMS供應商基于統一的XML開發工具開發分別適用于AMS控制器各個通道的XML,同時還需按照ARINC 604協議要求開發AMS控制器軟件所含的TAR功能相關軟件代碼。飛機制造商使用XML集成工具將TAR功能成員用戶的XML集成為飛機級TAR功能 (含AMS XML),以用加載到試驗室或飛機上進行TAR功能試驗。各個成員系統的XML和TAR功能相對獨立,互不影響,這保證各成員系統可以獨立進行TAR功能驗證。AMS TAR功能XML開發集成大致步驟如下:

圖3 AMS TAR功能XML開發集成
由于TAR功能需要專門的XML支持以及各成員系統TAR功能的差異性,若要各成員系統供應商對TAR功能XML和整個環節TAR功能進行驗證,則需要AMS供應商具備航電相關試驗平臺軟硬件等,試驗成本和難度很大;反之,若要CMS開發商進行全機TAR功能XML和整個TAR功能環節驗證(含AMS),則CMS供應商需要擁有所有各成員的各相關試驗平臺軟硬件等,試驗成本和難度更大,因此通常該驗證工作由飛機主制造商負責。
由于一般民用運輸類飛機TAR功能為DAL E級,且通常作為民用運輸類飛機機載軟件和數據庫符合性方法的DO-178B對DAL E級機載軟件和數據無要求,因此申請人無需針對XML對DO-178B符合性開展專門驗證工作。依據中國民航要求,運輸類飛機必須滿足CCAR25部要求,申請人為驗證AMS TAR功能滿足設計要求,特別表明符合適航相關條款要求,可采用如下驗證方法或組合。
申請人應在試驗室進行研發試驗,以進行整個AMS TAR功能測試(含AMS控制器軟件邏輯、傳輸以及最終顯示結果),用于驗證TAR功能的正確性和保證飛機安全。AMS TAR功能試驗室試驗方式見圖4。由于試驗室試驗可模擬較全面的輸入,特別是能夠模擬AMS一些非正常構型或狀態,比如開關故障、客艙高度告警、傳感器超出范圍等,這相對于機上試驗容易、成本低、且安全。

圖4 AMS TAR功能試驗室試驗方式
由于試驗室并非飛機真實構型以及試驗條件的部分限制,特別是當運行AMS IBIT測試時,根據AMS TAR功能控制邏輯設計,需要相關系統設備動作(比如活門等),這些需要在飛機上進行相關試驗才能夠真實驗證,因此AMS TAR功能要進行必要的機上研發試驗。機上研發試驗與試驗室試驗應在試驗目的、內容上有所不同并各自有其側重點。
由于國內目前民機取證經驗欠缺,特別是考慮申請人試驗室及人員資質條件,上述3.1和3.2節描述的TAR功能驗證方法僅為申請人自己的研發試驗,因此為滿足條款要求還需進行專門的AMS TAR功能表明符合性MOC5試驗。MOC5試驗前試驗大綱和試驗構型需獲得局方批準,試驗前局方需進行機上制造符合性檢查。試驗后的試驗報告及試驗結果應能表明AMS TAR功能符合設計要求、試驗滿足大綱判據,并最終需獲得局方批準試。
本文概述了民用運輸類飛機空氣管理系統TAR功能、通訊架構、XML開發集成以及驗證方法。對于TAR功能過驗證方法,由于項目及其主制造商和供應商責任分工的差異性,不同的運輸類飛機項目申請人采用的TAR功能驗證方法可能不同。隨著國內對民機研制規律認識的不斷深入以及經驗的不斷積累,若申請人相應的試驗構型和人員資質能夠獲得局方認可,且在申請人與局方就TAR功能符合性驗證方法達成一致前提下,若申請人在進行研發試驗室和機上地面試驗室前相關試驗大綱獲局方批準,則申請人的研發試驗室和機上地面試驗可并行視為局方表明符合性試驗,這樣可以避免重復進行TAR功能表明符合性MOC5試驗,這在一定程度能夠節省項目研發進度和成本。
[1]陳雯.先進的中央維護系統[J].民用飛機設計與研究,2010(1).
[2]趙瑞云.民用飛機機載維護系統的中央維護功能[J].中國民航大學學報,2008,26(5).
[3]趙瑞云.中央維護系統概念及其應用[J].航空電子技術,2008,36(2).