一、問題來源

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

GVDP將整車開發(fā)歸納為五個(gè)階段：架構(gòu)階段、戰(zhàn)略階段、概念階段、開發(fā)階段、產(chǎn)品及生產(chǎn)成熟階段。而每個(gè)階段又分別定義了相應(yīng)的“里程碑”節(jié)點(diǎn)?！袄锍瘫币馕吨囬_發(fā)工作階段性結(jié)束，同時(shí)意味著下一階段的開始?！袄锍瘫蓖舶殡S著本階段交付物的鎖定及下階段交付物的啟動(dòng)。




主機(jī)廠DRE（Design Release Engineer）們的零件開發(fā)工作會(huì)嚴(yán)格按照GVDP定義的階段及節(jié)點(diǎn)按部就班完成。整車項(xiàng)目經(jīng)理和VSE（Vehicle System Engineer）們同樣以此制定工作計(jì)劃，在相應(yīng)的整車閥點(diǎn)收集并審核DRE們提供的交付物，包括但不局限于樣件、設(shè)計(jì)文檔、臺(tái)架整車測試結(jié)果、最終的量產(chǎn)件。

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

在新四化的熱潮尚未開始前，該管理模式有序保證了整車的順利開發(fā)和量產(chǎn)。對(duì)于涉及軟件的控制器或執(zhí)行器，一般硬件供應(yīng)商同為軟件供應(yīng)商，功能范圍相對(duì)穩(wěn)定因而軟件代碼量較少，硬件和軟件可按GVDP的節(jié)點(diǎn)要求統(tǒng)一測試和交付。在G3（預(yù)試生產(chǎn)）閥點(diǎn)前即可鎖定零件的狀態(tài)，在SOP（Start of Production，正式生產(chǎn)）后繼續(xù)迭代的可能性較小。

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

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

對(duì)于當(dāng)前整車分布式電子電氣架構(gòu)及過渡階段的域架構(gòu)，新開發(fā)的車型都將擁有幾十個(gè)控制器，各供應(yīng)商的能力參差不齊導(dǎo)致了開發(fā)周期大相徑庭，各控制器斷點(diǎn)時(shí)間的不一致導(dǎo)致了交付的整車版本碎片化嚴(yán)重，碎片化的整車版本嚴(yán)重不利于整車的功能測試和驗(yàn)證。

二、解決方案

為了解決上述問題，同時(shí)加強(qiáng)整車生命周期內(nèi)軟件開發(fā)的協(xié)同管理，保證整車狀態(tài)可控、計(jì)劃有序，整車軟件新版本可以及時(shí)分步實(shí)施，不少主機(jī)廠尤其是新勢力廠商都制定了整車基線管理。

整車基線管理是把整車的控制器軟件版本按照周期劃分基線。在節(jié)點(diǎn)到達(dá)時(shí)，根據(jù)當(dāng)前釋放的各控制器軟件版本捏合成基線，以此作為基準(zhǔn)進(jìn)行集成測試和兼容性測試。測試通過后，鎖定并發(fā)布基線。

基線管理流程可基于GVDP的流程，對(duì)于GVDP中定義的閥點(diǎn)，如EP、PPV、PP、P、SOP等，均可定義為整車基線節(jié)點(diǎn)，對(duì)網(wǎng)絡(luò)診斷、整車功能的成熟度進(jìn)行定義。隨著整車SOP后的持續(xù)運(yùn)營，基線計(jì)劃可根據(jù)需求，根據(jù)FIP的持續(xù)迭代，定期更新發(fā)布。大致的運(yùn)營流程如下圖所示。 ?

車廠的基線小組需要在整車層面制定整車軟件基線的需求、開發(fā)計(jì)劃，并將計(jì)劃輸出給各控制器端，統(tǒng)一在某一節(jié)點(diǎn)交付當(dāng)期基線的軟件，并在測試驗(yàn)證通過后發(fā)布，通過OTA或者線下刷寫的方式應(yīng)用新版基線。

三、遺留問題

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

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

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

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

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

（4）隨著運(yùn)營的深入，跨基線升級(jí)帶來的開發(fā)和測試工作量。

四、寫在最后

綜上所述，對(duì)于OTA運(yùn)營，隨著整車基線管理的成熟，勢必將由點(diǎn)到面，不再以控制器的顆粒度去運(yùn)營，而將捏合成整車基線的控制器組，以整車功能的迭代計(jì)劃作為基準(zhǔn)，整體去迭代或者統(tǒng)一回滾，真正實(shí)現(xiàn)整車軟件的生命周期管理。

審核編輯：劉清