一、背景

整車基線管理，實質是整車的軟件版本管理問題，故事要從車廠的整車開發流程說起。車企均具有完整的整車開發流程，其貫穿了車型開發的生命周期，各家流程大同小異。以通用汽車經典的GVDP(Global Vehicle Development Process，整車開發流程)為例。



圖1 通用GVDP整車開發流程

GVDP將整車研發流程分為了多個階段，定義了各里程碑節點(G9~G1)。里程碑意味著本階段交付物的鎖定及下階段交付物的啟動。交付物包括 SOR 發布、數據發布，定點，送樣、認可，生產斷點、零部件版本的更新等，以整車零部件硬件作為單元，通過跨部門的團隊合作跟蹤零部件的誕生直至零部件最終成熟，從而協調、跟蹤和控制零件可用性，并保證零部件軟硬件狀態均滿足項目要求。

對零件的生命周期管理，大部分車廠采用PDM[1]+BOM[2]的系統方案，同時在PDM系統集成Catia、ProE等工程制圖軟件，將車型零件的工程數據和文檔聯系起來，實現對零件數據的組織、管理與控制。系統方案保證了工程、制造、售后等數據的一致性，支持各部門的高效協作，規范企業技術管理行為并實現流程制度化，提高了企業研發效率。

注釋：

[1] PDM(Product Data Management，產品數據管理)，提供規范的業務流程管理，文檔管理、CAD 集成管理、產品配置管理、設計變更管理等。縮短產品的設計周期，加快產品投入市場的進度。

[2] BOM(Bill of Material，物料清單)有的汽車企業也叫做零件俱樂部，是汽車生產企業的主導數據，貫穿從項目預言、立項、研發設計、試生產、正式生產制造到銷售以及售后服務的各個方面。



圖2 PDM/BOM零件生命周期管理

PDM/BOM系統中定義了整車結構樹的概念。整車結構樹由各零件總成組成，硬件、軟件、配置文件等作為零件總成下的子節點，如圖3所示。



圖3 整車結構樹

由于軟件為零件總成的子節點，同時車型配置信息和零件硬件具備關聯關系，因此控制器的軟件變更和管理依賴零件進行，識別高低配車輛的不同控制器軟件亦通過車型的硬件配置實現。

二、問題起源

在軟件定義汽車熱潮前，先前整車開發流程和零件生命周期管理有序保證了整車零件軟硬件的順利開發和量產。例如GVDP要求，G3（預試生產）閥點前必須鎖定零件的狀態，即凍結零件的硬軟件信息。由于先前車型的功能簡單，軟件相對獨立，代碼量少。SOP后亦無新需求迭代。因此軟件會隨硬件于同一節點凍結，并在產線一次性交付。

然而近幾年隨著車聯、智駕、座艙等新功能興起，整車電子架構日新月異，控制器數量大幅增加，SOP后的軟件頻繁迭代，車企必須實施整車軟硬件的開發流程并行管理，整車物理結構與整車功能有效解耦迫在眉睫。傳統車企的整車開發流程缺乏用戶使用階段軟件迭代的規范定義，導致不少車企在實際運營過程中遇到較大的困難，典型的問題有如下四個：

1、軟件無整車級別的流程管控，致使軟件需求階段、開發階段、驗證測試階段、發布階段均運營無序。例如各控制器版本發布日期、產線斷點日期無法統一，不僅整車功能集成和兼容性測試的嚴謹性受到挑戰，斷點時間不同導致的下線車輛版本不一致會使車輛版本碎片化嚴重，影響功能正常使用。

2、弱化下游業務（FOTA、線下診斷儀刷寫、工廠刷寫等）的運營效率。由于BOM中無整車軟件之間版本依賴關聯關系，使得在FOTA和線下刷寫平臺上軟件配置、車輛識別等工作經常需要通過硬件配置關聯，給升級任務配置帶來了難度。

