航空機電控制器軟件在線升級研究與實現

何與舟，王東升

(航空工業南京機電液壓工程研究中心 電子工程部，江蘇 南京 211106)

0 引言

航空機電控制器軟件部署在航空飛行器內各機電控制器中，當控制器交付裝機后，可能需要消除新發現的缺陷或進行系統需求變更，常常需要進行軟件升級。傳統的升級方法是將控制器從航空飛行器上拆卸下來、開蓋、連接仿真器重新燒錄軟件，該方法操作復雜、維護效率低，且存在對控制器造成破壞的風險。

本文通過對多種航空機電控制軟件升級策略、BOOT方式、文件格式等進行比較和分析，研究出一套利用航空機電控制器現有通信接口，通過通信數據處理、配置項ID確認、程序升級指令判定、應用程序固化、校驗、重傳、標志擦除等機制實現軟件原位在線升級的方案，試驗效果較好。

1 系統方案研究

1.1 升級策略選擇

從在線升級軟件功能與應用軟件的相對邏輯關系來分，常見的軟件在線升級策略有如下三種：

策略一：將在線升級軟件(BOOT軟件)與應用軟件分別存儲在不同的存儲器中，通過硬線開關選擇處理器運行的程序存儲器，若是要運行應用程序則選擇應用軟件存儲器，若是要進行在線升級則選擇BOOT軟件存儲器，升級設備通過與BOOT軟件的交互實現應用軟件的在線升級。該策略優點為BOOT軟件與應用軟件完全解耦，沒有任何交聯，方便進行獨立的維護和管理；缺點是需要為在線升級功能增加額外的硬件存儲器，同時，通過單根外部硬線選擇執行程序存儲器的方法可靠性低，若該硬線上存在干擾，將導致軟件運行出現不可預知的結果，且該隱患在控制器整個上電期間一直存在。

策略二：將BOOT軟件作為功能模塊嵌入到應用程序中，當需要進行軟件升級時，調用該功能模塊，擦除原有程序，并通過通信接口接收更新的程序，固化到存儲器中。該策略的優點為無需增加額外的硬件開銷，將BOOT軟件與應用軟件整合為單一軟件，實現簡潔，維護管理方便；缺點為應用軟件中包含擦除自身軟件的功能，存在安全隱患，另外，升級若失敗，下電后將無法再次進行在線升級，只能通過開蓋、用仿真器JTAG接口重新燒錄軟件，因此，策略二在實施上可靠性較弱。

策略三：將BOOT軟件與應用軟件作為獨立的軟件，但存儲在同一片存儲器的不同區域，當需要在線升級時，升級設備通過通信接口與應用軟件進行交互，應用軟件檢測到新的在線升級請求后，設置在線升級標志，并重啟處理器進入BOOT程序，BOOT程序檢測到升級標志后，將停留在BOOT程序中，并通過通信接口完成軟件在線升級。與策略一、二相比，該策略不增加額外硬件負擔，實施方法可靠、穩定。本方案選擇第三種升級策略。

1.2 BOOT方式選擇

策略三中提及的BOOT軟件有兩種實現方式，一種是采用芯片廠商自帶的BOOT軟件，另一種是完全自主開發。

芯片自帶的BOOT軟件一般支持RS422、CAN、IIC等多種升級方式，通過在處理器上電瞬間配置IO管腳的不同狀態來選擇升級方式，省去了BOOT軟件的開發工作，只要滿足其通信協議即可實現軟件的在線升級，但升級協議和升級機制均只能按照其固定邏輯進行。在實際應用過程中，無法靈活滿足各種應用場景的需要，尤其是對硬件看門狗喂狗的不支持，常常會給使用芯片自帶BOOT進行軟件升級帶來挑戰。

為了解決芯片自帶BOOT在使用過程中存在的問題，本方案選擇開發自主BOOT軟件，雖然增加了工作量，但帶來的好處也是顯而易見的。首先，可以滿足任何場景的在線升級需要，利用控制器現有通信接口即可進行升級；同時在機制上也更加靈活，可以選擇在任意時間點、以認為的更加安全的方式進行軟件在線升級。

