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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 軟件開發(fā)缺乏統(tǒng)一標準

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

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

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

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

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

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

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

二、應對質(zhì)量問題的策略與實踐 

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

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

三、流程改進

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

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

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

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

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

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

四、方法實踐                      

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

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

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

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

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

2.架構設計改進  

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

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

(1) 架構信息模型

在復雜的項目中，統(tǒng)一架構信息元素的概念非常重要，比如 Component 的定義，在不同的領域是不一樣的。保持所有人的認知對齊，能夠更好地幫助管理架構實施活動。

(2) 軟件架構設計

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

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

(3) 軟件詳細設計

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

增量式詳細設計關鍵特點：

①迭代式設計：

a.將詳細設計分解為多個迭代周期，每個周期都聚焦于一部分功能或模塊的設計。

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

②最小化可行設計：

a.在設計初期，只關注最關鍵的設計決策和架構元素，確保系統(tǒng)的基礎穩(wěn)定性。

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

③增量更新：

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

b.使用版本控制系統(tǒng)來管理設計文檔的變更歷史，確?？勺匪菪?。   

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

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

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

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

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

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

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

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

(3) 代碼門禁

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

4. 分層驗證體系   

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

(1) 分層測試體系

我們建議車企構建清晰明確的分層測試體系，明確每一層級測試的目標和方法。

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

(2) 測試有效性提升

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

因此加強測試活動，測試用例設計方法的培訓與賦能，提升開發(fā)人員測試用例編寫能力，是車企需要重點建設的地方。

五、工具支撐                      

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

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

1. 工具鏈搭建

好的需求、設計工具能夠幫助高效地管理需求與設計活動，同時滿足流程合規(guī)性要求。

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

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

2.構建軟件工廠平臺

如何將分散的工具鏈有機結合起來，需要從全局端到端的角度進行系統(tǒng)性的汽車軟件研發(fā)DevOps 平臺設計，打通工具鏈，構造研發(fā)組織級統(tǒng)一的 Software Factory。

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

3. 數(shù)據(jù)驅動質(zhì)量改進

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

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

以下表評估代碼質(zhì)量為例，基于 GQM 的度量方法，設計相應的度量指標。

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

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

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

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

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