用于监测自动驾驶车辆的适当行为的系统及其方法

摘要

提供了一种用于监测自动驾驶车辆的适当行为的系统及其方法。该方法包括：生成多个主体，其中多个主体中的每个描述物理对象，其中多个主体中的至少一个为针对DUT的主体；生成多个场景，其中每个场景对多个主体中的至少一个的行为进行建模，以及针对对相应主体进行建模的场景，监测多个主体与DUT主体之间的交互。

说明书

相关申请的交叉引用

本申请要求于2019年12月17日提交的美国临时申请No.62/949，098的权益，该申请的内容通过引用合并于本文。

版权声明

本专利文件中的所有材料均受美国和其他国家的版权法的版权保护。版权所有者不反对任何人对该专利文件或专利公开如其在官方政府记录中呈现的那样进行传真复制，但是除此之外，保留所有其他版权权利。

技术领域

本发明总体上涉及自动驾驶车辆，并且更具体地涉及监测这种车辆的适当性能。

背景技术

自动驾驶车辆领域的进步是迅速的。越来越多地，这样的车辆计划在未来十年内上路，并且实验车辆正在世界上许多城市的道路上漫游。像已经由人类设计的每个复杂设备一样，自动驾驶车辆享有人的独创性的好处，也经历其缺点。缺点表现为自动驾驶车辆的不期望的、不可预测的或错误的行为，使车辆的乘员以及车辆周围的其他人、动物和财产处于危险中。

为了防止这种错误的发生，首先在将车辆释放到道路之前对其进行测试，然后，当将它们部署在道路上时，车辆安装了附加的预防措施以确保不会发生事故。此外，驾驶员被分配到每个这样的车辆，其中当操纵或响应发生错误时驾驶员具有推翻车辆操作的能力。当然，这允许捕获这样的序列并且更新车辆的控制系统，使得在将来可以防止这样的危险情境的情况发生。然而，这些解决方案易于出错，因为它们在很大程度上依赖于由于操作者的干预或者已经发生某种损害的情况而导致的此类错误的捕获。当有可能防止不期望的结果发生时，导致不期望的结果的错误没有被有效地监测或捕获。

因此，期望提供一种允许基于对适当操作的预定期望来监测自动驾驶车辆的操作而不是等待发生严重错误的解决方案。从而通过将自动驾驶车辆暴露于大量场景，在受控环境(诸如模拟或测试轨道)中测试自动驾驶车辆同时系统地监测自动驾驶车辆的性能，将是有利的。

发明内容

以下是对所公开的若干示例性实施例的概要。提供该概要是为了方便读者以提供对此类实施例的基本理解，并且不完全限定所公开的范围。该概要不是所有构想的实施例的广泛概述，并且既不旨在标识所有实施例的关键或重要元素，也不旨在描绘任何或所有方面的范围。其唯一目的是以简化的形式呈现一个或更多个实施例的一些概念，作为稍后呈现的更详细描述的序言。为了方便起见，术语“一些实施例”或“某些实施例”在本文中可以用于指所公开的单个实施例或多个实施例。

本文公开的某些实施例包括一种用于监测待测设备(DUT)的适当行为的方法。该方法包括：生成多个主体，其中多个主体中的每个描述物理对象，其中多个主体中的至少一个为针对DUT的主体；生成多个场景，其中每个场景对多个主体中的至少一个的行为进行建模；以及针对对相应主体进行建模的场景，监测多个主体与DUT主体之间的交互。

本文公开的某些实施例还包括一种非暂态计算机可读介质，非暂态计算机可读介质上存储有用于使处理电路执行用于监测待测设备(DUT)的适当行为的过程的指令，该过程包括：生成多个主体，其中多个主体中的每个描述物理对象，其中多个主体中的至少一个为针对DUT的主体；生成多个场景，其中每个场景对多个主体中的至少一个的行为进行建模；以及针对对相应主体进行建模的场景，监测多个主体与DUT主体之间的交互。

此外，本文公开的某些实施例包括一种用于监测待测设备(DUT)的适当行为的系统。该系统包括：处理电路以及存储器，存储器含有指令，指令在由处理电路执行时配置该系统以：生成多个主体，其中多个主体中的每个描述物理对象，其中多个主体中的至少一个为针对DUT的主体；生成多个场景，其中每个场景对多个主体中的至少一个的行为进行建模；以及针对对相应主体进行建模的场景，监测多个主体与DUT主体之间的交互。

附图说明

在说明书的结尾处的权利要求书中特别指出并明确要求保护了本文公开的主题。通过以下结合附图的详细描述，所公开的实施例的前述和其他目的、特征和优点将变得显而易见。

图1是根据实施例的用于激活主体和场景以便监测自动驾驶车辆的行为的监测系统的示意图。

图2是描述根据实施例的用于部署自动驾驶车辆的监测系统的方法的流程图。

图3是描述根据实施例的用于生成监测系统的至少主体的方法的流程图。

图4A是根据实施例的超车(cut-in)和减速(slow)场景的端到端示意性描述。

图4B是根据实施例的超车和减速场景的领先阶段的示意性描述。

图4C是根据实施例的超车和减速场景的超车阶段的示意性描述。

图4D是根据实施例的超车和减速场景的减速阶段的示意性描述。

图5是根据实施例的超车和减速场景的覆盖度量的示意性描述。

具体实施方式

重要的是要注意，本文公开的实施例仅是本文创新性教导的许多有利用途的示例。通常，在本申请的说明书中做出的陈述不一定限制各个权利要求中的任何一个。此外，一些陈述可适用于一些发明特征但不适用于其他发明特征。通常，除非另有说明，否则单数元素可以是复数的，反之亦然，而不失一般性。

