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

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

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

一、汽車軟件研發面臨的主要問題  

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

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

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

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

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

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

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

汽車軟件質量問題的根源主要體現在以下幾個方面：

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

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

2. 軟件開發缺乏統一標準

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

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

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

4. 質量保證未貫穿軟件開發全生命周期 

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

5. 軟件開發過程不透明且缺乏數據驅動

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

二、應對質量問題的策略與實踐 

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

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

三、流程改進

流程/過程質量決定產出質量，高效的研發流程是保障軟件質量的基石。

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

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

汽車行業軟件開發主要有以下三種主流的開發模型：

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

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

四、方法實踐                      

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

1.需求工程優化  

有好的需求產出，項目就已經成功了一半。

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

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

2.架構設計改進  

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

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

(1) 架構信息模型

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

(2) 軟件架構設計

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

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

(3) 軟件詳細設計

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

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

①迭代式設計：

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

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

②最小化可行設計：

a.在設計初期，只關注最關鍵的設計決策和架構元素，確保系統的基礎穩定性。

b.隨著開發的深入，逐步細化設計細節，添加必要的功能和優化，滿足合規性要求。

③增量更新：

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

b.使用版本控制系統來管理設計文檔的變更歷史，確保可追溯性。   

3. 編碼實踐規范  

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

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

(1) 編碼規范定義

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

(2) 代碼提交規范

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

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

(3) 代碼門禁

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

4. 分層驗證體系   

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

(1) 分層測試體系

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

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

(2) 測試有效性提升

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

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

五、工具支撐                      

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

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

1. 工具鏈搭建

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

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

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

2.構建軟件工廠平臺

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

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

3. 數據驅動質量改進

改進才是目標，度量只是手段。基于數據建模方法構建度量指標體系，結構化研發過程數據和產品質量數據。通過不斷沉淀研發活動數據，建立統一的數據看板 Quality KPI Dashboard, 將研發質量透明化, 可視化。

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

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

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

六、持續改進與以人為本  

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

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

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