隨著軟件定義汽車(chē)（SDV: Software-Defined Vehicles）技術(shù)的快速發(fā)展，汽車(chē)產(chǎn)業(yè)正經(jīng)歷從傳統(tǒng)機(jī)械時(shí)代向電動(dòng)化、智能化時(shí)代的深刻變革。軟件在汽車(chē)中的比重顯著提升，軟件能力已成為車(chē)企核心競(jìng)爭(zhēng)力的關(guān)鍵要素。

相較于汽車(chē)機(jī)械和硬件領(lǐng)域業(yè)已成熟的研發(fā)體系，汽車(chē)電子軟件的研發(fā)流程尚存在明顯差距?，F(xiàn)階段，汽車(chē)軟件研發(fā)還未構(gòu)建起嚴(yán)謹(jǐn)?shù)馁|(zhì)量管理體系以及標(biāo)準(zhǔn)化的開(kāi)發(fā)流程，其開(kāi)發(fā)模式常常具有臨時(shí)性與分散化的特點(diǎn)，這種模式也被形容為“草臺(tái)班子”，“小作坊”式。這種"小作坊"式的開(kāi)發(fā)模式直接導(dǎo)致了軟件質(zhì)量的波動(dòng)性和不可預(yù)測(cè)性，給汽車(chē)軟件帶來(lái)了潛在風(fēng)險(xiǎn)。

本文將探討汽車(chē)軟件研發(fā)面臨的主要問(wèn)題與挑戰(zhàn)，以及行之有效的應(yīng)對(duì)之法。

一、汽車(chē)軟件研發(fā)面臨的主要問(wèn)題  

眾所周知, 在機(jī)械燃油時(shí)代，汽車(chē)功能的復(fù)雜度相對(duì)較低，各個(gè)控制器都是獨(dú)立開(kāi)發(fā)，軟硬一體，軟件功能很有限，因此這種軟件開(kāi)發(fā)方式并沒(méi)有明顯的問(wèn)題。

但在智能化時(shí)代，汽車(chē)功能呈現(xiàn)爆發(fā)式增長(zhǎng)，汽車(chē)電子電氣架構(gòu)也從分布式獨(dú)立控制逐步走向了集中式中央控制器模式。

汽車(chē)軟件的復(fù)雜度也指數(shù)級(jí)增長(zhǎng)，據(jù)統(tǒng)計(jì)，當(dāng)前一輛具備 L2++ 智能輔助駕駛的汽車(chē), 純軟件代碼量就超過(guò)了 1 億行，遠(yuǎn)超傳統(tǒng)燃油車(chē)時(shí)代的規(guī)模。

隨著市場(chǎng)競(jìng)爭(zhēng)加劇，車(chē)企整車(chē)項(xiàng)目研發(fā)周期從48個(gè)月縮至18個(gè)月。在巨大時(shí)間壓力下，汽車(chē)軟件研發(fā)面臨嚴(yán)峻挑戰(zhàn)，許多軟件未經(jīng)全面測(cè)試就匆忙上車(chē)，期望通過(guò)OTA升級(jí)解決質(zhì)量問(wèn)題。但這種做法過(guò)于理想化，既無(wú)法確保軟件可靠性，還可能引發(fā)潛在安全風(fēng)險(xiǎn)。

據(jù)相關(guān)數(shù)據(jù)顯示，近些年由于軟件問(wèn)題引發(fā)的召回事件，占車(chē)企所有召回事件的 30% 以上。

和電子消費(fèi)品不同，汽車(chē)軟件質(zhì)量直接關(guān)乎駕駛員及道路參與者的人身安全，必須引起足夠重視！

只有了解汽車(chē)軟件質(zhì)量問(wèn)題頻發(fā)的根源，才能更好地進(jìn)行針對(duì)性的解決。軟件質(zhì)量問(wèn)題往往不容易量化和度量，管理者缺乏有效手段來(lái)洞察系統(tǒng)中潛在的質(zhì)量隱患，因而難以做出客觀的決策，常常陷入“頭痛醫(yī)頭，腳痛醫(yī)腳”的被動(dòng)局面。

