1. 课程导入与体系总览

Mobileye EyeQ 系列（EyeQ4、EyeQ5、EyeQ6）在量产项目中的角色，并不是一颗“买来即用”的通用 SoC，而是一套由芯片、EyeQ Kit 软件栈、感知算法、安全机制与工具链共同构成的交付体系。整车厂或 Tier1 拿到的通常是一个可集成的软硬件基线，需要在自己的域控制器、传感器配置、整车网络与功能安全要求下完成适配、验证与量产放行。因此，理解 EyeQ 量产项目的关键，不在于记住某个 API，而在于看清“谁在什么阶段交付什么、集成方要做什么、如何判断可以进入下一阶段”。

典型生命周期：从 RFQ 到 SOP 再到持续维护

EyeQ 量产项目的生命周期通常可以划分为几个具有明确出口准则的阶段。第一阶段是需求与选型：OEM/Tier1 根据功能定义（如 L2 高速领航、记忆泊车、前视一体机）确定 EyeQ 型号、摄像头路数与分辨率、算力预算、功能安全等级（ASIL-B 或 ASIL-D 相关分解）。此阶段的关键交付物是技术可行性评估与接口需求文档，包括传感器接口（MIPI CSI-2 通道数、GMSL/以太网）、供电与散热边界、以及 EyeQ 侧可提供的感知输出清单。

第二阶段是样件与软件基线交付。Mobileye 会提供 EyeQ Kit 的软件包、固件、感知模型、标定工具与参考应用。集成方需要在自己的板级硬件上完成 Bring-up：确认 DDR 初始化、PCIe/以太网通信、摄像头链路锁定、时间同步（PTP 或硬件触发）等。这个阶段的典型出口是Bring-up 报告与基础感知输出可视化，例如在点云或目标列表上看到稳定的车道线、车辆与行人检测结果。

第三阶段是功能集成与标定。集成方将 EyeQ 的感知结果接入自己的融合、规划与控制模块，并完成摄像头外参标定、坐标系对齐、时间戳对齐。这里最容易出问题的不是算法本身，而是坐标系与时间基准不一致：EyeQ 输出的目标位置通常定义在车辆坐标系或摄像头坐标系下，若与融合模块的坐标系定义不一致，就会出现目标“漂移”或“跳变”。因此，标定与坐标变换必须作为独立交付物进行验证。

第四阶段是验证、放行与 SOP。包括功能测试、故障注入、诊断覆盖、EMC 与环境试验、以及整车道路测试。最终交付物是量产软件包、标定数据、诊断数据库、FMEA/安全分析报告与放行清单。SOP 之后进入维护阶段，处理现场问题、OTA 升级与法规变更。

集成与交付的核心目标

EyeQ 量产项目的集成目标可以概括为三条主线。第一条是功能正确性：感知输出在定义场景下满足精度、召回率与延迟要求。例如前视 800 万像素摄像头在 60 km/h 下，车辆检测距离需稳定覆盖 120 m 以上，车道线检测在曲率半径 250 m 内保持连续。第二条是时间确定性：从摄像头曝光到感知结果输出的端到端延迟必须可测量、可重复，通常要求控制在 100 ms 以内，且抖动不超过 20 ms。第三条是安全与可诊断性：系统需具备故障检测、降级策略与诊断码上报能力，确保单点失效不会导致不可控行为。

交付物清单并非一成不变，但以下内容在多数量产项目中是必需的：软件基线包（含版本号与校验值）、标定数据与标定流程说明、接口控制文档（ICD）、诊断数据库（CDD/ODX）、安全分析报告、测试报告与放行清单。这些交付物之间具有依赖关系：没有稳定的软件基线，标定数据无法复现；没有 ICD，融合模块无法正确解析感知输出；没有诊断数据库，售后无法定位现场问题。

一个可参考的启动检查表示例

以下检查表用于项目启动阶段快速对齐，字段可根据实际项目裁剪。示例中的参数为合理假设，不代表任何具体项目实测值。

常见误区与判断依据

初学者容易把 EyeQ 当成“黑盒”，认为只要接上摄像头就能输出结果。实际上，EyeQ 的感知性能高度依赖摄像头安装位置、镜头畸变、曝光策略与标定质量。例如，前视摄像头俯仰角偏差 0.5°，在 100 m 处就会造成约 0.87 m 的高度误差，足以影响目标接地点的判断。因此，标定后的验证不能只看“有没有目标”，而要看目标在图像与车辆坐标系中的位置是否与真值一致。

另一个误区是忽视版本管理。EyeQ Kit 的软件包、感知模型与标定数据必须作为整体版本进行管理，任何单独升级都可能导致感知行为变化。建议在项目早期就建立版本矩阵，记录每个软件版本对应的模型版本、标定版本与测试结果，确保问题可追溯、结果可复现。