一種1553E數據加卸載系統設計與實現

魏雪菲 史巖 薛威

摘要：在航空、航天、兵器、艦船等領域，1553B數據總線應用廣泛，但沒有統一的設備升級維護方法。傳統方式使用專用設備對每個總線設備進行升級維護，但該方式操作不方便且容易引入操作錯誤。本文提出一種1553B總線的數據加卸載協議，規定一種輕量級的數據加卸載，用于完成1553B總線下的數據上傳和下載，實現配置文件、應用軟件的在線加載、更新與數據文件的下載。上傳和下載操作以文件為單位進行傳輸，傳輸文件以 Block為單位進行校驗、應答和重傳，保證傳輸正確性和傳輸效率。支持一次加卸載多個數據文件，從而增強系統可維護性，提高系統維護效率，降低維護成本。最后，基于仿真卡和嵌入式環境下的遠程終端（RT）設備，采用軟件形式化開發方法，實現！553B總線加卸載軟件。

關鍵詞：1553B;升級維護;數據加卸載;Block

中圖分類號：TP393.08 文獻標識碼：A

1553B數據總線廣泛應用于航空、航天、艦船及兵器等多個領域，涉及機電系統、飛行控制系統、航電系統和武器系統等多個系統[1]。1553B總線作為機載、車載網絡的二級總線，承擔了系統的內部互聯。近年來，隨著海、陸、空一體化作戰的發展，機載、車載、艦載系統任務的數據量和復雜度呈幾何量級倍增，1553B設備的數量也急劇增長，網絡規模隨之增大。但1553B總線沒有統一的設備升級維護方法，仍采用傳統的針對單個機載設備使用專用仿真器設施進行升級的維護方式。這種方式需要將機載、車載、艦載1553B設備逐個拆卸，再連接專用外接設備進行維護升級。設備拆卸工作操作不便，增加了工作量和維護時間，影響機載設備使用壽命，同時增加人工操作失誤帶來的危險。

1 系統設計

1.1 系統架構

根據1553B總線通信特點，系統包含加載器、加載控制器和被加載器三種角色，連接關系如圖1所示。其中BC為1553B總線控制器，承擔加載控制器角色;PMAT為具有1553 RT仿真卡的主機，是一種PC機環境下的遠程終端，承擔加載器角色;RT為1553B遠程終端，承擔被加載器角色。若PMAT給BC加卸載文件，則BC既承擔加載控制器角色，又承擔被加載器角色[2，3]。

非加載模式下，總線網絡中包含三種角色：BC為1553B總線控制器，RT為1553B遠程終端，BBC為備份總線控制器，在BC正常工作時BBC僅用作普通遠程終端[4，5];BC在非加載模式下檢測PMAT是否在線，若檢測到PMAT在線，則切換至加載模式，終止正常通信，執行加卸載功能。

該加卸載協議實現PMAT在用戶操作下，向被加載器加卸載配置表、軟件以及其他數據文件，實現配置表、軟件的統一管理和升級，以及被加載器數據文件到PMAT的下載。

該協議具有以下特點：

（1）網絡各節點在正常通信過程中不執行加載操作，僅在系統切換到加載模式，正常通信終止，PMAT連人系統后，才能執行加卸載功能。

（2）為保證傳輸效率和數據完整性，該加卸載方案將文件劃分為若干個Block，以Block為單位進行校驗、重傳，接收端接收到Block后進行校驗，結果正確后，繼續下一個Block傳輸過程。

（3）每個Block包含若干數據幀，數據幀連續發送，不再單獨對其進行校驗，以保證傳輸效率。

（4）文件傳輸完成后，針對整個文件，進行循環冗余校驗（CRC），保證文件傳輸的正確性和完整性，滿足安全關鍵數據的要求。

（5）該方案以Block為單位進行校驗、重傳，能夠支持傳輸大數據文件，對數據文件大小不做上限要求，但考慮加卸載效率，不建議進行過大文件傳輸。

1.2 協議架構

該協議架構層次如圖2所示，涵蓋了1553B模塊驅動層和主機應用層[6]。若加卸載文件為配置文件或1553B模塊驅動軟件，則主機應用接收并存儲后，由1553B模塊驅動層燒寫至 1553B模塊FLASH中;若加卸載文件為其他數據文件，則主機應用層僅接收，不進行燒寫固化;若數據文件為主機應用軟件，則最終燒寫在CPU模塊的FLASH中。對于PMAT，則所有協議由主機應用層實現。

2 算法流程

加卸載協議包含FIND操作、上傳操作和下載操作。

加卸載協議以文件為單位進行傳輸，為保證傳輸正確性和傳輸效率，傳輸過程中將文件劃分為若干個Block，針對單個Block進行校驗、應答，若出現錯誤則以Block為單位進行重傳。為保證整個文件的正確性，文件傳輸完成后對整個文件再進行CRC校驗。

經過以Block為單位的累加和校驗以及對整個文件的CRC校驗，避免了數據傳輸過程中的誤碼、丟包等故障造成的數據不完整錯誤。以Block為單位的累加和校驗，保證了大數據文件傳輸過程中錯誤的及時發現與更正，保證了傳輸文件的數據完整性和傳輸效率。