在自动驾驶车辆领域中，预期车辆以超越人类的完美水平运行。然而，由人类设计和编程的安装在车辆中的设计和程序中的错误和故障可能导致不期望的和不可预测的结果。因此，可测量的场景描述语言(MSDL)用于生成操作监测数据流的监测设备的主体，其中，当与MSDL场景所表达的行为相比较时，这种数据流提供关于被监测车辆的行为的信息。使用MSDL创建主体并执行，以监测接收到的流并检测和报告异常、关键性能指标和场景覆盖。即，如果被监测车辆的行为与预期不同，则报告该异常。MSDL还允许描述被监测车辆的环境内的未被监测的元素。

图1描绘了根据实施例的用于激活主体和场景以便监测自动驾驶车辆的行为的监测系统100的示例性示意图。监测系统100包括处理单元110，处理单元110通信地连接到存储器120。存储器120可以包括易失性存储器(诸如随机存取存储器(RAM))以及非易失性存储器(诸如只读存储器(ROM)和闪存)两者。存储器120可以具有被分配为在其中包含可以由处理单元110执行的指令的存储器120的一部分，如本文进一步解释的。

数据库(DB)130进一步连接至处理单元110，并且数据库(DB)130在其中可以包含如在本文进一步讨论的各种类型的数据。数据库(DB)130可以包括用于由处理单元110执行的指令，或者要由处理单元110处理的数据。数据库(DB)130可以进一步在其中容纳由处理单元110预备的或以其他方式处理的数据。包含在数据库(DB)130中的数据可以包括先前预备的构造(诸如主体)，在本文中将对它们进行更详细地讨论。此外，根据所公开的实施例，数据库(DB)130可以包含数据流，例如视频短片，这些数据流可以用于监测自动驾驶车辆的行为的目的。

网络接口140进一步连接至处理电路110。网络接口140使监测系统100能够通过网络接收和发送数据，该网络可以是有线的或无线的。相关类型的网络包括但不限于：局域网(LAN)、广域网(WAN)、城域网(MAN)、蜂窝网络、

处理电路110可以被实现为一个或更多个硬件逻辑组件和电路。例如但不限于，可以使用的示例类型的硬件逻辑组件包括现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、图形处理单元(GPU)、张量处理单元(TPU)、通用微处理器、微控制器、数字信号处理器(DSP)等、或能够执行信息的计算或其他操纵的任何其他硬件逻辑组件。

存储器120可以是易失性的(例如，RAM等)、非易失性的(例如，ROM、闪存等)或它们的组合。

在一种配置中，用于实现本文公开的一个或更多个实施例的软件可以存储在数据库130中。在另一配置中，存储器120被配置为存储诸如软件代码125之类的软件代码。软件代码125包括使用MSDL开发的任何指令。软件代码125应当被广义地解释为意指任何类型的指令，无论其被称为软件、固件、中间件、微代码、硬件描述语言或其他。指令可包括(例如，源代码格式、二进制代码格式、可执行代码格式或任何其他合适的代码格式的)代码。在由处理单元110执行指令时，指令使处理单元110执行本文描述的各种过程。

数据库(DB)130可以是任何类型的存储装置，诸如磁存储装置、光存储装置等，并且数据库(DB)130可以被实现为例如闪存或其他存储器技术、CD-ROM、数字通用盘(DVD)或可以用于存储所期望的信息的任何其他介质。

应当理解，本文所描述的实施例不限于图1中所示出的特定架构，并且在不脱离所公开的实施例的范围的情况下可以等同地使用其他架构。

为了演示监测系统100的操作，描述了示例场景。可以理解，其他类似场景可以被容易地开发和部署，用于在作为监测设备操作的监测系统100上执行。就当前示例而言，使用被称为“超车和减速”的场景。这是在交通中经常遇到的场景，其中，一辆汽车在另一辆汽车(例如，自动驾驶车辆)前方超车并减速。

以下是根据所公开的实施例的如何使用MSDL从定义和场景设置至逻辑场景描述以及场景的最终实现来对场景“超车和减速”进行捕获的逐步解释。该MSDL用于确保自动驾驶车辆在测试时、或在监测自动驾驶车辆在模拟中的响应时或根据自动驾驶车辆在道路上时所捕获的真实数据流监测自动驾驶车辆的响应时如预期的那样执行。验证的责任在程序员的手中，程序员使用MSDL来定义来自使用监测系统100并且如本文所描述的元素的场景。

在当前示例性情况下描述了用于验证或监测期望行为的场景的定义。可以理解，在不脱离本发明的范围的情况下，其他场景也是可能的。在示例情况下，自动驾驶车辆可以以基本上恒定的速度行进，并尽可能长时间地保持在其车道。另一车辆可以在不同的车道上从该自动驾驶车辆后方接近，并且可以经过该自动驾驶车辆。然后，另一车辆可以在自动驾驶车辆的前方超车并且进入该自动驾驶车辆的车道。

然后，另一车辆可以减速，由此迫使自动驾驶车辆采取必要的措施以保持在距另一车辆的安全距离内，其中，另一车辆可以在自动驾驶车辆的车道中并且在自动驾驶车辆前方。可以理解，给定示例中包括两个行为，自动驾驶车辆的一个行为和另一车辆的一个行为。场景的定义还定义了覆盖度量和分级机制，其证明实现了验证目标。度量目标机动参数诸如但不限于汽车之间的距离和速度。

