王純委, 郝玉鍇, 楊軍祥, 楊煜坤, 李成文, 楊 濤
(1.中航工業(yè)西安航空計算技術(shù)研究所,西安 710065; 2.西安電子科技大學(xué)通信工程學(xué)院,西安 710065)
航空電子全雙工交換式以太網(wǎng)(Avionics Full Duplex Switched Ethernet,AFDX)是一種全雙工、高數(shù)據(jù)率、雙冗余的網(wǎng)絡(luò),相比于傳統(tǒng)的以傳遞命令和控制信息為主的機(jī)載總線,具有更高的可靠性、抗惡劣環(huán)境適應(yīng)性和確定的實時性,并克服了布線復(fù)雜、重量過重、維護(hù)及改型困難等缺點,成為目前主流航空電子網(wǎng)絡(luò)互連的基礎(chǔ)。AFDX 在組網(wǎng)規(guī)模和靈活性上的優(yōu)勢很大程度上提高了航空計算機(jī)網(wǎng)絡(luò)的通信性能,便于航電系統(tǒng)的擴(kuò)展和維護(hù)[1],是飛機(jī)機(jī)載網(wǎng)絡(luò)的一種較理想選擇。
針對規(guī)模龐大的航電系統(tǒng)網(wǎng)絡(luò),對其有效的管理是航電系統(tǒng)正常工作的基本保證,本文提出了一種適用于大型飛機(jī)的綜合航電系統(tǒng)中央處理機(jī)的雙機(jī)備份余度互聯(lián)的架構(gòu),并對此架構(gòu)下網(wǎng)絡(luò)管理進(jìn)行了需求分析、架構(gòu)設(shè)計和軟件實現(xiàn),完成之后的網(wǎng)絡(luò)管理功能作為重要的信息來源,直接服務(wù)于飛機(jī)的中央維護(hù)系統(tǒng)。
開放式、模塊化、綜合化系統(tǒng)是當(dāng)今航空電子領(lǐng)域的發(fā)展趨勢,在綜合化航電系統(tǒng)架構(gòu)下,常見的機(jī)載網(wǎng)絡(luò)有FC 網(wǎng)絡(luò)和AFDX 網(wǎng)絡(luò)等[2],其中,AFDX 網(wǎng)絡(luò)是一種利用了IEEE802.3 以太網(wǎng)標(biāo)準(zhǔn)以及相關(guān)傳輸協(xié)議的特殊交換式以太網(wǎng),為星型拓?fù)浣Y(jié)構(gòu)。AFDX 網(wǎng)絡(luò)由端系統(tǒng)、交換機(jī)和物理鏈路組成,可以為航空電子系統(tǒng)提供安全、可靠的數(shù)據(jù)傳輸服務(wù)。參照當(dāng)代先進(jìn)民用飛機(jī)綜合航電系統(tǒng)的設(shè)計思路,本文以AFDX 作為系統(tǒng)主干通信網(wǎng)絡(luò),建立了一個級聯(lián)式雙冗余的飛機(jī)航電系統(tǒng)架構(gòu)模型,包括兩個互為余度的中央處理機(jī)柜,以及通過高可靠AFDX 網(wǎng)絡(luò)進(jìn)行連接的其他分系統(tǒng),這里所指的其他分系統(tǒng)廣義上也可包含非航電系統(tǒng),例如液壓系統(tǒng),環(huán)控系統(tǒng)等。系統(tǒng)架構(gòu)如圖1 所示。
圖1 級聯(lián)式雙機(jī)備份架構(gòu)航電系統(tǒng)模型Fig.1 Module of redundant interconnection of the two-unit backup integrate avionics system
中央處理系統(tǒng)包括兩臺互為余度/備份的機(jī)柜,每臺機(jī)柜中包含若干塊電源模塊、通用處理模塊、數(shù)據(jù)處理模塊、圖形生成模塊、交換機(jī)模塊等。這些模塊之間通過AFDX 網(wǎng)絡(luò)以交換機(jī)為中心呈星型拓?fù)浣Y(jié)構(gòu)。對于交換機(jī)模塊,交換機(jī)A 與A',交換機(jī)B 與B',各自互為余度,分別接到其他功能模塊的AFDX 端系統(tǒng)A 端口和B 端口上。同一機(jī)柜中的交換機(jī)設(shè)計為級聯(lián)關(guān)系,所以兩個機(jī)柜中的任何兩個模塊都可以通過交換機(jī)交互數(shù)據(jù)。這種連接方法可以很大程度上促使數(shù)據(jù)的共享和提高網(wǎng)絡(luò)的可靠性。
在上述模型中,交換機(jī)的星型級聯(lián)允許網(wǎng)絡(luò)的規(guī)模不斷擴(kuò)大,外圍節(jié)點數(shù)量持續(xù)增加,盡管AFDX 網(wǎng)絡(luò)采用虛擬鏈路VL 技術(shù)、速率約束、流量管制和靜態(tài)路由等機(jī)制,但合理的網(wǎng)絡(luò)行為仍依賴于嚴(yán)格的系統(tǒng)層面設(shè)計,以及運行時的監(jiān)控[3],對AFDX 網(wǎng)絡(luò)有效的管理是航電系統(tǒng)正常工作的基本保證。
網(wǎng)絡(luò)管理在本質(zhì)上是一個監(jiān)視和控制的過程,其目的是盡可能地保證網(wǎng)絡(luò)的正常運行[4],基于TCP/IP的網(wǎng)絡(luò)管理通常包含網(wǎng)絡(luò)管理端(manager)進(jìn)程和網(wǎng)絡(luò)代理端(agent)進(jìn)程兩個角色。管理進(jìn)程和代理進(jìn)程之間的通信可以有兩種方式:一種是管理進(jìn)程向代理進(jìn)程發(fā)出請求,詢問或者按要求改變一個具體的參數(shù)值;另一種是代理進(jìn)程主動向管理進(jìn)程報告某個重要的事件發(fā)生[5]。除了管理端和代理端之外,網(wǎng)絡(luò)管理模型還包含3 個重要組成部分:1)管理信息庫(Management Information Base,MIB)包含所有代理進(jìn)程的所有可以被查詢和修改的參數(shù)[6];2)管理信息結(jié)構(gòu)(Structure of Management Information,SMI)是關(guān)于MIB的一套公用的結(jié)構(gòu)和表示符號[7];3)簡單網(wǎng)絡(luò)管理協(xié)議(Simple Network Management Protocol,SNMP)是管理進(jìn)程和代理進(jìn)程之間的通信協(xié)議[8]。
AFDX 網(wǎng)絡(luò)管理是指對AFDX 網(wǎng)絡(luò)中的終端進(jìn)行管理,是飛機(jī)航電系統(tǒng)正常工作的基本保證,與TCP/IP 協(xié)議的網(wǎng)絡(luò)管理類似,AFDX 網(wǎng)絡(luò)管理也分為管理端和代理端兩種角色,采用SNMP 協(xié)議進(jìn)行相互之間通信,其對應(yīng)機(jī)柜里所有連接到交換機(jī)的模塊(端系統(tǒng))以及交換機(jī)模塊本身進(jìn)行管理,并完成網(wǎng)絡(luò)拓?fù)渲兴泄?jié)點的狀態(tài)查詢、信息上報及故障管理。網(wǎng)絡(luò)管理主要包括構(gòu)型管理、故障管理、配置管理等。
2.2.1 構(gòu)型管理
構(gòu)型管理包括各模塊的上下網(wǎng)查詢以及管理模塊管理權(quán)的切換。上下網(wǎng)查詢指管理端可以主動查詢各端系統(tǒng)的在線狀況,如果端系統(tǒng)出現(xiàn)故障,網(wǎng)絡(luò)管理軟件將該端系統(tǒng)設(shè)置為離線狀態(tài)。管理模塊管理權(quán)的切換則指主管理模塊故障時,從管理模塊接管管理權(quán)。
2.2.2 故障管理
管理端每隔一段時間通過特定命令依次查詢網(wǎng)絡(luò)中一個設(shè)備(交換機(jī)或端系統(tǒng))的故障信息,端系統(tǒng)和交換機(jī)通過特定命令響應(yīng)網(wǎng)管的查詢指令,將故障信息反饋給網(wǎng)絡(luò)管理機(jī)。網(wǎng)管收到設(shè)備返回的故障信息后,將故障信息整理并上報飛機(jī)中央維護(hù)系統(tǒng)。
2.2.3 配置管理
網(wǎng)絡(luò)管理應(yīng)用軟件負(fù)責(zé)向維護(hù)系統(tǒng)上報自身和交換機(jī)的軟硬件配置管理信息。
AFDX 網(wǎng)絡(luò)管理軟件使用管理信息(MIB)庫在各模塊間交互信息,按照管理端與代理端分為兩部分,其中,管理端在2 個通用處理模塊上運行,代理端在交換機(jī)模塊、數(shù)據(jù)處理模塊、圖像生成模塊以及其他與交換機(jī)相連的模塊上運行。管理端和代理端軟件都基于VxWorks653 操作系統(tǒng)平臺而設(shè)計,以分區(qū)形式運行。
針對上述航電系統(tǒng)架構(gòu)模型抽象出的AFDX 網(wǎng)絡(luò)管理拓?fù)浣Y(jié)構(gòu)如圖2 所示。
圖2 AFDX 網(wǎng)絡(luò)管理拓?fù)淠P虵ig.2 Topology model of AFDX network manage
AFDX 網(wǎng)絡(luò)下SNMP 協(xié)議棧的位置跟TCP/IP 下的SNMP 協(xié)議類似,不同的是AFDX 網(wǎng)絡(luò)中SNMP 協(xié)議使用的是傳輸層的SAP(服務(wù)訪問點)端口進(jìn)行通訊。AFDX 通過虛鏈路實現(xiàn)了帶寬資源的有效分配和應(yīng)用隔離。虛鏈路可理解為一個端系統(tǒng)到另一個或多個端系統(tǒng)間的邏輯路徑,為單向連接,多條虛擬鏈路可以共用一條物理鏈路[9]。虛鏈路之間的通信方式有采樣、隊列以及SAP 3 種,AFDX 網(wǎng)絡(luò)下SNMP 協(xié)議的通訊,就是基于SAP 端口來實現(xiàn)的[10]。圖3 所示為AFDX 網(wǎng)絡(luò)管理端上SNMP/MIB 在AFDX 網(wǎng)絡(luò)中的協(xié)議棧的位置。
圖3 SNMP/MIB 在AFDX 網(wǎng)絡(luò)中的協(xié)議棧Fig.3 SNMP/MIB protocol stack location
代理端的MIB 庫是所有代理進(jìn)程包含的、并且能夠被管理進(jìn)程進(jìn)行查詢和設(shè)置的信息的集合。在AFDX網(wǎng)絡(luò)中,所有端系統(tǒng)和交換機(jī)中都具有MIB 庫。MIB 庫為樹形結(jié)構(gòu)圖,樹上的每個結(jié)點在擁有一個對象標(biāo)識的同時還有一個文字名[11],例如標(biāo)識“1.4.5.1”就和文字名“ESID”相對應(yīng)。在SNMP 的API 實現(xiàn)時,可以通過標(biāo)識符或者文字名進(jìn)行查詢。MIB 庫的結(jié)構(gòu)如表1 所示。
表1 MIB 庫的結(jié)構(gòu)Table 1 MIB structure
管理進(jìn)程和代理進(jìn)程之間的信息交互由SNMP 協(xié)議定義,SNMP v2 定義了7 種報文操作[12]:1)get-request操作,從代理進(jìn)程處提取一個或多個參數(shù)值;2)getnext-request 操作,從代理進(jìn)程處提取一個或多個參數(shù)的下一個參數(shù)值;3)set-request 操作,設(shè)置代理進(jìn)程的一個或多個參數(shù)值;4)get-response 操作,返回的一個或多個參數(shù)值,這個操作是由代理進(jìn)程發(fā)出的,是前面3 種操作的響應(yīng)操作;5)trap 操作,代理進(jìn)程主動發(fā)出的報文,通知管理進(jìn)程有某些事情發(fā)生;6)get-bulk-request操作,從代理進(jìn)程讀取大塊數(shù)據(jù);7)inform-request 操作,一個管理進(jìn)程向另一個管理進(jìn)程發(fā)送信息。
網(wǎng)絡(luò)管理應(yīng)用軟件主要利用SNMP 協(xié)議發(fā)起查詢以及對查詢到的數(shù)據(jù)進(jìn)行處理,分別對構(gòu)型管理、故障管理、狀態(tài)管理的軟件設(shè)計進(jìn)行描述。
構(gòu)型管理包括對AFDX 設(shè)備的構(gòu)型管理和對ARINC429 設(shè)備的構(gòu)型管理。
3.1.1 AFDX 設(shè)備的構(gòu)型管理
網(wǎng)絡(luò)管理應(yīng)用軟件每隔500 ms 查詢網(wǎng)絡(luò)中的所有終端,采用get-request 命令提取各端系統(tǒng)代理進(jìn)程中的EquipmentOnline 參數(shù),網(wǎng)絡(luò)管理軟件根據(jù)get-request 命令的執(zhí)行情況和返回的EquipmentOnline 參數(shù)的值判斷該設(shè)備的在線狀態(tài)。如果get-request 命令連續(xù)3 個周期未得到端系統(tǒng)代理進(jìn)程響應(yīng),則說明該端系統(tǒng)出現(xiàn)故障,網(wǎng)絡(luò)管理軟件應(yīng)將該端系統(tǒng)設(shè)置為離線狀態(tài);如果get-request 命令響應(yīng)成功,網(wǎng)絡(luò)管理軟件還要判斷返回的EquipmentOnline 參數(shù),如果連續(xù)3 次獲取到的該參數(shù)均為0,則說明端系統(tǒng)宿主機(jī)應(yīng)用軟件故障,該端系統(tǒng)應(yīng)設(shè)置為離線狀態(tài);否則說明端系統(tǒng)宿主機(jī)至少有一個應(yīng)用軟件/分區(qū)正常,該端系統(tǒng)應(yīng)設(shè)置為在線狀態(tài)。端系統(tǒng)代理進(jìn)程對網(wǎng)絡(luò)管理軟件的get-request 命令采用get-response 操作進(jìn)行響應(yīng),端系統(tǒng)代理進(jìn)程執(zhí)行完get-response 操作后,同時將MIB 庫中的EquipmentOnline 參數(shù)清零。
AFDX 設(shè)備的構(gòu)型管理流程如圖4 所示。
圖4 AFDX 設(shè)備的構(gòu)型管理流程圖Fig.4 Flow of AFDX end system construction management
3.1.2 ARINC429 設(shè)備的構(gòu)型管理
ARINC429 設(shè)備的構(gòu)型管理由遠(yuǎn)程數(shù)據(jù)采集器進(jìn)行收集并接受網(wǎng)管的統(tǒng)一管理,遠(yuǎn)程數(shù)據(jù)采集器收集下端ARINC429 設(shè)備的在線信息狀態(tài),并將其存放在MIB 庫中表示在線狀態(tài)的參數(shù)EquipmentOnline 中,該參數(shù)為整型變量,長度4 Byte,第31 位表示遠(yuǎn)程數(shù)據(jù)采集器的在線狀態(tài)信息,其他位按照相應(yīng)的對應(yīng)關(guān)系表示下端ARINC429 設(shè)備的在線狀態(tài)信息。網(wǎng)絡(luò)管理應(yīng)用軟件收集遠(yuǎn)程數(shù)據(jù)采集器的在線狀態(tài)信息的方式與AFDX 設(shè)備相同。
ARINC429 設(shè)備構(gòu)型管理的流程如圖5 所示。
圖5 ARINC429 設(shè)備的構(gòu)型管理流程圖Fig.5 Flow of ARINC429 equipment construction management
故障管理包括網(wǎng)管軟件對自身的軟硬件故障和交換機(jī)的軟硬件故障進(jìn)行的管理。
3.2.1 交換機(jī)的故障管理
交換機(jī)的故障包括通信錯誤演變成的故障和自檢測發(fā)現(xiàn)的故障。當(dāng)交換機(jī)的故障狀態(tài)發(fā)生改變時(正常變?yōu)楣收匣蚬收献優(yōu)檎?,交換機(jī)的代理進(jìn)程應(yīng)通過Trap 操作將狀態(tài)上報給網(wǎng)絡(luò)管理進(jìn)程,Trap 上報的基本信息單元為兩個32 位的信號,一個基本信息單元表示一個故障信息(包括故障編碼和故障發(fā)生時間),一個Trap 操作可以上報多個故障信息。
3.2.2 自身的故障管理
網(wǎng)絡(luò)管理應(yīng)用軟件自身的軟硬件故障由系統(tǒng)代號、分系統(tǒng)代號、位置信息和故障名稱編碼等構(gòu)成。其中,編碼的故障包括自身內(nèi)部故障,AFDX 通信故障或失效,電子盤故障或失效等。
3.2.3 故障信息上報
故障狀態(tài)改變,即故障發(fā)生或消失時,網(wǎng)絡(luò)管理應(yīng)用軟件向上級維護(hù)系統(tǒng)上報故障信息,內(nèi)容包括:
1)故障信息編碼;
2)故障次數(shù)(故障第幾次發(fā)生或消失);
3)故障狀態(tài)(存在、不存在);
4)故障類型,故障首次發(fā)生時置為硬故障,首次消失時即將故障類型修改為間歇故障,該故障狀態(tài)再次發(fā)生改變時維持間歇故障類型不變;
5)狀態(tài)改變時間(時、分、秒)。
網(wǎng)絡(luò)管理應(yīng)用軟件負(fù)責(zé)向維護(hù)系統(tǒng)上報自身和交換機(jī)的軟硬件配置管理信息。網(wǎng)管接收配置數(shù)據(jù)請求,并發(fā)送自身和交換機(jī)的硬件部件號、軟件版本號和配置表信息。處于工作狀態(tài)的網(wǎng)絡(luò)管理端通過get-request 命令獲取交換機(jī)的配置信息,將其信息整理之后與自身信息一起上報給維護(hù)系統(tǒng),而處于備份狀態(tài)的管理端則只上報自身配置管理信息。在此過程中,如發(fā)生管理權(quán)轉(zhuǎn)換,配置信息上報模塊維持原有的分配狀態(tài)不變,直至本次上報操作完成。
在完成軟硬件設(shè)計實現(xiàn)之后,分別在單元級、模塊級和系統(tǒng)級對該AFDX 網(wǎng)絡(luò)管理系統(tǒng)進(jìn)行測試,其中,系統(tǒng)級測試使用了整個航電系統(tǒng)地面測試環(huán)境,逐一對所有代理端設(shè)備的構(gòu)型管理(在線和離線狀態(tài))、故障管理(模擬故障注入)和配置管理(配置信息上報)等進(jìn)行了測試,結(jié)果表明,該AFDX 網(wǎng)絡(luò)管理系統(tǒng)穩(wěn)定可靠并且已成功應(yīng)用于飛機(jī)航電系統(tǒng)。
本文介紹了一種采用AFDX 為主干網(wǎng)絡(luò)的級聯(lián)式雙中央處理機(jī)備份互聯(lián)的航電系統(tǒng)架構(gòu)模型,在此模型的基礎(chǔ)上,進(jìn)行了AFDX 網(wǎng)絡(luò)管理需求分析,提取到其構(gòu)型管理、故障管理、配置管理等關(guān)鍵需求并且進(jìn)行了設(shè)計規(guī)劃,在VxWorks653 操作系統(tǒng)下實現(xiàn)了該網(wǎng)絡(luò)管理應(yīng)用軟件的全部功能并在充分測試后成功應(yīng)用。
[1] 周強(qiáng),熊華鋼.新一代民機(jī)航空電子互連技術(shù)發(fā)展[J].電光與控制,2009,16(4):1-6. (ZHOU Q,XIONG H G.Development of the new generation civil avionic interconnection technology[J].Electronics Optics & Control,2009,16(4):1-6.)
[2] 杜宏偉,馬捷中. 航空電子全雙工交換式以太網(wǎng)及其關(guān)鍵技術(shù)研究[J]. 測控技術(shù),2008,27(12):65-67.(DU H W,MA J Z. Research on avionics full duplex switched Ethernet and its key technology[J]. Measurement & Control Technology,2008,27(12):65-67.)
[3] 顧偉青. 航空電子系統(tǒng)發(fā)展面臨的挑戰(zhàn)與自主創(chuàng)新[J].航空制造技術(shù),2008(23):68-71.(GU W Q.Challenge and self-dependent innovation for avionics development[J]. Aeronautical Manufacturing Technology,2008(23):68-71.)
[4] 馬睿,劉源,秦前清.基于SNMP 協(xié)議的網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計[J]. 微機(jī)發(fā)展,2004,14(9):1-3. (MA R,LIU Y,QIN Q Q.Design of network management system based on SNMP[J].Microcomputer Development,2004,14(9):1-3.)
[5] 李明江.SNMP 簡單網(wǎng)絡(luò)管理協(xié)議[M]. 北京:電子工業(yè)出版社,2007. (LI M J. Simple network management protocol[M].Beijing:Publishing House of Electronics Industry,2007.)
[6] IETF.RFC1213.Management information base for network management of TCP/IP-based internets:MIB-II[S].1991.
[7] IETF. RFC1155 Structure and identification of management information[S].[S.l.]:IETF,1990.
[8] IETF. RFC1157 A Simple Network Management Protocol(SNMP)[S].[S.l.]:IETF,1990.
[9] SAE. ARINC 664 Aircraft data network,Part 2:Ethernet physical and data link layer specification[S].[S. l.]:ARINC,2002.
[10] SAE.ARINC 664 Aircraft data network,Part 7:deterministic networks[S].[S.l.]:ARINC,2003.
[11] 王莉莉,何鋒,李峭,等.基于策略的AFDX 網(wǎng)絡(luò)管理的設(shè)計與分析[J].計算機(jī)工程與設(shè)計,2012,33(2):421-424.(WANG L L,HE F,LI Q,et al. Analysis of novel policy-based network management in AFDX networks[J]. Computer Engineering and Design,2012,33(2):421-424.)
[12] STALLINGS W. SNMP and SNMPv2:the infrastructure for network management [J]. Communications Magazine,1998,36(3):37-45.