在現代汽車電子控制單元（ECU）中，Bootloader（引導加載程序）的核心功能之一是實現ECU軟件的遠程或在線更新（OTA/SOTA）。由于車載ECU在車輛安裝后不易拆卸，Bootloader提供了一種便捷的方式，無需拆卸ECU硬件即可更新軟件程序（Application, App）以添加新功能或修復缺陷。

為滿足不同的可靠性、效率和成本要求，發展出了多種Bootloader方案。以下將逐一介紹幾種常見方案的核心原理、工作流程及其優缺點。

方案一：基礎擦寫方案

圖1

原理： ECU軟件由獨立的Boot和App兩部分組成。正常運行狀態下App運行。當需要更新App時，ECU進入Boot執行刷寫流程。

流程【參考圖1】：

1. 狀態1: App V1.0 已存儲并運行，Boot準備就緒。

2. 擦除數據【箭頭1->2】： Boot 擦除當前App存儲區域。

3. 狀態2: App區域被擦除（標記為“已擦除”），Boot保持不變。

4. 寫入數據【箭頭2->3】： Boot 將新的App V2.0寫入到已擦除的區域。

5. 狀態3: App區域更新為App V2.0，Boot依舊不變，更新完成，新App開始運行。

優點：

• 實現簡單，邏輯清晰。

• 所需存儲空間少（僅存儲當前App和Boot）。

缺點：

• 核心問題：可靠性低。 如果在擦除后（狀態2）或寫入過程中出現中斷（如斷電、通訊錯誤），ECU將因App缺失或損壞而無法啟動或功能失常。這是最基本方案的最大弊端。

方案二：備份恢復方案

圖2

設計目標： 解決方案一刷寫失敗導致系統故障的問題。

原理： 在方案一基礎上，ECU內額外配置一塊專用存儲空間，用于在刷寫開始前臨時備份當前運行的App。

流程【參考圖2】：

1. 狀態1: App V1.0運行，備份區空閑。

2. 創建備份【箭頭1->2】： Boot將當前App V1.0完整復制到備份區。狀態2【圖2狀態2】： App V1.0運行，備份完成，準備后續操作。

3. 擦除數據【箭頭2->3，與方案一類似】： Boot擦除當前App存儲區（目標區域）。

4. 狀態3： App目標區標記為“已擦除”，Boot和備份的App V1.0保持不變。

5. 寫入數據【箭頭3->4】： Boot將新的App V2.0寫入目標區。

6. 狀態4: 更新成功，App V2.0開始運行，備份區仍保留App V1.0。若更新失敗，Boot可立即從備份區將App V1.0恢復至原位置。

優點：

顯著提高可靠性： 通過備份機制，有效應對刷寫中斷的故障，保障ECU在異常情況下仍能回退并正常運行舊版App。

缺點：

• 刷寫時間延長： 完整備份舊App的操作（拷貝數據）顯著增加了整體刷寫過程的耗時。

• 存儲需求增加： 需要額外提供與App同等大小的備份存儲空間。

方案三：雙分區輪換方案

圖3

設計目標： 解決方案二因備份操作導致的刷寫時間延長問題。

原理： 將App存儲的Flash劃分為兩個大小相同的物理分區（Partition A / Partition B, 或簡稱A區/B區）。同一時刻僅有一個分區內的App處于運行狀態（Active App）。刷寫操作直接在非運行態分區（Standby Partition）上進行。

流程【參考圖3】：

1. 狀態1: 假設A區運行App V1.0，B區存儲的是不運行的舊版App V0.5（或空閑）。

2. 擦除非活動區數據【狀態1->2】： Boot擦除非運行分區（此處為B區）的舊App V0.5。

3. 狀態2： A區運行App V1.0，B區被擦除（標記為“已擦除”）。

4. 寫入新App到非活動區【圖3狀態2->3】： Boot將新App V2.0寫入到已擦除的B區。

5. 狀態3： A區運行App V1.0，B區寫入App V2.0完成。更新完成后（通常由Boot在下次啟動時判斷），引導程序跳轉到B區運行App V2.0，此時B區成為激活區，A區成為待機區（反之亦然）。

優點：

1. 刷寫時間優化： 無需備份當前運行App（直接在空閑/舊分區操作），刷寫效率優于方案二。

2. 隔離性好： 運行分區與刷寫分區物理隔離，互不影響。

