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

1、OEM升級Booloater程序的痛點

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

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

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

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

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

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

2、避免產品斷點方案

（一）方案一

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

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

（二）方案二

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

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

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