徐 輝，王海濤

（海裝駐南昌地區(qū)軍事代表室,江西 南昌,330024）

0 引言

MIL-STD-1553B（簡稱1553B）總線是一種數字式命令/響應時分制數據總線，是第三代軍用戰(zhàn)斗機所使用的典型數據總線?？偩€中通信節(jié)點按照功能分為三種類型：總線控制器（Bus controller，BC）、總線監(jiān)控器（Bus Monitor，BM）、遠程終端（Remote Terminal，RT）。BC 負責總線消息收發(fā)組織和通信調度，MC 負責監(jiān)控數據總線上的傳輸數據，對總線傳輸的消息進行監(jiān)控和記錄，RT 在總線控制器控制下進行數據收發(fā)[1-2]。實際應用中，1553B 總線一般采用兩個總線控制器：主BC、備份BC，正常工作時主BC 控制整個1553B總線的調度和控制，備份BC 作為RT/MT 監(jiān)聽主BC 工作狀態(tài)，主BC 發(fā)生故障時，備份BC 接管1553B 總線控制，避免BC 單點故障的發(fā)生。

某型飛機航電系統(tǒng)采用以1553B 總線為主總線的系統(tǒng)架構，顯示與控制管理處理機作為1553B 總線的總線控制器，任務管理計算機作為備份總線控制器，在顯示與控制管理處理機正常工作時，任務管理計算機作為遠程終端（RT），當顯示與控制管理處理機發(fā)生故障時，任務管理計算機作為總線控制器（BC），接管顯示與控制管理處理機的總線控制功能。

本文介紹了某型飛機1553B 總線主/備份功能控制原理，針對飛機外場使用中出現的主BC 故障、備份BC 接管總線控制的故障現象，對故障發(fā)生的原因進行分析定位，對故障的機理進行深層次分析。針對系統(tǒng)故障，對相關軟件設計邏輯進行完善，并對完善后的邏輯進行了驗證。

1 某型飛機航電系統(tǒng)總線控制模式

某型飛機航電系統(tǒng)主總線采用1553B 總線，系統(tǒng)正常情況下顯示與控制管理處理機（DCMP）作為1553B 總線的BC，對總線進行控制管理；當DCMP 故障后，任務管理計算機（MMC）接管1553B 總線的控制與管理權，充當1553B 總線的BC，航電總線系統(tǒng)進入備份控制模式。

DCMP 與MMC 之間的“交、接權”通過飛機座艙內總線控制開關、DCMP 發(fā)送給 MMC 的健康線、DCMP 發(fā)送給MMC 的1553B 總線信號共同控制。座艙內總線控制開關有三種工作模式：正常、備份1 及備份2。當開關位于“正?！蔽粫r，默認DCMP 為1553B 總線控制器，DCMP 故障后，MMC 接管 1553B 總線控制權；當開關位于“備份1”時，強制 DCMP 作為1553B總線控制器，DCMP 故障后，DCMP 重啟；當開關處于“備份 2”時，強制MMC 接管 1553B 總線控制權，MMC作為1553B 總線控制器。

本次故障發(fā)生時，總線控制開關位于“正?！蔽唬时疚膬H考慮在“正?！惫ぷ髂Ｊ綍rDCMP 和MMC交、接權的情況。 正常工作時，DCMP 每個周期通過1553B 總線向 MMC 發(fā)送“心跳”信息，通過 IOC 模塊硬線向MMC 輸出“健康線”標識。當MMC 在一定周期內未接收到“心跳”信息或“健康線”信號時，通過B總線詢問BCMP 是否交權，若MMC 周期內未接收到DCMP 回復的“禁止接權”信號，則MMC 重構系統(tǒng)當BC。

2 故障現象及原因分析

某型飛機航電系統(tǒng)在外場使用過程中多次發(fā)生DCMP 交出總線控制權、MMC 接管總線控制權的現象，出現時間不固定。查看DCMP 內非易失性存儲器（NVRAM）中記錄的信息，發(fā)現當故障發(fā)生時均記錄到“0x300 例外”，其余記錄信息正常。“0x300 例外”是指CPU 對系統(tǒng)未配置空間資源進行訪問，即訪問非法地址。 根據故障發(fā)生時記錄到的PC 指針，對軟件目標碼進行反匯編，故障定位為SIO_429_ReadBlock驅動函數錯誤。 SIO_429_ReadBlock 驅動函數用于統(tǒng)計某一時刻所有ARINC429 通道的數據幀。其工作過程中涉及的硬件資源如圖1 所示。