汽車(chē)軟件質(zhì)量問(wèn)題的根源主要體現(xiàn)在以下幾個(gè)方面：

1. 汽車(chē)軟件代碼規(guī)模與復(fù)雜度激增

隨著汽車(chē)智能化的發(fā)展，軟件代碼量呈指數(shù)級(jí)增長(zhǎng)，復(fù)雜度也隨之大幅提升。代碼規(guī)模越大、邏輯越復(fù)雜，出現(xiàn)漏洞和缺陷的可能性就越高，這對(duì)軟件質(zhì)量提出了嚴(yán)峻挑戰(zhàn)。

2. 軟件開(kāi)發(fā)缺乏統(tǒng)一標(biāo)準(zhǔn)

盡管軟件行業(yè)中存在 CMMI（能力成熟度模型集成）和 ASPICE（汽車(chē)軟件過(guò)程改進(jìn)與能力評(píng)定）等過(guò)程能力模型，但這些標(biāo)準(zhǔn)在實(shí)際應(yīng)用中缺乏具體指導(dǎo)。傳統(tǒng)的 V 模型靈活性不足，難以應(yīng)對(duì)快速迭代的需求；而 Agile 模型雖然靈活，卻無(wú)法完全滿(mǎn)足汽車(chē)行業(yè)對(duì)合規(guī)性、質(zhì)量與安全的嚴(yán)格要求。

3. OEM與供應(yīng)商合作中的質(zhì)量管控問(wèn)題    

主機(jī)廠對(duì)供應(yīng)商的質(zhì)量管控能力不足，導(dǎo)致在系統(tǒng)集成階段容易出現(xiàn)兼容性和完整性問(wèn)題。此外，供應(yīng)商通常采用黑盒交付模式，使得軟件系統(tǒng)的可追溯性較差，問(wèn)題定位耗時(shí)且效率低下。

4. 質(zhì)量保證未貫穿軟件開(kāi)發(fā)全生命周期 

主機(jī)廠仍沿用傳統(tǒng)的測(cè)試思維，將質(zhì)量保證集中在開(kāi)發(fā)后期的測(cè)試階段，依賴(lài)人力堆砌來(lái)解決問(wèn)題，而非基于“預(yù)防大于發(fā)現(xiàn)”的原則。這種模式難以應(yīng)對(duì)復(fù)雜軟件系統(tǒng)的質(zhì)量要求。

5. 軟件開(kāi)發(fā)過(guò)程不透明且缺乏數(shù)據(jù)驅(qū)動(dòng)

軟件開(kāi)發(fā)過(guò)程的有效性缺乏科學(xué)的評(píng)價(jià)手段和度量方法，主要依賴(lài)經(jīng)驗(yàn)主義，而非數(shù)據(jù)驅(qū)動(dòng)的決策思維。這種不透明性導(dǎo)致問(wèn)題難以及時(shí)發(fā)現(xiàn)和解決，進(jìn)一步加劇了質(zhì)量風(fēng)險(xiǎn)。

二、應(yīng)對(duì)質(zhì)量問(wèn)題的策略與實(shí)踐 

要解決這些問(wèn)題，必須從根源入手，通過(guò)透明化開(kāi)發(fā)過(guò)程、強(qiáng)化標(biāo)準(zhǔn)執(zhí)行和指導(dǎo)方法、優(yōu)化合作模式以及引入數(shù)據(jù)驅(qū)動(dòng)的質(zhì)量管理方法，構(gòu)建貫穿全生命周期的汽車(chē)軟件質(zhì)量保證體系，才能真正提升汽車(chē)軟件的質(zhì)量與可靠性。

基于上述的解決策略要點(diǎn)進(jìn)行歸類(lèi)后，我們可以圍繞 PPT (Process, Methods, Tools) 三個(gè)維度來(lái)構(gòu)建端到端汽車(chē)軟件研發(fā)質(zhì)量保障體系，系統(tǒng)性解決汽車(chē)軟件質(zhì)量問(wèn)題。

三、流程改進(jìn)

流程/過(guò)程質(zhì)量決定產(chǎn)出質(zhì)量，高效的研發(fā)流程是保障軟件質(zhì)量的基石。

