潘文卿， 劉興義， 王飛飛， 宋炳雨， 王琳琳

（濰柴動力股份有限公司， 山東濰坊 261061）

在汽車領(lǐng)域， 隨著智能化的不斷提升， 汽車各方面的功能越來越多， 越來越復(fù)雜， 軟件會不斷地迭代升級， 而且更新周期開始變得越來越短， 所以需要不斷地更新升級程序。 程序升級的流程和架構(gòu)需要保證正確穩(wěn)定， 安全可靠。 在汽車領(lǐng)域的嵌入式系統(tǒng)軟件中， 主要包含兩部分程序， 一部分是引導(dǎo)加載程序， 主要負責(zé)完成初始化硬件設(shè)備， 建立內(nèi)存空間的映射關(guān)系， 升級控制程序， 即Bootloader程序， 以下簡稱Boot程序； 另一部分是實現(xiàn)相關(guān)控制功能的應(yīng)用程序即APP程序。

1 Bootloader的相關(guān)概念

Bootloader就是在操作系統(tǒng)內(nèi)核運行之前運行的一段程序， 初始化硬件設(shè)備， 建立內(nèi)存空間的映射關(guān)系， 從而將系統(tǒng)的軟硬件環(huán)境帶到一個合適狀態(tài)， 以便最終調(diào)用操作系統(tǒng)內(nèi)核做好正確的環(huán)境。 Bootloader是依賴于硬件而實現(xiàn)的， 特別是在嵌入式系統(tǒng)中。 因而我們可以構(gòu)建一個具有適用性、 安全可靠的架構(gòu)。

2 單Boot刷寫架構(gòu)

單Boot刷寫的架構(gòu)， 即系統(tǒng)一上電， 先進入Boot程序，進行軟硬件的初始化， 建立內(nèi)存空間的映射關(guān)系， 然后校驗應(yīng)用程序的完整性， 如果程序是完整的， 當前也沒有程序更新需求進入， 將跳轉(zhuǎn)到APP程序中運行。 如果應(yīng)用程序運行過程中收到刷寫的命令， 則跳轉(zhuǎn)到Boot程序進行APP軟件升級的會話流程。 這種單Boot的架構(gòu)隨著功能的不斷迭代升級， 局限性已日漸明顯。 一旦Boot程序燒錄到控制器中， 即無法再更新。 圖1是Boot程序和APP程序運行及刷寫架構(gòu)圖。

圖1 Boot和APP的跳轉(zhuǎn)及刷寫流程

這種單Boot的架構(gòu)適用于項目規(guī)劃最初就能夠?qū)?yīng)用程序的架構(gòu)劃分明確， 不會因為功能的增加， 程序的迭代導(dǎo)致程序區(qū)或者數(shù)據(jù)區(qū)空間不夠， 需要重新劃分區(qū)間的情況。 一旦應(yīng)用程序的架構(gòu)有調(diào)整， 單Boot的刷寫架構(gòu)將不再適用， 控制器將不再支持軟件版本上下兼容， 持續(xù)升級。

3 雙Boot刷寫架構(gòu)

3.1 雙Boot刷寫架構(gòu)1

為了規(guī)避單Boot 的架構(gòu)帶來的不便， 再單獨拿一塊Flash區(qū)域做成雙Boot， 我們分別用BootA （更新應(yīng)用程序的Bootloader）， BootM （更新BootA的Bootloader） 區(qū)分。 BootA中有啟動程序， 一上電， 程序就從BootA中啟動運行， 上電后初始化軟硬件， 完成內(nèi)存空間的映射關(guān)系， 校驗APP應(yīng)用程序的完整性， 在BootA中停留一定時間后跳轉(zhuǎn)到APP應(yīng)用程序， 如果在此停留期間收到更新APP的會話請求， 按照標準的UDS刷寫流程進行APP應(yīng)用程序更新， 更新完成后， 則跳轉(zhuǎn)到APP入口運行應(yīng)用程序； 如果在BootA運行期間收到更新BootA的會話命令， 則跳轉(zhuǎn)到BootM中， 按照標準的UDS刷寫流程更新BootA， 更新完成后， 先從BootM跳轉(zhuǎn)到BootA， 然后再跳轉(zhuǎn)到APP。

如果在APP運行期間收到更新BootA的會話請求， 則先從APP跳轉(zhuǎn)到BootA， 再從BootA跳轉(zhuǎn)到BootM， 進行BootA的程序更新， 更新完成后則由BootM 先跳轉(zhuǎn)到BootA， 再由BootA跳轉(zhuǎn)到APP。 BootM和APP之間不能直接跳轉(zhuǎn)， 以保證BootM的獨立性。

