1. 课程导入与交付全景

Mobileye EyeQ 系列芯片（EyeQ4、EyeQ5、EyeQ6）是智能驾驶领域广泛采用的视觉感知 SoC 平台，其配套的 EyeQ Kit、EyeQ SDK 以及 Mobileye 提供的感知算法栈，构成了从摄像头输入到 ADAS/AD 功能输出的完整技术底座。所谓EyeQ 智能驾驶项目工程交付，指的是在整车厂或 Tier1 拿到 Mobileye 芯片与软件授权后，围绕具体车型的 ADAS/AD 功能需求，完成从需求定义、软硬件集成、感知与规控适配、标定、测试验证到量产释放的一整套工程活动，并最终向整车项目交付可量产、可追溯、可维护的智能驾驶系统。

它不同于单纯的“芯片选型”或“算法研究”，也不同于一般意义上的软件开发。EyeQ 项目交付的核心特征在于：软硬件强耦合、感知与规控分层、安全与合规约束前置、量产节点倒逼验证节奏。理解这一点，是后续所有章节展开的前提。

交付范围：从芯片到整车的四层边界

EyeQ 项目的交付范围可以按“芯片—软件—系统—整车”四个层次来界定。第一层是芯片与基础软件层，包括 EyeQ 芯片本身、EyeQ Kit 运行时、驱动、BSP、工具链以及 Mobileye 提供的感知算法库；第二层是感知与融合层，涉及摄像头、雷达、激光雷达等传感器的接入、时间同步、目标级/特征级融合；第三层是规控与功能层，包括 AEB、ACC、LKA、NOA 等功能的决策、规划与控制；第四层是整车集成与验证层，涵盖 CAN/Ethernet 通信、诊断、OTA、功能安全与预期功能安全、整车标定与路试验证。

需要特别说明的是，Mobileye 通常提供“感知黑盒”或“感知白盒”两种合作模式。黑盒模式下，EyeQ 输出目标列表、车道线、可行驶区域等结构化结果，规控由客户或 Tier1 自研；白盒模式下，客户可对部分感知模块进行定制。交付范围的边界必须在项目启动阶段就以接口控制文档（ICD）和责任矩阵（RACI）的形式固化，否则后期极易出现“感知结果不满足规控预期”的扯皮。

核心角色与职责分工

一个典型的 EyeQ 量产项目通常涉及以下角色：Mobileye 侧包括 FAE（现场应用工程师）、算法支持团队、芯片与工具链支持；客户侧包括系统架构师、感知集成工程师、规控开发工程师、标定工程师、测试验证工程师、功能安全工程师、项目经理；Tier1 侧可能承担传感器、域控制器、执行器集成。各方通过接口人机制和问题升级路径协同，避免多头对接。

端到端流程总览

EyeQ 项目的端到端流程可以概括为六个阶段：需求与可行性分析 → 架构与接口定义 → 软硬件集成与感知适配 → 标定与功能调试 → 测试验证与安全评估 → 量产释放与持续维护。每个阶段都有明确的输入、输出和准出条件。例如，架构阶段的准出是 ICD 冻结；集成阶段的准出是感知结果在回放数据上达到约定指标；标定阶段的准出是静态标定与动态标定均通过；验证阶段的准出是功能安全案例与路试报告通过评审。

下面用一张端到端流程图，把上述阶段、关键活动、主要交付物和角色关系集中呈现，便于在项目启动时作为“全景地图”使用。

为什么需要“全景视角”

很多 EyeQ 项目在启动时只关注“芯片能不能跑起来”，结果在集成阶段才发现感知输出频率与规控周期不匹配，或者在标定阶段才发现摄像头安装角度超出算法容忍范围，导致返工。全景视角的价值在于：把接口、责任、准出条件前置，让每个阶段都知道自己需要向下一阶段交付什么、验收标准是什么。

例如，在架构阶段就应明确：EyeQ 输出的目标列表坐标系是车辆坐标系还是图像坐标系？时间戳基准是传感器触发时刻还是 EyeQ 接收时刻？这些定义一旦模糊，后续融合与规控就会反复调整。再如，标定阶段需要区分静态标定（在标定间完成，确定摄像头内参和外参初值）与动态标定（在道路行驶中在线修正外参），两者的输入数据、工具链和验收指标完全不同。

交付成功的三个判断维度

第一，功能维度：AEB、ACC、LKA 等功能是否在定义工况下达到性能指标，误触发率与漏触发率是否满足要求。第二，安全维度：功能安全（ISO 26262）与预期功能安全（ISO 21448）的分析是否闭环，安全案例是否可追溯。第三，工程维度：代码与配置是否可版本管理，标定参数是否可追溯，OTA 升级是否可回滚。三者缺一不可，任何一项在量产前未闭环，都会成为释放的阻塞项。