汽车软件开发V模型的本质

瀑布模型，顾名思义，就是像瀑布的水流一样逐层推进。

简单来说，就是在 需求、设计、测试3大基础板块上的扩展 ，各项工程活动就像多米诺骨牌一样按次序排布，并逐层驱动直至最后一块骨牌倒下。

这种方式虽然简单，但非常易于理解，所以也便于管理。对于标准化、规范化要求比较高的领域，更是极具友好性，就像汽车制造，就是非常典型的瀑布。

一个简单的、单一的软件模块的开发，如果需求描述清晰、设计方式确定、测试用例明确，最佳的办法也就是一波流的瀑布。

当然，不是像一串珠子一样的单向、单通道、串行模式才是瀑布。即使是最简单的一个机械件开发，也会有并行、来回反复修正的过程。

总体的，我们可以总结 瀑布在广义上的两个特点 ：

• 在时间线上线性串行。

• 后序输入需要依赖前序输出。

这样，我们会发现，瀑布不单是一种开发模型，也是 一种无法跳脱的思考方式 。

然而，世间规律并非总是完美如12345这样的次序。当我们面临具备一定复杂性的系统和合作环境时，最基础的瀑布模型就不便于我们参考了。

身处冗长供应链和拥有复杂机电软硬一体系统的汽车，就面临了这样的问题， 基于瀑布而演变的V模型就逐渐成为汽车行业应用最广的模型 。

诸如ASPICE、26262、21434等行业内各种体系标准也都是基于V模型搭的架构。

V模型习惯被认为是软件开发的一种模型，但 对于汽车软件，显然无法独立谈软件 。

我们不妨按照系统工程的方式理解一下，当俯瞰 整个汽车的设计开发 时，会发现就是一个个 大V模型套小V模型 的架构。

首先， 多个整车V模型会作为背景板 来支撑汽车整体开发架构，并进而支持整车属性定义、造型设计、架构设计、需求拆分、子系统实现、样件交付、整车集成、整车验证等 整车里程碑目标的达成 。

接下来，一个个 ECU子系统 的开发再通过 多个小的ECU V模型 来不断推进。

进一步地，每一个ECU子系统还能划分为机械、软件、算法、标定、硬件、子系统集成等 学科领域 ，而它们也是通过 更下一级的小小V模型 来运转。

伴随着不断的V模型的迭代，零部件、子总成、功能域系统、整车逐渐成熟，直至整车SOP。

那么，V模型的内核到底在哪里？有4个点值得关注。

2.2.1 分层分块细化

我们对于不太好搞懂的东西，要掰开了、揉碎了看。就像我们认识物质，一直从分子、原子、原子核、质子、夸克深挖下去才算是多少弄明白点。

2.2.2 高度关注验证确认

汽车及汽车软件的开发涉及 大量的各层级的验证 。狭义上，就是工程上的测试；广义上，所有的评审、走查、里程碑、审计、试驾都是验证确认的一部分。

2.2.3 分工合作

第一条的 可分层细化也是分工合作的前提 ，反过来， 分工合作的模式也影响了系统的层次和架构 ，这是相互的。就像 康威定律 所指出的，“产品必然是其组织沟通结构的缩影”。

2.2.4 开始 “混沌”

现在的问题在于，划分为 不同“层”和“块”的V模型并不是终极解决方案 。

汽车行业开发生态与V模型相互成就， V模型在汽车业的蓬勃中也成为骨架 。

但随着软件的进入、域化、集中化的演变，系统到组件的层级关系越来越弱化，组件之间的学科界限越来越模糊。

现实工作中，我们经常会矛盾于这是系统需求还是软件需求，纠结于这是软件测试还是硬件测试抑或是集成测试。

分层分块概念的混沌正在变得明显 。

于是，解决这种混沌就成为当下的重点，或许还需要一定的时间，再次由乱到治，但这个过程中，并不用太急着去质疑V模型本身的存在意义。

• 瀑布是一种基础的认知与工程逻辑。
• 复杂的汽车是通过层层嵌套的V模型逐渐走向SOP的。
  
• V模型的特点在于分层分块细化、高度关注验证确认、分工合作，但目前遇到了分层分块混沌的问题。