之前Boot是無法再次更新的，也就是說出廠后，Boot的軟件版本就是固定的，除非是拆件。不過現在越來越多的主機廠要求Boot也要支持刷寫，即使發生潛在錯誤時，Boot也可以更新修復。另外現在越來越多的ECU實施AB區的刷寫方案。下面主要從Boot啟動流程、ECU刷寫流程、升級測試、Boot自更新方案三方面來梳理。
01. Boot的啟動流程
ECU上電后，首先執行Boot。Boot首先完成一些基本的初始化，例如CAN驅動，IO模塊，初始化完成后，開始檢查刷新請求標志位是否為有效，如果刷新請求標志位有效，則等待刷寫指令。如果刷新請求標志位無效，則檢查應用軟件的狀態，如果應用軟件是有效的，則應用軟件代碼將被執行，如果應用軟件是無效的，則繼續執行Bootloader代碼。當ECU運行在應用軟件，當收到進入編程會話指令，ECU將外部刷新請求標志位設置為有效，并執行ECU重啟，如下圖所示。重啟后則按照之前上述的流程檢查。
▲圖 Bootloader啟動時序[來源網絡，侵刪]
02. 刷寫流程
刷新時序分為三個編程步驟：
- 預刷新步驟：刷新前的CAN網絡準備；
- 主刷新步驟：下載應用軟件或應用數據；
- 后刷新步驟：重同步CAN網絡。
1#. 預刷新步驟
預刷新步驟如下所示。
1、喚醒ECU，喚醒的方法和策略由汽車制造商制定；
2、為了關閉DTC存儲和運行0x28服務關閉相關的通信，需運行0x10服務跳轉至擴展會話；
3、進入擴展會話后，汽車制造商可以進一步進行特定數據鏈路的初始化；
4、運行0x31服務對刷寫條件進行檢查，例如低壓電是否在正常范圍內等。除了條件檢查之外，還會有一些安全機制，保證刷寫安全，避免以下幾種情況：
a. 來自非法源的下載動作；
b. 當前刷新條件不滿足；
c.下載錯誤的應用軟件或應用數據到ECU；
d.軟件之間不兼容；措施主要包括以下幾種：
安全訪問：ECU通過診斷0x27服務，SEED&KEY機制進行安全訪問服務限制，保證ECU免遭未授權的編程動作影響。
刷新預條件：ECU確保刷新時處于安全狀態，條件不滿足（如高壓上電、低壓異常或車速不為零）時，刷新服務請求將被拒絕。
完整性校驗：ECU對即將下載到flash的程序或數據進行完整性檢查，當一個邏輯模塊下載后，使用CRC32算法驗證當前邏輯塊的所有數據字節是否被正確傳輸和寫入。
通過“檢查編程完整性”例程控制激活ECU完整性校驗。當ECU接收到此服務請求時，Bootloader將計算下載數據字節的CRC32值，并將計算結果與診斷儀請求報文中發送的校驗值進行比較。
一致性檢查：不兼容的軟件不能配合使用，如果配合使用可能會使功能異常或產生致命性錯誤。為此，ECU通過驗證軟件兼容性來檢查刷新程序的一致性，包括應用軟件與Bootloader軟件、應用數據
與應用軟件檢驗等。
5、為了防止刷寫過程中出現異常誤觸發DTC存儲，運行0x85服務關閉DTC的存儲；
6、該步驟提供給汽車制造商一個接口，可以通過0x31服務啟動或關閉ECU的故障安全響應(failsafe reaction);
7、為了提高刷寫速度，降低刷寫程序時總線負載率，通過運行0x28服務關閉無關報文，比如應用報文和網絡管理報文；
8、在關閉部分通信之后，通過0x22服務讀取被刷ECU的狀態(應用軟件和數據)、軟件指紋信息等；
9、為了減少刷寫的時間，可以通過0x87服務提高CAN總線的波特率。
2#. 主刷新步驟
在預刷新步驟之后，是主刷新步驟。主刷新時序是單個ECU刷新事件的應用，因此所有服務的請求都使用物理尋址。
其中：
1、運行0x10服務進入programmingSession；
2、運行0x27服務進入特定的安全等級；
3、運行0x2E服務將指紋信息寫入ECU；
4、運行0x34、0x36、0x37服務將永久存儲區寫入默認值；
5、運行0x31服務檢查步驟4是否成功，另外一種方法是通過0x37的響應確定是否成功；
6、運行0x31服務對特定的Flash進行擦除；
7、分別運行0x34、0x36、0x37服務將Flash driver下載至內存中；
8、運行0x31服務檢查Flash driver下載是否成功；
9、分別運行0x34、0x36、0x37服務將軟件和數據下載至ECU的flash中；
10、運行0x31服務檢查步驟9是否下載成功；
11、運行0x31服務驗證程序是否能正常運行，例如checksum、標志位等；
12、在下載完軟件和數據后，汽車制造產商需要一些特定的操作，比如寫入VIN碼等。
3#. 后刷新步驟
該步驟主要通過0x11服務對ECU進行復位或者通過0x10服務切換至默認會話，如圖3所示，如果在預編程中中調整了波特率，須通過特定的操作將波特率調整至正常值。通常操作是運行0x11服務使ECU復位，回到正常狀態。
03. 刷寫測試用例
刷寫功能開發完之后，通常都是要按照測試用例進行測試的，那一般都要做哪些測試呢，才能證明刷寫功能是OK的呢？主要分為4部分測試。首先是模擬診斷儀正常刷寫，測試用例主要包括下圖所示，圖中測試用例還考慮了標定數據的刷寫。
▲圖 正常刷寫用例
然后是錯誤注入測試，其前提是錯誤刷寫不損壞系統Boot，當重新上電后，DUT可以正常更新應用程序。用例如下所示。
▲圖 故障注入測試用例
再之后是刷寫完整性測試，測試用例如下所示。
▲圖 完整性測試用例
最后就是刷寫流程以及預條件測試，主要測試3E服務，前置條件，刷寫失敗等，測試用例如下圖所示。
04. Boot自更新
Boot自更新的需求現在也是越來越多，主要為了修復Boot軟件中存在的Bug。以下有幾種Boot自更新的方案。
1#. Supplier Boot(SB) + Customer Boot(CB)
通常情況下，供應商都有自己的平臺軟件，包括Boot和Appl。而各主機廠都有自己不同的軟件升級規范，為了適配主機廠的需求，通常的做法是加一層Customer Boot來實現客戶的需求。那軟件的運行順序就是SB->CB->Appl，如圖1所示。這種做法可以簡單、快速的滿足CB也可以更新。
▲圖 SB+CB的升級方式[來源網絡，侵刪]
不過這種方式，通常情況下通過SB更新CB是通過供應商自己定義的升級流程，并且通過自己的上位機來實現升級。也就意味著這種方式只適應項目開發階段，因為供應商的升級流程無法接入到整車的OTA流程。這種方式的優點就是簡單，能很快地適配客戶的需求，而且即使面向不同的客戶，只需要簡單的更改CB就可以滿足需求，適應性比較好。但是缺點就是會浪費Flash空間。
2#. 將Boot先放到RAM中運行，然后更新Boot的Flash區域
這種方式只需要一份Boot，其具體方案是，在Boot的鏈接文件中，將程序和數據映射到特性的RAM空間，然后在控制器上電時，首先將Boot的代碼和數據搬運到RAM中，程序運行在RAM中，當收到更新Boot的需求時(這里需要上位機在發送更新指令的時候，區別是更新Boot還是App，比如通過在0x31服務寫入不同的標志位進行區分)，通過RAM中的程序以及上位機下載的Flash Driver，將Boot的Flash區域進行更新。
▲圖 方案二
這種方式的優點就是節省Flash空間，而且如果客戶想把Boot自更新的功能保留到量產之后，也是可以的，因此控制器的升級是完全遵循主機廠的要求的。不過這種方式有個缺點，就是在更新過程中，不能斷電，一旦斷電，控制器就會變成板磚，需要換件。另外程序運行在RAM中，對踩內存這種行為更加敏感。不過在整車上，出現意外斷電的情況應該很少。首先升級之前會檢查低壓蓄電池的電壓水平，甚至對新能源車來說，可以啟動DCDC，來保證12V的穩定供應。
3#. 兩個CB+minBoot
這種方案下，有兩個CB和一個miniBoot，miniBoot的作用很簡單，就是根據引導區的標志位來決定切換到哪個Boot。
▲圖 2個CB+miniBoot方案
這種方案的優勢就是可以保證刷新過程中斷電不會導致控制器變成板磚，而且也可以在SOP之后繼續使用。缺點也很明顯，空間占用率比較大，軟件復雜，需要三個Boot。
轉自汽車ECU開發
