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

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

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

一、汽車軟件研發(fā)面臨的主要問題  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、流程改進(jìn)

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

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

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

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

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

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

四、方法實(shí)踐                      

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

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

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

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

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

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

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

因此，我們建議首先在架構(gòu)信息層面對齊認(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)知對齊，能夠更好地幫助管理架構(gòu)實(shí)施活動(dòng)。

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

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

通過 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)評估委員會(huì) TAB等實(shí)踐，幫助組織高效管理架構(gòu)活動(dòng)，最大化架構(gòu)價(jià)值。

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

在當(dāng)前敏捷開發(fā)模式下，很難先完成詳細(xì)設(shè)計(jì)文檔基線后，然后再寫代碼。但是也不能沒有詳細(xì)設(shè)計(jì)文檔，只有代碼。詳細(xì)設(shè)計(jì)不僅僅是車載軟件合規(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.隨著開發(fā)的深入，逐步細(xì)化設(shè)計(jì)細(xì)節(jié)，添加必要的功能和優(yōu)化，滿足合規(guī)性要求。

③增量更新：

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

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

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

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

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

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

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

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

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

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

(3) 代碼門禁

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

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

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

(1) 分層測試體系

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

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

(2) 測試有效性提升

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

因此加強(qiáng)測試活動(dòng)，測試用例設(shè)計(jì)方法的培訓(xùn)與賦能，提升開發(fā)人員測試用例編寫能力，是車企需要重點(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í)滿足流程合規(guī)性要求。

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

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

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

如何將分散的工具鏈有機(jī)結(jié)合起來，需要從全局端到端的角度進(jìn)行系統(tǒng)性的汽車軟件研發(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)融入到汽車研發(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ā)過程數(shù)據(jù)和產(chǎn)品質(zhì)量數(shù)據(jù)。通過不斷沉淀研發(fā)活動(dòng)數(shù)據(jù)，建立統(tǒng)一的數(shù)據(jù)看板 Quality KPI Dashboard, 將研發(fā)質(zhì)量透明化, 可視化。

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

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

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

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

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

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

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