2. EyeQ视觉感知系统架构解析

要验证EyeQ的视觉感知性能，首先必须理解它“看什么、怎么算、输出什么”。EyeQ不是一颗通用GPU，而是一颗面向ADAS/AD的专用视觉SoC：从摄像头原始数据进入，到最终输出目标列表、车道线、可行驶区域和自车运动估计，整条链路被高度定制化。验证工作的对象，正是这条链路上的每一个可观测节点。

一、视觉处理流水线：从光子到目标列表

EyeQ的视觉流水线可以概括为四级：图像信号处理（ISP）→ 预处理与金字塔 → 感知神经网络/专用加速 → 后处理与融合输出。摄像头通常以LVDS或MIPI CSI-2输入，EyeQ内部ISP完成去马赛克、黑电平校正、镜头阴影校正、自动曝光/白平衡，并输出YUV或RGB图像。随后图像被缩放为多尺度金字塔，供不同感受野的检测网络使用。

感知计算层是EyeQ的核心。以EyeQ4为例，它包含多个专用向量加速器（如PMA、VMP）和CNN加速单元，能够并行运行目标检测、车道线检测、语义分割、光流/深度估计等网络。EyeQ5进一步引入多核CPU集群与更强的深度学习加速器，支持多路高分辨率摄像头同时处理。计算完成后，后处理模块将网络输出解码为结构化目标：边界框、类别、距离、相对速度、车道线三次方程、可行驶区域掩码等。

验证视角下，这条流水线意味着：任何一级的输入偏差都会向后传播。例如ISP的自动曝光在隧道出口场景下若响应过慢，会导致感知网络短暂“失明”；金字塔缩放若引入混叠，会直接影响小目标检测。因此性能验证不能只看最终输出，还要在关键中间节点设置可观测点。

二、感知模块划分与接口

EyeQ的感知功能通常按“任务”划分模块，每个模块有独立的输入输出契约。典型模块包括：

• 车辆/行人/骑行者检测：输入为金字塔特征图，输出为边界框、类别、置信度、距离估计。
• 车道线检测：输出为车道线三次多项式系数、车道线类型（实线/虚线/路沿）、置信度。
• 可行驶区域分割：输出为像素级掩码或栅格化区域，用于路径规划。
• 交通标志/信号灯识别：输出为标志类别、位置、置信度。
• 自车运动估计：结合视觉里程计与车辆总线（车速、横摆角速度），输出自车位置与姿态变化。

这些模块通过内部共享内存或消息队列交换数据，对外则通过CAN/FlexRay或以太网输出结构化结果。验证时需要关注接口的时序与数据一致性：例如目标检测输出频率为30Hz，而车道线为20Hz，融合模块必须处理时间戳对齐；若某帧检测超时，输出应标记为无效而非沿用旧值。

三、各代EyeQ演进对验证提出的新要求

EyeQ2/3时代，感知任务单一、分辨率低，验证重点在于基本检测率与误报率。EyeQ4引入多网络并行和800万像素前视，验证必须覆盖多任务并发下的资源竞争：当检测、分割、光流同时运行时，单帧延迟是否稳定？网络间是否因共享内存带宽而相互拖累？

EyeQ5/6面向L2+至L3，支持多路高分辨率摄像头和BEV（鸟瞰图）融合。验证要求随之升级：

• 跨摄像头时空对齐：不同摄像头曝光时刻不同，BEV融合前必须验证时间同步误差是否在允许范围内（例如≤5ms）。
• 端到端延迟预算：从光子到目标输出，总延迟需控制在100ms以内，验证需分段测量ISP、推理、后处理各环节耗时。
• 功能安全与降级策略：当某路摄像头失效或置信度骤降时，系统能否在限定时间内切换到降级模式并输出安全停车指令。
• 数据闭环与场景覆盖：高分辨率带来更大数据量，验证需借助影子模式与回放工具，确保长尾场景被充分覆盖。

四、从架构到验证用例的映射示例

以“隧道出口强光恢复”场景为例，验证用例可这样设计：输入一段包含隧道出口的实车视频，注入到EyeQ的ISP前端；在ISP输出端记录AE收敛曲线，在感知输出端记录目标检测置信度随时间的变化。判定条件可设为：出口后500ms内，前方车辆检测置信度恢复至0.8以上，且车道线检测未丢失超过3帧。这样的用例直接对应架构中的ISP节点和检测节点，而不是笼统地“测试感知性能”。

再以“多摄像头BEV融合”为例，验证需在时间同步节点采集各摄像头帧时间戳，计算最大偏差；在融合输出端对比BEV目标位置与真值（如RTK定位）的横向/纵向误差。若时间偏差超过阈值，即使单摄像头检测正常，融合结果也可能出现目标“拖影”或位置跳变。这类问题只有回到架构层面才能定位。