3. 场景构建基础：场景的定义、组成要素
各位同学，咱们今天聊聊场景构建的基础。说实话，我刚入行那会儿，觉得场景不就是「车在路上跑」嘛。后来踩了不少坑才明白——场景定义是整个仿真测试的基石。你场景搭歪了，后面所有测试结果都是白搭。
3.1 场景到底是什么？
先给个我自己的理解。场景，说白了就是「自动驾驶系统在某个时间片段里，面对的所有外部条件的集合」。它不是一张静态照片，而是一段有起止、有变化的动态过程。
举个例子。你在路上开车，前面有辆车突然急刹——这是一个场景。但如果只是「前面有辆车停着」，那不算完整场景，因为缺少了「突然急刹」这个动态事件。
场景三要素（我个人总结的）：
- 谁在哪儿 —— 道路、交通参与者的位置
- 发生了什么 —— 事件、动作、状态变化
- 环境怎么样 —— 天气、光照、路面条件
嗯，这里要注意：场景和用例不一样。场景是客观描述，用例是「我要测什么」。比如「前车急刹」是场景，「验证AEB在50km/h下能否避免碰撞」是用例。别搞混了。
3.2 场景的五大组成要素
我习惯把场景拆成五个维度来讲。这五个维度缺一个，场景就不完整。你想想看，少了天气，你测出来的结果能代表雨天吗？不能。
3.2.1 道路要素
道路是场景的「舞台」。没有路，车往哪儿开？
道路要素包括：
- 道路类型：高速公路、城市道路、乡村道路、匝道、环岛
- 车道结构：车道数、车道宽度、车道线类型（实线/虚线/双黄线）
- 路面条件：干燥、湿滑、积雪、结冰、坑洼
- 几何特征：直道、弯道（曲率）、坡度、超高
- 附属设施：护栏、路肩、隧道、桥梁、收费站
我的经验： 做高速公路场景时，别忘了匝道口的曲率变化。我曾经有个项目，所有直道场景都过了，一上匝道就偏——因为匝道曲率半径太小，控制算法没适配。后来我们在场景库里专门加了一组「小曲率匝道」场景。
3.2.2 交通参与者要素
交通参与者就是「舞台上的人」。不只是车，还有行人、自行车、动物……
我一般把它们分成三类：
| 类别 | 典型对象 | 关键属性 |
|---|---|---|
| 机动车 | 轿车、卡车、公交车、摩托车 | 速度、加速度、转向角、尺寸、类型 |
| 非机动车 | 自行车、电动滑板车 | 速度、轨迹、是否突然变向 |
| 行人 | 成人、儿童、推婴儿车、宠物 | 位置、朝向、运动意图、遮挡情况 |
这里有个坑。很多新手只关注「车」，忽略了行人。我遇到过最头疼的场景是「儿童从停放的车辆之间突然冲出」——这个场景里，行人的初始位置是被遮挡的，感知系统根本看不到。你如果不把「遮挡」这个属性加进去，场景就失真了。
3.2.3 环境要素
环境要素是「舞台的灯光和布景」。它直接影响传感器的感知质量。
- 光照条件：白天、黄昏、夜晚、逆光、隧道出入口的光照突变
- 天气现象：晴天、雨天、雪天、雾天、霾、沙尘
- 温度湿度：极端高温/低温对传感器性能的影响
- 电磁干扰：隧道内、高压线附近的信号干扰
避坑指南： 我曾经在测试一个L4级系统时，所有白天场景都通过了。结果一测夜间场景，感知召回率直接掉了30%。原因很简单——训练数据里夜间样本太少。所以，环境要素不是「锦上添花」，是「必须覆盖」。
3.2.4 天气要素
天气和环境有重叠，但我习惯单独拎出来讲。为什么？因为天气对自动驾驶的影响太直接了。
我列几个关键天气参数：
- 降雨强度：小雨（0-2.5mm/h）、中雨（2.5-10mm/h）、大雨（>10mm/h）
- 能见度：>1000m（良好）、500-1000m（一般）、<500m（差）
- 路面摩擦系数：干燥0.7-0.8、湿滑0.4-0.6、积雪0.2-0.3、结冰<0.2
- 侧风风速：>10m/s 时对车辆稳定性有影响
嗯，这里有个细节。雨量不是越大越危险。我见过一个案例，小雨+路面油污，比大雨更滑。因为小雨把路面上的油膜浮起来了，形成一层「润滑剂」。所以场景设计时，不能只看「下没下雨」，要看「路面状态」。
3.2.5 事件要素
事件是场景的「剧情」。没有事件，场景就是静态的，测不出动态响应。
事件分为两类：
- 触发事件：前车急刹、行人横穿、车辆切入、红绿灯变化
- 响应事件：自车减速、变道、紧急制动、转向避让
事件设计有个原则——「合理但不意外」。什么意思？就是事件要符合交通逻辑，不能为了难而难。比如「前车在高速上突然倒车」，这种场景现实中极少发生，测了也没太大意义。
我个人常用的场景事件模板：
事件ID: EVT-001
事件类型: 前车急刹
触发条件: 自车与前车距离 < 30m，且相对速度 > 10km/h
前车动作: 以 -6m/s² 减速至 0
自车预期: 在 2.5s 内完成制动，避免碰撞
环境约束: 路面干燥，能见度良好3.3 场景的层次结构
最后聊一下场景的层次。我习惯把场景分成三层：
- 功能场景：用自然语言描述，比如「车辆在高速公路上遇到前车急刹」
- 逻辑场景：用参数范围描述，比如「前车速度 60-120km/h，减速度 4-8m/s²」
- 具体场景：用具体数值描述，比如「前车速度 80km/h，减速度 6m/s²」
为什么要有这三层？因为测试需要「覆盖度」。你不可能把所有参数组合都跑一遍，但你可以用逻辑场景定义参数空间，然后采样生成具体场景。这叫「场景泛化」。
我的建议： 刚开始做场景库时，别贪多。先搭20个核心功能场景，每个场景覆盖3-5个参数变体。跑通了再扩展。我见过有人一上来就搭了500个场景，结果一半是重复的，一半是无效的——浪费时间。
好了，场景的定义和组成要素就讲到这里。下一节咱们聊聊怎么用工具把这些场景搭出来。记住一句话：场景不是越多越好，是越「对」越好。