為了防止出現(xiàn)異常復(fù)位或者刷死APP的情況， 設(shè)定復(fù)位機制， 強制停留在BootA程序中， 并發(fā)送一條具有復(fù)位原因標識內(nèi)容的報文到總線上以便分析， 當前因異常強制停留在了BootA， 可以分析APP程序進行定位以便重新進行程序刷寫。

此架構(gòu)的優(yōu)點是隨著程序的不斷迭代升級， 當BootA的刷寫流程或者程序設(shè)計不滿足要求的時候， 可以通過BootM進行更新， BootM僅有更新BootA的功能， 比較純粹和獨立，僅僅是用來更新BootA， 因此它占用的空間會比較小， 對整個嵌入式系統(tǒng)程序的設(shè)計不會帶來太大的影響。

如圖2 所示， BootM 和APP 沒有直接的跳轉(zhuǎn)關(guān)系，都是通過BootA來跳轉(zhuǎn)， 這樣BootM 會比較獨立， 不受APP 的影響，但是同時更新BootA 時風(fēng)險比較大， 此時要保持通信的設(shè)備和線路穩(wěn)定， 通信會話流程設(shè)計要安全可靠， 如果在更新BootA的過程中出現(xiàn)間斷、 卡滯等問題會導(dǎo)致刷寫失敗， 如果BootA不能正常啟動運行， 會導(dǎo)致控制器失效。 因此更新BootA的風(fēng)險性較高。

圖2 BootA-BootM-APP跳轉(zhuǎn)關(guān)系1

3.2 雙Boot刷寫架構(gòu)2

控制器上電首先進入BootM， BootM中包含了啟動程序，初始化程序， 校驗APP完整性功能， 在BootM運行期間收到刷寫會話命令， 如果要更新BootA， 則按照標準的UDS刷寫流程更新BootA， 更新完畢后， 跳轉(zhuǎn)到APP； 如果收到更新APP的會話命令， 則先跳轉(zhuǎn)到BootA， 然后更新APP； 如果沒有收到任何更新程序的會話命令， 則直接跳轉(zhuǎn)到APP。

在APP程序運行期間， 如果收到更新BootA的會話命令，則跳轉(zhuǎn)到BootM， 更新BootA， 更新完畢后跳轉(zhuǎn)到APP； 如果收到更新APP的會話命令， 則跳轉(zhuǎn)到BootA， 對APP程序進行更新， 更新完畢后跳轉(zhuǎn)到APP運行。 BootM的功能保證了不管什么情況下即便是BootA異常刷死了， 也可以重新上電跳轉(zhuǎn)到APP正常運行。

如圖3 所示， 在此架構(gòu)關(guān) 系 中 ，BootM、 BootA、 APP 三者建立相互跳轉(zhuǎn)關(guān)系， BootM承接一部分初始化的功能，更 新 BootA，如果更新BootA失敗， 則停留在BootM中。 BootA保留更新APP的功能， 如果APP存在異常， 連續(xù)復(fù)位或者被刷死的時候， 設(shè)定復(fù)位機制， 停留在BootA中， BootA會通過一條可以標識復(fù)位原因的報文發(fā)送到總線上以便分析并進一步更新APP； 如果APP更新失敗， 會停留在BootA中； 如果BootA更新失敗， 停留在BootM中， 以便程序進一步更新， 可以保證控制器不會因為程序問題而失效。

圖3 BootA-BootM-APP跳轉(zhuǎn)關(guān)系2

4 結(jié)論

本文以實際的嵌入式系統(tǒng)程序升級為例， 提出了3種嵌入式系統(tǒng)程序升級Boot架構(gòu)設(shè)計， 并對每一種Boot架構(gòu)的優(yōu)缺點進行了分析。 在功能不斷智能化、 多樣化的情況下，程序不斷迭代升級， 頻繁升級程序是不可避免的， 在優(yōu)化過程中， Boot也會升級。 為了保證控制器下線后， Boot程序和應(yīng)用程序都能夠不斷地升級， 我們提出了雙Boot的概念，用一個Boot升級另一個Boot， 另一個Boot升級應(yīng)用程序， 這樣上電后的啟動順序以及跳轉(zhuǎn)關(guān)系成了關(guān)鍵。 本文從兩種Boot架構(gòu)中分析了各自的優(yōu)缺點， 在架構(gòu)2中彌補了架構(gòu)1的缺點， 降低了Boot刷寫的風(fēng)險， 提高了系統(tǒng)的穩(wěn)定性。