01 背景

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

圖1 通用GVDP整車開發(fā)流程

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

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

注釋：

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

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

圖3 整車結構樹

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

02 問題起源

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

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

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

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

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

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

03 解決方案

針對上述問題，車企進行著流程的優(yōu)化和變革，加強整車生命周期內軟件開發(fā)的協(xié)同管理，保證整車狀態(tài)可控、計劃有序，整車軟件新版本可以及時分步實施。并期望通過系統(tǒng)的自動化管理，解決線下材料的繁瑣和不穩(wěn)定性。

傳統(tǒng)車企的軟件管理模式仍以控制器為顆粒度，一般由零件工程師提出發(fā)版需求，軟件發(fā)布小組或工程支持部門人為控制管理發(fā)布流程。在轉型全新車型和電子架構的開發(fā)過程中容易導致運營混亂，例如A車型的TBOX在量產后有新版本需求，由零件工程師發(fā)起軟件發(fā)布流程，整車功能測試通過后發(fā)起OTA流程。

零件工程師根據斷點時間線下提供車輛清單至OTA運營。如有其他控制器亦提出了發(fā)布需求，需由OTA運營決定是否加入本次任務。而一旦有多個控制器加入，用戶車輛的版本碎片化問題凸顯，一般需要按車輛版本分組，或是通過多個OTA任務，才能實現(xiàn)用戶車輛的同步。

圖4 部分傳統(tǒng)車企的OTA運營流程

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

圖5 整車基線示例

在基線的集成測試和兼容性測試通過后，鎖定發(fā)布基線至下游系統(tǒng)，F(xiàn)OTA、售后診斷刷寫系統(tǒng)獲取基線數據，根據單車配置計算本次任務的軟件包。

面對各家車企日益增長的需求，艾拉比的VSP[3]不僅為傳統(tǒng)車企實現(xiàn)了整車基線管理，通過建設完整的軟件運營流程和系統(tǒng)，將數據在研發(fā)設計、質量、銷售、售后跨部門之間同步與共享。更以功能為核心將場景功能基線對齊，為軟件可售的運營管理提供基礎支撐；串聯(lián)車企內部的FOTA系統(tǒng)、售后質量及智能診斷系統(tǒng)，建立軟件BOM和軟件倉庫，彌補PDM/BOM體系對于軟件管理的不足；并打造軟件升級SUMS體系并匹配國家監(jiān)管，支持海外市場法規(guī)政策。

注釋：

VSP是一款艾拉比自主研發(fā)的面向軟件定義汽車和新一代整車EE架構下的汽車軟件協(xié)同管理平臺，管理汽車ECU固件包、功能配置、整車基線、應用軟件、診斷數據庫、廣告、主題皮膚等內容?？山鉀Q軟件定義時代軟件升級通道多需要同源管理、軟件種類多需要統(tǒng)一的分層管理、車主觸點豐富需要統(tǒng)一體驗、汽車生命周期數字資產需要統(tǒng)一管理四大痛點。實現(xiàn)汽車軟件內容從研發(fā)、試制、生產、售后的全生命周期管理，是汽車行業(yè)面向工業(yè)4.0轉型、實現(xiàn)價值鏈轉移的數字化基礎設施，也是實現(xiàn)千車千面的數字化基礎設施。艾拉比的VSP解決方案以軟件基線為核心，為OEM提供智能軟件全生命周期管理設計研發(fā)運維運營服務，協(xié)助OEM進行智能軟件自主管控升級內容與版本。

04 總結

對于車企而言，基線管理流程的建立，解決了整車軟件開發(fā)發(fā)布的問題，使汽車成為具有生命力的產品，有效解耦整車軟硬件開發(fā)流程，實現(xiàn)了車輛全生命周期持續(xù)迭代。

未來整車功能的定義與實現(xiàn)必將通過軟件驅動，為了支撐軟件多樣化開發(fā)與部署，真正達到軟件定義汽車，基線管理的內容還將繼續(xù)豐富和拓展。

審核編輯：劉清