51TECH是
一款技术专栏内容
对最前沿、最硬核的技术进行全实战解析
我们相信技术的变革力量
我们信仰技术的向善美好
我们希望将最宝贵的经验和思考，与行业共享
就在
51TECH
有什么技术，能确保一辆自动驾驶汽车安全行驶？
仿真测试，为什么成为了研发自动驾驶的必选项？
从0到1，制定一套行业标准，是一种怎样的体验？
……
本期51TECH邀请到的嘉宾是51Sim高级研发经理毛祖秋。毛祖秋参与OpenX系列标准的OpenSCENARIO标准制定，并多次担任SubgroupF Leader。
毛祖秋将从第一视角，讲述OpenSCENARIO诞生的背后故事，发展演变历程，以及背后的技术逻辑和理论逻辑。
干货满满~千万不要错过！
51Sim高级研发经理毛祖秋：
在真正介绍OpenSCENARIO之前，我想先简单聊聊自动驾驶安全测试。
近年来，伴随技术发展和商业化的快速落地，自动驾驶变得不再遥不可及。身处北京亦庄，扫码下单就有可能打到一辆无人驾驶出租车。更不要提，售价在20万以上的新能源汽车，其标配和宣传的亮点之一就是智能辅助驾驶系统。
当一项先进的技术开始脱离实验室，真正走向千家万户，确保其安全和可靠就变得至关重要。更直接一点说，一辆由自动驾驶系统驱动的汽车，如何能比人类司机更靠谱？
兰德公司提出：自动驾驶系统需要完成110亿英里的里程测试才能比人类驾驶员更可靠。然而，在实际道路上进行大规模测试并不容易，危险、成本高不说，效率低，耗时还长。那么，有没有什么办法能够更高效、安全、低成本地实现自动驾驶测试？
这里就需要引出我们本篇文章的主角之一——仿真测试。
自动驾驶仿真测试，即通过虚拟环境模拟不同的交通场景、道路条件、天气光照和异常情况，评估自动驾驶系统在各种情况下的功能、反应和决策能力。虚拟环境中进行测试，不仅可以保障安全，还能大幅降低测试成本，提高效率。
因此，仿真测试成为了解决自动驾驶安全问题的重要方案。
▲云仿真高并发
那么，如何实现可衡量的自动驾驶安全测试？目前已经完成了哪些测试？如何进行测试的调整和改进，以最大程度地提高覆盖率？如何确保量产交付的安全性？接下来我将详细解答。
Part.1 从里程的数量到覆盖的质量——自动驾驶安全测试的一场质变为了达到可衡量安全测试，行业当前的趋势是从基于里程数量的测试转向基于场景覆盖质量的测试。
- 基于里程的数量
传统的自动驾驶安全测试方法通常以测试车辆行驶的里程数为指标。也就是，需要在实际道路上驾驶自动驾驶车辆，记录并累积行驶里程。
这种方法的优势是可以获得大量的数据，但存在时间和成本上的挑战。同时，相同里程数下，平平淡淡的一公里和危险重重的一公里所产生的边际效应是不一样的。仅依靠里程数无法保证测试覆盖所有可能的情况和场景。
- 基于覆盖的质量
基于覆盖的质量是一种更为细致和全面的自动驾驶安全测试方法。
它关注的是测试覆盖的质量，即系统是否经历了各种可能的情况和场景。通过定义一系列测试用例和测试场景，这种方法可以确保自动驾驶系统在各种路况、交通情况和异常情况下进行测试。覆盖的质量可以包括路况变化、交通行为、特殊天气条件、紧急情况等方面。
基于场景覆盖的质量的方法强调全面性和深度，可以检测到更多潜在的问题和边界情况。它可以通过模拟和仿真技术来实现，减少对实际道路测试的依赖，并提供更高效、安全和可控的测试环境。通过定义和执行一系列具有高覆盖率的测试用例和场景，开发人员可以更全面地评估自动驾驶系统的性能、安全性和可靠性。
Part.2 场景方案：从PEGASUS，ISO到ASAM这里就牵涉到一个关键问题，什么是场景？
场景，是指在执行动态驾驶任务时，与自动驾驶车辆相关的情景序列及其交互方式。
它描述了道路、交通设施、天气条件、交通参与物等外部状态，以及自动驾驶车辆的驾驶任务和状态等信息。场景以空间和时间维度描述了人-车-路-环境之间复杂动态关系的模型，它是自动驾驶汽车产品研发和功能实现的基础。
如何制定基于场景的标准和方法？不同的组织、机构，做了不同的尝试。
01. 欧盟PEGASUS项目
PEGASUS（天马项目）由德国联邦经济与能源部（BMWi）牵头启动。
它将场景模型分为六层：道路层、交通基础设施层、临时操作的交通设施层、可移动对象层、环境层、数字信息层。
▲PEGASUS场景六层模型
PEGASUS系统分析自动驾驶汽车不同研发阶段的测试需要，进一步将场景分为三个抽象等级，从高到低分别为功能场景、逻辑场景和具体场景。通过将结构化的功能场景与参数范围相结合，可以生成逻辑场景。而逻辑场景则可以通过从参数范围中选择具体值来转换为具体场景。
02. ISO（国际标准化组织）
ISO还制定了一系列与自动驾驶测试场景相关标准，包括3450x系列：34501-场景词汇、34502-基于场景的安全验证框架、34503-设计运行范围分类方法、34504-场景分类、34505-场景评估以及测试场景生成。
ISO21448预期功能安全（SOTIF），还将场景分为了已知安全、已知危险、未知安全、未知危险四大类，希望通过不断发现更多的已知危险场景，从而缩小未知危险场景区域，提高系统的安全性。
03. ASAM（德国自动化及测量系统标准协会）
实际发展过程中，各家整车厂、供应商以及仿真工具商使用的数据格式与接口五花八门，很难统⼀标准。
基于此，德国自动化及测量系统标准协会（ASAM）推出了仿真领域的OpenX系列标准，并获得了全球的关注。其中，OpenSCENARIO场景标准应运而生。
某种程度上说，OpenSCENARIO的出现，是自动驾驶仿真的分水岭。
▲ASAM OpenSCENARIO1.x和2.x路线图
相应地，国内C-ASAM工作组由中汽中心联合ASAM共同成立，也在积极筹划中国特色的场景标准，定期向国内成员更新ASAM标准研究进展，促进国际合作。
2018年，我所在的公司——51Sim对外发布了全国第⼀款全模块自动驾驶仿真测试平台SimOne，由此开启了与ASAM的紧密合作。作为国际组织ASAM会员单位、C-ASAM早期会员单位，我们一直在积极参与ASAM标准的制定。而我本人，也深度参与其中，多次担任Subgroup Leader，也见证了OpenSCENARIO标准的一路发展。
经过几年的发展，OpenX因其良好的工程化和标准化，成为了自动驾驶仿真场景的事实工业标准。
Part.3 ASAM OpenSCENARIO自发布以来，OpenSCENARIO已经进行了多次的迭代与修订。接下来，我整体介绍一下，ASAM OpenSCENARIO的发展演变史。
01. OpenSCENARIO1.0
OpenSCENARIO定义了⼀个标准的仿真测试场景格式，具体用于描述驾驶模拟应用程序中动态内容，兼容不同的仿真测试软件。适用场景主要包括动作、轨迹（多段线、回旋线）、车辆（几何、类型、轴、性能）、驾驶员（状态）、环境（天气、时间、路况）等。同时OpenSCENARIO也是自动驾驶仿真领域知识的沉淀和总结。
OpenSCENARIO1.0（现已更名为OpenSCENARIO XML）中用于动作描述的数据以分层结构组织，并以XML文件格式序列化。XML文件可以通过仿真工具和内容编辑器轻松地进行验证和编辑，导入和导出。该格式与技术和供应商无关。
▲OpenSCENARIO1.x架构图
OpenSCENARIO场景一句话描述就是：谁（行人、车辆、自行车），在哪儿（地图），什么时候（条件），干什么（动作）。
在ASAM的OpenX标准中，OpenSCENARIO用于描述动态内容，OpenDRIVE用于描述静态内容的道路网络，OpenCRG用于描述静态内容的路面。这三个标准互为补充，共同涵盖了环境仿真应用中的静态和动态内容。
▲OpenX静态和动态内容标准
02. OpenSCENARIO1.1
参数化和采样是实现场景泛化的重要方法。迭代更新的OpenSCENARIO1.1支持逻辑场景，并且提供了随机和确定分布来描述参数的分布情况。通过定义参数分布类型和取值范围，可以在仿真过程中生成各种变量，从而创建多样化的场景。
通过使用随机分布，可以对参与者的行为参数进行随机化，以模拟现实世界中的不确定性和变化性。例如，可以通过描述车辆的速度、加速度、转向角等行为参数的分布情况，在不同的仿真实例中生成不同的行为。
我在ASAM OpenSCENARIO1.1标准工作组的主要工作就是参与逻辑场景部分的标准制定。
▲逻辑场景泛化流程
03.OpenSCENARIO2.0
▍引入DSL（领域特定语言）
然而，随着大数据和人工智能的发展，传统的测试方法已经无法满足当前的需求。为了更好地描述和定义自动驾驶系统的仿真测试，需要采用更高级别的场景描述方式，即领域特定语言（DSL）。DSL是一种专门用于解决特定领域问题的编程语言。
OpenSCENARIO 2.0（现已更名为OpenSCENARIO DSL）引入了DSL作为一种描述自动驾驶场景和仿真的语言。这套DSL语言能够满足开发人员、认证机构、工具提供商、场景生成者等多方参与者的需求，提供领域相关的抽象和语法，以便更好地描述和定义自动驾驶领域的概念和行为。OpenSCENARIO 2.0具有以下特点：
- 支持高级抽象描述；
- 是一种编程语言；
- 是一种声明式语言，描述应该发生什么而不是指示如何发生；
- 是一种基于约束的语言，可以对参数指定约束条件，以更抽象的方式定义场景，创建一个涵盖许多具体场景的场景模型；
- 是一种面向切面（aspect-oriented）的编程语言，可以在不破坏场景的原始描述的情况下修改其行为，以完成特定目的。
▍场景抽象级别
▲场景的4个抽象等级
对场景进行抽象化意味着扩大场景表达的空间，而对场景进行具体化意味着缩小场景表达的空间。
举个例子来说，考虑两个场景：场景A和场景B。如果场景A所包含的合法表达空间是场景B所包含的合法表达空间的子集，那么场景A是场景B的具体化。反之，如果场景A所包含的表达空间是场景B所包含的合法表达空间的超集，那么场景A是场景B的抽象化。具体化和抽象化形成了一个抽象程度连续的谱，类似于光谱的连续性。
为了在这个谱上提供更多结构，定义了不同的抽象级别。最常见的抽象级别包括具体场景（Concrete）、逻辑场景（Logical）和抽象场景（Abstract）。
▲OpenSCENARIO1.1和2.0的具体场景，逻辑场景和抽象场景
▍SOTIF和抽象场景表达未知危险
具体场景和逻辑场景在表达未知危险方面都存在一定的限制，因为一旦参数类型和值确定，并且存在多个约束，表达空间就相对受限。
抽象场景的抽象性使其能够容纳更多的变化和不确定性，从而为具体化未知危险提供了空间。通过在抽象场景中考虑更广泛的可能性和潜在风险，可以更好地应对自动驾驶系统可能面临的未知情况和危险。
用户可能希望根据SOTIF（预期功能安全）探索未知或意外情况，并可以通过以下两种方式来实现：
- 明确指定场景的执行方式。
- 以随机的方式提供一般方向
通常，用户希望同时使用这两种方法的组合：某些参数被指定，而某些参数以一致的方式自动推断提供的值。OpenSCENARIO可以实现这一点，它允许同时组合具体和抽象语句。OpenSCENARIO允许用户控制自由度的级别。
▍语言层面支持覆盖度，做到用户可自定义的覆盖度
OpenSCENARIO的覆盖范围和记录功能允许用户为验证和验证任务设置目标，包括：
- 确定执行哪些场景，例如切入并减速场景。
- 规定如何执行这些场景，例如测试切入并减速场景时应从左侧和右侧进行，并且使用各种车辆进行测试。
- 定义需要观察多少次数才能宣布测试完成，例如每个组合至少在道路上行驶50次。
覆盖范围允许存储在开发和验证过程中预期观察到的数值。报告使用类似的语法，旨在存储数据以供后续分析或KPI（关键绩效指标）分析使用。覆盖范围和报告定义可以在多个设计运行域（ODD）和项目中重复使用，因为它们可以进行非侵入性地覆盖重写。
▍OpenSCENARIO2.0编译器实现，反馈和工具
- OpenSCENARIO 2.0 Implementers Forum（实现者论坛）
为了更好地支持企业对于OpenSCENARIO 2.0标准的深入理解，ASAM组织举办了OpenSCENARIO 2.0 Implementers Forum（实现者论坛）。该论坛为技术交流提供了平台，促进了开发工作与标准的结合。论坛组与标准制定组并行运作，为标准的改进提供了宝贵的反馈。在ASAM OpenSCENARIO 2.0 Implementers Forum中，我作为仿真组的组长，组织团队进行了方案展示和讨论，提出了大量更具实操性的建议和反馈，推动标准发展。
- OpenSCENARIO2.0编译器和场景引擎
在OpenSCENARIO 2.0标准的制定过程中，需要编译器实现验证和反馈。51Sim自主研发了原生OpenSCENARIO 2.0编译器，并与全球同行分享，为标准的制定提供了反馈。其框架分为三个阶段：
- 预处理：对标准库和第三方库进行预处理；
- 编译器前端：使用ANTLR4实现EBNF、词法、语法和语义分析；
- 编译器后端：包括虚拟机的字节码和指令集、函数调用的栈帧实现，以及OpenSCENARIO 2.0的语义模型（如驾驶、变道等）等部分。
▲51Sim OpenSCENARIO场景编译器管线
- OpenSCENARIO2.0语法检查工具
OpenSCENARIO 2.0作为一门编程语言，可以使用EBNF语法来验证场景的合法性。51Sim已经开源了OpenSCENARIO 2.0语法解析器，可以在以下链接找到：
https://github.com/51WORLD/osc2checker
该解析器具备词法和语法检查功能，不仅对场景编写者有用，对于开发基于OpenSCENARIO 2.0编译器的企业也具有帮助。
此外，在2022年的第五届ASAM全球大会上，51Sim发布了支持OpenSCENARIO 2.0语法检测的Visual Studio Code扩展插件。借助这个插件，用户可以在集成开发环境中进行编辑和保存时自动获得语法错误提示。这进一步降低了学习和应用OpenSCENARIO 2.0的门槛。
▍OpenSCENARIO2.x和OpenSCENARIO1.x的兼容和改名
OpenSCENARIO 2.x最初旨在成为OpenSCENARIO 1.x的超集。然而，这两个标准在应用工具链中各自拥有独特的定位和目标，其设计哲学和领域模型存在显著差异。
在ASAM OpenSCENARIO标准工作组经过充分讨论后，于2023年12月，ASAM宣布技术指导委员会做出了决定：ASAM OpenSCENARIO的两个版本，1.x和2.x，将作为两个独立的标准进行开发，ASAM无需进行正式的迁移或融合。与此同时，为更清晰区分，OpenSCENARIO这两个标准正式更名：
- ASAM OpenSCENARIO V1.X命名为ASAM OpenSCENARIO XML
- ASAM OpenSCENARIO V2.X命名为ASAM OpenSCENARIO DSL
这两个标准的主要针对的场景不同（不意味着排他性）：OpenSCENARIO XML支持条件触发动作的描述，支持指定并精确定义轨迹，同时允许参数化和改变其属性等。其主要用例为：可预测的高度精确的场景，可与V&V的外部测试规范协同使用。
OpenSCENARIO DSL支持在更高的抽象级别上指定场景意图、KPI、检查和覆盖率指标，旨在探索场景/功能空间，以确定潜在的未知因素等。其主要用例为：大规模V&V。
ASAM将继续支持和鼓励这两个标准的持续对齐。
在整个过程中，51Sim积极参与，并担任了ASAM OpenSCENARIO标准领域X模型对齐组的组长。
此外，为解决兼容性问题，51Sim独立开发了51SDL（51场景描述语言），作为OpenSCENARIO 2.x对OpenSCENARIO 1.x的完全兼容扩展方案。在初期讨论阶段，该方案已经提交给ASAM OpenSCENARIO标准工作组，其中包括一对一的参数映射提案，为从1.x迁移到2.x提供了更多的候选方案和思路。随后的计划是开源兼容性扩展方案，进一步为OpenSCENARIO社区做出贡献。
Part.4 OpenSCENARIO的应用01. OpenSCENARIO场景编辑器
借助编辑器的编辑和快速预览功能，用户可以快速有效地创建场景。此外，通过使用自然语言输入和AIGC技术，可以高效生成OpenSCENARIO场景。另外，OpenSCENARIO场景库可以在不同的仿真平台之间进行交换和共享。
▲51Sim AIGC Scenario Copilot
02. OpenSCENARIO场景用于自动驾驶算法仿真测试
利用OpenSCNEARIO的控制切换，可支持人工驾驶和自动驾驶的切换，方便灵活。
▲OpenSCENARIO场景用于测试Apollo算法
03.OpenSCENARIO进一步应用于传感器感知仿真测试
▲传感器数据集摄像头图片和激光雷达点云
此外，ASAM OpenX还包括其他标准，如仿真接口OSI、标注OpenLABEL、设计运行域OpenODD以及本体论OpenXOntology等。我们也在积极参与并及时跟进这些标准的发展，未来也将一一和大家揭晓。
▲ASAM OpenX标准
51Sim简介
51Sim是51WORLD于2017年孵化的数据仿真平台，专注于为智驾及交通领域客户提供数据驱动闭环全栈仿真测试及宏中微观一体化交通仿真解决方案，加速智驾量产落地同时推动交通运输体系更加高效，安全和低碳。
51Sim数据仿真平台旗下包含智能驾驶仿真测试平台SimOne，数据闭环与合成数据平台DataOne，以及交通信息模型平台TIM。
聪明的车，智慧的路，让未来出行更加安全、高效和美好。
▼
了解更多及解决方案，欢迎访问官网及公众号
