嵌入式系統自更新機制的設計與應用

2．3 更新后的啟動流程
通過以上更新流程，系統完成了一次軟件版本的升級。重新部署Flash后，客戶端具有相對獨立的bootloader，并固化在Flash的低地址處，能夠保證系統啟動后總是先進入bootloader。bootloader通過讀取對比標識存儲區的啟動地址參數來跳轉執行代碼。在正常情況下，啟動地址總是指向RTOS。當更新完成重新啟動客戶端后，bootloader便會引導新的鏡像文件。
為了確保軟件更新后系統啟動的穩定性，通過設計異常處理程序來加載代碼備份存儲區的文件防止系統癱瘓。當bootloader引導更新后的鏡像文件失敗后，系統進入異常處理函數，在此函數中將啟動地址指向代碼備份區，并設置標識位。代碼備份區保存的是設備出廠時最初版本的image文件，具有非常高的穩定性，這樣就保證系統功能正常運行，并確保服務器端與客戶端正常通信。異常處理流程如圖4所示。

當軟件更新過程中遇到致命異常時，通過異常處理程序，系統能夠重新啟動備份的軟件版本，有效地提高了嵌入式系統自更新機制的安全性，避免了系統徹底崩潰。

3 測 試
為了評估自更新機制的穩定性和安全性，確保其適用于真實設備與網絡，測試應盡可能覆蓋現實情況中可能遇到的情況。用戶能看到的升級性能主要有更新包下載時間和自更新時間。設備廠商關注的是高穩定性和安全性，以及更新包所占Flash的比例。測試中應考慮到各種版本，制作測試矩陣，然后按順序測試，包括回退更新。
在一個實際運行的移動設備中驗證和測試更新機制的性能。首先測試更新進程的通信狀況。結果表明，每次均能正確地與服務器端建立會話，并進行數據傳輸；更新包均能通過無線網絡準確下載并存儲至客戶端。測試的重點是系統更新結束后新程序啟動的穩定性和安全性。對軟件更新過程進行干擾，以測試bootloader能否正確啟動。測試中模擬了兩大類情況：一類是更新包隨機挑選版本的相互升級，另一類是人為設置導致更新包出現不能啟動錯誤的數據，然后進行升級。設計三種具體方案進行測試，每個方案測試30次，查看系統能否按預期結果啟動程序。測試方案及結果如表1所列。

從測試結果看出，系統更新后，每次均能正確啟動程序；此外，更新機制對代碼區具有較強的修復能力，防止了由于數據異常而導致的無法啟動。本更新機制能有效地提高嵌入式軟件更新后重新啟動的穩定性和可靠性。

結 語
本文提出了一種具有較高穩定性和安全性、基于bootloader的嵌入式軟件自動更新機制。該更新機制同時保存了3個文件，需要較多的Flash存儲空間，但同時降低了維護成本。其創新點在于設置1個標識區、3個程序存儲區并設計了異常機制，提高了嵌入式系統更新過程的穩定性，尤其能夠有效地防止軟件更新后系統啟動失敗的情況，具有較高的實用價值。