3. 量产项目集成环境搭建

EyeQ 量产项目的集成环境不是一台装了编译器的开发机，而是一套能把“真实传感器输入”和“真实整车网络行为”在实验室里稳定复现出来的台架系统。它的价值在于：当某个感知算法在实车上偶发失效时，团队可以在台架上按需重放同一段场景，反复定位问题，而不必依赖实车路测的时间窗口。本节围绕四个相互耦合的部分展开：硬件在环（HIL）台架、摄像头与雷达注入设备、网络与电源配置、版本管理工具链初始化。

一、HIL 台架的整体结构

EyeQ 的 HIL 台架通常由四层构成。最底层是供电与保护层，负责给 EyeQ 模组、注入设备和交换机提供受控电源，并具备过流、反接和浪涌保护。第二层是传感器注入层，摄像头通过视频注入卡把预录图像序列以 MIPI CSI-2 或 GMSL 链路送入 EyeQ，雷达通过 CAN FD 或以太网注入目标列表。第三层是网络与整车仿真层，用 CANoe/CANalyzer 或类似工具模拟整车 CAN、CAN FD、LIN 与车载以太网报文，包括车速、横摆角速度、转向角、挡位等信号。第四层是测试执行与记录层，运行自动化测试脚本，采集 EyeQ 输出的感知结果、告警和诊断信息。

这四层的关键约束是时间同步。摄像头帧、雷达目标、整车报文必须共享同一时间基准，否则回放出来的场景在时间轴上就是错位的。工程上通常用 PTP（IEEE 1588）或 GPS 秒脉冲给注入设备和网络仿真设备对时，并在测试脚本里记录每一帧的绝对时间戳。

二、摄像头与雷达注入设备

摄像头注入是台架里最容易出问题的一环。EyeQ 对输入视频的格式、时序和链路特性有明确要求，注入卡必须匹配这些要求，否则模组会直接判定链路异常而不进入感知流程。以常见的 GMSL2 链路为例，注入卡需要配置分辨率、帧率、像素格式和串行器型号。一个典型配置是 1920×1080、30 fps、YUV422 8-bit，串行器为 MAX9295，解串器为 MAX9296。配置完成后，用示波器或链路分析仪确认链路锁定状态，再让 EyeQ 读取图像。

雷达注入通常走两条路径：一是通过 CAN FD 直接注入目标列表，模拟雷达 ECU 的输出；二是通过以太网注入原始点云或目标级数据。前者实现简单，适合验证融合逻辑；后者更接近真实雷达，但需要处理数据包时序和丢包。工程上建议先用 CAN FD 路径打通链路，再逐步切换到以太网路径。

注入设备的时间同步必须与网络仿真设备一致。如果摄像头帧的时间戳和整车报文的时间戳来自不同时钟源，融合算法看到的“同一时刻”其实是错位的，会导致误判。因此，注入卡和网络仿真设备应统一由 PTP 主时钟授时，并在测试脚本中记录每帧的绝对时间。

三、网络与电源配置

网络配置的核心是“让 EyeQ 看到它期望的整车网络”。这包括三件事：物理链路、报文数据库和网络管理。物理链路方面，CAN FD 需要确认终端电阻为 120 Ω，以太网需要确认链路速率和双工模式。报文数据库方面，需要导入整车 DBC 或 ARXML 文件，确保信号名称、起始位、长度、字节序和缩放因子与实车一致。网络管理方面，需要模拟整车的网络管理报文，让 EyeQ 正常进入和退出网络状态。

电源配置常被低估。EyeQ 模组对供电电压范围、上电时序和电压跌落敏感。台架上应使用可编程直流电源，设置标称电压（例如 12 V 或 24 V，视车型而定）、过流保护阈值和上电斜率。如果需要验证欠压行为，可以按标准波形模拟电压跌落，例如从 12 V 跌到 6 V 并保持 50 ms，观察 EyeQ 是否复位、是否记录诊断码。

四、版本管理工具链初始化

量产项目的版本管理不只是 Git 仓库，而是一套“代码—配置—数据—工具”四类资产的版本化体系。代码包括感知算法、驱动和测试脚本；配置包括注入卡参数、DBC 文件、网络管理配置和电源波形；数据包括回放场景、标定参数和测试用例；工具包括编译器、调试器和分析脚本。这四类资产必须能追溯到同一个项目基线。

初始化时，建议先建立仓库结构，再配置分支策略和标签规则。一个可参考的仓库结构如下：

eyeq_project/
├── src/                # 感知算法与驱动代码
├── config/
│   ├── injection/      # 摄像头与雷达注入参数
│   ├── network/        # DBC / ARXML / 网络管理配置
│   └── power/          # 电源波形与保护阈值
├── data/
│   ├── scenarios/      # 回放场景序列
│   └── calibration/    # 标定参数
├── tools/              # 编译、调试与分析脚本
└── docs/               # 接口说明与测试记录

分支策略上，建议采用 main、release 和 feature 三条线。main 保持可集成状态，release 对应量产基线，feature 用于单个功能开发。标签规则建议包含项目代号、版本号和日期，例如 EQ6L-2025.03-RC1。这样在排查问题时，可以快速定位到“哪个版本、哪套配置、哪段场景”。

工具链初始化还包括编译环境和调试环境的统一。建议用容器或脚本固化编译器版本、依赖库版本和环境变量，避免“在我机器上能编译”的问题。对于 EyeQ 这类嵌入式平台，交叉编译工具链的版本尤其敏感，应在项目启动时就锁定并记录。

五、联调顺序与验收判断

台架搭建完成后，不建议一次性把所有设备都接上再上电。推荐的联调顺序是：先单独验证电源，再验证网络通信，然后验证摄像头注入，最后验证雷达注入和融合。每一步都有明确的验收判断：电源阶段看电压和电流是否在预期范围；网络阶段看 EyeQ 是否能正常收发报文并进入网络状态；摄像头阶段看 EyeQ 是否能输出感知结果；雷达阶段看融合结果是否随注入目标变化。

如果某一步不通过，应回到该步的输入和配置检查，而不是直接怀疑 EyeQ 模组。实践中，大部分问题出在链路配置、时间同步和报文数据库上，而不是模组本身。把每一步的验收判断记录下来，形成台架验收清单，可以显著缩短后续调试时间。

完成以上四部分后，集成环境才具备“可复现、可追溯、可回归”的能力。后续的算法迭代、问题定位和量产交付，都建立在这套环境之上。