4、场景构建与编辑：OpenSCENARIO标准介绍、静态场景构建、动态场景编辑、场景库管理

好，咱们进入第四章。这一章我特别想跟你好好聊聊，因为场景构建这件事，说白了就是仿真测试的「灵魂」。你算法再牛，模型再准，场景搭得不对，那测试结果就是自欺欺人。我在项目里见过太多团队，花大价钱买了仿真工具，结果场景库一塌糊涂，最后测试覆盖率连30%都不到。

咱们今天就把这块硬骨头啃下来。从标准到实操，从静态到动态，再到怎么管好你的场景库，一步步来。

4.1 OpenSCENARIO标准介绍

先说说标准。你想想看，如果每家工具厂商都用自己的场景描述格式，那场景库怎么复用？怎么在不同工具间流转？这就是OpenSCENARIO存在的意义。

OpenSCENARIO，全称ASAM OpenSCENARIO，是ASAM（Association for Standardization of Automation and Measuring Systems）制定的标准。目前主流版本是1.x和2.0。我个人习惯用1.1版本，因为生态最成熟，工具支持也最全。

它到底描述什么？简单说，它描述的是「动态内容」——谁在什么时间、什么位置、做什么动作。比如：

  • 主车（Ego Vehicle）在10秒后开始变道
  • 目标车（Target Vehicle）从对向车道驶来，速度50km/h
  • 行人从路边开始横穿马路

嗯，这里要注意：OpenSCENARIO不描述静态道路。道路拓扑、车道线、交通标志这些，是OpenDRIVE的活。两者配合使用，一个管静态，一个管动态。

核心概念：OpenSCENARIO基于「Storyboard」结构。一个场景由多个Story组成，每个Story包含多个Act，每个Act包含多个Maneuver，Maneuver里是具体的Event和Action。这种层级结构，说白了就是「剧本」——谁（Actor），在什么条件下（Trigger），做什么事（Action）。

给你看个最简单的例子，描述一辆车在5秒后加速到60km/h：

<Scenario>
  <Storyboard>
    <Init>
      <Action>
        <PrivateAction>
          <LongitudinalAction>
            <SpeedAction>
              <Target>
                <AbsoluteTargetSpeed value="10"/>
              </Target>
              <TransitionDynamics shape="linear" rate="2"/>
            </SpeedAction>
          </LongitudinalAction>
        </PrivateAction>
      </Action>
    </Init>
  </Storyboard>
</Scenario>

这段代码的意思是：初始状态下，车辆加速到10m/s（约36km/h），加速度2m/s²。你看，XML格式，结构清晰，但写起来确实繁琐。所以我建议你用图形化编辑器来生成，别手写，除非你跟我一样有强迫症。

我的经验：刚开始接触OpenSCENARIO时，别急着写复杂场景。先搭一个最简单的「直道跟车」场景，跑通了再逐步加变道、加切入、加行人。我曾经一口气写了个2000行的复杂场景，结果调试了三天才发现是某个Trigger条件写错了。

4.2 静态场景构建：道路与交通标志

静态场景，就是仿真世界的「舞台」。舞台搭不好，演员（动态物体）再卖力也没用。

静态场景主要包含两部分：道路网络和交通基础设施。

4.2.1 道路网络构建

道路网络用OpenDRIVE描述。核心元素包括：

  • 道路（Road）：由参考线（Reference Line）定义，包含车道（Lane）、路肩（Shoulder）等
  • 交叉口（Junction）：多条道路的连接点，包含连接路径（Connecting Road）
  • 高程（Elevation）：道路的纵向坡度
  • 横坡（Superelevation）：弯道处的横向倾斜

构建时，我一般遵循这个流程：

  1. 确定道路拓扑：直道、弯道、十字路口、环岛？先画草图
  2. 定义参考线：用三次多项式或样条曲线描述道路走向
  3. 配置车道：车道数量、宽度、方向（同向/对向）
  4. 添加连接：交叉口处的车道连接关系
  5. 设置高程和横坡：让道路更真实

举个例子，一段双向四车道的高速公路，单车道宽3.75m，中央分隔带宽2m：

<road id="1" length="1000.0" junction="-1">
  <planView>
    <geometry s="0.0" x="0.0" y="0.0" hdg="0.0" length="1000.0">
      <line/>
    </geometry>
  </planView>
  <lanes>
    <laneSection s="0.0">
      <left>
        <lane id="-1" type="driving" level="false">
          <width sOffset="0.0" a="3.75" b="0.0" c="0.0" d="0.0"/>
        </lane>
        <lane id="-2" type="driving" level="false">
          <width sOffset="0.0" a="3.75" b="0.0" c="0.0" d="0.0"/>
        </lane>
      </left>
      <center>
        <lane id="0" type="median" level="false">
          <width sOffset="0.0" a="2.0" b="0.0" c="0.0" d="0.0"/>
        </lane>
      </center>
      <right>
        <lane id="1" type="driving" level="false">
          <width sOffset="0.0" a="3.75" b="0.0" c="0.0" d="0.0"/>
        </lane>
        <lane id="2" type="driving" level="false">
          <width sOffset="0.0" a="3.75" b="0.0" c="0.0" d="0.0"/>
        </lane>
      </right>
    </laneSection>
  </lanes>
