📚 课程目录第3章标准体系

3. 标准体系

在动态场景开发工程中，ASAM OpenSCENARIO 是描述“车辆、行人、环境如何随时间运动与交互”的行业标准。理解 1.x 与 2.x 的差异、XML 架构、核心元素与文件结构，是后续编写、校验、仿真与回放场景的基础。本节从标准演进、架构组成、核心元素、文件组织四个角度展开，并给出可直接对照的工程要点。

一、核心原理：1.x 与 2.x 的定位差异

OpenSCENARIO 1.x 以 XML 为唯一载体，采用“Storyboard—Story—Act—Maneuver—Event—Action”的层级叙事结构，强调用“剧本”方式描述场景。它的优势是语义直观、工具链成熟，适合确定性场景与法规测试；不足是 XML 层级深、复用粒度粗、难以表达大规模参数化与组合场景。

OpenSCENARIO 2.x 则引入领域特定语言（DSL），以“声明式 + 可组合”为核心，支持场景片段（Scenario Fragment）、抽象与继承、参数化与约束求解。2.x 不再强制以 XML 作为唯一表达，而是通过编译器生成中间表示，再映射到仿真器。它更适合大规模场景库、随机化测试与持续集成。两者并非简单替代：1.x 仍是大量现有工具与项目的实际交换格式，2.x 代表未来方向。

工程判断：若项目需要与现有仿真器、测试管理平台快速对接，优先使用 1.x XML；若需要构建可复用、可组合、可参数化的场景库，应评估 2.x DSL 及其编译链。

二、XML 架构：1.x 的骨架与约束

1.x 的 XML 架构由 XSD 定义，根元素为 <OpenSCENARIO>，其下通常包含 FileHeader、ParameterDeclarations、CatalogLocations、RoadNetwork、Entities、Storyboard 等一级节点。XSD 规定了元素顺序、必选/可选、类型与取值约束，因此“顺序错误”是常见校验失败原因。

<OpenSCENARIO>
  <FileHeader revMajor="1" revMinor="2" date="2024-06-01T10:00:00"
              description="Cut-in scenario" author="scenario-team"/>
  <ParameterDeclarations>
    <ParameterDeclaration name="EgoSpeed" parameterType="double" value="13.89"/>
  </ParameterDeclarations>
  <CatalogLocations>...</CatalogLocations>
  <RoadNetwork>
    <LogicFile filepath="maps/highway.xodr"/>
  </RoadNetwork>
  <Entities>...</Entities>
  <Storyboard>...</Storyboard>
</OpenSCENARIO>

其中 FileHeader 的 revMajor/revMinor 决定了解析器按哪个版本规则校验；ParameterDeclarations 提供全局参数；CatalogLocations 指向车辆、行人、控制器等目录；RoadNetwork 绑定 OpenDRIVE 地图；Entities 定义场景中的参与者；Storyboard 承载全部动态行为。

三、核心元素：从实体到动作的映射

1.x 的核心元素可归纳为“实体—行为—触发—条件”四类。ScenarioObject 描述车辆或行人，并挂接 Vehicle、Pedestrian、Controller 等类型；Init 中的 Private 与 TeleportAction 决定初始位姿；Storyboard 下的 Story、Act、ManeuverGroup、Maneuver、Event、Action 构成行为树；Trigger 与 Condition 决定事件何时发生。

2.x 的核心概念则转向 scenario、actor、behavior、phase、constraint 等，强调“谁在什么条件下做什么”，并通过组合与继承减少重复。下表给出关键对照：

维度	OpenSCENARIO 1.x	OpenSCENARIO 2.x
表达载体	XML + XSD	DSL，可编译为中间表示
组织方式	Storyboard 层级叙事	场景片段组合与继承
参数化	ParameterDeclaration 为主	参数、约束、求解器协同
复用粒度	Catalog 与文件级复用	片段级、行为级复用
适用场景	确定性法规与回归测试	大规模随机化与组合测试

四、文件结构与工程组织

一个可维护的 1.x 场景工程通常按“地图、目录、场景、参数、结果”分层组织。地图使用 .xodr；车辆、行人、控制器等复用资产放入 Catalogs；具体场景以 .xosc 保存；参数可外置为 .json 或 .yml 供批量生成；仿真输出与校验日志单独存放。这样做的目的是让“场景逻辑”与“资产数据”解耦，便于版本管理与 CI 校验。

project/
├── maps/
│   └── highway.xodr
├── catalogs/
│   ├── vehicles/
│   └── controllers/
├── scenarios/
│   ├── cut_in.xosc
│   └── pedestrian_cross.xosc
├── params/
│   └── cut_in_params.json
└── results/
    └── validation.log

在 2.x 工程中，目录结构会额外出现 .osc 源文件、编译配置与生成的中间文件，但“地图—资产—场景—参数—结果”的分层思想仍然适用。

五、案例：同一“切入”场景的两种写法

以“主车匀速行驶，旁车从左侧切入”为例。1.x 写法需要在 Storyboard 中定义 Act，用 LaneChange 动作配合 RelativeDistance 触发条件；2.x 写法可先定义“切入”片段，再通过参数指定切入距离、速度差与触发时机，最后组合成完整场景。前者结构清晰但重复度高，后者复用性强但需要编译器支持。

实操建议：先用 1.x 把场景跑通并验证触发逻辑，再评估是否迁移到 2.x。迁移时优先抽取“可参数化的行为片段”，而不是逐行翻译 XML。

六、误区与复盘

误区一：把 2.x 当作 1.x 的新版本号。两者在表达范式、工具链与适用场景上差异显著，不能简单替换。
误区二：忽略 XSD 顺序约束。1.x 对元素顺序敏感，FileHeader 必须位于最前，Storyboard 通常位于最后。
误区三：参数全部硬编码。应把速度、距离、触发阈值外置，便于批量生成与回归测试。
误区四：地图与场景版本不匹配。OpenDRIVE 地图的坐标系、车道编号变化会直接导致场景失效，需在 CI 中做一致性校验。

校验要点：使用 XSD 校验 1.x 文件时，务必确认 revMajor/revMinor 与 XSD 版本一致；2.x 则需确认编译器版本与 DSL 语法版本匹配，否则会出现“语法通过但语义失败”的隐蔽问题。

综上，掌握 1.x 与 2.x 的差异，关键不是记住版本号，而是理解“XML 叙事”与“DSL 组合”两种范式；掌握 XML 架构，关键是把 XSD 顺序、参数声明与目录引用用对；掌握核心元素与文件结构，关键是让场景逻辑、复用资产与地图数据各归其位。这样在后续编写、校验与迁移场景时，才能既跑得通，也管得住。