1. 课程导入与工程全景

在 ADAS 与自动驾驶（AD）系统的量产开发中，芯片、算法、数据与验证构成了一条紧密耦合的工程链。Mobileye EyeQ 系列芯片长期承担着前视感知与驾驶辅助决策的核心角色，从早期的 EyeQ3 到 EyeQ4、EyeQ5，再到面向高阶自动驾驶的 EyeQ6，其算力、传感器接入能力与安全机制不断演进。理解 EyeQ 在整车电子电气架构中的位置，是理解后续场景库与回归验证工作的前提。

EyeQ 芯片通常部署在挡风玻璃后方的前视摄像头模组内，或作为独立的域控制器核心。它接收来自摄像头、毫米波雷达、激光雷达等传感器的原始数据，经过感知、融合、规划与决策，输出横向控制（转向）、纵向控制（油门/制动）以及人机交互信号。在 L2 及以下系统中，EyeQ 往往直接驱动执行器或通过 CAN 总线向整车控制器发送指令；在 L2+ 及以上系统中，EyeQ 可能作为感知与部分决策单元，与更高性能的计算平台协同工作。无论架构如何变化，EyeQ 的输出都直接关系到车辆的安全行为，因此其功能正确性必须通过系统化的场景测试与回归验证来保证。

场景库不是简单的测试用例集合，而是对驾驶任务、道路结构、交通参与者、环境条件与车辆状态的结构化描述。一个完整的场景通常包含道路几何（车道数、曲率、坡度）、交通标志与标线、动态目标（车辆、行人、骑行者）的行为、光照与天气条件、以及自车状态（速度、加速度、转向角）。在 EyeQ 项目中，场景库需要覆盖功能定义、危害分析与风险评估（HARA）中识别出的所有相关场景，并按照发生概率、严重度与可控性进行优先级排序。

回归验证则是在软件版本迭代过程中，自动或半自动地重新执行场景库中的测试用例，对比新旧版本的输出差异，判断是否出现功能退化。对于 EyeQ 这类嵌入式芯片，回归验证通常包括模型在环（MIL）、软件在环（SIL）、硬件在环（HIL）以及实车测试四个层级。每个层级的输入输出、时间精度与覆盖范围不同，但共享同一套场景描述与评价指标。例如，在 SIL 阶段可以用回放真实路采数据的方式验证感知算法，在 HIL 阶段则通过注入 CAN 信号与视频流验证芯片的实时响应。

从工程全景来看，EyeQ 芯片处于“传感器输入—感知融合—规划决策—控制输出”这条信号链的核心位置。场景库为这条链提供输入激励，回归验证则对链上每个环节的输出进行比对与评估。一个典型的回归验证流程是：从场景库中选取一组测试用例，在 SIL 环境中回放视频与 CAN 数据，记录 EyeQ 模型输出的目标列表、车道线方程与控制指令；然后切换到新版本软件，重复相同输入，逐帧对比新旧输出的差异。如果某个场景下横向控制指令的偏差超过阈值（例如转向角速度偏差大于 0.5°/s 持续 200ms），则判定为潜在退化，需要人工复核。

本课程的学习路径将围绕三个层次展开。第一层是基础认知：理解 EyeQ 芯片的硬件架构、软件框架与安全机制，掌握场景库的要素定义与分类方法。第二层是工程实践：学习如何从真实路采数据中提取场景、如何编写可执行的测试用例、如何搭建 MIL/SIL/HIL 回归环境。第三层是分析与优化：掌握回归结果的统计方法、退化根因定位技巧，以及如何根据覆盖率与通过率持续改进场景库。每一层都配有具体的工具操作与示例参数，帮助读者从“知道是什么”过渡到“知道怎么做”。

需要特别强调的是，场景库与回归验证不是一次性任务，而是伴随整个产品生命周期的持续活动。在概念阶段，场景库用于定义功能边界；在开发阶段，用于验证算法与软件；在测试阶段，用于覆盖极端与边缘场景；在量产之后，用于分析现场事件并反哺场景库更新。EyeQ 作为安全关键组件，其回归验证的通过标准通常由功能安全团队与系统团队共同制定，并与 ISO 26262、ISO 21448（SOTIF）等标准的要求对齐。理解这些工程约束，才能在实际项目中做出合理的验证策略取舍。

接下来的章节将逐步展开 EyeQ 的硬件与软件架构、场景描述语言、测试用例设计方法、回归平台搭建与结果分析。本章作为导入，目标是建立一张完整的工程地图：知道 EyeQ 在系统中的位置，知道场景库与回归验证各自解决什么问题，知道后续学习将获得哪些可落地的能力。带着这张地图进入后续内容，学习会更有方向感。