4、场景构建与测试：OpenSCENARIO 标准、场景编辑器使用、典型测试场景库设计

大家好，我是你们的老朋友。今天咱们聊聊场景构建与测试。说实话，这一块是仿真里最「接地气」也最「磨人」的环节。你想想看，算法写得再漂亮，没有好的场景去验证，那就是纸上谈兵。我在项目里见过太多「仿真跑得飞起，实车一上路就翻车」的案例，根源往往就是场景没设计好。

4.1 OpenSCENARIO 标准：场景的「通用语言」

先说说标准。为什么需要 OpenSCENARIO？说白了，就是为了让场景能跨平台、跨工具复用。你不可能在 VTD 里写一套场景，换到 CARLA 又重写一遍吧？

OpenSCENARIO 是一个 XML 格式的标准，用来描述动态场景。它定义了：

车辆、行人、障碍物的初始位置和状态
行为逻辑：比如「前车在 5 秒后开始减速」
道路环境：天气、光照、路面附着系数等

我个人习惯把 OpenSCENARIO 文件拆成三块来看：

模块	作用	示例
Storyboard	定义故事线，谁在什么时候做什么	主车直行，目标车切入
Entities	定义所有参与者的属性	车辆型号、尺寸、传感器配置
Actions	定义具体动作	加速、减速、变道、转向

嗯，这里要注意：OpenSCENARIO 1.0 和 1.1 版本在动作描述上有差异。1.1 版本引入了更丰富的条件触发机制。我曾经在迁移旧场景时踩过坑——1.0 的 Condition 写法在 1.1 里直接报错。所以建议新项目直接用 1.1。

核心要点：OpenSCENARIO 不是用来描述静态地图的（那是 OpenDRIVE 的事），它只负责「动」的部分。两者配合使用，才能构成完整的仿真场景。

4.2 场景编辑器使用：从「手写 XML」到「拖拽生成」

早期我做场景，都是手写 XML。那叫一个痛苦。一个简单的切入场景，光坐标对齐就要折腾半天。后来有了场景编辑器，效率提升不止一个量级。

目前主流的场景编辑器有：

ESMINI：开源，轻量，适合快速原型
VTD Scenario Editor：商业软件，功能强大，但学习曲线陡
CARLA Scenario Runner：Python 脚本驱动，灵活度高

我个人比较推荐 ESMINI 入门。它的操作逻辑很直观：

导入 OpenDRIVE 地图文件
在地图上放置车辆、行人
设置轨迹点（waypoints）
添加触发条件（比如「距离小于 20 米时开始减速」）
导出为 OpenSCENARIO 文件

举个例子，一个典型的「前车急刹」场景，在编辑器里大概长这样：

<Scenario name="EmergencyBrake">
  <Entities>
    <Entity name="Ego" type="vehicle"/>
    <Entity name="Target" type="vehicle"/>
  </Entities>
  <Storyboard>
    <Init>
      <Action entity="Ego">
        <Position x="0" y="0" h="0"/>
        <Speed value="15"/>
      </Action>
      <Action entity="Target">
        <Position x="30" y="0" h="0"/>
        <Speed value="10"/>
      </Action>
    </Init>
    <Story name="BrakeEvent">
      <Act>
        <Condition>
          <ByEntity>
            <RelativeDistance entity="Ego" to="Target" value="15"/>
          </ByEntity>
        </Condition>
        <Action entity="Target">
          <Brake intensity="0.8"/>
        </Action>
      </Act>
    </Story>
  </Storyboard>
</Scenario>

你可能会问：「手写和编辑器生成，哪个更好？」我的答案是：编辑器用于快速搭建，手写用于精细调参。编辑器生成的 XML 往往有冗余字段，手写可以精简。但反过来，编辑器能帮你避免语法错误。

小技巧：先用编辑器搭出场景骨架，导出后再用文本编辑器微调。我一般会保留一份「手写模板」，把常用的动作块（比如变道、切入、减速）存成代码片段，需要时直接粘贴。

4.3 典型测试场景库设计：你的「场景弹药库」

场景库设计，说白了就是把你需要的测试场景分门别类存好。我见过很多团队，场景散落在各个工程师的本地文件夹里，命名混乱，版本不明。结果就是：A 测过的场景，B 找不到；C 改了一个参数，D 不知道。

一个规范的场景库，应该包含以下维度：

分类维度	说明	示例
功能类型	按自动驾驶功能划分	ACC、LKA、AEB、NOA
危险等级	按碰撞风险划分	安全、临界、危险
道路类型	按场景发生地点划分	高速、城市、乡村、隧道
天气条件	按环境因素划分	晴天、雨天、雪天、夜间

我个人习惯用「功能类型 + 危险等级」作为一级目录。比如：

scenario_library/
├── AEB/
│   ├── safe/
│   │   ├── aeb_straight_clear.xosc
│   │   └── aeb_curve_clear.xosc
│   ├── critical/
│   │   ├── aeb_straight_occluded.xosc
│   │   └── aeb_curve_occluded.xosc
│   └── dangerous/
│       ├── aeb_pedestrian_jaywalk.xosc
│       └── aeb_cyclist_cutin.xosc
├── LKA/
│   ├── safe/
│   └── ...
└── NOA/
    └── ...

为什么要这样设计？因为你在做回归测试时，可以按危险等级筛选。比如发布前，必须跑完所有「dangerous」级别的场景。我曾经吃过亏——有一次发布前只跑了「safe」场景，结果实车测试时在「critical」场景里出了事故。从那以后，我把场景分级写进了流程规范。

避坑指南：场景库不是「一次性」的。随着算法迭代，旧场景可能失效（比如感知范围变了，原来 50 米的触发距离现在变成 80 米）。我建议每两个迭代周期做一次场景库审计，删除无效场景，补充新场景。

4.4 知识体系总览

下面这张图，是我自己梳理的场景构建与测试的核心逻辑。你可以把它当作本章的「地图」：

从图上你能看到，整个流程是「输入 → 构建 → 管理 → 应用」的闭环。地图、标准、模型是原材料，编辑器是加工工具，场景库是成品仓库，最终服务于仿真测试。

好了，这一章的内容就到这里。场景构建这件事，没有捷径，就是多搭、多测、多积累。你搭的场景越多，对算法的理解就越深。希望今天的分享能帮你少走一些弯路。

可可精品资料库

📚 课程目录

4、场景构建与测试：OpenSCENARIO 标准、场景编辑器使用、典型测试场景库设计

4.1 OpenSCENARIO 标准：场景的「通用语言」

4.2 场景编辑器使用：从「手写 XML」到「拖拽生成」

4.3 典型测试场景库设计：你的「场景弹药库」

4.4 知识体系总览