嵌入式系統(tǒng)自更新機制的設計與應用

　　隨著嵌入式系統(tǒng)的發(fā)展和廣泛應用,必不可少的維護工作變得日益繁重。如移動電話在用戶使用過程中，部分未能在軟件研發(fā)階段發(fā)現的缺陷會逐漸暴露,不可避免地增加了維護成本。 又如在設備運行期間,用戶往往會基于原有軟硬件對產品提出新功能或更高的性能要求，這對軟件重用性提出了挑戰(zhàn)。在移動設備數量較多, 而且使用地點無法預知的情況下, 采用傳統(tǒng)的人工更新方式會耗費大量的人力物力。自更新技術在嵌入式系統(tǒng)中分為兩個相互聯(lián)系又相互獨立的階段：首先是將更新包下載至本地移動設備中，然后在本地移動設備中實現自更新。

　　將自更新技術嵌入RTOS中的關鍵在于自更新后系統(tǒng)啟動的穩(wěn)定性。嵌入式移動系統(tǒng)一般都有獨立的bootloader對系統(tǒng)進行初始化并引導加載內核。這種啟動基于bootloader，該自更新機制決定了bootloader不僅僅起到加載內核鏡像這一基本功能，而是被看作是一個虛擬系統(tǒng)。

圖1? 自更新機制架構圖

1??自更新機制的架構

　　支持自更新功能的嵌入式系統(tǒng)由服務器端和客戶端兩部分組成。服務器端通過OMA協(xié)議，與客戶端建立無線連接?？蛻舳瞬捎没?a target="_blank">ARM9的微處理器,配有8 MB的RAM和32 MB的NOR? Flash存儲器,及其他相關外圍設備，具有相對可見的bootloader程序。自更新機制架構如圖1所示。

　　自更新機制總體流程如下： a. 設備廠商根據需求，生成包括升級到新版本或返回到舊版本的多個更新包。b. 這些更新包將被送至無線服務提供商處進行統(tǒng)一管理，并最終將更新包提供給用戶。c. 在更新包提供給用戶前，每個單獨的移動設備將會選擇最優(yōu)方案（即網絡提供商）。d. 服務器端通過傳輸機制(如OMADL 1.0協(xié)議標準或網絡提供商標準)與客戶端建立會話連接，客戶端將下載并存儲更新包。e. 更新應用程序將與用戶交互以獲得更新權限并進入更新進程。整個更新過程由bootloader完全控制，直到更新成功。f. 更新后的目標設備重啟，并將更新結果發(fā)送至服務器端。

2? 更新系統(tǒng)的設計

2.1? Flash 存儲器的布局

　　原有嵌入式系統(tǒng)Flash存儲器的布局如圖2(a)所示。系統(tǒng)啟動時從Flash的首地址開始執(zhí)行，而bootloader和RTOS都位于code區(qū)，也就是bootloader并不獨立于內核。將原本與
代碼區(qū)相鄰的文件系統(tǒng)區(qū)后移，用于存儲更新包。這種布局也是很多嵌入式系統(tǒng)所采用的，尤其是許多商業(yè)系統(tǒng)。系統(tǒng)在更新過程中根據自更新算法與原有代碼區(qū)進行比對，燒寫到Flash中。這種Flash部署方法有一個致命的缺點，就是沒有考慮到更新過程中可能遇到的突發(fā)事件。比如，在更新過程中因為不可預料的掉電使得燒寫錯誤,完全可能導致軟件更新后系統(tǒng)無法啟動,出現這種情況后必須人工重新燒寫原有軟件。

圖2? 存儲器布局

　　為了在原有基礎上使系統(tǒng)具有高穩(wěn)定性與擴展性,需要對Flash進行重新布局, 如圖2(b)所示。將代碼區(qū)劃分為兩個區(qū)域：bootloader區(qū)，這個區(qū)域不可被擦寫更新；RTOS區(qū)域，存放內核及應用程序。將更新包存儲區(qū)設計為4部分。其中一個用來存儲系統(tǒng)啟動和更新過程的標識參數，這些數據極為重要，掉電后仍需保存于Flash中。另一個存儲區(qū)用于存放更新時用到的更新包, 稱為更新包區(qū)。第三個區(qū)域存儲下載的更新包,稱為更新包備份區(qū)。最后一個區(qū)域存放設備出廠時的軟件版本。bootloader固定在第一個分區(qū),這樣的設計具有很強的可擴展性，涵蓋了更新算法。為了使人機接口更人性化，此區(qū)域包括LCD及其控制器的驅動和應用程序，使更新過程對用戶可見。系統(tǒng)啟動時設置異常向量表，初始化內存、堆棧指針寄存器、I/O器件、系統(tǒng)需求的RAM變量，使能中斷,然后根據啟動地址和更新標識這兩個參數跳轉執(zhí)行相應代碼，每次更新都不改變bootloader區(qū)域的內容。其中，啟動地址指向bootloader要執(zhí)行的代碼,更新標識用于記錄更新階段。