圖1 SIO_429_ReadBlock 函數涉及的硬件資源

SIO 模塊中的DSP 通過ARINC429 驅動器、內部緩沖區(qū)接收外部數據，按照數據格式，通過B 口存儲在雙口存儲器中；CPU 模塊經由VME 總線、邏輯芯片通過A 口訪問雙口存儲器，調用SIO_429_Read-Block 函數統(tǒng)計ARINC429 接口接收到的數據幀。根據SIO_429_ReadBlock 函數工作原理及涉及的軟硬件資源，建立如圖2 所示的故障樹，下面依次對故障樹中各個底事件進行分析。

圖2 0x300 例外的故障樹

2.1 軟件設計錯誤（PG1）

軟件設計錯誤會導致程序進行非預期循環(huán)，進而導致數組越界，造成0x300 例外。SIO_429_ReadBlock函數的思想為：統(tǒng)計某一時刻各個通道的幀數目，然后將各個通道的幀數目相加，得到該時刻有效幀的計數。經檢查，該部分軟件算法實現無錯誤。

2.2 VME 協(xié)議實現故障（PG2）

CPU 模塊按照VME 協(xié)議訪問SIO 模塊的雙口存儲器。若VME 協(xié)議實現有誤，會導致程序進行非預期循環(huán)，造成數組越界。針對該情況，參考標準VME 時序，通過示波器采集DCMP、VME 時序并進行對比分析，發(fā)現VME 協(xié)議符合規(guī)定要求，故排除該故障事件。

2.3 VME 硬件走線故障(PG3)

VME 硬件走線是VME 協(xié)議的載體，若 VME 硬件走線存在故障，會導致CPU 端讀寫DPRAM 數據出現錯誤，進而引起應用程序進入預期外的分支，造成數組越界。針對該情況，對VME 硬件走線進行了靜態(tài)測量（短路、開路測量）、DPRAM 非競爭模式的訪問測試。靜態(tài)測量表明硬件不存在開路、短路等問題；DPRAM 非競爭模式的訪問測試結果表明處理器端的VME 訪問控制邏輯功能正確。 測試結果表明硬件走線完好，不存在開路、短路、虛焊等問題。故排除該故障事件。

2.4 雙口邏輯故障(PG4)

雙口邏輯主要實現 CPU 模塊與SIO 模塊對DPRAM 的訪問。雙口邏輯無競爭時工作正常，下面分析雙口邏輯在競爭下的訪問過程。

CPU 模塊通過A 口訪問雙口存儲器 （CE# 置為低），邏輯先將DTACK#置為高，通知CPU 模塊等待，若此時SIO 模塊正通過B 口訪問同一單元，雙口會通過A 口發(fā)出BUSY#信號，邏輯根據BUSY#信號保持DTACK# 信號的高電平狀態(tài)，通知CPU 模塊繼續(xù)等待，待BUSY# 信號結束后，將繼續(xù)保持（1~3 個時鐘周期），等待雙口完成數據準備，隨后邏輯使能讀寫信號，并通知CPU 模塊數據已準備完畢，將DTACK# 信號置低，CPU 模塊讀取數據后，CE#置高，訪問周期結束。若雙口邏輯出錯，會導致從雙口獲取的數據錯誤，影響條件判斷，致使程序無法跳出循環(huán)。

在雙口邏輯代碼段加入打印，查看故障發(fā)生時的頭尾指針和數組下標temp 值。發(fā)現當故障發(fā)生時，頭指針為異常值（非3 的整數倍），temp 一直增加，數組越界，將棧區(qū)其他信息改寫成采集的ARINC429 數據。另外，捕獲雙口發(fā)生競爭時的數據訪問時序圖，發(fā)現DSP 端在BUSY# 有效時，繼續(xù)進行數據訪問，未對DSP 端的ready 信號進行處理，造成雙口數據訪問錯誤。

3 故障機理分析

3.1 雙口存儲器工作原理分析

雙口存儲器（DPRAM）通過提供兩套訪問接口，允許兩端設備同時進行訪問。在本文中，當DCMP 運行時，CPU 訪問DPRAM 某一單元，若此時DSP 端也同時訪問該單元，正常情況下DSP 端應收到來自雙口的BUSY#，并根據BUSY# 的持續(xù)時間維持ready為低狀態(tài)，保持DSP 端等待。 待CPU 模塊完成訪問后，再由DSP 端進行訪問。 對雙口訪問邏輯代碼中進行走查測試，發(fā)現DSP 端訪問雙口邏輯部分未對BUSYL# 信號進行處理判斷，故在CPU 端和DSP 端同時對同一地址進行訪問時，會導致數據讀取錯誤，發(fā)生故障。

