3. 场景库工程化定义
在 EyeQ 这类 ADAS/AD 芯片的验证体系中，“场景”这个词被频繁使用，但不同团队口中的场景往往指的不是同一件事。有人说的场景是一段自然驾驶片段，有人说的是一条仿真脚本，还有人说的是回归报告里的一个条目。如果概念边界不清，就会出现“场景库看起来很大，但回归覆盖说不清”“测试用例写了几千条，却无法回答某个 ODD 是否被验证过”这类问题。本节先把四个核心概念拆开，再说明它们在 EyeQ 开发流程中的位置与交付物形态。
一、四个概念的分层定义
场景（Scenario）是对一段交通情境的抽象描述，回答的是“世界上发生了什么”。它通常由道路结构、交通参与者、环境条件、动态行为四类要素构成。例如：双向两车道、限速 60 km/h、本车直行、对向卡车在距本车 80 m 处左转横穿、晴天、路面干燥。场景本身是与实现无关的，它不指定用哪颗芯片、哪个版本、哪种传感器配置去跑，也不规定通过判据。场景是知识资产，不是执行资产。
场景库（Scenario Library）是场景的受控集合，回答的是“我们决定覆盖哪些情境”。它的工程价值不在数量，而在组织方式：按 ODD 维度（道路类型、天气、光照、交通密度）、按功能（AEB、LKA、ACC、ELK）、按风险等级、按来源（法规、事故、路测、专家构造）建立索引与标签体系。场景库必须带元数据：唯一 ID、版本、来源、适用功能、参数范围、优先级、关联需求 ID。没有元数据的场景集合只是文件夹，不是场景库。
测试用例（Test Case）是把场景绑定到具体执行条件后的可执行单元，回答的是“在什么配置下、怎么跑、怎么判”。一个场景可以派生出多个测试用例。例如上述“对向卡车左转横穿”场景，在 EyeQ 验证中可派生：摄像头+雷达融合配置、纯视觉降级配置、不同 EyeQ 软件版本、不同触发时刻（TTC = 2.5 s / 2.0 s / 1.5 s）等多个用例。测试用例必须包含：输入激励（视频注入/回放/仿真参数）、被测对象（芯片+软件版本+传感器配置）、预期输出（报警时刻、制动减速度、误报/漏报判定）、通过判据。
回归集（Regression Set）是从测试用例中挑选出的、每次软件变更后必须重跑的稳定子集，回答的是“这次改动有没有破坏已有能力”。回归集不是全量测试集，它强调快、稳、可重复、可判定。典型做法是按风险分层：P0 回归集覆盖安全相关核心功能，要求每次提交必跑；P1 覆盖主要功能，每日构建跑；P2 覆盖边缘场景，版本发布前跑。
二、概念边界的三个易混淆点
第一，场景不等于测试用例。很多团队把“场景库里有 5000 个场景”直接等同于“有 5000 个测试用例”，这是危险的。一个场景在不同 EyeQ 软件版本、不同传感器配置、不同触发参数下，行为可能完全不同。场景是“考什么”，测试用例是“怎么考、考哪个版本、多少分算过”。场景库可以跨项目复用，测试用例必须绑定具体版本。
第二，回归集不等于全量测试集。回归集的核心约束是“每次变更都能跑完且结果可信”。如果回归集包含大量不稳定、判定模糊、执行时间长的用例，它就会失去回归价值。工程上通常用“失败可复现率”和“单次执行时长”两个指标筛选回归集：失败可复现率低于 95% 的用例先移出 P0，单条执行超过 10 分钟的用例考虑降层或优化。
第三，场景库不是一次性交付物。场景库随 ODD 扩展、事故数据积累、法规更新而持续演进。每次回归失败、每次路测发现新边缘场景，都应反馈到场景库，形成“验证—发现—补充—再验证”的闭环。这也是 EyeQ 这类长生命周期芯片必须把场景库当作版本化资产管理的原因。
三、EyeQ 开发流程中的位置与交付物
在 EyeQ 项目中，场景库位于需求分析与回归验证之间，起到“需求可验证化”的桥梁作用。需求分析阶段输出 ODD 定义和功能需求，场景库构建阶段把这些需求翻译成可描述、可检索、可复用的场景集合；用例开发阶段再把场景绑定到 EyeQ 的具体配置上；回归验证阶段从用例集中筛选稳定子集，在每次软件变更后执行并输出报告。
各阶段的关键交付物如下表所示。需要强调的是，场景库的元数据表是整个链条的“索引骨架”，没有它，后续的用例追溯和回归筛选都会退化为人工翻找。
| 阶段 | 核心活动 | 交付物 | 关键字段/内容 |
|---|---|---|---|
| 需求分析 | 定义 ODD、功能需求、安全目标 | 场景需求清单 | ODD 维度、功能 ID、风险等级、法规引用 |
| 场景库构建 | 采集/构造/标注/评审场景 | 场景库 + 元数据表 | 场景 ID、版本、来源、参数范围、适用功能、优先级 |
| 用例开发 | 绑定配置、激励、判据 | 测试用例集 | 用例 ID、关联场景 ID、EyeQ 版本、传感器配置、通过判据 |
| 回归验证 | 分层筛选、执行、归因 | 回归集定义 + 回归报告 | P0/P1/P2 清单、通过率、失败用例归因、版本对比 |
四、一个可参考的场景库元数据字段示例
下面给出一个简化的场景库元数据表结构，字段设计围绕“可检索、可追溯、可回归”三个目标。实际项目中可根据团队工具链扩展，但核心字段不建议省略。
场景ID: SCN-AEB-CC-0012
场景名称: 对向卡车左转横穿_晴天干燥_城市道路
场景版本: v1.3
来源: 事故数据库 / 专家构造
ODD标签: 城市道路 | 晴天 | 干燥 | 限速60
适用功能: AEB-Car-to-Car
风险等级: P0
参数范围: 本车速度 40~60 km/h, TTC 1.5~2.5 s
关联需求: REQ-AEB-0042
关联用例: TC-AEB-CC-0012-01 ~ 05
创建日期: 2024-03-15
最后评审: 2024-06-20
状态: 已发布
这个结构的关键在于：场景 ID 是稳定主键，版本号支持演进，ODD 标签支持多维检索，关联需求与关联用例形成双向追溯，风险等级直接决定它进入哪一层回归集。当 EyeQ 软件从 v1.0 升级到 v1.1 时，回归系统可以按“适用功能=AEB-Car-to-Car 且 风险等级=P0”自动筛选出必须重跑的场景，再映射到对应版本的测试用例执行。
理解这四个概念的边界，本质上是在理解验证工程的“抽象层次管理”：场景保持与实现无关，场景库保持可管理，测试用例保持可执行，回归集保持可重复。四层各司其职，EyeQ 的场景库才能真正支撑起持续、可信、可追溯的回归验证。