技术解读丨ASAM OpenSCENARIO 2.0 Implementers Forum实现者论坛与编译器实现-绵羊汽车生活记录

11月25日举办的第二届ASAM中国区域大会，C-ASAM邀请到了上海机动车检测认证中心、51WORLD、四维图新、大疆创新等多家中外权威机构、整车企业、科技公司，与会单位围绕自动驾驶仿真标准ASAM Open X的应用案例等内容展开了深层次探讨，进一步促进了汽车技术标准化、国际化进程。

会上，来自北京51WORLD的高级研发经理毛祖秋先生作为ASAM OpenSCENARIO 2.0 Implementers Forum（以下简称“实现者论坛”）仿真组代表，介绍了实现者论坛的工作内容，并讲解了支持ASAM OpenSCENARIO 2.0标准的编译器实现。

ASAM OpenSCENARIO 2.0 Implementers Forum 实现者论坛

ASAM OpenSCENARIO标准定义的内容主要覆盖动态场景描述，包括主车的位置与速度等信息，及其他交通参与者的信息。目前，ASAM OpenSCENARIO主要发布了1.0版本和2.0 Public Release Candidate版本。

在ASAM OpenSCENARIO 1.0版本中，动态场景信息被描述于XML格式的数据中。该版本定义了“事件板”式的动态场景信息描述方式，包括故事、活动、顺序、动作、事件和行动六个环节，而车辆速度、位置、加速度等一系列主要信息将被分类写入基于XML格式的“事件版”中。

在ASAM OpenSCENARIO 2.0版本中，逻辑场景的概念被广泛应用。所有输入的动态场景被整理成一系列不可再分的基本动作，如循线行驶、加速、减速等；再通过组合各基本动作，形成较复杂的逻辑场景，如左侧超车，右前方车辆并线等。这些基本逻辑场景仅对场景中的动作进行归纳和分类，使用者需结合实际情况将原始数据填入对应动作条目内。

ASAM OpenSCENARIO 2.0版本使海量数据的标准化处理成为可能，有利于将采集得到的原始数据转换成标准化、有逻辑、易归纳的动态场景文件。

▲ ASAM OpenSCENARIO标准开发计划为了支持企业对于ASAM OpenSCENARIO 2.0标准更深层次的理解，ASAM举办了ASAM OpenSCENARIO 2.0 实现者论坛，提供了一个交流技术的平台，促进开发工作与标准相结合。该论坛定期与开发项目交流反馈，目标确保制定出更易理解、并可得到工具部分支持的标准。实施者论坛将提供用于合作讨论、使用及实施ASAM OpenSCENARIO V2的框架。目前该论坛一直与标准的制定并行运行，并已为标准持续改进提供了宝贵的反馈。实现者论坛设有两个小组，一个专注于使用使用ASAM OpenSCENARIO 2.0创建和描述场景（规范组），另一个专注于在现有工具或新工具中实现ASAM OpenSCENARIO（仿真组）。ASAM OpenSCENARIO 2.0标准支持具体场景、逻辑场景和抽象场景。实现者论坛还讨论了具体场景的定义。如，具体场景的定义是什么？具体到什么程度才算具体场景？仅仅没有描述车辆颜色而其他参数都确定的场景是不是具体场景？论坛为此进行了多次讨论，并将具体场景的定义向开发项目进行了反馈。另外，论坛还进行了大量的实现结果展示、讨论和反馈，比如车道保持，逻辑场景，控制切换，路口场景，切出场景等。

支持ASAM OpenSCENARIO 2.0标准的编译器实现目前在ASAM OpenSCENARIO 2.0实施者论坛中，仿真组有两种方式实现ASAM OpenSCENARIO 2.0标准语言，第一种是将ASAM OpenSCENARIO 2.0转换为内部或工具特定的格式；第二种则是通过基于ASAM OpenSCENARIO 2.0标准开发的专用编译器直接使用ASAM OpenSCENARIO 2.0这一场景领域特定语言（DSL）。后者可以更直接地为标准制定过程提供宝贵的技术意见，有助于为标准开发项目提供反馈循环，以探寻任何潜在的问题。经典的编译器开发主要包括三个部分，前端、中端、后端。例如，在使用方面，利用LLVM模块化和可重用的方法，不同语言可统一使用LLVM中端和中间代码。编译器支持一种新的的编程语言只需实现一个新的前端，例如C++、Rust、Fortran只需实现各自的前端；而其支持一种新的硬件比如X86、ARM和Power PC等硬件，只需实现一个新的后端。

在实现者论坛上，博世公司介绍的场景编译器YASE（Yet Another Scenario Engine）正是经典编译器应用的典型案例，它借鉴了经典编译器中类似LLVM的模块化和可重用的方法。YASE场景编译器的框架也分为三个阶段，前端、中端、后端。ASAM OpenSCENARIO 1.x、ASAM OpenSCENARIO 2.0和内部工具实现各自的前端，并统一使用YASE中端，不同的模拟器实现各自的后端，如esmini、OpenPASS和内部工具。YASE使用Unity和UE等常在游戏引擎中用到的行为树进行场景执行。

在实现者论坛上，51WORLD也介绍了其基于ASAM OpenSCENARIO 2.0标准开发的51Sim-One编译器，其框架也分为三个阶段，预处理、编译器前端、编译器后端。◆ 预处理：第一阶段是进行预处理以获取整个内容，当得到一个场景时，可能会导入另一个文件或标准库；◆ 编译器前端：使用ANTLR4来实现EBNF，可以生成词法分析器和语法分析器，之后，可得到抽象的语法树并将其传递给语义分析器；◆ 编译器后端：场景引擎使用脚本引擎和语义模型作为后端，脚本引擎实现了函数调用和表达式计算，并通过栈帧实现函数调用。语义模型实现ASAM OpenSCENARIO 2.0的领域模型，例如驾驶（Drive）、变道（ChangeLane），其使用状态机控制车辆运动。

ASAM OpenSCENARIO 1.0用XML Schema来验证场景的合法性。在没有编译器时，ASAM OpenSCENARIO 2.0可以使用EBNF语法来验证场景的合法性。例如，使用ANTLR4来实现EBNF，做基本的词法和语法检查，不仅对场景编写者有用，而且对开发基于ASAM OpenSCENARIO 2.0标准编译器的企业也有帮助。

在开发编译器的过程中，ASAM OpenSCENARIO 2.0标准的语法并没有制定完成，尤其在开始阶段，需求的经常改变，对于程序员编程实现来说是一大困难和挑战，不得不综合参考各方面的信息，比如概念版、早期版本、M-SDL、Python语法等。因此，在研发51Sim-One编译器时，51WORLD采用模块化架构，前端定期更新以应对变化及跨厂商兼容性挑战，后端基本保持稳定的方案。