OpenSCENARIO 是什么:自动驾驶仿真测试中的“剧本语言”

OpenSCENARIO 是 ASAM 推出的开放标准，用于描述自动驾驶、辅助驾驶和交通仿真中的动态场景。简单说，它不是仿真软件，也不是渲染引擎，而是一种“场景剧本格式”：它规定在某个道路环境中，哪些车辆、行人、交通灯、天气条件、触发事件和行为动作应该如何发生。其核心作用是让不同仿真平台、测试工具和车企之间能够用统一方式描述、交换和复现实验场景。ASAM 官方将其定位为驾驶仿真应用中动态内容的描述标准，主要用于 ADAS、自动驾驶和自主车辆的虚拟开发、测试与验证。

1. 测试场景可复现

很多人一听仿真，就先想到 3D 场景、传感器渲染、逼真光照、车流画面。但 OpenSCENARIO 关心的重点不是“画得像不像”，而是测试事件是否被准确描述。

例如，一个典型自动驾驶测试场景可能是：

一辆自车以 80 km/h 在高速公路中间车道行驶，前方车辆突然减速，右侧车辆并线切入，自车需要判断是否制动、换道或保持车道（语义描述）。这个场景里真正重要的不是建筑材质多精细，而是车辆初始位置、速度、触发条件、变道动作、制动行为、时间关系和评价指标（量化描述）。

OpenSCENARIO 就是用来描述这些内容的。它可以定义车辆、行人等交通参与者，指定速度变化、换道、跟车、停车、路径跟随、交通灯变化、环境条件变化等动态行为。ASAM 官方说明，OpenSCENARIO XML 主要用于描述涉及多车辆、行人和其他交通参与者的复杂同步机动行为，并支持基于驾驶员动作或轨迹的场景描述。

2. OpenSCENARIO 与 OpenDRIVE 的区别

理解 OpenSCENARIO，必须把它和 OpenDRIVE 分开。

OpenDRIVE 描述“路是什么样”，包括道路几何、车道、路口、道路连接关系、交通标志、静态道路网络等。ASAM 官方把 OpenDRIVE 定义为静态道路网络描述标准，文件格式通常是 .xodr 或 .xodrz。

OpenSCENARIO 描述“路上发生了什么”，包括车辆如何运动、何时触发某个动作、交通参与者之间如何交互、测试何时开始和结束等。OpenSCENARIO XML 的文件格式通常是 .xosc，OpenSCENARIO DSL 的文件格式通常是 .osc。

所以可以这样理解：

如果一个自动驾驶仿真系统只有 OpenDRIVE，没有 OpenSCENARIO，那么它只有“地图”，没有“测试事件”；如果只有 OpenSCENARIO，没有 OpenDRIVE，它可以描述事件逻辑，但缺少具体道路承载环境。

3. OpenSCENARIO 的基本结构

以 OpenSCENARIO XML 为例，它通常采用分层结构组织场景。ASAM 官方文档提到，场景描述可组织为 storyboard，并进一步细分为 stories、acts 和 sequences；事件由条件触发，动作则描述具体发生什么，例如变道、超车、减速、驶向某个位置或改变交通灯状态。

可以粗略理解为：

Entities：谁参与场景

包括自车、目标车、行人、骑行者、障碍物等。

Road / Environment：在哪里发生

通常关联 OpenDRIVE 地图，也可以指定天气、光照、道路摩擦系数等环境条件。

Storyboard：剧情如何推进

描述测试开始后，不同参与者在什么条件下做什么动作。

Trigger：什么时候触发

比如距离前车小于 20 米、仿真时间达到 5 秒、自车速度超过 60 km/h、车辆到达某个位置等。

Action：触发后做什么

比如目标车变道、自车制动、行人横穿、交通灯变红、前车减速等。

Parameter：哪些变量可以变化

例如初始速度、跟车距离、切入时间、制动减速度等。参数化是 OpenSCENARIO 的关键价值之一，因为它允许一个基础场景生成大量测试变体，而不是手工写成百上千个文件。

4. OpenSCENARIO XML 与 OpenSCENARIO DSL