根据各实施例，如本文中所描述的，场景的所有定义是使用MSDL来实现的，并且场景的执行是使用例如系统100来监测的。度量在本领域中也被称为关键性能指标(KPI)。KPI通常是物理参数，诸如但不限于速度、距离、加速度等。覆盖度量通常是逻辑的、布尔的或离散的描述、查询等，例如但不限于“已经发生接管？”“已经发生超车？”“已经发生左侧超车或右侧超车？”等。

图2是描述根据实施例的用于部署自动驾驶车辆的监测系统100的方法的示例流程图200。

在S210，生成多个主体，多个主体至少包括用于待测设备(DUT)的主体。在典型实施例中，DUT主体用于自动驾驶车辆(AV)。使用MSDL描述每个主体，提供了使用主体的示例并且在下文中提供了MSDL的更详细的但非限制性的描述。

出于描述新创建的主体的目的，主体可以使用先前生成的主体。因此，建立主体的层次结构。在一个实施例中，根主体是直接或通过其层级调用所有主体的主体。主体可以描述DUT、车辆、道路、人行道、人、动物、交通灯、交通锥标、障碍物、自行车、火车、天气元素、危险元素和类似的物理对象。应当理解，所提供的列表不是穷举的，并且可以使用MSDL、主体的层次结构、或MSDL以及主体的层次结构两者来描述其他主体。可进一步理解，此类主体可以自动地生成或通过由处理单元110执行的用户接口(未示出)手动地生成。

可以通过使用数据流(例如但不限于视频流)来完成自动提取，其中针对期望的物理对象生成主体。可以通过网络接口140实时提供数据流，或者可以将数据流存储在数据库(DB)130中并离线使用。主体可以包括对较低层次结构主体的参考，较低层次结构主体允许不重新创建先前已经定义的主体。例如但不限于，如果车辆由于环境照明的变化而操作灯，并且打开前照灯的物理对象已经作为主体存在，那么，当创建用于车辆的主体时，使用先前生成的主体可能是有用的。

在S220，生成多个场景，也可以使用MSDL来描述场景，其中，场景可以对主体的行为进行建模。例如但不不限于，汽车可具有驾驶场景，行人可具有步行场景，交通灯可具有灯变化场景等。应当理解，交通场景可具有多个汽车交互的更复杂的场景，诸如作为示例而非限制的：超车场景，其中汽车在DUT前方超车；两侧超车场景，其中两辆汽车例如从两个不同车道在DUT前方超车；超车和减速场景，其中汽车在DUT前方超车然后减速，等等。

这些复杂的场景可以激活其参与场景中的较低级别的场景以适当地执行。即，“超车”可以调用每辆汽车的驾驶场景，从而多次调用“超车”场景。可以理解，该列表不是穷举的，并且可以使用MSDL、场景的层次结构、或MSDL以及场景的层次结构两者来描述其他场景。可进一步理解，此类场景可以自动地生成或通过由处理单元110执行的用户接口(未示出)手动地生成。可以通过使用数据流来完成自动提取，例如但不限于从其场景生成的视频流。可以通过网络接口140实时提供数据流，或者可以将数据流存储在数据库(DB)130中并且离线使用。场景可以包括对较低层次结构场景的参考，较低层次结构场景允许不重新创建先前已经定义的主体，且如本文中进一步描述的。

在S230，为了监测DUT主体的行为，由监测系统100执行所生成的主体和场景。

在S240，检查是否已经提供错误指示。在实施例中，该检查可检测场景何时成功发生。检查还可以包括存储关键性能指标(参数)及其覆盖数据。例如但不限于在DUT主体进入低照明区域但尚未激活DUT的前照灯的情况下，可能生成错误。在另一情况下，例如，在由主体执行超车和减速的场景时，预期DUT主体将导致DUT在距超车车辆的安全距离处减速。可以理解，车辆之间的最小距离是关键性能指标(KPI)的非限制性示例，一旦检测到超车和减速场景，该关键性能指标可以被存储。如果在S240已经检测到错误，则继续执行S250。否则，继续执行S260。

在S250，生成表示检测到错误的通知。在实施例中，进一步提供导致错误通知的场景，也可以提供使得能够在特定情况下响应于DUT的主体而重新创建导致错误的序列的其他通知以及它们的任意组合。

在S260，例如通过生成附加的(一个或更多个)主体和/或(一个或更多个)场景来检查是否应当继续监测，如果是，则继续执行S230。否则，执行终止。

图3描绘了描述根据实施例的用于生成监测系统的至少主体的方法的示例流程图300。

在S310，由监测系统100接收数据流。该数据流可以通过网络接口140接收，例如用于实时视频，或者该数据流从数据库(DB)130接收，例如用于离线视频处理。

在S320，选择物理对象，例如DUT、车辆、人行道、人等。可以借助于用户界面(未示出)来执行选择，该用户界面允许例如连接到I/O网络接口140的指示设备(未示出)，该指示设备用于指向和选择由数据流提供的物理对象。可以理解，在不脱离所公开的实施例的范围的情况下，在S320的选择可以扩展到多个物理对象的选择，用于针对每个物理对象创建相应的主体。

在S330，针对可以进一步使用先前定义的主体的物理对象创建主体，从而创建主体的层次结构。在S330创建的主体可以是与物理对象的特性匹配的特定类型，其中对象类型是使用MSDL来定义的。在一个实施例中，手动用户干预可以在必要时和在必要处提供主体的生成的指导。此外，两个或更多个主体的生成可以并行发生。

在S340，所创建的主体被存储在存储器中，例如存储器为在一个实施例中的存储器120或者在另一实施例中的数据库(DB)130。使用如本文所讨论的MSDL创建主体。