</road>

注意：道路的坐标系是右手系，X轴正向为东，Y轴正向为北，Z轴向上。车道编号有约定：中心线为0，左侧为负，右侧为正。这个搞反了，你的车就会在逆向车道行驶。我曾经犯过这个错，仿真跑起来所有车都在逆行，场面一度非常尴尬。

4.2.2 交通标志与标线

交通标志用OpenDRIVE的<signal>元素描述。包括：

  • 标志类型：限速牌、停止牌、让行牌、红绿灯等
  • 位置：在道路上的纵向位置（s坐标）和横向偏移（t坐标）
  • 属性：限速值、红绿灯相位等

比如，在道路100米处设置一个限速60km/h的标志：

<signal id="1" s="100.0" t="-2.0" dynamic="no" type="274" subtype="-1" value="60" unit="km/h">
  <validity fromLane="-2" toLane="-1"/>
</signal>

这里type="274"是德国标准中限速标志的编码。不同国家的编码体系不同，构建时要注意适配。

4.3 动态场景编辑：车辆与行人轨迹

动态场景，就是给静态舞台配上「演员」和「剧本」。这是OpenSCENARIO的主场。

动态场景的核心要素：

要素 描述 典型参数
车辆 主车、目标车、干扰车 初始位置、速度、加速度、变道时机
行人 横穿、沿路行走、静止 起始点、终点、速度、反应时间
自行车 骑行轨迹、速度变化 路径点、速度曲线
动物 突然闯入（如鹿、狗） 出现位置、移动方向、速度

编辑动态场景，我习惯用「时间-空间」双维度来思考：

  • 时间维度：什么时刻触发动作？触发条件是什么？（距离触发、时间触发、事件触发）
  • 空间维度：动作发生在哪条车道？相对主车的横向/纵向位置？

举个例子，一个典型的「前车切入」场景：

  1. 主车在左车道以100km/h巡航
  2. 目标车在右车道以80km/h行驶，位于主车前方30m
  3. 当两车纵向距离缩短到20m时，目标车开始向左变道
  4. 目标车以0.5m/s²的横向加速度完成变道，用时3秒

这个场景在OpenSCENARIO中，核心就是定义好目标车的变道动作和触发条件。触发条件用<Condition>描述，变道动作用<LaneChangeAction>描述。

避坑指南：我曾经在编辑行人轨迹时，把行人的初始位置设在了车道中间。结果仿真一开始，行人就被主车撞飞了。后来我养成了习惯：所有动态物体的初始位置，一定要检查是否在合法区域内（人行道、路肩等）。

4.4 场景库管理

场景多了，就得管。不然你找场景的时间比跑测试的时间还长。

场景库管理，我总结了三件事：分类、版本、复用。

4.4.1 场景分类

按功能分类，我一般分这几类：

  • 法规场景：Euro NCAP、C-NCAP、NHTSA等法规要求的测试场景
  • 功能场景：针对特定功能（AEB、LKA、ACC）的测试场景
  • 边缘场景：极端天气、传感器失效、特殊路况等
  • 随机场景：参数随机化生成的泛化测试场景

每个场景都要有元数据标签，比如：

标签 示例值
场景ID SCN-AEB-001
功能 AEB
危险等级 高/中/低
天气 晴天/雨天/雪天
光照 白天/夜晚/黄昏
道路类型 高速/城市/乡村
创建日期 2024-03-15
版本 v1.2

4.4.2 版本管理

场景文件也是代码，得用Git管起来。我建议：

  • 每个场景一个独立文件，命名规则统一（如：功能_编号_版本.xml）
  • 场景文件与对应的OpenDRIVE文件放在同一目录
  • 每次修改都要写commit message，说明改了啥、为啥改
  • 重要场景要打tag，比如release_v1.0

4.4.3 场景复用

别重复造轮子。一个场景稍微改几个参数就能变成另一个场景。比如：

  • 把目标车速度从50km/h改成80km/h，就是一个新的测试用例
  • 把直道改成弯道，就是考验车辆弯道性能的场景
  • 把晴天改成雨天，就是考验传感器鲁棒性的场景

我建议用参数化模板来管理。把场景中的关键参数（速度、距离、角度等）提取出来，做成可配置的变量。这样你只需要维护一个模板，然后通过参数组合生成大量场景。

核心思路：场景库不是静态的「仓库」，而是动态的「工厂」。好的场景库，应该能通过参数组合，自动生成覆盖各种工况的测试用例。我见过最牛的场景库，用100个模板生成了超过10000个测试场景，覆盖了90%以上的法规要求。

好了，这一章的内容就到这。场景构建是个细活，急不来。我的建议是：先搭一个最简单的场景跑通流程，然后逐步加复杂度。别一上来就想搞个完美的大场景，那只会让你陷入调试的泥潭。

下一章，咱们聊聊仿真引擎的架构和调度机制，那又是另一片天地了。

← 上一章 📖 返回目录 下一章 →