3.2 故障形成過程機理分析

由于ARINC429 接收通道的頭尾指針數據儲存在DPRAM 中，當DPRAM 發(fā)生訪問沖突時，邏輯缺陷導致獲取的頭尾指針發(fā)生錯誤，使軟件流程進入非預期循環(huán)，導致數組越界。 DPRAM 緩沖區(qū)的存儲容量為 144（0~143）word（16bits），且緩沖區(qū)為環(huán)形緩沖區(qū)，即當頭指針指到143 時再接收數據，頭指針將從0 位置重新接收。假定單通道進行數據收發(fā)前，緩沖區(qū)及頭、尾指針位置如圖3 中左圖所示，某一時刻，SIO 模塊接收了3 幀數據，一幀數據包括1 word 的通道號和2 word 的數據。 接收數據后頭指針和尾指針在雙口中的位置如圖3（右）所示。 應用程序周期調用SIO_429_ReadBlock 函數，當檢測到緩沖區(qū)不為空時，SIO_429_ReadBlock 函數統(tǒng)計該緩沖區(qū)接收到的數據。正常情況下，頭指針的移動見圖4（左）所示。故障發(fā)生時的情況如圖4（右）所示，由于雙口訪問邏輯的缺陷，軟件獲取了錯誤的頭指針位置（本例中錯誤值為10）。 其中頭尾指針正常情況下都是從0 開始每次進行加3 操作，即頭尾指針應為3 的整數倍。如果讀到的值為非3 的整數倍，會導致while 的判斷條件一直為真，循環(huán)繼續(xù)，造成read_data[150]數組越界，棧區(qū)被DPRAM 緩存的ARINC429 數據幀改寫，導致系統(tǒng)崩潰。

圖3 故障機理分析圖

圖4 故障機理分析圖

4 雙口存儲器處理邏輯改進及驗證

4.1 雙口存儲器處理邏輯改進

針對故障現象及機理分析，對DPRAM 處理邏輯進行如下改進：在頂層文件連接BUSYL#，當DSP 端訪問片選CE# 變?yōu)橛行r，將ready 置低，等待雙口的BUSY# 建立。然后根據BUSY# 情況進行判斷，如果BUSY# 有效，則等待BUSY# 變?yōu)闊o效，待BUSY#變?yōu)闊o效后，再等待讀數據的建立時間；最后待數據有效后，將ready 置高，通知DSP 端采樣讀數據，并結束訪問。

系統(tǒng)驅動程序完善函數SIO_429_ReadBlock 中判斷有無接收數據幀的控制邏輯：原控制程序中的循環(huán)條件為當前讀取的尾指針和頭指針不相等，而由機理分析可知，一旦出現頭、尾指針讀寫錯誤的情況，造成數組下標temp 越界；故完善循環(huán)條件，增加對數組下標temp 值的判斷，應小于149，否則上報錯誤并退出循環(huán)。

4.2 邏輯改進后的驗證情況

將更改后的雙口邏輯通過專用的雙口競爭測試程序（“狗叫狗”）進行常溫、高低溫測試，結果顯示雙口讀寫正常。 模擬機上ARINC429 環(huán)境，DCMP 連接4個外部ARINC429 超載荷的情況下，應用軟件循環(huán)調用SIO_429_ReadBlock驅動函數，DCMP 工作正常。

5 結語

本文介紹了某型飛機航電系統(tǒng)1553B 總線主/備份控制系統(tǒng)邏輯構型及工作模式，對外場中出現的1553B 主總線控制器異常故障、備份總線控制器接管總線控制權的故障現象進行了原因分析及定位，通過故障樹分析法對可能引起故障的原因進行逐一分析，對產生故障的原因機理進行深層次分析研究。分析結果表明：DCMP 訪問SIO 模塊雙口存儲器邏輯設計存在缺陷，在特定條件下改寫了棧區(qū)的數據，引發(fā)數組越界，最終造成系統(tǒng)崩潰。

針對故障發(fā)生的原因，對DCMP 內SIO 模塊雙口存儲器訪問邏輯進行了完善，并且優(yōu)化了軟件代碼中緩沖區(qū)頭、尾指針讀取設計和while 判斷條件。 經驗證，改進措施有效，原故障排除。