在S350，例如，基于由监测系统100接收的数据流来检查是否要创建更多主体，如果是，则继续执行S320。否则，执行终止。

图4A是根据实施例的超车和减速场景的示例示意性描述400A。自动驾驶车辆(AV)在图中被称为EGO 410，而另一车辆420在图中被称为CAR。因此，自动驾驶车辆420在起始点410S处开始该场景，而另一车辆420在位置420S(其在位置410S的后方)处开始该场景。相对于AV 410具有大于零的相对速度的另一车辆420在行驶路径440上经过AV 410，超车至AV410车道，并且减速，到达位置420E。这进而迫使在路径450上移动的AV 410减速以适应另一车辆420的速度变化，以便维持安全要求，从而在位置420E结束该场景。

图4A中提供的描述可以在三个单独的阶段中执行：领先于AV 410、超车和减速(图4B至图4D)。

图4B是根据实施例的超车和减速场景的领先阶段的示意性描述400B。图4B中描述的第一阶段被定义在起始位置与车辆420先于AV 410的位置之间。在该阶段中，车辆420从420S加速至420A，以便在同一车道中行驶距离440A而领先于AV 410A。在此期间，AV 410在410S处开始并继续到420A，在AV 410维持其速度和轨迹时覆盖距离450A。

图4C是根据实施例的超车和减速场景的超车阶段的示意性描述400C。在图4C中所描绘的第二阶段中，在420A处开始的车辆变换车道以覆盖距离440C到达AV 410A的前方的位置420C处。如果超车不是激进的(即，在AV 410A和车辆420A之间以锐角和/或短距离变换车道)，此时，从AV 410A覆盖距离450C到达的AV 410C仍然维持其速度和轨迹。第二阶段结束时的车辆420A的速度可以等于或大于第二阶段起始时的速度。可以理解，AV 410的新位置现在被标记为410C(被车辆420A超车后的AV 410)，并且车辆420A的新位置现在被标记为420C(在AV 410A之前超车后的车辆420，现在称为AV 410C，因为它处于不同的位置)。

图4D是根据实施例的超车和减速场景的减速阶段的示意性描述400D。在图4D所示的第三阶段中，当距AV 410C的距离为450E时，车辆420C刹车并且AV 410C必须以相同的方式作出反应。当进入该第三阶段时，AV 410C的最终速度小于两个车辆的初始速度。一旦完成，AV 410在AV 410E处并且AV 420在AV 420E处。根据实施例，例如通过如本文进一步描述的do_serial指令，MSDL允许将场景分段成更小的子场景或阶段，并且可以提供内置链接机制。

图5是根据实施例的超车和减速场景的覆盖度量的示意性描述。图5中描述的符号如下：rel_d_cls描述了在变换车道起始点处的相对距离([0..1500]cm中的间隔为50cm)；ego_v_cls描述了在AV 410的变换车道起始点处的绝对速度([10..130]km/h中的间隔为10km/h)；rel_v_cls描述了车辆420在变换车道起始点处相对于AV 410的相对速度([-33..33]m/s中的间隔为1m/s)；rel_d_cle描述了在变换车道结束点处AV 410和车辆420之间的相对距离([0..3000]cm中的间隔为50cm)；ego_v_cle描述了AV 410在变换车道结束点的绝对速度([10..130]km/h中的间隔为10km/h)；以及rel_v_cle描述了车辆420在变换车道结束点处相对于AV 410的相对速度([-33..33]m/s中的间隔为1m/s)。

根据所公开的实施例，覆盖度量(诸如上述覆盖度量等)及其任何组合可被用来手动地或自动地实施场景。

可以使用MSDL来定义超车和减速场景的示例如下：

在以上示例中，定义了汽车主体的类型字段car1、道路的路段以及汽车相对于ego在其上开始的初始侧。然后，将路径约束在[100..250]米长，并且需要具有至少2个车道的路径。

在MSDL中，除非另有说明，否则所有字段默认为可随机化。这意味着字段在运行时在其合法值空间内被给予随机值。每个字段具有由其类型的值范围定义的物理值空间，以及物理值空间与对其施加的任何约束条件之间的交集的合法值空间。例如，假定没有施加约束条件，侧字段具有[left,right]的物理值空间和相同的合法值空间。另一方面，路径字段具有作为地图能够提供的所有道路路段的集合的物理值空间，而合法价值空间被减少到仅具有在[100..250]米内的长度和至少两个车道的那些道路路段。“+path_*”是施加于要选择的道路路段的特性的约束条件。在一个实施例中，MSDL可以提供帮助定义场景或主体的多个主体。如本文所述，如可能需要，可以自动地或手动地定义主体和场景。任何场景必须在主体的背景下被定义以及被执行。

因此，场景行为可定义为如下：

在以上示例中，“do serial”是描述按照其定义的顺序链接的连续活动的内置运算符。在示例性实施例中，首先执行“get_ahead_of_ego”，之后执行“cut_in”，在“cut_in”之后执行“slow_down”。“phase”是描述并行活动的另一内置运算符。例如，并行地执行“ego_car.drive()”和“car1.drive()”。每个阶段具有起始时间点和结束时间点。类似地，“do serial”在第一阶段的开始处开始并在最后阶段的结束处结束。

可以在SDL语言手册中找到阶段结束条件的完整列表。根据实施例，MSDL监测系统100规划car1的轨迹，使得car1在cut_in阶段的起始处在ego的侧边。换言之，基于MSDL的监测系统100被适配成推断所有必要的移动以便在cut_in的起始处到达所期望的位置，这进而使测试工程师的工作变得容易并且创建更多样的具体场景，由此提供相对于现有技术解决方案的显著技术改进。

