整車軟件開發(fā)流程介紹

一、背景

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



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

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

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

注釋：

[1] PDM(Product Data Management，產(chǎn)品數(shù)據(jù)管理)，提供規(guī)范的業(yè)務(wù)流程管理，文檔管理、CAD 集成管理、產(chǎn)品配置管理、設(shè)計變更管理等?？s短產(chǎn)品的設(shè)計周期，加快產(chǎn)品投入市場的進度。

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



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

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



圖3 整車結(jié)構(gòu)樹

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

二、問題起源

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

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

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

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

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

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

三、解決方案

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

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

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



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

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

?

圖5 整車基線示例

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

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

?

注釋：

[3] VSP是一款艾拉比自主研發(fā)的面向軟件定義汽車和新一代整車EE架構(gòu)下的汽車軟件協(xié)同管理平臺，管理汽車ECU固件包、功能配置、整車基線、應(yīng)用軟件、診斷數(shù)據(jù)庫、廣告、主題皮膚等內(nèi)容?？山鉀Q軟件定義時代軟件升級通道多需要同源管理、軟件種類多需要統(tǒng)一的分層管理、車主觸點豐富需要統(tǒng)一體驗、汽車生命周期數(shù)字資產(chǎn)需要統(tǒng)一管理四大痛點。實現(xiàn)汽車軟件內(nèi)容從研發(fā)、試制、生產(chǎn)、售后的全生命周期管理。

四、總結(jié)

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





審核編輯：劉清