徐 輝,王海濤
(海裝駐南昌地區(qū)軍事代表室,江西 南昌,330024)
MIL-STD-1553B(簡稱1553B)總線是一種數(shù)字式命令/響應(yīng)時分制數(shù)據(jù)總線,是第三代軍用戰(zhàn)斗機所使用的典型數(shù)據(jù)總線。總線中通信節(jié)點按照功能分為三種類型:總線控制器(Bus controller,BC)、總線監(jiān)控器(Bus Monitor,BM)、遠程終端(Remote Terminal,RT)。BC 負責(zé)總線消息收發(fā)組織和通信調(diào)度,MC 負責(zé)監(jiān)控數(shù)據(jù)總線上的傳輸數(shù)據(jù),對總線傳輸?shù)南⑦M行監(jiān)控和記錄,RT 在總線控制器控制下進行數(shù)據(jù)收發(fā)[1-2]。實際應(yīng)用中,1553B 總線一般采用兩個總線控制器:主BC、備份BC,正常工作時主BC 控制整個1553B總線的調(diào)度和控制,備份BC 作為RT/MT 監(jiān)聽主BC 工作狀態(tài),主BC 發(fā)生故障時,備份BC 接管1553B 總線控制,避免BC 單點故障的發(fā)生。
某型飛機航電系統(tǒng)采用以1553B 總線為主總線的系統(tǒng)架構(gòu),顯示與控制管理處理機作為1553B 總線的總線控制器,任務(wù)管理計算機作為備份總線控制器,在顯示與控制管理處理機正常工作時,任務(wù)管理計算機作為遠程終端(RT),當顯示與控制管理處理機發(fā)生故障時,任務(wù)管理計算機作為總線控制器(BC),接管顯示與控制管理處理機的總線控制功能。
本文介紹了某型飛機1553B 總線主/備份功能控制原理,針對飛機外場使用中出現(xiàn)的主BC 故障、備份BC 接管總線控制的故障現(xiàn)象,對故障發(fā)生的原因進行分析定位,對故障的機理進行深層次分析。針對系統(tǒng)故障,對相關(guān)軟件設(shè)計邏輯進行完善,并對完善后的邏輯進行了驗證。
某型飛機航電系統(tǒng)主總線采用1553B 總線,系統(tǒng)正常情況下顯示與控制管理處理機(DCMP)作為1553B 總線的BC,對總線進行控制管理;當DCMP 故障后,任務(wù)管理計算機(MMC)接管1553B 總線的控制與管理權(quán),充當1553B 總線的BC,航電總線系統(tǒng)進入備份控制模式。
DCMP 與MMC 之間的“交、接權(quán)”通過飛機座艙內(nèi)總線控制開關(guān)、DCMP 發(fā)送給 MMC 的健康線、DCMP 發(fā)送給MMC 的1553B 總線信號共同控制。座艙內(nèi)總線控制開關(guān)有三種工作模式:正常、備份1 及備份2。當開關(guān)位于“正?!蔽粫r,默認DCMP 為1553B 總線控制器,DCMP 故障后,MMC 接管 1553B 總線控制權(quán);當開關(guān)位于“備份1”時,強制 DCMP 作為1553B總線控制器,DCMP 故障后,DCMP 重啟;當開關(guān)處于“備份 2”時,強制MMC 接管 1553B 總線控制權(quán),MMC作為1553B 總線控制器。
本次故障發(fā)生時,總線控制開關(guān)位于“正?!蔽?,故本文僅考慮在“正?!惫ぷ髂J綍rDCMP 和MMC交、接權(quán)的情況。 正常工作時,DCMP 每個周期通過1553B 總線向 MMC 發(fā)送“心跳”信息,通過 IOC 模塊硬線向MMC 輸出“健康線”標識。當MMC 在一定周期內(nèi)未接收到“心跳”信息或“健康線”信號時,通過B總線詢問BCMP 是否交權(quán),若MMC 周期內(nèi)未接收到DCMP 回復(fù)的“禁止接權(quán)”信號,則MMC 重構(gòu)系統(tǒng)當BC。
某型飛機航電系統(tǒng)在外場使用過程中多次發(fā)生DCMP 交出總線控制權(quán)、MMC 接管總線控制權(quán)的現(xiàn)象,出現(xiàn)時間不固定。查看DCMP 內(nèi)非易失性存儲器(NVRAM)中記錄的信息,發(fā)現(xiàn)當故障發(fā)生時均記錄到“0x300 例外”,其余記錄信息正常。“0x300 例外”是指CPU 對系統(tǒng)未配置空間資源進行訪問,即訪問非法地址。 根據(jù)故障發(fā)生時記錄到的PC 指針,對軟件目標碼進行反匯編,故障定位為SIO_429_ReadBlock驅(qū)動函數(shù)錯誤。 SIO_429_ReadBlock 驅(qū)動函數(shù)用于統(tǒng)計某一時刻所有ARINC429 通道的數(shù)據(jù)幀。其工作過程中涉及的硬件資源如圖1 所示。
圖1 SIO_429_ReadBlock 函數(shù)涉及的硬件資源
SIO 模塊中的DSP 通過ARINC429 驅(qū)動器、內(nèi)部緩沖區(qū)接收外部數(shù)據(jù),按照數(shù)據(jù)格式,通過B 口存儲在雙口存儲器中;CPU 模塊經(jīng)由VME 總線、邏輯芯片通過A 口訪問雙口存儲器,調(diào)用SIO_429_Read-Block 函數(shù)統(tǒng)計ARINC429 接口接收到的數(shù)據(jù)幀。根據(jù)SIO_429_ReadBlock 函數(shù)工作原理及涉及的軟硬件資源,建立如圖2 所示的故障樹,下面依次對故障樹中各個底事件進行分析。
圖2 0x300 例外的故障樹
軟件設(shè)計錯誤會導(dǎo)致程序進行非預(yù)期循環(huán),進而導(dǎo)致數(shù)組越界,造成0x300 例外。SIO_429_ReadBlock函數(shù)的思想為:統(tǒng)計某一時刻各個通道的幀數(shù)目,然后將各個通道的幀數(shù)目相加,得到該時刻有效幀的計數(shù)。經(jīng)檢查,該部分軟件算法實現(xiàn)無錯誤。
CPU 模塊按照VME 協(xié)議訪問SIO 模塊的雙口存儲器。若VME 協(xié)議實現(xiàn)有誤,會導(dǎo)致程序進行非預(yù)期循環(huán),造成數(shù)組越界。針對該情況,參考標準VME 時序,通過示波器采集DCMP、VME 時序并進行對比分析,發(fā)現(xiàn)VME 協(xié)議符合規(guī)定要求,故排除該故障事件。
VME 硬件走線是VME 協(xié)議的載體,若 VME 硬件走線存在故障,會導(dǎo)致CPU 端讀寫DPRAM 數(shù)據(jù)出現(xiàn)錯誤,進而引起應(yīng)用程序進入預(yù)期外的分支,造成數(shù)組越界。針對該情況,對VME 硬件走線進行了靜態(tài)測量(短路、開路測量)、DPRAM 非競爭模式的訪問測試。靜態(tài)測量表明硬件不存在開路、短路等問題;DPRAM 非競爭模式的訪問測試結(jié)果表明處理器端的VME 訪問控制邏輯功能正確。 測試結(jié)果表明硬件走線完好,不存在開路、短路、虛焊等問題。故排除該故障事件。
雙口邏輯主要實現(xiàn) CPU 模塊與SIO 模塊對DPRAM 的訪問。雙口邏輯無競爭時工作正常,下面分析雙口邏輯在競爭下的訪問過程。
CPU 模塊通過A 口訪問雙口存儲器 (CE# 置為低),邏輯先將DTACK#置為高,通知CPU 模塊等待,若此時SIO 模塊正通過B 口訪問同一單元,雙口會通過A 口發(fā)出BUSY#信號,邏輯根據(jù)BUSY#信號保持DTACK# 信號的高電平狀態(tài),通知CPU 模塊繼續(xù)等待,待BUSY# 信號結(jié)束后,將繼續(xù)保持(1~3 個時鐘周期),等待雙口完成數(shù)據(jù)準備,隨后邏輯使能讀寫信號,并通知CPU 模塊數(shù)據(jù)已準備完畢,將DTACK# 信號置低,CPU 模塊讀取數(shù)據(jù)后,CE#置高,訪問周期結(jié)束。若雙口邏輯出錯,會導(dǎo)致從雙口獲取的數(shù)據(jù)錯誤,影響條件判斷,致使程序無法跳出循環(huán)。
在雙口邏輯代碼段加入打印,查看故障發(fā)生時的頭尾指針和數(shù)組下標temp 值。發(fā)現(xiàn)當故障發(fā)生時,頭指針為異常值(非3 的整數(shù)倍),temp 一直增加,數(shù)組越界,將棧區(qū)其他信息改寫成采集的ARINC429 數(shù)據(jù)。另外,捕獲雙口發(fā)生競爭時的數(shù)據(jù)訪問時序圖,發(fā)現(xiàn)DSP 端在BUSY# 有效時,繼續(xù)進行數(shù)據(jù)訪問,未對DSP 端的ready 信號進行處理,造成雙口數(shù)據(jù)訪問錯誤。
雙口存儲器(DPRAM)通過提供兩套訪問接口,允許兩端設(shè)備同時進行訪問。在本文中,當DCMP 運行時,CPU 訪問DPRAM 某一單元,若此時DSP 端也同時訪問該單元,正常情況下DSP 端應(yīng)收到來自雙口的BUSY#,并根據(jù)BUSY# 的持續(xù)時間維持ready為低狀態(tài),保持DSP 端等待。 待CPU 模塊完成訪問后,再由DSP 端進行訪問。 對雙口訪問邏輯代碼中進行走查測試,發(fā)現(xiàn)DSP 端訪問雙口邏輯部分未對BUSYL# 信號進行處理判斷,故在CPU 端和DSP 端同時對同一地址進行訪問時,會導(dǎo)致數(shù)據(jù)讀取錯誤,發(fā)生故障。
由于ARINC429 接收通道的頭尾指針數(shù)據(jù)儲存在DPRAM 中,當DPRAM 發(fā)生訪問沖突時,邏輯缺陷導(dǎo)致獲取的頭尾指針發(fā)生錯誤,使軟件流程進入非預(yù)期循環(huán),導(dǎo)致數(shù)組越界。 DPRAM 緩沖區(qū)的存儲容量為 144(0~143)word(16bits),且緩沖區(qū)為環(huán)形緩沖區(qū),即當頭指針指到143 時再接收數(shù)據(jù),頭指針將從0 位置重新接收。假定單通道進行數(shù)據(jù)收發(fā)前,緩沖區(qū)及頭、尾指針位置如圖3 中左圖所示,某一時刻,SIO 模塊接收了3 幀數(shù)據(jù),一幀數(shù)據(jù)包括1 word 的通道號和2 word 的數(shù)據(jù)。 接收數(shù)據(jù)后頭指針和尾指針在雙口中的位置如圖3(右)所示。 應(yīng)用程序周期調(diào)用SIO_429_ReadBlock 函數(shù),當檢測到緩沖區(qū)不為空時,SIO_429_ReadBlock 函數(shù)統(tǒng)計該緩沖區(qū)接收到的數(shù)據(jù)。正常情況下,頭指針的移動見圖4(左)所示。故障發(fā)生時的情況如圖4(右)所示,由于雙口訪問邏輯的缺陷,軟件獲取了錯誤的頭指針位置(本例中錯誤值為10)。 其中頭尾指針正常情況下都是從0 開始每次進行加3 操作,即頭尾指針應(yīng)為3 的整數(shù)倍。如果讀到的值為非3 的整數(shù)倍,會導(dǎo)致while 的判斷條件一直為真,循環(huán)繼續(xù),造成read_data[150]數(shù)組越界,棧區(qū)被DPRAM 緩存的ARINC429 數(shù)據(jù)幀改寫,導(dǎo)致系統(tǒng)崩潰。
圖3 故障機理分析圖
圖4 故障機理分析圖
針對故障現(xiàn)象及機理分析,對DPRAM 處理邏輯進行如下改進:在頂層文件連接BUSYL#,當DSP 端訪問片選CE# 變?yōu)橛行r,將ready 置低,等待雙口的BUSY# 建立。然后根據(jù)BUSY# 情況進行判斷,如果BUSY# 有效,則等待BUSY# 變?yōu)闊o效,待BUSY#變?yōu)闊o效后,再等待讀數(shù)據(jù)的建立時間;最后待數(shù)據(jù)有效后,將ready 置高,通知DSP 端采樣讀數(shù)據(jù),并結(jié)束訪問。
系統(tǒng)驅(qū)動程序完善函數(shù)SIO_429_ReadBlock 中判斷有無接收數(shù)據(jù)幀的控制邏輯:原控制程序中的循環(huán)條件為當前讀取的尾指針和頭指針不相等,而由機理分析可知,一旦出現(xiàn)頭、尾指針讀寫錯誤的情況,造成數(shù)組下標temp 越界;故完善循環(huán)條件,增加對數(shù)組下標temp 值的判斷,應(yīng)小于149,否則上報錯誤并退出循環(huán)。
將更改后的雙口邏輯通過專用的雙口競爭測試程序(“狗叫狗”)進行常溫、高低溫測試,結(jié)果顯示雙口讀寫正常。 模擬機上ARINC429 環(huán)境,DCMP 連接4個外部ARINC429 超載荷的情況下,應(yīng)用軟件循環(huán)調(diào)用SIO_429_ReadBlock驅(qū)動函數(shù),DCMP 工作正常。
本文介紹了某型飛機航電系統(tǒng)1553B 總線主/備份控制系統(tǒng)邏輯構(gòu)型及工作模式,對外場中出現(xiàn)的1553B 主總線控制器異常故障、備份總線控制器接管總線控制權(quán)的故障現(xiàn)象進行了原因分析及定位,通過故障樹分析法對可能引起故障的原因進行逐一分析,對產(chǎn)生故障的原因機理進行深層次分析研究。分析結(jié)果表明:DCMP 訪問SIO 模塊雙口存儲器邏輯設(shè)計存在缺陷,在特定條件下改寫了棧區(qū)的數(shù)據(jù),引發(fā)數(shù)組越界,最終造成系統(tǒng)崩潰。
針對故障發(fā)生的原因,對DCMP 內(nèi)SIO 模塊雙口存儲器訪問邏輯進行了完善,并且優(yōu)化了軟件代碼中緩沖區(qū)頭、尾指針讀取設(shè)計和while 判斷條件。 經(jīng)驗證,改進措施有效,原故障排除。