中汽数据周博林：ASAM 标准助力自动驾驶仿真测试落地

仿真是自动驾驶领域的一项关键技术，能够帮助自动驾驶汽车在模拟的极端环境中进行测试，同时，提高测试效率、降低测试成本。

然而，相对于计算机科学、芯片等其它领域，针对自动驾驶的仿真测试才刚刚起步，尚且存在着许多新问题；尤其是在实际发展过程中，整车厂、供应商以及仿真工具提供商使用的数据格式与接口没有统一标准，导致各方之间的合作受到一定的阻碍。

近日，雷锋网新智驾邀请了中汽数据有限公司国际标准总监周博林来进行业内分享。以下为周博林的演讲内容，雷锋网(公众号：雷锋网)新智驾进行了不改变原意的整理：

大家好！首先我做一下自我介绍，我是中汽数据有限公司的周博林。

2017年，我加入了中汽数据，工作重心在于算法开发，包括计算机视觉算法。在此之前，我在美国和欧洲留学，也拥有一定的工作经历。

2018年，我的工作开始从“基于数据开发算法”转变为“从数据中去探索新的内容”。也就是说，我 2018 年更多的是在研究和处理数据之间的关系，为企业提供相应的服务。

到了 2019 年，我们逐渐发现，开发需求、企业需求以及其他需求会在一定程度上有所重叠，随后我们联系到了 ASAM 组织，展开了相关的合作。

回到今天的主题上，今天主题为《ASAM OpenX 标准助力自动驾驶仿真测试落地应用》。

一、自动驾驶行业发展背景

随着自动驾驶等级的提高，面向传统汽车的测试工具与测试方法已不能满足自动驾驶汽车测试的需要。比如，自动驾驶汽车无法在一些危险的场景下进行实际的测试。

因此，相比起传统测试方式，基于场景的虚拟测试方法在测试效率、测试成本，场景覆盖度等方面具有巨大的技术优势，是未来自动驾驶汽车测试验证的重要手段。而且，除了自动驾驶，计算机科学、软件行业，以及芯片行业等领域或多或少都会通过仿真数据来进行测试，从而助力产品优化。

换句话说，仿真技术已成为当前的研究热点。

针对自动驾驶的仿真测试是一种新的解决方案，但它与其他行业又有不同，比如芯片，芯片的输入输出十分稳定，每一个模块所要解决的问题也是相对固定的。然而，自动驾驶在仿真测试中会遇到许多新问题，主要包括以下几个方面：

• 缺乏有效的场景库建设方法；

• 缺乏自动化的生成方法和测试用例标准格式；

• 格式转换，动态场景、静态地图缺乏统一兼容格式标准；

• 缺失统一标准接口。

想要解决上面的问题，有两种思路——立法者的思路和开发者的思路。

如果我们是立法者，我们会更加关心自上而下的体系。比如，当前这套体系是否和中国的法律法规保持一致，如何把它控制在法律法规的界限之内，如何满足法律法规的要求。

如果我们是开发者，我们则会考虑自下而上的体系。我们需要通过大量的数据和实验才能完善这套体系。

举个例子，比如说我们现在立了一套法，但实际上，世界上有很多案例是在法律条款之外的。在自动驾驶里面也有许多规则之外的未知的场景，根据这些场景来修正规则， 是自上而下的梳理。

另一方面，许多新算法和新技术的变革，其实是从下而上的变化。比如，通过一定的先验知识去训练模型，然后通过大量数据对模型进行优化。

上述的两种方法，在某一时刻会打通，为了尽快实现这一目标，我们就需要一套标准化的研究体系。这也我们当前工作的关键点。

仿真测试的大致流程如上图：

首先，在做测试之前，要有一个明确的测试需求。简单来说，就是要知道测试目标以及测试内容，然后确定场景是不是符合测试需求。

第二步，把场景输入到仿真环境中进行渲染，这一部分需要考虑的是仿真场景里的内容和真实的场景是否保持一致，目标反射率和物理情况下的反射率是否保持一致等。

然后，确保模拟测试的输出效果与实际情况相符合，并且达到测试的目的和预期。

这些都是我们需要攻克的难点。

具体应该怎么操作？

首先，我们要对测试场景、驾驶动作、判断条件进行描述，将这些信息输入到模拟环境之中，搭建起一个仿真场景。在对仿真运行环境进行调试之后，这些信息都会传输到测试硬件中进行融合和处理。

在设计这样的场景之前，除了要保证整个数据流被打通，还要在流程中的难点上得到反馈。比如记录相应的数据，以便判断仿真的内容是否符合测试的目的等。

