4. 量产验证流程与V模型

EyeQ 系列芯片（如 EyeQ4、EyeQ5）在 ADAS 量产项目中，验证工作并不是“最后测一遍”，而是与开发过程同步展开、逐层收敛的系统工程。V 模型之所以成为 Mobileye 量产验证的主流框架，是因为它把“分解”和“验证”一一对应：左侧从整车需求逐级分解到软硬件单元，右侧从单元测试逐级集成回整车验证，每一层左侧的输入，都对应右侧一个明确的验证出口和交付物。理解这条对应关系，是判断“某个阶段到底该交什么、测什么、谁来签字”的关键。

V 模型左侧：需求逐级分解与设计落地

V 模型左臂是“自上而下分解”。最顶层是整车级需求，例如“在 60 km/h 以下对静止车辆实现 AEB 刹停”“车道保持横向误差不超过 0.3 m”。这些需求来自法规（如 UN R152、Euro NCAP）、主机厂功能规范和 Mobileye 的 ADAS 功能定义。整车需求向下分解为系统需求：感知、规划、控制、执行各子系统的功能与性能指标，例如前视摄像头探测距离、EyeQ 芯片算力预算、CAN 报文周期等。

系统需求再分解为软件架构与硬件设计。EyeQ 内部通常划分为感知（Perception）、融合（Fusion）、决策规划（Planning）等模块，每个模块有明确的接口定义（输入图像帧、输出目标列表）和性能约束（延迟、置信度阈值）。再往下是单元级设计：具体算法函数、驱动、通信栈。左侧每一层都要产出可追溯的需求规格和设计文档，这是右侧验证的“标尺”。

V 模型右侧：逐级验证与交付物

右臂是“自下而上验证”，与左侧严格镜像对应：

• 单元测试：针对单个函数或模块，验证输入输出是否符合设计。例如对目标跟踪的卡尔曼滤波单元，输入一组带噪声的测量序列，检查输出轨迹的收敛误差是否在设定范围内。交付物是单元测试报告与代码覆盖率（如语句覆盖、分支覆盖）。
• 集成测试：验证模块间接口与协同。例如把感知输出接入融合模块，检查目标 ID 在跨帧之间是否稳定、时间戳是否对齐。交付物是集成测试用例集与接口一致性报告。
• 系统测试：在台架或 HIL（硬件在环）上验证整个 EyeQ 系统功能。例如注入仿真视频流，验证 AEB 触发时机与减速度曲线。交付物是系统测试报告与需求覆盖率矩阵。
• 整车验证：在实车上按场景库执行，验证真实道路与极端工况。交付物是整车验证报告、问题清单与放行结论。

需要强调的是，右侧每一层的验证依据都来自左侧对应层的需求，而不是临时拍脑袋设计用例。这种“左需右验”的镜像关系，正是 V 模型能保证可追溯性的原因。

各阶段输入、输出与交付物对照

下面这张图把 V 模型左右两臂的对应关系、每阶段的典型输入与交付物集中呈现，便于在项目中快速定位“当前处于哪一层、该交什么”。

关键实践：可追溯性与阶段放行

在真实量产项目中，V 模型能否落地，取决于两件事：需求可追溯性和阶段放行准则。可追溯性要求每个测试用例都能追溯到一条需求，每个需求都能找到至少一个验证用例。Mobileye 项目通常使用需求管理工具维护“需求—设计—测试”三向链接，任何需求变更都会触发对应测试用例的评审与更新。

阶段放行准则则是“出口条件”。例如单元测试阶段要求语句覆盖率不低于 90%、分支覆盖率不低于 80%；系统测试阶段要求需求覆盖率 100%、严重缺陷清零；整车验证阶段要求场景库通过率达标且无 A 类问题遗留。这些阈值是示例性设定，实际项目会依据 ASIL 等级和主机厂要求调整。

常见误区与排障思路

第一个误区是把 V 模型当成“文档流程”，只产出文档不做真实验证。判断方法是抽查测试用例：如果用例只描述“验证功能正常”而没有具体输入、预期输出和判定阈值，就说明验证没有真正落地。第二个误区是右侧验证与左侧需求脱节，导致“测了很多但没测到需求”。排障时先做需求覆盖率审计，找出没有对应用例的需求条目，再补齐用例。

第三个误区是整车验证阶段才发现问题，返工成本极高。合理的做法是在 HIL 系统测试阶段就尽可能覆盖边界场景，例如低照度、强逆光、目标遮挡、传感器脏污等，把能在台架暴露的问题提前拦截。整车验证则聚焦真实道路中台架难以复现的工况，如复杂交通流、非标车道线、隧道出入口光照突变。

把 V 模型理解成一张“需求与验证的对应地图”，而不是一张“先左后右的流程图”，才能真正用好它。在 EyeQ ADAS 项目中，每一层左侧写下什么需求，右侧就必须有对应的验证出口和交付物；这条镜像主线贯穿从需求分析到整车验证的全过程，也是量产验证可审计、可追溯、可放行的根本依据。