工程思考：為什么OEM抵觸Bootloader更新？

工程項目中，軟件維護和修復是整個軟件生命周期"永恒"的議題，換句話說：軟件的魯棒程度是相對的，而軟件存在bug是絕對的。所以，當軟件出現(xiàn)bug時，如何最大程度地降低維護成本是OEM（Original Equipment Manufacturer）最為關(guān)切的問題。相比Application程序或者Calibration程序的更新，Bootloater程序的更新成本更"高昂"，如何理解這里的"高昂"呢？這需要先從OEM升級Bootloader的痛點說起。

1、OEM升級Booloater程序的痛點

為什么OEM更新某個控制器的Bootloater程序更"痛苦"呢？搞清楚這個問題，就得從OEM的視角去看問題，OEM作為主機廠，生產(chǎn)的每一輛車，其實可以看作成千上萬商品的組裝。這里的商品包括大量供應(yīng)商的產(chǎn)品。比如：某供應(yīng)商A的控制器A，而供應(yīng)商A的控制器A中，需要提前預刷Bootloader，之后由OEM刷寫對應(yīng)的Application、Calibration等軟件程序。所以，從OEM視角看產(chǎn)品：產(chǎn)品A = 控制器A硬件+Bootloader程序。OEM為了維護和追蹤產(chǎn)品，當車輛下線時，伴隨車輛的產(chǎn)品A批次會分配唯一的"總成號"。這也就意味著，如果產(chǎn)品A批次出現(xiàn)硬件或者Bootloader迭代，則需要重新分配一個總成號。供應(yīng)商某批次控制器交付OEM，到OEM刷寫軟件的流程，示意如下:

提示：車輛下線時，總成號通過診斷服務(wù)寫入。

對于OEM來說，每次從供應(yīng)商拿到產(chǎn)品就需要先確認產(chǎn)品的批次，如果控制器硬件+Bootloader沒有變更，則認為是同一批次產(chǎn)品。如果供應(yīng)商對控制器硬件或者Bootloader做了升級，OEM則認為產(chǎn)品有迭代，如此，則需要為新的產(chǎn)品分配總成號，同時，OEM工廠會產(chǎn)生"生成斷點"。如何理解生產(chǎn)斷點呢？如果產(chǎn)品沒有迭代之前，OEM所拿到的產(chǎn)品為A批次，供應(yīng)商產(chǎn)品更新后，OEM拿到的產(chǎn)品為B批次，這就意味著之前車輛裝配的產(chǎn)品為A批次，之后車輛裝配的產(chǎn)品為B批次，如此，OEM的車輛或者庫存中就會存在兩種產(chǎn)品，進而就形成了產(chǎn)品斷點，示意如下所示：

形成產(chǎn)品斷點會帶來怎樣的市場影響呢？如果是控制器產(chǎn)品硬件或者Bootloader問題，且影響駕/乘人員安全，則意味著產(chǎn)品需要召回，或者需要進行遠程升級，修復軟件Bug。如果產(chǎn)品召回，則意味著OEM需要承擔召回的成本開銷，這里的開銷不單單是一個產(chǎn)品替換的成本，還會涉及售后、維修人員等費用開銷。而且產(chǎn)品斷點還會帶來產(chǎn)品管控的風險，舉例：由于產(chǎn)品批次混淆，在OEM產(chǎn)線端，可能出現(xiàn)新下線車輛裝錯產(chǎn)品批次問題。

本文討論Bootloader出現(xiàn)問題如何解決，或者說是否有更好的方案避免產(chǎn)品斷點問題。

Bootloader本身就屬于軟件范疇，只是因為從OEM角度，將其看作產(chǎn)品的一部份。按照OEM的生產(chǎn)處理流程，如果Bootloader出問題，且必須升級時，則OEM一定需要為修復的產(chǎn)品批次分配總成號，進而出現(xiàn)產(chǎn)品斷點。所以，產(chǎn)品斷點的原因之一是因為Bootloader和總成號綁定，深度耦合。如果Bootloader程序不與總成號綁定，像Application或者Calibration那樣，出現(xiàn)bug，隨時更新，是否就不會形成產(chǎn)品斷點呢？答：是的。

2、避免產(chǎn)品斷點方案

（一）方案一

既然Bootloader改動需要重新分配總成號，是否可以在軟件中將總成號與Bootloadr程序解綁？答：可以。在軟件層面，將總成號單獨拆分出來，放在某固定區(qū)域（該區(qū)域不隨著Bootloader更新而改動），只要OEM分配一次總成號即可。在軟件的角度，此處的PBL（Primary Bootloader）與總成號綁定，PBL只起到跳轉(zhuǎn)作用。由于總成號不再修改，OEM工廠也就認為Bootloader永遠不用修改，即：產(chǎn)品不會形成斷點。同時，將原有的PBL升級功能放到內(nèi)存的其他區(qū)域，與App、Cal等軟件程序同等處理，當更新程序出問題時，按照App流程更新即可。方案示意如下：

核心點：將原有的PBL功能進行拆分，將容易出問題的功能獨立出來，等同于App處理，不與總成號綁定。

（二）方案二

工程中，PBL出問題，很多時候是因為路由子節(jié)點、隊列刷寫、并行刷寫造成的。如果將PBL中的這些功能移交給SBL（Secondary Bootloader）處理，也就意味著PBL出現(xiàn)問題的概率極大降低，進而降低總成號分配頻次，避免形成過多的產(chǎn)品斷點。因為SBL本身放在RAM區(qū)，即使每次修改也不會帶來額外影響，示意如下：

其實，不管方案一、方案二還是其它方案，最終都需要考慮對整車測試、EE測試、OEM產(chǎn)線、OTA等各個環(huán)節(jié)的影響，盡量做到影響范圍最小，實施性最高。

延伸思考：當產(chǎn)品更新時，通過診斷服務(wù)（eg：$2E，Write Data By Identifier service）把總成號寫成一樣的不可以嗎？聽起來似乎很合理，但是，不可行。這涉及到產(chǎn)線（eg：EOL，End of Line）軟件結(jié)算維護問題，我們需要從工程流程化角度考慮，不能只盯著技術(shù)實現(xiàn)維度。