可以理解，所提供的描述描述的是系统主动控制car1使得场景发生的情境。在一个实施例中，从数据流(例如，视频短片)中选择car1，并且监测car1以查看在“cut-in-and-slow(超车和减速)”场景中描述的交互是否发生。在示例性实施例中，系统100(图1)相对于控制car1是被动的。

在实施例中，可以在场景定义中或者在场景的扩展(也称为场景的“方面”)中进一步定义场景内的覆盖。以下是覆盖场景扩展中的超车的非限制性示例：

根据实施例，定义覆盖的测试工程师考虑两个维度：对什么参数值进行采样，以及何时对它们进行采样。使用MSDL监测系统100，向测试工程师提供构造以指定对哪些参数进行采样并且细化必须被采样的值集(例如，单位、值范围)。覆盖定义(coveragedefinition)使用指定参数应当被采样的时刻的事件。在以上示例中，“change_lane.start”和“change_lane.end”是激活参数采样的采样事件。测试工程师可以使用预定义的事件，或者定义并触发再次使用这样的预定义的事件的定制事件。

根据实施例，测试流程的第一阶段是将MSDL源加载到监测系统100。下一步骤是加载并解释场景将使用的地图。此时，MSDL监测系统100准备好规划动作列表。该阶段将场景中描述的行为扩展到更高粒度的移动场景中。它还链接场景中的各个阶段。

如果规划阶段成功，则测试移动至模拟。在该阶段中，MSDL监测系统100开始与模拟器进行交互：其推进模拟；其检索主体的动态信息(位置、速度、加速度)；并且如果需要，其调整规划以便实现规划的目标。值得注意的是，在任何AV模拟中都有一定的不可预测性：可以采取不可预测决策来处理情境的AV是由交通背景迫使的。这意味着规划不总是与实际匹配，并且MSDL监测系统100通过在每个模拟步骤结束时调整规划来减轻AV行为的副作用。

在另一实施例中，MSDL源文件可被加载到系统(例如，监测系统100)。此后提供数据流。基于对物理对象的选择，根据本文描述的公开的实施例来生成主体。然后，关于例如“cut-in-and-slow”场景来监测所生成的主体的活动。监测系统在其检测到场景中的步骤的发生时生成事件。覆盖信息由系统保存并且相应地发布相应的消息。

以下是根据各种实施例用来定义主体和场景的MSDL的描述。为了验证自动驾驶车辆(AV)或高级驾驶员辅助系统(ADAS)的安全性，车辆或系统的行为应在各种情境或场景中被观察。可以使用可测量场景描述语言(MSDL)来定义和创建描述AV以及环境中的其他活动者的行为的场景。活动者包括车辆、行人、天气、道路条件等。

由于MSDL场景是高级描述，可以通过改变场景参数(诸如速度、车辆类型、天气条件等)来创建场景的许多具体变型。在实施例中，MSDL工具可以在指定约束条件的集合内自动地生成这些变型。这样的约束条件可由用户提供。在实施例中，MSDL工具从成功的测试中收集和汇总参数数据，从而能够测量你的AV的安全性。

MSDL是大部分声明的编程语言。自动执行的唯一场景是顶层场景。可以通过将场景添加到顶层场景来控制程序的执行流程。MSDL是面向方面的编程语言，其中可以对对象的一些或所有实例的行为或方面进行修改以适合特定验证测试的目的，而不干扰对象的原始描述。

MSDL是被设计用于描述其中诸如汽车和行人的活动者(有时称为主体)移动通过环境的场景的小型的域特定语言。这些场景具有允许控制并约束活动者、移动和环境的参数。MSDL被设计成促进场景和测试的组合，使得可以使用你自己的方法来定义复杂的行为。最小可扩展的活动者和场景的集合包括基本构建块。一些内置场景执行所有场景共有的任务，诸如实现并行执行。其他描述相对复杂的行为，诸如“car.drive”场景。

通过调用这些场景，可以描述甚至更复杂的行为，诸如接近让路标志的车辆。为了进一步提供复杂性，可以混合多个场景。例如，天气场景可与汽车场景混合。可以根据需要轻松创建新的活动者和新的场景，无论是从头开始还是使用已经定义的场景。例如，下面呈现的场景“cut_in”使用场景“car.drive”来定义。在实施例中，提供标准场景库来维持所有场景。根据需要向库添加新的场景或定制的场景。

MSDL构建块

MSDL的构建块是数据结构，至少包括以下各项：

·简单结构体–包含属性、约束条件等的基本实体。

·活动者–类似结构体，但也具有相关联的场景。

·场景–描述活动者的行为。

这些数据结构具有保存标量值、列表和其他结构的属性。属性值可被描述为表达式或通过外部方法定义来计算。属性值可用keep()约束条件来控制，例如：keep(speed＜50kph)(速度＜50kph)。

场景中的属性值可用keep()约束条件或用诸如speed()的场景修改符来控制。例如，speed(20kph,faster_than:car1)。

数据结构还定义事件，例如，事件too_close是(distance_between(car1,car2)<10m)。

可以通过调用内置场景来描述场景行为。可以激活或调用运算符场景串行(serial)、并行(parallel)或混合(mix)，以在串行或并行执行模式下实现场景或将其与另一场景混合。其他内置场景实现了与时间相关的动作，诸如发出、等待或错误报告。

示例场景

示例1示出了如何使用MSDL来定义和扩展活动者。活动者car_group最初用两个属性来定义。然后在不同的文件中对其进行扩展以添加另一属性。