汽車(chē)電子軟件研發(fā)涉及到軟硬件集成，大規(guī)模協(xié)作，供應(yīng)商管理等方方面面，一個(gè)ADAS系統(tǒng)開(kāi)發(fā)動(dòng)輒數(shù)百上千人的研發(fā)人員，也使得軟件研發(fā)管理的復(fù)雜度劇增。

但是隨著軟件復(fù)雜度的增加，軟件研發(fā)效率卻無(wú)法及時(shí)跟上節(jié)奏，復(fù)雜度與效率矛盾日益突出。          

汽車(chē)行業(yè)軟件開(kāi)發(fā)主要有以下三種主流的開(kāi)發(fā)模型：

車(chē)企需要基于不同的業(yè)務(wù)類(lèi)型和復(fù)雜度，選擇合適的開(kāi)發(fā)模式。深刻理解康威定律和復(fù)雜性理論，調(diào)整組織結(jié)構(gòu)和角色職責(zé)以適應(yīng)開(kāi)發(fā)模式。

以雙態(tài)開(kāi)發(fā)（Agile+V Model）為例，將 ASPICE 等合規(guī)性要求融入到具體的敏捷活動(dòng)中去，既滿(mǎn)足流程合規(guī)又能發(fā)揮敏捷開(kāi)發(fā)的作用。

四、方法實(shí)踐                      

僅僅有流程規(guī)范是遠(yuǎn)遠(yuǎn)不夠的，因?yàn)樵趯?shí)際操作過(guò)程中，動(dòng)作很容易會(huì)發(fā)生變形，只有有效且可落地的方法才能夠更好地滿(mǎn)足流程要求。CMMI 或者 V 模型之所以在車(chē)企軟件研發(fā)中越來(lái)越難提升質(zhì)量和效率，其根源就在于缺乏有效的質(zhì)量保障方法來(lái)進(jìn)行指導(dǎo)。

1.需求工程優(yōu)化  

有好的需求產(chǎn)出，項(xiàng)目就已經(jīng)成功了一半。

然而需求質(zhì)量低，是大部分車(chē)企面臨的主要痛點(diǎn)。需求階段主要的問(wèn)題有：需求不清晰，需求描述不規(guī)范，需求結(jié)構(gòu)混亂，需求的跟蹤管理失控等等。

需求階段我們通過(guò)需求的分層與結(jié)構(gòu)化，需求開(kāi)發(fā)與需求實(shí)施解耦等方式，來(lái)提升需求管理和需求傳遞的質(zhì)量。

2.架構(gòu)設(shè)計(jì)改進(jìn)  

設(shè)計(jì)階段，車(chē)企面臨的主要挑戰(zhàn)在于，如何確保設(shè)計(jì)的一致性，如何平衡設(shè)計(jì)與變更的工作量，以及如何進(jìn)行高效的設(shè)計(jì)。

因此，我們建議首先在架構(gòu)信息層面對(duì)齊認(rèn)知，優(yōu)化架構(gòu)設(shè)計(jì)方法與工具，引入高效的架構(gòu)治理實(shí)踐。

(1) 架構(gòu)信息模型

在復(fù)雜的項(xiàng)目中，統(tǒng)一架構(gòu)信息元素的概念非常重要，比如 Component 的定義，在不同的領(lǐng)域是不一樣的。保持所有人的認(rèn)知對(duì)齊，能夠更好地幫助管理架構(gòu)實(shí)施活動(dòng)。

(2) 軟件架構(gòu)設(shè)計(jì)

架構(gòu)設(shè)計(jì)在軟件開(kāi)發(fā)的整個(gè)生命周期中占據(jù)著舉足輕重的地位。它不僅關(guān)乎技術(shù)的實(shí)現(xiàn)，更直接影響到軟件的可維護(hù)性、可擴(kuò)展性和性能。一個(gè)精心設(shè)計(jì)的架構(gòu)能夠確保軟件在未來(lái)的迭代中保持靈活性和高效性。

