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

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

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

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

提示：車(chē)輛下線時(shí)，總成號(hào)通過(guò)診斷服務(wù)寫(xiě)入。

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

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

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

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

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

（一）方案一

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

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

（二）方案二

工程中，PBL出問(wèn)題，很多時(shí)候是因?yàn)槁酚勺庸?jié)點(diǎn)、隊(duì)列刷寫(xiě)、并行刷寫(xiě)造成的。如果將PBL中的這些功能移交給SBL（Secondary Bootloader）處理，也就意味著PBL出現(xiàn)問(wèn)題的概率極大降低，進(jìn)而降低總成號(hào)分配頻次，避免形成過(guò)多的產(chǎn)品斷點(diǎn)。因?yàn)镾BL本身放在RAM區(qū)，即使每次修改也不會(huì)帶來(lái)額外影響，示意如下：

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

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