缺點：

地址依賴性： 兩個分區在Flash上的物理地址必然不同。這意味著運行在不同分區的App，其編譯鏈接時的起始地址（Base Address）和鏈接腳本（Linker Script）必須不同。這導致：

• 必須為每個硬件分區編譯不同版本的App軟件鏡像（如 AppV2.0_for_A, AppV2.0_for_B）。

• 軟件管理成本劇增： 需要維護兩套可執行文件，開發、測試、版本控制、發布和工廠刷寫流程都需做相應調整，復雜度高、易出錯。

空間浪費： 一半的空間長期存儲一個不運行的舊版本App。

方案四：硬件AB Swap方案

圖4

設計目標： 解決方案三地址依賴導致的軟件雙版本問題。

原理： 利用現代微控制器的硬件特性，將存儲代碼的Flash劃分為兩個大小相同且對稱的分區（A區和B區）。其核心硬件機制是存儲器地址映射重定向：系統總存在一個物理上的激活區（Active Partition），無論這個激活區對應的是A區還是B區，程序啟動時訪問的邏輯起始地址是固定的（0x00000000等）。

• 激活區的程序代碼如同存儲在這個固定起始地址上運行。

• 非激活區（Inactive Partition）的地址則被硬件映射到其他高位地址（或其他范圍），對其內容不會影響當前運行的程序。

• 通過特定的指令或寄存器操作（通常由Boot完成）可以實現兩個分區的硬件切換。

流程【參考圖4】：

1. 狀態1: A區為激活區，運行App V1.0。B區為非激活區，存儲舊版App V0.5（可無功能或未使用）。

2. 擦除非激活區數據【圖4狀態1->狀態2（隱含擦除）】： Boot擦除非激活區（B區）的App V0.5。

3. 狀態2: A區（激活）運行App V1.0，B區被擦除（標記為“已擦除”）。

4. 寫入數據到非激活區【圖4狀態2->狀態3（隱含寫入）】： Boot將新App V2.0寫入非激活區（B區）。

5. 狀態3： 寫入完成。執行分區切換： Boot觸發硬件交換操作（Swap），使B區成為激活區（邏輯地址映射切換）。系統重啟后，新App V2.0開始運行在A區（物理B區），A區（物理A區）變為非激活區存儲App V1.0。

優點：

• 單一軟件鏡像： 硬件地址映射解決了方案三的核心痛點。同一個App軟件鏡像（App V2.0）只需編譯一次，可以刷寫到任何一個分區。激活區機制保證其運行地址始終一致。

• 高可靠性： 在寫入完成并校驗無誤之前，非激活區的操作不影響當前運行程序。切換是原子操作（或可保障），降低了刷寫中斷影響范圍。

• 物理隔離： 運行與刷寫空間隔離。

缺點：

• 硬件成本增加： 要求微控制器芯片支持硬件AB Swap功能。Flash整體需求需翻倍（A區+B區大小之和等于方案一的完整App空間需求）。

真實Boot方案的缺點

以上四個方案都依賴真實boot來完成軟件刷新，它們都有以下類似的不足：

刷寫流程（包括引導、通訊、擦寫、切換）依賴于一個獨立于App的Bootloader程序。Bootloader本身也存在挑戰：

• 刷寫期間App不可用： 更新需要從App切換到Boot執行，期間App功能中斷。

• Boot更新困難： Boot自身出現缺陷或需要協議升級（如支持新通訊接口DoIP）時，更新非常困難，可能需要特殊工具或在生產環節完成，風險高成本大。

• 功能冗余與空間占用： Boot需要實現與App類似的底層驅動（如通信接口CAN/Ethernet）、診斷協議棧和文件處理邏輯，這部分代碼不能與App共享，導致冗余存儲占用。隨著協議棧復雜度提升（如支持DoIP需TCP/IP協議棧），Boot占用空間增大。

方案五：集成虛擬Boot的AB Swap方案

圖5

設計目標： 解決前四個方案中真實Bootloader帶來的問題（刷寫期間功能中斷、Boot更新難、協議棧冗余）。

原理：

• 在方案四硬件AB Swap的基礎上，將Bootloader的主要功能模塊（通訊、診斷、擦寫邏輯、狀態管理）作為軟件模塊（稱為虛擬 Boot 或 App-based Bootloader）集成到App中運行。

