一、問題來源

故事要從主機廠的整車開發流程說起。目前國內各大主機廠基本沿用通用汽車的GVDP(Global Vehicle Development Process，整車開發流程)來定義自己的整車開發計劃。GVDP作為汽車領域最廣為人知的開發流程之一，貫穿了車型開發的整個生命周期。

GVDP將整車開發歸納為五個階段：架構階段、戰略階段、概念階段、開發階段、產品及生產成熟階段。而每個階段又分別定義了相應的“里程碑”節點?！袄锍瘫币馕吨囬_發工作階段性結束，同時意味著下一階段的開始?！袄锍瘫蓖舶殡S著本階段交付物的鎖定及下階段交付物的啟動。




主機廠DRE（Design Release Engineer）們的零件開發工作會嚴格按照GVDP定義的階段及節點按部就班完成。整車項目經理和VSE（Vehicle System Engineer）們同樣以此制定工作計劃，在相應的整車閥點收集并審核DRE們提供的交付物，包括但不局限于樣件、設計文檔、臺架整車測試結果、最終的量產件。

至于工程管理系統架構，主要由BOM（Bill of Material，物料清單）、PDM(Product Data Management，產品數據管理)等子系統構成。在這些子系統中，一般會以零件的LOU(Line of Usage)信息作為整車零件的管理顆粒度，零件的硬件和軟件序號和信息在PDM中均掛在該零件總成下。DRE牽頭零件工程更改的過程中，同樣會以這個零件總成號和相應的LOU向整車項目組提交更改方案和費用。

在新四化的熱潮尚未開始前，該管理模式有序保證了整車的順利開發和量產。對于涉及軟件的控制器或執行器，一般硬件供應商同為軟件供應商，功能范圍相對穩定因而軟件代碼量較少，硬件和軟件可按GVDP的節點要求統一測試和交付。在G3（預試生產）閥點前即可鎖定零件的狀態，在SOP（Start of Production，正式生產）后繼續迭代的可能性較小。

然而近幾年軟件定義汽車的熱潮涌動，伴隨著網聯、智駕功能的蓬勃發展，軟件的開發和迭代日益復雜，交付逐步與硬件分離。整車的一些域控制器，比如常見的ADAS，在實際的開發過程中，會由多家供應商和主機廠一起協同開發。 例如，硬件由A供應商提供，底層軟件發包給B供應商，應用層軟件定點至第三家供應商C。一些應用層的支持功能，例如FOTA，也會選擇開發經驗更豐富的供應商D，甚至于測試臺架或者人力也會外包給供應商E協作完成。

這樣便會給控制器的開發和軟件的集成和測試帶來巨大的挑戰，很多控制器無法在SOP前完成所有功能的開發和測試驗收，不少功能和BUG需要在車輛下線后去迭代。這一軟件版本發布的現狀對原有的GVDP開發流程也帶來了變化，流程中尚未定義對于控制器軟件版本快速迭代的管理方案，也沒有定義SOP后軟件發版流程。

對于當前整車分布式電子電氣架構及過渡階段的域架構，新開發的車型都將擁有幾十個控制器，各供應商的能力參差不齊導致了開發周期大相徑庭，各控制器斷點時間的不一致導致了交付的整車版本碎片化嚴重，碎片化的整車版本嚴重不利于整車的功能測試和驗證。

二、解決方案

為了解決上述問題，同時加強整車生命周期內軟件開發的協同管理，保證整車狀態可控、計劃有序，整車軟件新版本可以及時分步實施，不少主機廠尤其是新勢力廠商都制定了整車基線管理。

整車基線管理是把整車的控制器軟件版本按照周期劃分基線。在節點到達時，根據當前釋放的各控制器軟件版本捏合成基線，以此作為基準進行集成測試和兼容性測試。測試通過后，鎖定并發布基線。

基線管理流程可基于GVDP的流程，對于GVDP中定義的閥點，如EP、PPV、PP、P、SOP等，均可定義為整車基線節點，對網絡診斷、整車功能的成熟度進行定義。隨著整車SOP后的持續運營，基線計劃可根據需求，根據FIP的持續迭代，定期更新發布。大致的運營流程如下圖所示。 ?

車廠的基線小組需要在整車層面制定整車軟件基線的需求、開發計劃，并將計劃輸出給各控制器端，統一在某一節點交付當期基線的軟件，并在測試驗證通過后發布，通過OTA或者線下刷寫的方式應用新版基線。

三、遺留問題

上文主要論述的是基線管理的需求來源和總體方案。隨著OTA在各主機廠落地，極大改變了車輛軟件迭代的方式。主機廠的整車基線管理勢必與OTA的運營管理緊密相關，OTA的運營流程作為整車基線發布的下游，需要按著基線的節拍去實施。

主機廠希望通過OTA迭代整車基線，并作為基線管理的主要手段。但對于目前尚不穩定的FOTA能力和流程的缺失，仍有如下問題待主機廠根據自己的實際情況解決：

（1）對于多配置或者具有高低配零件的車型，整車基線的定義方式；

（2）對于不具備FOTA能力或者FOTA失敗風險較大的控制器，如何通過OTA+線下刷寫的方式共同拉齊整車基線；

（3）控制器售后換件或異常刷寫導致整車基線異常的拉齊策略；

（4）隨著運營的深入，跨基線升級帶來的開發和測試工作量。

四、寫在最后

綜上所述，對于OTA運營，隨著整車基線管理的成熟，勢必將由點到面，不再以控制器的顆粒度去運營，而將捏合成整車基線的控制器組，以整車功能的迭代計劃作為基準，整體去迭代或者統一回滾，真正實現整車軟件的生命周期管理。

審核編輯：劉清