其中，目前 ASAM 描述的关系就是仿真环境中的 OSC 和 XODR，一个针对地图信息，一个针对场景信息。针对传感器信息的为 OSI，标记数据传感器硬件为 OpenLABEL；除此之外还有 OpenCRG等。这些内容我们之后都会详细展开。

接下来，我们用一个具体的案例来帮助理解。

如上图，在一个配备红绿灯的路口，左边有一辆自动驾驶车辆，A车，其后有一辆 B 车，A 面临黄灯；下方是 C 车，正在等红灯。这是一个特定的简单的场景。

然而，如果要将这个场景搭建到仿真环境中，我们需要描述清楚这些车辆和路口的距离，要标记各种的坐标信息，还要描述车辆的速度以及其他条件信息。比如，我们需要预测结局，包括“A 车顺利通过”“A 车与 B 车相撞”“A 车与 C 车相撞”。

无论是哪一种情况，我们都需要进行大量的计算，包括 A 车面临的黄灯什么时候切换到红灯、A 车什么时候能够感知到 C 车的存在；B 车的初始速度是多少、它与 A 车的距离是多少、它对 A 车的反应如何、C 车绿灯后的反应时间是多少，它在绿灯是的行驶状态如何；还有一些环境信息，比如天气、道路表面、光线信息等。

除此之外，我们还需要考虑法规，比如有些国家可以闯黄灯，有些国家不可以，这些信息也需要写进系统。

那么，在测试流程中，如果 A 车感知到了 C 车的存在，它应该做出哪种决策？比如完全抱死，这个决策存在被 B 车追尾的风险；比如转弯避让 B 车或 C 车；再比如通过按喇叭的方式来让 C 车意识到自己（A 车）的存在。

这些都是一个完整测试所需要涵盖的参数和描述。

二、ASAM 标准助力仿真测试发展

给大家简单介绍一下 ASAM。

1998 年，德国主要的整车厂创建了非营利性的 ASAM 组织，希望能够打造一个工程、模拟、测试和自动化环境，在此环境中，设备和软件应用程序可以自由互联，数据可以无缝交换。

简单来说就是为汽车行业制定、提高和推广标准提供平台。

目前的成员超过 200 个，包括 20 个整车厂。其中，主要参与者来自欧美和日本，中国 OEM 的参与者代表为上汽集团。

研究领域方面，ASAM 主要的方向有：数据管理与分析、测试自动化、软件开发、测量与校准、诊断、ECU 网络、仿真等。我们今天分享的重心就在于仿真方面，即描述用于驾驶和交通模拟的道路网络、驾驶行为和测试场景的说明。

随着驾驶和交通仿真场景测试需求的不断增加，市场上出现了众多来自各厂家的不同数据格式标准。

基于此，ASAM 致力于推广 OpenX 系列格式标准，使其成为驾驶和交通仿真场景数据格式的官方标准，并承诺将其作为一项长期标准以促进未来产业发展。

ASAM 仿真格式标准整体包括以下五个方面：

• OpenDRIVE 对应静态地图场景，负责描述地图信息，包括高精地图信息；

• OpenCRG 对应道路表面，专注于车辆动力学，以及车辆对路面信息的反馈；

• OpenSCENARIO 对应动态行为场景，也就是描述自动驾驶的测试场景；

• OSI对应仿真接口，比如传感器仿真接口或是各种信息的仿真接口；

• OpenLABEL 是今年新开的一个项目，研究的是场景标签与传感器原始数据。

如图所示，OpenDRIVE、OpenCRG 和 OpenSCENARIO 组成了道路及场景描述格式，OpenLABEL 负责数据方面。OpenODD 与我们之前提到的测试需求有很大的关联，能够帮助进一步优化决策方向。

在仿真测试的过程中，OSI 也是非常重要的一部分，这涉及到如何测试功能，以及测试的功能是否能够达到要求。

上述这些重要的模块组成在一起就是 OpenXOntology 以及相应领域模型。

具体来看这个体系中的内容。

• OpenDRIVE

OpenDRIVE 项目 2005 年由戴姆勒和 VIRES 启动，定义了一个标准的静态地图格式，以实现不同仿真测试软件的兼容性，具体是用于描述道路网络的文件格式，涉及到驾驶模拟、交通模拟、传感器仿真等领域。不过，OpenDRIVE 不作用于或于道路网络交互的实体。

2019 年 1 月，OpenDRIVE 1.5 版本发布。在补充了 ASAM 标准定义及介绍、语言和语法说明、正式的数据模型之后，OpenDRIVE 1.6 版本于今年 3 月正式发布。

• OpenCRG