通過(guò) Document as Code. Arch as Code的設(shè)計(jì)理念，構(gòu)建輕量化的架構(gòu)設(shè)計(jì)解決方案，并且引入持續(xù)架構(gòu)設(shè)計(jì)，演進(jìn)式架構(gòu)設(shè)計(jì)方法，C4 模型，架構(gòu)決策記錄 ADR，架構(gòu)評(píng)估委員會(huì) TAB等實(shí)踐，幫助組織高效管理架構(gòu)活動(dòng)，最大化架構(gòu)價(jià)值。

(3) 軟件詳細(xì)設(shè)計(jì)

在當(dāng)前敏捷開(kāi)發(fā)模式下，很難先完成詳細(xì)設(shè)計(jì)文檔基線后，然后再寫(xiě)代碼。但是也不能沒(méi)有詳細(xì)設(shè)計(jì)文檔，只有代碼。詳細(xì)設(shè)計(jì)不僅僅是車(chē)載軟件合規(guī)性的要求，也是后續(xù)軟件維護(hù)的重要保障。因此我們建議構(gòu)建持續(xù)增量式軟件詳細(xì)設(shè)計(jì)，同時(shí)詳細(xì)設(shè)計(jì)與編碼活動(dòng)交叉進(jìn)行，而不是瀑布模式下的前后線性關(guān)系。

增量式詳細(xì)設(shè)計(jì)關(guān)鍵特點(diǎn)：

①迭代式設(shè)計(jì)：

a.將詳細(xì)設(shè)計(jì)分解為多個(gè)迭代周期，每個(gè)周期都聚焦于一部分功能或模塊的設(shè)計(jì)。

b.在每個(gè)迭代周期結(jié)束時(shí)，確保設(shè)計(jì)文檔得到更新，并與代碼實(shí)現(xiàn)保持同步。

②最小化可行設(shè)計(jì)：

a.在設(shè)計(jì)初期，只關(guān)注最關(guān)鍵的設(shè)計(jì)決策和架構(gòu)元素，確保系統(tǒng)的基礎(chǔ)穩(wěn)定性。

b.隨著開(kāi)發(fā)的深入，逐步細(xì)化設(shè)計(jì)細(xì)節(jié)，添加必要的功能和優(yōu)化，滿(mǎn)足合規(guī)性要求。

③增量更新：

a.不試圖一次性編寫(xiě)完整的詳細(xì)設(shè)計(jì)文檔，而是隨著開(kāi)發(fā)的進(jìn)展逐步更新文檔。

b.使用版本控制系統(tǒng)來(lái)管理設(shè)計(jì)文檔的變更歷史，確保可追溯性。   

3. 編碼實(shí)踐規(guī)范  

基于大量的項(xiàng)目統(tǒng)計(jì)，編碼階段是引入缺陷最多的過(guò)程，其原因是多樣的，比如企業(yè)對(duì)于代碼內(nèi)部質(zhì)量的忽視，缺乏有效的編碼規(guī)范和度量工具，一次性代碼，沒(méi)有考慮后續(xù)的擴(kuò)展性，缺乏代碼審查機(jī)制等等。

基于此，車(chē)企需要加強(qiáng)對(duì)于編碼規(guī)范，代碼重構(gòu)與技術(shù)債管理，同行評(píng)審，質(zhì)量門(mén)禁等活動(dòng)的實(shí)踐。

(1) 編碼規(guī)范定義

車(chē)企需要基于業(yè)界通用的一些編碼標(biāo)準(zhǔn)（如 MISRA C/C++, AUTOSAR, CERT 等）和自身業(yè)務(wù)場(chǎng)景相結(jié)合，構(gòu)建自身的軟件編碼規(guī)范，并將規(guī)則固化到一些自動(dòng)化的代碼檢查工具中，對(duì)于無(wú)法自動(dòng)化檢測(cè)的規(guī)則，則需要納入代碼評(píng)審檢查表中，進(jìn)行人工的檢查和確認(rèn)，確保代碼規(guī)范被完全遵守。

(2) 代碼提交規(guī)范