3、無法滿足日趨嚴苛的汽車軟件更新法規。國標草案《汽車軟件升級通用技術要求》、WP29/UN R156等國內外法規條文均規定，升級管理體系建設應具備唯一的軟件識別碼，該識別碼在每次升級完成后更新，標識準入或認證相關系統所有初始和更新版本的軟件，并能識別軟件版本的一致性。

4、由于缺乏整車功能層面和軟件的關聯關系，用戶車輛版本碎片化嚴重，后續功能可售或訂閱實現只能通過硬件綁定，增加了實現難度。筆者曾服務于一家傳統車企的軟件可售項目，核心問題在于單車的可售范圍、功能的上下架管理。如沒有相關系統的建設，極大影響商品的露出策略和部署實施。

三、解決方案

針對上述問題，車企進行著流程的優化和變革，加強整車生命周期內軟件開發的協同管理，保證整車狀態可控、計劃有序，整車軟件新版本可以及時分步實施。并期望通過系統的自動化管理，解決線下材料的繁瑣和不穩定性。 傳統車企的軟件管理模式仍以控制器為顆粒度，一般由零件工程師提出發版需求，軟件發布小組或工程支持部門人為控制管理發布流程。

在轉型全新車型和電子架構的開發過程中容易導致運營混亂，例如A車型的TBOX在量產后有新版本需求，由零件工程師發起軟件發布流程，整車功能測試通過后發起OTA流程。零件工程師根據斷點時間線下提供車輛清單至OTA運營。如有其他控制器亦提出了發布需求，需由OTA運營決定是否加入本次任務。

而一旦有多個控制器加入，用戶車輛的版本碎片化問題凸顯，一般需要按車輛版本分組，或是通過多個OTA任務，才能實現用戶車輛的同步。



圖4 部分傳統車企的OTA運營流程

對于沒有歷史包袱新勢力車企，建立了初步的基線管理系統，并配套了相應的運營流程。基線管理是把整車的控制器軟件版本按照一定周期劃分基線。在節點到達時，根據當前釋放的各控制器軟件版本捏合成基線，并以基線發布為節點，整體管控整車各控制器軟件版本的需求、開發、測試、發布階段。

?

圖5 整車基線示例

在基線的集成測試和兼容性測試通過后，鎖定發布基線至下游系統，FOTA、售后診斷刷寫系統獲取基線數據，根據單車配置計算本次任務的軟件包。 目前，國內也有相對成熟的方案，如艾拉比的VSP[3]，不僅為傳統車企實現了整車基線管理，通過建設完整的軟件運營流程和系統，將數據在研發設計、質量、銷售、售后跨部門之間同步與共享。

更以功能為核心將場景功能基線對齊，為軟件可售的運營管理提供基礎支撐；串聯車企內部的FOTA系統、售后質量及智能診斷系統，建立軟件BOM和軟件倉庫，彌補PDM/BOM體系對于軟件管理的不足；并打造軟件升級SUMS體系并匹配國家監管，支持海外市場法規政策。

?

注釋：

[3] VSP是一款艾拉比自主研發的面向軟件定義汽車和新一代整車EE架構下的汽車軟件協同管理平臺，管理汽車ECU固件包、功能配置、整車基線、應用軟件、診斷數據庫、廣告、主題皮膚等內容。可解決軟件定義時代軟件升級通道多需要同源管理、軟件種類多需要統一的分層管理、車主觸點豐富需要統一體驗、汽車生命周期數字資產需要統一管理四大痛點。實現汽車軟件內容從研發、試制、生產、售后的全生命周期管理。

四、總結

對于車企而言，基線管理流程的建立，解決了整車軟件開發發布的問題，使汽車成為具有生命力的產品，有效解耦整車軟硬件開發流程，實現了車輛全生命周期持續迭代。 未來整車功能的定義與實現必將通過軟件驅動，為了支撐軟件多樣化開發與部署，真正達到軟件定義汽車，基線管理的內容還將繼續豐富和拓展。





審核編輯：劉清