• 原始的“真Boot”保留極小功能：初始化硬件、檢查更新標志/信號、加載并跳轉到App中的虛擬Boot模塊或者直接跳轉到當前激活區的App。

• 當ECU接收到有效更新請求且安全條件滿足時，App中運行的虛擬Boot接管控制權：

• 負責與非激活區通訊（利用App運行的資源）。

• 準備、下載、驗證更新包。

• 在后臺執行對非激活分區的擦除和新App的寫入操作（通常采用分塊/分頁操作以允許App主功能間歇運行）。

• 寫入完成并校驗后，協調（或請求真Boot）執行最終的硬件分區Swap操作。

流程【參考圖5 - 著重理解狀態3】：

• 流程與方案四基本一致，唯一的區別是軟件升級流程由虛擬Boot而不是真Boot負責。

優點：

• 功能連續性好（可能實現無感刷新）： 虛擬Boot在App運行時執行大部分刷寫任務，App的主要功能在刷寫過程中可以（部分或完全）正常運行，用戶體驗更好。

• 虛擬Boot可更新： 虛擬Boot作為App的一部分，其缺陷或功能升級可隨App一同進行普通刷寫更新。

• 資源共享，節省空間： 虛擬Boot復用App已運行的通信接口驅動、協議棧（CAN/Ethernet, DoIP/UDS等）和文件系統資源，顯著減少了獨立Boot所需的冗余代碼和存儲空間。真Boot則極為精簡。

缺點：

• 資源共享帶來的復雜性： 需要精心設計資源調度，確保虛擬Boot的刷寫任務與App實時任務共享CPU、內存、通訊帶寬等資源時不產生沖突或性能瓶頸。

• 潛在穩定性風險： 刷寫操作在App環境中執行，App的運行狀態（如高負載、bug）可能干擾刷寫過程的穩定性和成功率，需更復雜的錯誤檢測和恢復機制。

• 刷寫速度可能受影響： 與獨立Boot（獨占資源、專門優化）相比，虛擬Boot的運行效率和刷寫速度通常較低。

• 設計復雜： 實現健壯的虛擬Boot解決方案需要更深層次的系統設計考慮和更嚴格的驗證。

小結

從方案一到方案五體現了Bootloader設計在可靠性、效率、成本、用戶體驗和工程管理復雜性之間的持續權衡與演進：

實際選擇哪種方案需要根據具體的項目需求（成本約束、可靠性要求、OTA體驗、硬件平臺支持、開發資源）進行綜合評估。方案四（硬件AB Swap）是目前車載ECU可靠刷寫的常用方案，方案五（集成虛擬Boot）則代表了追求更高OTA體驗和集成度的前沿方向。

來源：知乎@數數

https://zhuanlan.zhihu.com/p/1929163178593490273

新勢力車企：

特斯拉、合眾新能源-哪吒、理想、極氪、小米、賓理汽車、極越、零跑汽車、阿維塔汽車、智己汽車、小鵬、嵐圖汽車、蔚來汽車、吉祥汽車、賽力斯......

外資傳統主流車企代表:

大眾中國、大眾酷翼、奧迪汽車、寶馬、福特、戴姆勒-奔馳、通用、保時捷、沃爾沃、現代汽車、日產汽車、捷豹路虎、斯堪尼亞......

內資傳統主流車企：

吉利汽車、上汽乘用車、長城汽車、上汽大眾、長安汽車、北京汽車、東風汽車、廣汽、比亞迪、一汽集團、一汽解放、東風商用、上汽商用......

全球領先一級供應商：

博世、大陸集團、聯合汽車電子、安波福、采埃孚、科世達、舍弗勒、霍尼韋爾、大疆、日立、哈曼、華為、百度、聯想、聯發科、普瑞均勝、德賽西威、蜂巢轉向、均聯智行、武漢光庭、星紀魅族、中車集團、贏徹科技、濰柴集團、地平線、紫光同芯、字節跳動、......

二級供應商(500+以上)：

Upstream、ETAS、Synopsys、NXP、TUV、上海軟件中心、Deloitte、奇安信、為辰信安、云馳未來、信大捷安、信長城、澤鹿安全、紐創信安、復旦微電子、天融信、奇虎360、中汽中心、中國汽研、上海汽檢、軟安科技、浙江大學......