2.2? 更新進程的設計

　　系統(tǒng)每次啟動后, 服務器端主動報告當前有無可更新的軟件包。如果客戶端響應并發(fā)起會話，則隨后檢查Flash上的更新包備份區(qū),存儲下載的更新包，并更新標識。為了增強傳輸過程的安全性, 在應用層設計一套具有校驗、確認和斷點續(xù)傳功能的收發(fā)協(xié)議, 以保證數據能夠準確地通過移動通信系統(tǒng)傳輸到客戶端。

圖3? 更新進程流程

　　當更新包下載完畢后, 先將更新包由備份區(qū)拷貝至更新包區(qū)，更新進程根據已經設定的代碼區(qū)在Flash中的地址,調用Flash 的讀寫函數通過比對算法將更新包寫入代碼區(qū)。更新結束后設置標識,如果由于某種原因沒有更新成功則標識位不變,系統(tǒng)復位后繼續(xù)更新直到更新成功。可參考如下代碼：

　　ldrr0,=v_Update_flag
　　ldrr1,[r0]
　　ldrhr0,[r1]
　　ldrr1,=MC_ENTER_RTOS_FLAG
　　cmpr0,r1
　　beqcontinue
　　BEnter_Update_process
　　continue
　　ldrpc,=Enter_rtos

　　更新進程的程序流程如圖3 所示。

2.3? 更新后的啟動流程

　　通過以上更新流程,系統(tǒng)完成了一次軟件版本的升級。重新部署Flash后，客戶端具有相對獨立的bootloader,并固化在Flash的低地址處,能夠保證系統(tǒng)啟動后總是先進入bootloader。bootloader通過讀取對比標識存儲區(qū)的啟動地址參數來跳轉執(zhí)行代碼。在正常情況下, 啟動地址總是指向RTOS。當更新完成重新啟動客戶端后, bootloader便會引導新的鏡像文件。

　　為了確保軟件更新后系統(tǒng)啟動的穩(wěn)定性,通過設計異常處理程序來加載代碼備份存儲區(qū)的文件防止系統(tǒng)癱瘓。當bootloader 引導更新后的鏡像文件失敗后, 系統(tǒng)進入異常處理函數, 在此函數中將啟動地址指向代碼備份區(qū),并設置標識位。代碼備份區(qū)保存的是設備出廠時最初版本的image文件，具有非常高的穩(wěn)定性，這樣就保證系統(tǒng)功能正常運行,并確保服務器端與客戶端正常通信。異常處理流程如圖4所示。

圖4? 異常處理流程圖

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

3? 測試

　　為了評估自更新機制的穩(wěn)定性和安全性，確保其適用于真實設備與網絡，測試應盡可能覆蓋現實情況中可能遇到的情況。用戶能看到的升級性能主要有更新包下載時間和自更新時間。設備廠商關注的是高穩(wěn)定性和安全性，以及更新包所占Flash的比例。測試中應考慮到各種版本，制作測試矩陣，然后按順序測試，包括回退更新。

　　在一個實際運行的移動設備中驗證和測試更新機制的性能。首先測試更新進程的通信狀況。結果表明, 每次均能正確地與服務器端建立會話，并進行數據傳輸；更新包均能通過無線網絡準確下載并存儲至客戶端。測試的重點是系統(tǒng)更新結束后新程序啟動的穩(wěn)定性和安全性。對軟件更新過程進行干擾,以測試bootloader 能否正確啟動。測試中模擬了兩大類情況:一類是更新包隨機挑選版本的相互升級,另一類是人為設置導致更新包出現不能啟動錯誤的數據,然后進行升級。設計三種具體方案進行測試, 每個方案測試30 次,查看系統(tǒng)能否按預期結果啟動程序。測試方案及結果如表1所列。

表1? 啟動可靠性測試結果

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

結語

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