OpenCRG 于 2008 年由戴姆勒与奥迪、宝马、保时捷和大众共同发起，其文件格式集成在 OpneDRIVE 中，主要对路面给进行了详细描述，以便进行轮胎模拟、振动模拟和驾驶模拟。

OpenCRG 的源代码包括数据读/写和评估的 C-API，以及用于数据读/写、评估、生成、修改和可视化的MATLAB API。

OpenCRG 项目的启动时间为 2019 年 8 月 28 日，到 2020 年 9 月，OpenCRG 1.2（用户手册和规范文件将会发布）；同时，C-和MATLAB API 1.0 也将发布。

• OpenSCENARIO

OpenSCENARIO（OSC）定义了一个标准的仿真测试用例格式，兼容不同的仿真测试软件，具体用于描述驾驶模拟应用程序中动态内容的文件格式，适用场景主要包括动作、轨迹（多段线、回旋线）、车辆（几何、类型、轴、性能）、驾驶员（状态）、环境等（天气、时间、路况）。

简单理解就是“谁在哪儿干什么”。

在描述的过程中还涉及非常具体的分层，比如，在一个事件板中，从活故事、动、顺序、动作、事件，再到相应行动的执行。然而，随着大数据和 AI 的发展，这种方式已经不足以覆盖如今的测试需求。

因此，需要更高级别场景描述的指定领域语言来进行描述，即一套为自动驾驶仿真测试而生的语言。这套语言应该覆盖开发者、认证机构、工具提供商、场景生成者等多方参与者。

那么，这套语言就是 OSC 2.0 版本的研究重心。2020 年 3 月 16 日，OSC1.0 版本与 2.0 concept 版本相继发布，后续版本的制定同步进行。

• OSI

OSI 定义了一个通用的接口，用来连接自动驾驶功能的开发和各种自动驾驶模拟框架，以实现兼容性，以期做到使任何自动驾驶功能与任何仿真工具连接，同时能够集成各种传感器模型。

OSI 由两部分独立的目标信息接口组成，即真值和传感器数据；支持统计和物理传感器模型两种传感器数据。

不过，目前 OSI 的研究内容并不能够完全满足自动驾驶仿真测试的需求，而是需要一个更加完整的体系，因此，OSI 将会从屋里传感器仿真、工具开发支撑、交通流信息、其他 Open 标准关联进行拓展。 

• OpenLABEL

OpenLABEL 概念项目提出了一个关于标签的标准提议，这个标准将包括标签方法，标签结构、文件格式等内容，旨在解决不同厂商之间数据无法互通的痛点

不过，这一项目去年年底才开始推动，目前尚处于起步阶段。

三、C-ASAM和 OpenX 仿真云工具

关于 ASAM 标准的相关工作基本上都是欧美、日本的企业在参与，作为国内的代表企业，去年 9 月 27 日，我们与 ASAM 签订了战略协议，联合成立了 C-ASAM 的工作组，为中国企业提供一个了解 ASAM 的平台，并进行统筹管理。

目前，国内加入的企业已经将近20家，包括上汽集团、数据资源中心、腾讯、百度、华为、大疆、51VR，以及清华、北航等高校。我们也非常欢迎其他企业加入到 C-ASAM 中来。

除此之外，我们自己也开发了一套类似的工具——OpenX 仿真云。

不同于以往的由原始场景数据通过人工方法直接转换为测试用例，OpenX 仿真云工具将采集到的原始场景数据通过分类标记、比对归纳、标准化基本动作整合等步骤最终形成 OSC 格式的场景文件。

中汽数据开发了用于连接现有数据与OpenX系列数据的OpenX仿真云工具，以实现现有场景格式与OpenX格式的相互转换和交互，优化OpenX系列数据的使用体验，同时重点评价场景测试的覆盖率和通过率。

OpenX 仿真云工具四大模块：数据检查、场景归纳、格式转换、云端测试评价。

实际上，我上面说的所有内容都是帮助大家去理解，并不代表目前的体系能够满足所有人的需求。从某种程度上来说，把我们自己的需求在国际平台上共享，对于标准的制定和推进会起到重要作用。

作一个测试方，我们关心的不仅仅是某一个场景下传感器的准确度，我们更关心的是，这个场景的可遇见的，我们要解决什么问题（感知结果融合问题）；不可遇见的场景，我们会遇到什么样的问题（指针问题、溢出问题、内存问题）；以及其他可能的问题。也就是说，反馈信息是我们更加关心的内容。

而且，要让整个体系理解所遇到的问题，仅凭一两个案例是不够的，需要在这个环境中不断进行迭代测试，就像硬件测试的压力测试一样。

以上就是我演讲的全部内容，也十分欢迎大家后续跟我们进行交流，再见。

雷锋网

。