V模型的本質是什么？汽車軟件ECU子系統的開發

太多人在講V模型了，但越是司空見慣的概念，似乎越讓人難以達成共識。這篇文章給出我的觀點。 ?

開發模型其實有很多，比如，增量式、原型式、螺旋式、噴泉式、W模型等。限于篇幅且必要性不大，我們不講那么多。

其實，能夠反映最基本工程邏輯的模型就是瀑布，包括V模型在內的其他模型大多是以瀑布為基礎來衍生的，或多或少也都能看到它的影子。

我們先從瀑布說起。

1 瀑布模型是一種認知邏輯 ? ? 瀑布模型是大家聽得最多的，也是具備最樸素的認知邏輯的一種模型。

瀑布模型，顧名思義，就是像瀑布的水流一樣逐層推進。

簡單來說，就是在需求、設計、測試3大基礎板塊上的擴展，各項工程活動就像多米諾骨牌一樣按次序排布，并逐層驅動直至最后一塊骨牌倒下。

這種方式雖然簡單，但非常易于理解，所以也便于管理。對于標準化、規范化要求比較高的領域，更是極具友好性，就像汽車制造，就是非常典型的瀑布。

一個簡單的、單一的軟件模塊的開發，如果需求描述清晰、設計方式確定、測試用例明確，最佳的辦法也就是一波流的瀑布。

當然，不是像一串珠子一樣的單向、單通道、串行模式才是瀑布。即使是最簡單的一個機械件開發，也會有并行、來回反復修正的過程。

總體的，我們可以總結瀑布在廣義上的兩個特點：

在時間線上線性串行。

后序輸入需要依賴前序輸出。

這樣，我們會發現，瀑布不單是一種開發模型，也是一種無法跳脫的思考方式。

2 V模型的本質 ? ?

然而，世間規律并非總是完美如12345這樣的次序。當我們面臨具備一定復雜性的系統和合作環境時，最基礎的瀑布模型就不便于我們參考了。

身處冗長供應鏈和擁有復雜機電軟硬一體系統的汽車，就面臨了這樣的問題，基于瀑布而演變的V模型就逐漸成為汽車行業應用最廣的模型。

諸如ASPICE、26262、21434等行業內各種體系標準也都是基于V模型搭的架構。

2.1?層層嵌套的汽車V模型 ? ?

V模型習慣被認為是軟件開發的一種模型，但對于汽車軟件，顯然無法獨立談軟件。

我們不妨按照系統工程的方式理解一下，當俯瞰整個汽車的設計開發時，會發現就是一個個大V模型套小V模型的架構。

首先，多個整車V模型會作為背景板來支撐汽車整體開發架構，并進而支持整車屬性定義、造型設計、架構設計、需求拆分、子系統實現、樣件交付、整車集成、整車驗證等整車里程碑目標的達成。

接下來，一個個ECU子系統的開發再通過多個小的ECU V模型來不斷推進。

進一步地，每一個ECU子系統還能劃分為機械、軟件、算法、標定、硬件、子系統集成等學科領域，而它們也是通過更下一級的小小V模型來運轉。

伴隨著不斷的V模型的迭代，零部件、子總成、功能域系統、整車逐漸成熟，直至整車SOP。

2.2?V模型的內核 ? ?

那么，V模型的內核到底在哪里？有4個點值得關注。

2.2.1 分層分塊細化

我們對于不太好搞懂的東西，要掰開了、揉碎了看。就像我們認識物質，一直從分子、原子、原子核、質子、夸克深挖下去才算是多少弄明白點。

2.2.2 高度關注驗證確認

汽車及汽車軟件的開發涉及大量的各層級的驗證。狹義上，就是工程上的測試；廣義上，所有的評審、走查、里程碑、審計、試駕都是驗證確認的一部分。

2.2.3 分工合作

第一條的可分層細化也是分工合作的前提，反過來，分工合作的模式也影響了系統的層次和架構，這是相互的。就像康威定律所指出的，“產品必然是其組織溝通結構的縮影”。

2.2.4 開始“混沌”

現在的問題在于，劃分為不同“層”和“塊”的V模型并不是終極解決方案。

汽車行業開發生態與V模型相互成就，V模型在汽車業的蓬勃中也成為骨架。

但隨著軟件的進入、域化、集中化的演變，系統到組件的層級關系越來越弱化，組件之間的學科界限越來越模糊。

現實工作中，我們經常會矛盾于這是系統需求還是軟件需求，糾結于這是軟件測試還是硬件測試抑或是集成測試。

分層分塊概念的混沌正在變得明顯。

于是，解決這種混沌就成為當下的重點，或許還需要一定的時間，再次由亂到治，但這個過程中，并不用太急著去質疑V模型本身的存在意義。

3 全文小結 ? 總結下來，本文給出了3個關鍵信息或觀點： ?

瀑布是一種基礎的認知與工程邏輯。

復雜的汽車是通過層層嵌套的V模型逐漸走向SOP的。

V模型的特點在于分層分塊細化、高度關注驗證確認、分工合作，但目前遇到了分層分塊混沌的問題。

4 寫在最后 ? 混亂之下，我們最容易被概念蒙蔽，大家都喜歡標新立異。 ? 實際上，無論如何，我們走不出工程最本源——瀑布，也離不開V模型的內核思路，至少在目前，它依然是我們認識、理解汽車軟件的基礎。

審核編輯：黃飛

?