3. 场景分类体系
在智能驾驶场景覆盖与里程验证工程中，场景分类体系是连接“真实世界复杂性”与“可测试、可度量、可复现”的桥梁。若没有统一的层级划分，测试团队很容易陷入两种极端：要么用大量零散的具体案例堆砌里程，要么用过于抽象的功能描述掩盖关键参数差异。PEGASUS 项目提出的“功能场景—逻辑场景—具体场景”三层体系，正是为了解决这一问题，它让场景从自然语言描述逐步收敛为可执行、可参数化、可批量生成的测试输入。
一、核心原理：三层场景的抽象层级
三层场景的本质是抽象程度递减、参数确定性递增。功能场景用自然语言描述“发生了什么”，逻辑场景用参数空间描述“可能发生什么”，具体场景用固定参数描述“这一次到底发生了什么”。三者不是替代关系，而是同一场景在不同工程阶段的表达形式。
- 功能场景（Functional Scenario）：以自然语言或结构化文本描述交通参与者的行为与道路环境，例如“本车直行通过无信号灯路口，右侧有车辆横向驶出”。它不绑定具体数值，主要用于需求分析、场景库分类和测试范围界定。
- 逻辑场景（Logical Scenario）：将功能场景中的关键变量参数化，形成参数空间。例如本车速度 v∈[30,60] km/h，目标车速度 v∈[10,40] km/h，距离 d∈[5,50] m。逻辑场景是场景生成、组合测试和覆盖率分析的核心对象。
- 具体场景（Concrete Scenario）：从逻辑场景的参数空间中取一组确定值，形成可直接注入仿真或实车测试的完整案例。例如 v=45 km/h，v=25 km/h，d=18 m，天气为小雨，路面附着系数 0.7。
关键理解：功能场景回答“测什么行为”，逻辑场景回答“在什么参数范围内测”，具体场景回答“这一次用哪组数测”。里程验证中，逻辑场景决定覆盖维度，具体场景决定实际执行次数。
二、层级关系与转化流程
从功能场景到具体场景，通常经历“行为分解—参数识别—参数空间定义—采样与组合—具体化”五个步骤。以“前车紧急制动”为例：功能场景描述为“本车跟随前车行驶，前车突然减速”；逻辑场景提取本车速度、跟车距离、前车减速度、反应时间等参数并给出范围；具体场景则固定为“本车 50 km/h，跟车距离 25 m，前车以 4 m/s² 减速，本车反应时间 1.2 s”。
图中清晰展示了三层场景的抽象收敛关系。需要强调的是，三层之间并非单向流水线，实际工程中常出现“具体场景测试失败后回溯到逻辑场景调整参数空间”的迭代过程。
三、静态场景要素与动态场景要素
无论哪一层场景，其内容都由静态要素和动态要素共同构成。静态要素描述“环境与道路的固定条件”，动态要素描述“交通参与者随时间变化的行为”。二者缺一不可：只有静态要素，场景是空的道路模型；只有动态要素，场景缺少物理约束和感知背景。
| 要素类别 | 典型内容 | 在场景层级中的体现 | 验证关注点 |
|---|---|---|---|
| 静态要素 | 道路几何、车道线、交通标志、信号灯、路沿、建筑、树木、天气、光照 | 功能场景中作为背景描述；逻辑场景中作为离散或连续参数；具体场景中固定取值 | 感知识别率、地图匹配、定位精度、光照鲁棒性 |
| 动态要素 | 本车、前车、旁车、行人、骑行者、动物等交通参与者的位置、速度、加速度、航向 | 功能场景中描述行为意图；逻辑场景中参数化轨迹与交互；具体场景中固定轨迹和时序 | 决策规划合理性、碰撞避免、交互博弈、舒适性 |
| 环境条件 | 雨、雪、雾、夜间、逆光、路面湿滑 | 通常作为逻辑场景的离散参数或具体场景的固定条件 | 传感器衰减、制动距离变化、感知置信度 |
四、案例：路口右转遇行人场景的三层展开
以“本车右转，人行横道有行人通过”为例。功能场景描述为：本车在路口右转，人行横道上有行人正在通过，本车需要避让。逻辑场景提取本车速度、行人速度、人车距离、行人位置、光照条件等参数，并定义范围。具体场景则固定为：本车 20 km/h，行人 1.2 m/s，人车纵向距离 8 m，行人位于人行横道中央，白天晴天。
在里程验证中，一个逻辑场景可能生成数百个具体场景。若只跑一个具体场景，覆盖率极低；若盲目穷举所有参数组合，测试成本不可接受。因此工程上常采用边界值采样、正交实验、拉丁超立方等方法，在参数空间中选取代表性具体场景。
逻辑场景参数空间示例：
ego_speed: [10, 30] km/h, step 5
pedestrian_speed:[0.5, 2.0] m/s, step 0.5
distance: [3, 20] m, step 1
illumination: {day, night, backlight}
weather: {clear, rain, fog}
采样策略：边界值 + 正交表
生成具体场景数：5 × 4 × 18 × 3 × 3 = 3240 组
经正交裁剪后保留：约 120 组代表性案例五、常见误区与复盘
误区一：把功能场景直接当测试用例。功能场景没有参数，无法执行，也无法判定通过与否。它只能作为分类标签和需求输入。
误区二：逻辑场景参数范围拍脑袋。参数范围应来自事故数据、自然驾驶数据、法规限值和系统设计域，否则覆盖率分析失去意义。
误区三：只关注动态要素，忽略静态要素。大量感知失效和定位漂移发生在隧道、逆光、雨雾、标线磨损等静态条件下，静态要素必须纳入场景参数。
误区四：具体场景数量等于测试充分性。具体场景多不代表覆盖好，关键看逻辑场景的参数空间是否被有效探索，边界和组合是否被覆盖。
工程建议：建立“功能场景清单—逻辑场景参数表—具体场景生成脚本”三级资产。功能场景用于与需求对齐，逻辑场景用于覆盖率度量，具体场景用于自动化执行。每次测试失败后，回溯到逻辑场景调整参数边界，再重新生成具体场景，形成闭环迭代。
掌握三层场景的层级关系与静态/动态要素划分，是后续场景生成、覆盖率评估和里程验证指标设计的基础。只有把“测什么、在什么范围内测、具体怎么测”三个问题分开表达又统一管理，才能让智能驾驶测试从经验驱动走向工程化、可度量、可复现。