金庸筆下的武俠世界里，掌握一門內功心法是獨步武林的基礎。在汽車電子領域，也有著這樣的內功心法——V模型的開發流程。
開發模型有很多，包括增量式、原型式、螺旋式、噴泉式、W模型等，但在實際開發中，V模型被應用最多。所以，掌握好這門心法，才能更好地做好開發工作。
汽車開發的基本模式
你我都知道，在汽車開發過程中，汽車概念首先被分解成系統和組件，然后重新整合成整車，那么怎么拆就是一個問題。
當前，新能源整車及三電系統的設計開發主要采納ASPICE V模型開發模式。
ASPICE全稱為“Automotive Software Process Improvement and Capacity Determination”，即汽車軟件過程改進及能力測定模型，是汽車軟件的開發過程標準。
而V模型是一個軟件開發過程模型，它強調測試和軟件開發各階段之間的關系。在系統開發活動中，最為常見的開發模型是V模型。V模型因其開發過程展現的形式與英文字母“V”非常相似而得名。V模型具有與瀑布模型相同的順序設計過程，每個階段都必須在下一個階段開始前完成，同時相應的測試計劃應與對應的開發階段并行進行。
軟件開發V模型，圖源｜《智能汽車：電子電氣架構詳解》
V模型從瀑布模型而來，1970年溫斯頓·羅伊斯（Winston Royce）提出瀑布模型，將軟件生命周期分為若干階段和固定的順序，形如瀑布流水，最終得到軟件產品。
瀑布模型將軟件生命周期劃分為：制定計劃、需求分析、軟件設計、程序編寫、軟件測試、.運行維護。
瀑布模型的優點是為項目提供了按階段劃分的檢查瀑布模型查點；當前一階段完成后，只需要去關注后續階段；可在迭代模型中應用瀑布模型。不過，瀑布模型各個階段的劃分完全固定，階段間產生大量文檔，極大增加工作量。此外，由于開發模型為線性的模型，用戶只有等到過程末期才能見到開發成果，從而增加開發風險。更重要的是，早期錯誤可能要等到開發后期的測試階段才能發現，進而帶來嚴重后果。
V模型則是Kevin Forsberg & Harold Mooz在1978年提出，V模型強調測試在系統工程各個階段中的作用，并將系統分解和系統集成的過程通過測試彼此關聯。
實際生產中的V模型
不過，光是這么個模型，其實還是很理想化的模型，在實際生產中，V模型要復雜的多。
在實際的軟件開發過程中，鑒于測試驗證的反復性、功能需求的迭代更新等多重因素，往往會涉及多個版本的發布。因此，真正的開發流程是由一系列相互關聯的“小V”模型串聯而成，這些“小V”模型共同構建了一個更為宏觀、綜合的“大V”模型，以適應軟件開發過程中的多樣性和復雜性。
復雜軟件開發模型示意，圖源｜《智能汽車：電子電氣架構詳解》
在實際運作中，整車的開發任務又會被切割到各個域，然后又被逐漸分解到系統、部件，以及部件內的組件（軟件、硬件、機械等），所以整個V模型會更為復雜。
如下圖所示，每個車型的研發周期可以看作一個獨立的“大V”模型，“大V”模型中的子研發階段（系統集成節點之間）可以看作“小V”模型。每個系統研發周期可以視作獨立的“大V”模型，它又由多個“小V”模型串聯而成。
整車開發中的V模型分解示意圖，圖源｜《智能汽車：電子電氣架構詳解》
V模型開發結構明確劃分了設計開發與分析活動（位于模型左側）以及設計結果的測試與驗證活動（位于模型右側），兩側互為補充，共同構建了一個完整且嚴謹的開發流程。
從V模型結構中，我們可以看出，測試驗證環節與開發環節處于同等重要的地位，是系統開發中不可或缺的關鍵環節。
盡管當前許多車企從互聯網領域借鑒并引入了“敏捷開發”的理念，但汽車類的設計開發流程依然以V模型作為其主干結構。
ASPICE設計開發流程，圖源｜ RIO電驅動
V模型上的工具
那么在每個階段，又有什么工具，來支持各個階段的開發工作。以下是對這些階段的工作目標，常用工具鏈及其相應的供應商：
1. 需求分析階段
需求管理工具：DOORS（IBM），Jama Software，Polarion（Siemens）
需求建模工具：Enterprise Architect（Sparx Systems），MagicDraw（No Magic）
2. 系統設計階段
系統建模工具：Enterprise Architect（Sparx Systems），Rhapsody（IBM）
仿真和驗證工具：Simulink（MathWorks），Modelica（OpenModelica）
3. 詳細設計階段
軟件設計工具：UML建模工具（如Enterprise Architect，MagicDraw）
硬件設計工具：Altium Designer，Cadence，Mentor Graphics（Siemens）
4. 實現階段
集成開發環境（IDE）：Eclipse，Keil（Arm），IAR Embedded Workbench
版本控制工具：Git，SVN（Subversion），Jenkins
5. 單元測試階段
測試框架：Google Test，CppUnit，JUnit
測試覆蓋率工具：gcov（GCC），Bullseye Coverage
6. 集成測試階段
集成測試工具：Vector CANoe，National Instruments（NI TestStand）,VT-System(Vector)
仿真工具：Simulink，MATLAB
7. 系統測試階段
測試管理工具：HP ALM(Application Lifecycle Management)，JIRA
硬件在環（HIL）測試工具：dSPACE ，ETAS LABCAR ，Vector Informatik
8. 驗收測試階段
工具鏈和供應商：HP ALM，JIRA，TestRail（Gurock）
9. 維護階段
問題追蹤工具：JIRA，Bugzilla，Redmine
配置管理工具：Git，SVN，Perforce
把敏捷開發加入V模型
最近一段時間，汽車交付越來越快，甚至出現一年一車的盛況。V模型的局限性也越來越明顯，V模型的測試過程是在開發過程的后期進行的，這意味著問題在測試階段被發現可能會導致較高的修復成本。
為了補足V模型的缺點，將敏捷開發和V模型結合使用是全新的方法，也就是將敏捷原則嵌入到V模型中。
顧名思義，敏捷開發是一種迭代式、增量式的開發方法，強調對需求變化的快速響應和持續交付有價值的軟件，將其用于產品的開發，實現敏捷迭代。
通過結合敏捷開發和V模型，可以實現對汽車軟件開發過程的全面評估和改進，提高產品研發質量和可靠性。
結合完大改長這樣：
原本按照V模型按部就班走，每個環節走得都不一樣快，走得快其實就可以有時間喘口氣等一等。當加入敏捷思維之后，這基本是一種讓大家都閑不下來的方法，一段時間內可能會比較容易提升效率和效果，但長久來看，如何通過激勵措施持續運作下去會是一個問題。
轉變并非易事，汽車行業幾十年來一直遵循V模型開發流程，未來怎么融合，也是現階段在考慮的事情。原文：想做好汽車軟件開發，先練好這個內功
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