示例2示出了如何使用MSDL来定义命名为two_phases的新场景。该场景定义单个属性car1，其为绿色卡车，并且使用串行运算符和并行运算符来激活car1.drive场景，然后向其施加speed()修改符。two_phases场景操作如下：

·在第一阶段期间，car1从0kph加速至10kph。

·在第二阶段期间，car1保持10至15kph的速度。

示例3示出了如何定义要运行的测试：

1.导入适当的配置，以使用模拟器(例如，SUMO模拟器)运行测试。

2.导入定义的two_phases场景。

3.扩展预先定义的最初为空的top.main场景，以调用所导入的two_phases场景。

示例4示出了如何定义场景中的超车。其中，car1从左侧或从右侧超车到dut.car的前方。dut.car(也称为ego汽车)是预定义的。应注意，此场景比two_phases更抽象。

“超车”场景包括三个参数：

·汽车进行cut_in(car1)。

·cut_in的侧边(左或右)。

·由这两辆汽车使用的路径(道路)，被约束为具有至少两条车道。

然后我们定义行为：

·在第一阶段中，car1领先于ego。

·在第二阶段中，car1超车到ego的前方。

这里使用场景修改符speed()、position()和lane()。可以以绝对术语或者与相同阶段中另一汽车的关系来指定每个场景修改符。可以针对整个阶段或仅针对该阶段的起始点或结束点来指定每个场景修改符。

示例5示出了如何使用cut_in场景来定义two_cut_in场景。two_cut_in场景执行从左的cut_in场景，随后执行从右的cut_in场景。此外，所涉及的两辆汽车的颜色被约束为不同的。

示例6示出了如何运行具有具体值的cut_in。原始cut_in指定范围，因此默认地，每个运行将选择该范围内的随机值。可以使用约束条件将测试定义为具体的。

示例7示出了如何混合以下多个场景：cut_in场景、称为interceptor_at_yield的另一场景、以及set_weather场景。mix_dangers场景具有类型weather_kind的单个属性，由于我们希望出现危险的情境，mix_dangers场景被约束为不美好(即，！nice)。该属性被传递到set_weather。

示例8运行mix_dangers。在这种情况下，指定具体天气(雨)而不是非特定术语(例如，不美好的天气)。

语法约定的概要：

MSDL类似于Python脚本语言。MSDL程序由声明或扩展类型的语句组成，诸如结构体、活动者、场景或导入由该语句组成的其他文件。每个语句包括来自该语句本身缩进一个单位(一致数目的空格)的成员的可选列表。块中的每个成员(取决于其类型)可以具有其自己的成员块，该成员块从成员本身缩进一个单元。由此，MSDL程序的层次结构和该层次结构中每个成员的位置严格地由缩进指示。