汽車(chē)軟件開(kāi)發(fā)是大規(guī)模協(xié)作的過(guò)程，因此制定和遵守開(kāi)發(fā)紀(jì)律是一個(gè)合格開(kāi)發(fā)人員的基本素養(yǎng)。企業(yè)需要制定完善的代碼提交規(guī)范，確保代碼提交的規(guī)范化和可溯源性。同時(shí)我們可以通過(guò)工具來(lái)自動(dòng)檢測(cè)每一筆代碼提交是否滿(mǎn)足規(guī)范要求，做到自動(dòng)化審查。         

如：某車(chē)企非常重視代碼的回溯性，需要將需求和問(wèn)題單與代碼變更關(guān)聯(lián)起來(lái)。為此，該企業(yè)實(shí)施了一項(xiàng)措施，即對(duì)代碼提交信息（commit message）進(jìn)行標(biāo)準(zhǔn)化配置。當(dāng)開(kāi)發(fā)人員嘗試提交代碼時(shí)，系統(tǒng)會(huì)自動(dòng)驗(yàn)證提交信息中是否包含了需求或問(wèn)題單的唯一標(biāo)識(shí)ID。若提交信息中缺少I(mǎi)D，或者ID的格式不符合預(yù)設(shè)規(guī)范，系統(tǒng)將阻止代碼提交，從而確保每一次代碼變更都能準(zhǔn)確地追溯到相應(yīng)的需求或問(wèn)題單。

(3) 代碼門(mén)禁

借助MR（合并請(qǐng)求）、門(mén)禁自動(dòng)檢查以及 Code Review（代碼審核）來(lái)對(duì)研發(fā)流程予以一定的規(guī)范。所有的變更都必須經(jīng)由MR來(lái)提交，并且要通過(guò)流水線上的門(mén)禁代碼檢查，這其中涵蓋了靜態(tài)代碼檢查和單元檢查。只有當(dāng)至少兩位審核人員審核通過(guò)之后，變更后的代碼才被允許合并到代碼主干分支之中。

4. 分層驗(yàn)證體系   

車(chē)企在驗(yàn)證環(huán)節(jié)面臨的主要痛點(diǎn)是測(cè)試活動(dòng)覆蓋不全，測(cè)試周期太長(zhǎng)，問(wèn)題反饋太慢，測(cè)試資源不足等。

(1) 分層測(cè)試體系

我們建議車(chē)企構(gòu)建清晰明確的分層測(cè)試體系，明確每一層級(jí)測(cè)試的目標(biāo)和方法。

基于開(kāi)源軟件工具創(chuàng)建持續(xù)測(cè)試體系，在每一次軟件版本發(fā)版后自動(dòng)觸發(fā)。分別通過(guò)單元驗(yàn)證，組件集成測(cè)試，軟件測(cè)試、軟硬件集成測(cè)試、真實(shí)外設(shè)環(huán)境下的系統(tǒng)測(cè)試、整車(chē)測(cè)試。其中單元和組件測(cè)試是分鐘級(jí)別完成，硬件、系統(tǒng)與整車(chē)層面的測(cè)試能夠在天級(jí)別內(nèi)完成，從而加快各層級(jí)測(cè)試反饋。

(2) 測(cè)試有效性提升

在實(shí)踐中，我們常常收到一線開(kāi)發(fā)人員的反饋，單元測(cè)試和集成測(cè)試沒(méi)有效果，反而耗費(fèi)了大量的時(shí)間和精力等。這從側(cè)面反映了我們測(cè)試設(shè)計(jì)有效性不足以及對(duì)于測(cè)試認(rèn)知不足的問(wèn)題。

因此加強(qiáng)測(cè)試活動(dòng)，測(cè)試用例設(shè)計(jì)方法的培訓(xùn)與賦能，提升開(kāi)發(fā)人員測(cè)試用例編寫(xiě)能力，是車(chē)企需要重點(diǎn)建設(shè)的地方。

五、工具支撐                      

根據(jù)麥肯錫的研究，引入標(biāo)準(zhǔn)化工具鏈可以提升30-40%的組織生產(chǎn)力。