OpenSCENARIO 目前不是单一形态，而是并行存在两个标准：OpenSCENARIO XML 和 OpenSCENARIO DSL。ASAM 在 2024 年宣布将原 OpenSCENARIO 1.x 和 2.x 拆分为两个独立标准：1.x 对应 XML，2.x 对应 DSL，二者不要求正式迁移或强制融合。

截至目前，ASAM OpenSCENARIO XML 的当前版本是 1.3.1，发布日期为 2024 年 11 月 21 日；ASAM OpenSCENARIO DSL 的当前版本是 2.2.0，发布日期为 2026 年 3 月 19 日。

二者差异很重要：

ASAM 官方也明确区分了二者：OpenSCENARIO XML 更适合描述可预测、高精度、可与外部测试规范配合使用的场景；OpenSCENARIO DSL 则面向自动驾驶和 ADAS 的大规模安全与功能验证，强调组合复用、抽象场景、KPI、检查项和覆盖度指标。

5. 为什么自动驾驶测试需要 OpenSCENARIO

自动驾驶测试的难点不是“跑几个 demo”，而是如何证明系统在大量复杂、危险、边缘场景中具有足够安全性。真实道路测试成本高、风险高、覆盖效率低，因此行业必须依赖虚拟仿真、场景库和自动化测试。

OpenSCENARIO 的价值主要体现在四点。

第一，提高场景复现能力。同一个 cut-in、AEB、ACC、行人横穿、无保护左转场景，可以被标准化描述，并在不同工具链中重复执行。

第二，降低供应商绑定风险。如果场景只存在某一家仿真软件的私有格式里，车企或测试机构就会被工具生态锁死。OpenSCENARIO 作为公开、厂商中立标准，有助于场景资产跨平台迁移。ASAM 官方也强调，OpenSCENARIO XML 是公开开发、供应商无关的标准，适合用于安全验证相关的场景库定义。

第三，支持参数化与批量测试。例如同一个并线场景，可以把切入距离设置为 10 m、15 m、20 m，把前车速度设置为 40 km/h、60 km/h、80 km/h，把天气设置为晴天、雨天、夜间。这样，一个基础场景就能扩展为大量测试用例。

第四，支撑法规、认证和评价体系建设。自动驾驶安全验证最终需要可解释、可审计、可复现的测试证据。标准化场景语言比口头描述、视频说明或私有脚本更适合进入认证和工程闭环。

6. 局限

OpenSCENARIO 很重要，但不要神化它。

第一，它不负责物理真实性。车辆动力学、传感器模型、雷达反射、摄像头成像、轮胎路面作用、控制器延迟，这些不是 OpenSCENARIO 本身解决的问题。

第二，它不保证不同仿真器结果完全一致。ASAM 官方也指出，虽然标准化格式能够清晰描述机动行为，但不同仿真器的仿真结果不一定相同。这是因为执行引擎、车辆模型、交通流模型、控制器接口、碰撞判定和时间步长都可能不同。

第三，它更偏测试描述，不等于场景生成智能。OpenSCENARIO 可以描述场景，但如何从真实事故、自然驾驶数据、corner case 挖掘、生成式模型中自动构建高价值场景，是另一套问题。

第四，XML 版本的表达能力相对偏“具体执行”，复杂场景写起来会臃肿；DSL 版本更适合抽象和组合，但工具链成熟度、解析器支持、工程落地仍需要看具体平台能力。近期也有研究关注如何把 OpenSCENARIO 2.1 DSL 编译到 CARLA 等开源仿真平台中，这侧面说明 DSL 的表达能力更强，但工程生态仍在建设过程中。

结论

OpenSCENARIO 的本质是自动驾驶仿真测试中的动态场景描述标准。它负责把“谁在什么道路环境下、什么时候、因为什么条件、做了什么动作、测试如何评价”写成可执行、可交换、可复现的标准化场景。它的价值不在于让画面更真实，而在于让测试场景资产标准化、参数化和工程化。

对普通仿真项目来说，OpenSCENARIO XML 已经足够承担大量确定性场景测试；对面向自动驾驶安全验证、场景库建设和大规模 V&V 的高级项目，则需要关注 OpenSCENARIO DSL。