共有缩进指示处于相同层级的成员。推荐使用四个空格(空格符号)的倍数来指示连续的层级，但是只要用法是一致的，允许其他单位(两个、三个等等)的倍数。块内的不一致的缩进是错误。代码中的制表符被转换为空格。在将反斜杠字符(\)放置在换行字符之前以后，长度太长而不能容纳在单个物理行中的成员(字符串除外)可以继续到下一行。然而，具有左圆括号(或左方括号[的行换行，而不需要反斜杠字符。行内注释以井号字符(#)开头，并且在行末结束。允许分块注释。块中的每一行必须以/*字符开始且以*/字符结束。允许嵌套的块注释。注释内的换行和注释的缩进不影响代码嵌套。

MSDL构造

语句是程序中的任何其他构造之外的顶层构造。语句包括：

·枚举类型声明

·结构体声明

·活动者声明

·场景声明

·场景修改符声明

·对那些声明的扩展

·导入语句。

语句是定义或扩展类型或导入由语句组成的文件的顶层构造。枚举类型声明定义了明确地命名的值的集合。例如，枚举类型driving_style可以定义两个值的集合：正常(normal)和激进(aggressive)。结构体声明定义存储各种类型的相关数据的复合数据结构。例如，称为car_collision的结构体可以存储关于涉及碰撞的车辆的数据。活动者声明模型化如汽车、行人、如交通灯的环境对象等的实体。语句是存储关于这些实体的信息的复合数据结构。与结构体相反，它们还与场景声明或扩展相关联。由此，活动者是相关数据和所声明的活动两者的集。

场景声明定义了描述一个或更多个活动者的行为或活动的复合数据结构。可以控制场景的行为，并且可以通过声明场景本身中或其相关活动者或结构体中的数据字段和其他成员来收集关于它们执行的数据。示例场景是car.drive、dut.cut_in、dut.cut_in_with_person_running等。场景修改符声明通过约束诸如速度、位置等属性来修改(但不定义)场景行为。场景修改符声明可以包括先前定义的修改符。对枚举类型的现有类型或子类型、结构体、活动者或场景的扩展添加到原始声明而无需对它进行修改。这种能力允许扩展用于特定测试或测试集合的目的的类型。

结构体、活动者或场景成员。以下构造可仅出现在结构体、活动者或场景声明或扩展内。这些构造包括：

·覆盖定义

·事件

·字段声明

·字段约束条件(keep())

·外部方法声明

·当子类型时

注意，场景与特定活动者相关联，但被声明为顶层语句。

本部分中所描述的构造可以仅出现在结构体、活动者或场景声明或扩展内。覆盖定义允许对与场景执行相关的关键参数进行采样。通过场景的多次执行来收集该数据允许评估AV的安全性。例如，如果汽车活动者具有字段speed，则可以收集该字段在场景期间的关键点处的值。

覆盖定义出现在场景中以访问场景的参数并且根据场景改变覆盖定义。字段声明定义了任何标量、结构体或活动者类型的命名数据字段或任何这些类型的列表。必须指定字段的数据类型。例如，该字段声明定义了命名为legal_speed类型的速度的字段。用keep()定义的字段约束条件限制可被分配到数据字段或为数据字段生成的值。例如，由于以下keep()约束条件，legal_speed的随机化值被保持在120kph以下：

keep(legal_speed<120kph)

该约束条件还可以写成如下，其中隐含变量引用legal_speed字段：

legal_speed:speed with:

keep(it<120kph)

事件定义特定时间点。事件由场景中的显式发出动作或由它所绑定到的另一事件的发生来引发。场景和场景阶段具有三个预定义事件：开始、结束和失败。当子类型在指定条件为真时扩展对象时。例如，如果活动者my_car具有driving_style类型的字段，则活动者的属性或行为在driving style(驾驶风格)的值为激进时与在driving style的值为正常时相比可以是不同的。外部方法声明标识用其他编程语言(诸如C++、Python和e验证语言)编写的强制代码可从MSDL程序调用。例如，可以调用基于场景的参数来计算和返回值的外部方法。

场景成员。场景成员出现在场景声明或扩展内。场景成员包括：

·在结构体或活动者中允许的成员

·场景修改符调用

·do(行为定义)

场景具有在结构体或活动者中不被允许的两个成员。场景修改符是约束场景行为的各种属性的场景。它们不定义场景的主要行为。存在相对和绝对修改符两者。在下面的示例中，speed()修改符将受影响的汽车的速度设置为相对于car1快1至5kph：

speed([1..5]kph,faster_than:car1)

“do”场景成员定义了当其被调用时的场景的行为。

场景调用。

可以调用以下类型的场景：

·运算符场景

·事件相关场景

·零时间场景

·用户定义的场景

场景调用扩展了MSDL程序的执行。自动调用内置的top.main场景。Top.main需要扩展来调用其他场景，从而定义整个SDL程序的行为。

表达式。

可以在语句或成员内使用表达式并且对指定类型的值进行评估。在所指定的构造中允许表达式。该表达式必须针对指定类型进行评估。表达式可以包括对外部值返回方法的调用。

数据类型

MSDL定义以下数据类型：

·标量类型一次保存一个值：数字、布尔和枚举。

·列表类型保存一个类型的多个值。

·字符串类型保存用双引号括起来的ASCII字符序列。

·资源类型保存地图交叉点和段的列表。

·真实类型保存浮点值。

·复合类型保存多个类型的多个值。

物理类型

物理类型用于表征空间中的物理移动，包括速度、距离、角度等。当在表达式中指定这些类型中的一个的值或者定义其覆盖范围时，必须定义和使用相应的单位。如下表所示，可选择最常用类型的单位选择。物理常数具有隐含的类型。例如，12.5km具有隐含类型的距离。示例：2米、1.5s、[30..50]kph。

以下是所使用的标准物理单位：acceleration.kphps(＝kph per second)、mpsps(＝meters per second per second)angle.Deg、degree、rad、radianangular_speed.degree_per_second、radan_per_second distance.mm、millimeter、cm、centimeter、in、inch、feet、m、meter、km、kilometer、mile speed.kph、kilometer_per_hour、mph、mile_per_hour temperature.c、celsius、f、Fahrenheit time.ms、millisecond、s、sec、second、min、minute、hr、hourweight.kg、kilogram、ton。

枚举类型

枚举类型表示明确地命名的值的集合。在下面的示例中，枚举类型driving_style具有两个值：激进和正常。

type driving_style:[aggressive,normal]

列表类型

列表是在MSDL中描述类似值的容器的方式。列表可以包含来自数据类型的任意数量的元素。例如，可以声明车队包含汽车活动者列表、或形状作为点列表。列表文字被定义为逗号分隔的项目列表，例如：

[point1,point2]

列表不允许使用[n..n]表示法；它是为范围保留的。列表示例为：

convoy:list of car

shape:list of point

列表分配的示例为：

shape:list of point with:

keep(it＝＝[map.explicit_point("-15",0,20m,1),

map.explicit_point("-15",0,130m,1)]

列表约束条件的示例为:

distances:list of distance with:

keep(it＝＝[12km,13.5km,70km])

资源类型

资源类型包括用于保存当前地图上的位置的全局列表的交叉点和段。

复合类型

MSDL定义了三种内置复合类型：场景定义行为，诸如接近让路标志的汽车、横越街道的行人等。场景通过激活其他场景来定义行为。MSDL提供了描述基本行为(诸如移动、加速、转弯等)的内置场景库。活动者通常表示环境中的物理实体并且允许场景定义它们的行为。MSDL提供了内置活动者的集合，包括汽车、交通、环境等。如果在名称为my_car的程序中创建活动者汽车的实例，则其内置场景驾驶可被调用为my_car.drive。结构体定义了相关数据字段的集合并且存储由程序为那些字段分配或生成的值。例如，结构体可能在特定时间存储汽车的位置、速度和与其他汽车的距离。

复合类型可以扩展为包括新的数据或行为，并且它们的定义可以通过类似继承而传递至新的复合类型。例如，可以将预定义的活动者汽车扩展为包括新的场景，或者可以创建继承了汽车场景并且然后添加新的场景的新的活动者my_car。复合类型还可以在继承时有条件地扩展。利用该特征，仅在指定条件为真时扩展类型。例如，如果活动者my_car具有driving_style类型的字段，则活动者的属性或行为在驾驶风格的值为激进时与在驾驶风格的值为正常时相比可以是不同的。

预定义的AV类型

MSDL环境包含若干预定义的活动者。活动者顶部包含以下活动者的实例：builtin表示MSDL的内置场景；av_sim_adaptor表示MSDL的模拟器接口；map表示活动者行驶的路径的集合；traffic表示汽车、行人等；env表示环境系统以及具有诸如天气、一天中的时间等场景；以及，dut表示AV系统或待测设备。在traffic下，存在称为汽车活动者的汽车的列表。在dut下有：car类型的dut.car表示实际dut car(也称为ego)；可能还有其他活动者，对应各种监督功能等。

应注意，因为map、env、traffic和dut实例化为顶部的字段，所以这些字段可直接作为全局活动者来访问，而不参考它们在层次结构中的位置，例如：

keep(x＝＝env.time_of_day)

keep(car_in_position＝＝map.reach(car1,point1))

任何活动者都可以在该层次结构中扩展以添加活动者。MSDL可在运行之前或期间创建活动者。在创建时，根据已指定的约束条件来随机化活动者的字段，并且其内置开始场景开始以活动模式运行。开始场景可以执行其他场景，并且这些场景也以活动模式运行。场景top.main()间接地从top.start()中被调用。该场景最初是空的并且定义测试做什么。因此，为了使你的测试运行cut_in_and_slow场景，可以扩展top.main，top.main可延伸：

extend top.main:

do c:cut_in_and_slow()

预定义的env活动者

env活动者是全局活动者，并且包含所有与环境相关的活动。它具有改变像weather和time_of_day的环境的场景，例如：

weather(kind:rain,temperature:12.5c,duration:3min)

time_of_day(part:evening,start_time:18hr)

类型部分(part)是上午、中午、晚上或夜晚，种类(kind)是雨、雪、阳光。例如：

预定义的汽车活动者字段

汽车活动者的以下字段可被扩展或约束，以与你的模拟器所允许的类型相匹配。可以对这些字段进行采样并在覆盖定义中使用它们。

汽车活动者还具有被称为驾驶的场景。驾驶(drive)是移动场景，并且其具有表示要驾驶的路径的路径参数。可以在汽车的驾驶场景内指定场景修改符。

预定义的枚举类型。下表中列出了各种枚举类型：

用户任务流程

MSDL支持的验证任务流程如下：

1、规划验证项目。

·标识表示诸如城市驾驶、公路驾驶、天气、传感器发生故障等风险维度的顶层场景类别。

·标识场景子类别。例如，车道变换可以是公路驾驶的子类别。

·标识每个场景子类别中的行为。例如，超车和减速将是车道变换子类别中的行为。

·标识覆盖收集点以确定每个场景已经被覆盖(成功执行)地多彻底。例如，超车和减速行为可能具有包括道路条件、距离和速度的覆盖点。

·标识用来判断DUT在各种场景中执行得有多好的检查标准(等级)。

·标识那些行为和场景的覆盖目标。

2、创建验证环境。

·以MSDL描述场景、行为和覆盖点，将它们基于较低级别的内置场景或在库中可用。

·标识DUT和执行平台。

·标识可使用的任何其他附加工具。

3、自动化测试运行。

·写测试，可能混合来自不同子类别的场景，诸如具有冲突车道变换的超车和减速。

·针对场景变量(诸如道路条件、速度和可见度)的不同值来启动多个运行。

4、分析失败。

·标识任何检查错误的原因，诸如碰撞或接近碰撞。

·修复DUT或应用临时补丁，使得测试可以继续。

·自动地重新运行所有失败的运行。

5、跟踪进度。

·分析与在验证规划中指定的每个目标相关的覆盖数据，以确定哪些场景没有被充分地测试。

·写新的测试以达到那些极端情况。

本文公开的各种实施例可以被实施为硬件、固件、软件或它们的任意组合。此外，软件优选地被实施为有形地体现在程序存储单元或计算机可读介质上的应用程序，该程序存储单元或计算机可读介质包括部件或某些设备和/或设备的组合。可以将应用程序上传到包括任何适当架构的机器并且由该机器执行。优选地，机器在具有硬件(诸如一个或更多个中央处理单元(“CPU”)、存储器和输入/输出接口)的计算机平台上实施。计算机平台还可以包括操作系统和微指令代码。本文描述的各种过程和功能可以是可以由CPU执行的微指令代码的一部分或应用程序的一部分或它们的任意组合，无论是否明确示出了这样的计算机或处理器。此外，诸如附加数据存储单元和打印单元的各种其他外围单元可以连接到计算机平台。此外，非暂时性计算机可读介质是除了暂时性传播信号之外的任何计算机可读介质。

本文所叙述的所有示例和条件性语言旨在用于教学目的，以帮助读者理解所公开的实施例的原理以及发明人为进一步促进本领域所贡献的概念，并且应解释为不限于这些具体叙述的示例和条件。此外，本文叙述所公开的实施例的原理、方面和实施例以及其特定示例的所有陈述旨在涵盖其结构和功能上的等同物。另外，这种等同物旨在包括当前已知的等同物以及将来开发的等同物，即，不管结构如何都执行相同功能的开发的任何元素。

如在本文中所使用的，跟随有项目列表的短语“至少一个”是指可以单独使用所列出的项目中的任何一个，或者可以使用所列出的项目中的两个或更多个的任意组合。例如，如果系统被描述为包括“A、B和C中的至少一项”，则该系统可以包括单独的A、单独的B、单独的C、A和B的组合、B和C的组合、A和C的组合、或A、B和C的组合。