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

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

1、OEM升級Booloater程序的痛點(diǎn)

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

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

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

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

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

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

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

（一）方案一

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

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

（二）方案二

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

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

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