1.3 升級的文件格式

常見的嵌入式IDE工具生成的目標文件格式多為ELF、OUT等，比如Code Composer V5.5使用的是OUT格式，由于對上述格式文件的解析太過復雜，因此在線升級軟件過程中使用較多的文件格式為HEX文件或者BIN文件。

HEX文件格式的缺點是可能出現中間地址不連續的情況，這就導致在做程序校驗時，相同的程序邏輯有可能出現不一樣的校驗結果。而BIN文件相較于HEX文件，更加直白和簡潔，在FLASH中存儲的數據是什么，BIN文件保存的數據就是什么，在整個升級過程中，無需額外的文件解析工作，收到的文件數據就是程序文件。本方案中的升級文件采用BIN文件格式。

2 系統設計

2.1 系統概述

航空機電控制器在線升級軟件通過RS422接收上位機(升級設備)發送的升級指令和待升級的應用軟件代碼文件，將該代碼固化到DSP中，實現對控制器應用軟件的在線升級，并向升級設備上傳控制器在線升級過程中的實時狀態，如圖1所示。

圖1 航空機電控制器在線升級原理圖

2.2 系統模式設計

系統模式設計見表1，其轉換關系如圖2所示。

圖2 模式轉換圖

表1 系統模式

2.3 軟件在線升級流程

軟件在線升級具體流程如下：升級設備通過RS422將升級指令發送給控制器的應用軟件；應用軟件接收到在線升級指令后，將在線升級標志(OFP)置為有效并復位；復位后先運行BOOT軟件，BOOT軟件識別到OFP標志有效后，停留在BOOT軟件中，查詢升級設備發送代碼中的軟件配置項標識(CSCI ID)，如果不是本控制器的代碼則空等待，如果是本控制器的代碼則擦除原先舊的應用程序代碼，并把待升級的應用程序代碼固化到控制器的DSP中。

BOOT軟件在升級過程中，將升級的狀態實時地通過RS422上傳給升級設備。升級完成后，升級設備發送退出在線加載狀態的指令，BOOT軟件接收到該指令后，清除OFP加載標志并等待下電，重新上電后運行應用軟件。

BOOT軟件的跳轉流程如圖3所示，加載程序流程如圖4所示。

圖3 BOOT軟件跳轉流程

圖4 加載程序流程

2.4 通信協議設計

升級設備和控制器之間的通信采用RS422方式，8位有效位，1位校驗位，1位停止位。升級文件目標碼格式采用BIN格式。升級設備與控制器的通信幀格式如表2、表3所示。

表2 升級設備發送給控制器的通信幀格式

表3 控制器回傳給升級設備的通信幀格式

2.5 數據校驗

在線升級軟件采用多重校驗的方法保證數據的可靠性。在數據傳輸過程中，對每包數據進行校驗和驗證。另外，為保證整個軟件升級過程中的一致性，升級設備將待升級軟件的CRC16校驗碼發送給控制器，控制器在升級過程中計算CRC16校驗碼，并與升級設備發送的校驗碼比對，如果一致，則升級成功；否則重新執行在線升級。

3 測試結果

通過升級設備對航空機電控制器軟件進行在線升級測試，運行結果見圖5。在升級設備依次執行選擇程序、配置端口后，向控制器發送升級程序。升級過程中，升級設備接收到控制器升級軟件回傳的“傳輸中”、“傳輸成功”、“固化中”、“固化成功”、“校驗中”、“校驗成功”等信息。經過檢查，升級軟件接收到的配置項ID、CRC校驗碼均與升級設備發送的一致，控制器軟件升級成功。

圖5 在線升級運行結果

4 結論

本文研究并實現了一套利用航空機電控制器現有通信接口，不額外增加硬件，通過通信處理以及ID和指令確認、固化、校驗、重傳等程序結構設計，實現航空機載軟件原位在線升級的方案，極大地方便了軟件升級工作，節省了維護成本。該方案通用性高，多重數據校驗等安全性設計保障了升級軟件的可靠性和準確性，目前已在多型飛行器上應用，具有良好的應用前景。