流程也需要工具支撐才能保證有效執(zhí)行，減少規(guī)則宣貫和人員跟進(jìn)的工時(shí)損耗，同時(shí)減少信息孤島。

1. 工具鏈搭建

好的需求、設(shè)計(jì)工具能夠幫助高效地管理需求與設(shè)計(jì)活動(dòng)，同時(shí)滿(mǎn)足流程合規(guī)性要求。

如基于 Arc42 模板和Structurizr、Asciidoctor 等工具鏈構(gòu)建的 document as code方式，能夠提高架構(gòu)師編寫(xiě)架構(gòu)文檔的效率，同時(shí)比傳統(tǒng)的Microsoft Word離線文檔方式，更便于架構(gòu)的版本管理，協(xié)作開(kāi)發(fā)等。

代碼建模工具能夠確保詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)的一致性，自動(dòng)化測(cè)試工具的引入也能夠極大提高回歸測(cè)試的效率。

2.構(gòu)建軟件工廠平臺(tái)

如何將分散的工具鏈有機(jī)結(jié)合起來(lái)，需要從全局端到端的角度進(jìn)行系統(tǒng)性的汽車(chē)軟件研發(fā)DevOps 平臺(tái)設(shè)計(jì)，打通工具鏈，構(gòu)造研發(fā)組織級(jí)統(tǒng)一的 Software Factory。

同時(shí)基于安全內(nèi)建（Built-in Security）與性能內(nèi)建 (Built-in Performance)的理念，將安全與性能要求和活動(dòng)融入到汽車(chē)研發(fā) DevOps 端到端全流程中。

3. 數(shù)據(jù)驅(qū)動(dòng)質(zhì)量改進(jìn)

改進(jìn)才是目標(biāo)，度量只是手段。基于數(shù)據(jù)建模方法構(gòu)建度量指標(biāo)體系，結(jié)構(gòu)化研發(fā)過(guò)程數(shù)據(jù)和產(chǎn)品質(zhì)量數(shù)據(jù)。通過(guò)不斷沉淀研發(fā)活動(dòng)數(shù)據(jù)，建立統(tǒng)一的數(shù)據(jù)看板 Quality KPI Dashboard, 將研發(fā)質(zhì)量透明化, 可視化。

構(gòu)建質(zhì)量數(shù)據(jù)運(yùn)營(yíng)機(jī)制，如指標(biāo)趨勢(shì)分析，TOPN 問(wèn)題根因與改進(jìn)等等，可以幫助組織更好地利用數(shù)據(jù)，診斷問(wèn)題，度量成效，指導(dǎo)改進(jìn)。

以下表評(píng)估代碼質(zhì)量為例，基于 GQM 的度量方法，設(shè)計(jì)相應(yīng)的度量指標(biāo)。

除了代碼質(zhì)量指標(biāo)以外，還有過(guò)程性能指標(biāo)，架構(gòu)指標(biāo)等其他維度，這里不做列舉。

六、持續(xù)改進(jìn)與以人為本  

策略與方法是基礎(chǔ)，但僅有策略和方法，是不夠的，只有行動(dòng)起來(lái)，從實(shí)踐中持續(xù)獲取反饋并調(diào)整改進(jìn)，才是解決問(wèn)題的根本之道。    

軟件定義汽車(chē)所引發(fā)的挑戰(zhàn)涵蓋了各個(gè)方面：包括思想觀念、技術(shù)水平、工作流程、方法策略以及工具應(yīng)用等。車(chē)企只有不斷的迭代和創(chuàng)新，充分利用新技術(shù)，新范式，如 AI4SE, LLM 大模型等手段不斷進(jìn)行工程實(shí)踐（如輔助需求編寫(xiě)，業(yè)務(wù)代碼和測(cè)試用例生成等），才能從容應(yīng)對(duì)當(dāng)下的不確定性和復(fù)雜性。

最后，也是最重要的一點(diǎn)，軟件研發(fā)仍然是人的創(chuàng)造性活動(dòng)過(guò)程，因此所有的流程，方法設(shè)計(jì)均要以人為本，提升人的主觀能動(dòng)性，這是確保組織目標(biāo)達(dá)成的關(guān)鍵。