考慮1553B總線的通信特點，PMAT、RT、BBC之間的數據直接通信，需要由BC進行控制。

2.1 FIND操作

進行文件上傳或下載操作前，需要通過FIND操作來查看被加載器是否在線，并通過FIND操作來獲取被加載器的軟硬件及其版本信息。

2.2 上傳操作

上傳操作實現加載器到被加載器的文件傳輸和燒寫功能，加載器通過加載控制器與被加載器建立傳輸連接后，在加載控制器的干預下，完成數據文件到目標機的上傳操作。上傳操作的流程可分為加載初始化和加載兩部分。上傳過程中一個文件劃分為若干個Block，一個Block大小可通過協商確定，也可根據實際需要確定。

上傳操作的流程可分為上傳初始化和上傳階段兩部分，上傳初始化實現被加載器狀態查詢，確認當前被加載器是否在線、是否允許上傳;上傳階段加載器在加載控制器的干預下以Block為單位，逐塊向被加載器發送數據文件，直至文件傳輸完成。一次正常的文件上傳流程如圖3所示。

2.3 下載操作

下載操作實現被加載器數據文件到加載器的下載功能。下載操作的過程是：加載器通過加載控制器與被加載器建立傳輸連接后，完成被加載器數據文件的下載操作。下載過程中一個文件劃分為若干個Block，一個Block大小可通過協商確定，也可根據實際需要確定。

下載操作的流程可分為下載初始化和下載階段兩部分，下載初始化實現被加載器狀態查詢，確認當前被加載器是否在線、是否允許下載;下載階段將文件劃分成若干Block進行連續傳輸，直至文件傳輸完畢。一次正常的文件下載流程如圖4所示。

3 軟件設計與實現

軟件包含加載器、加載控制器和被加載器三部分，分別駐留在PMaT、嵌入式1553BBC設備和嵌入式1553BRT設備上，這三部分軟件通過1553B總線進行通信，完成協議功能。加載器、加載控制器和被加載器軟件需求均通過協議進行分析獲取，通過形式化方法進行軟件開發的分析、設計和實現[7]。

3.1 軟件形式化規格

有限狀態機是有限計算的基本模型，也是許多形式化規格、驗證方法的基礎模型。加載器軟件通過1553B數據加卸載協議獲取需求，用有限狀態機對其進行形式化規格描述，有限狀態機狀態轉移圖如圖5所示。

加載控制器若收到的操作被加載器是自身時，則其有限狀態機與被加載端相同;若其收到的操作被加載器為其他RT或BBC時，有限狀態機狀態轉移圖如圖7所示。

3.2 軟件實現

根據加載器、加載控制器和被加載器有限狀態機，基于1553B仿真卡和嵌入式平臺實現該加卸載協議，加載器仿真卡采用自主研發的1553B PCI仿真卡，主機采用WindowsXP操作系統，Microsoft Visual Studio 2010開發環境。加載控制器和被加載器采用國產1553B SOC芯片，基于PowerPC處理器實現，采用XMC接口與主機中央處理器（CPU）交互、供電。主機采用VxWorks 6.6，使用WorkBench開發環境，SOC芯片使用C*CORE 1DE開發環境。

加載器軟件采用分層方式實現，協議軟件采用C語言開發，封裝成lib庫，供上層調用，上層提供用戶操作界面，采用C++語言實現。加載控制器和被加載器采用C語言。

經測試，加卸載軟件加載并固化32KB文件需要4s，平均速率8kB/s。

4 結束語

本文設計并實現了1553B總線數據加卸載軟件，達到了64kB/s的傳輸速率，1553B總線速率為1MB/s，因此該速率仍有進州步提升空間，需針對加載器、加載控制器和被加載器等待時間進行研究，縮短等待時間開銷，提高通信速率。1553B總線加卸載軟件的實現，為1553B設備提供了一種在線升級維護方法，在機載、艦載、車載1553B設備中有廣泛的應用前景。

參考文獻

[1]劉士全，雋揚，蔡潔明，等.1553B總線應用發展研究[J].電子與封裝，2013，13（12）：12-15.

[2]ARINC 615A-3-2007 Software data loader using ethernet in-terface[S].ARINC Airlines Electronic Engineering Committee，2007.

[3]ARINC 615-4 Airborne computer high speed data loader[S].ARINC Airlines Electronic Engineering Committee，2002.

[4]MIL-STD-1553 Protocol tutorial[S].Condor EngineeringInc.，2004.

[5]楊衛軍，許化龍，訾向勇.基于 1553B總線的嵌入式網絡BBC設計與實現[J].微電子學與計算機，2007，24（1）：63-65.

[6]刑秀琴，姚竹亭.基于1553B總線的通信接口及其應用[J].中北大學學報：自然科學版，2007，28（1）：91-94.

[7]古天龍.軟件開發的形式化方法[M].北京：高等教育出版社，2005.