应用计算机软件matlab使用迭代法仿真激光谐振腔模式_经验论文：自动驾驶控制应用中基于搜索的测试...

摘要

仿真环境中的自动测试生成和评估是验证自动驾驶(AD)应用程序的一项关键技术。基于搜索的测试(SBT)是一种用于自动生成测试的方法，该方法利用一些优化方法从抽象测试描述中高效地生成具体的测试。在这篇文章中，我们成功地将 SBT 应用于具有不同特征的多个 AD 控制应用程序用例中，并报告了我们的观察结果。根据我们的经验，我们得出了许多教训，我们认为这些教训对于在工业环境中采用 SBT 方法和工具很重要。其中，最关键的教训是，SBT 会发现许多相关的错误，并向开发人员提供有价值的反馈，但需要特定工具来编写规范。

关键词

基于搜索的测试，自动驾驶，自动生成测试

1 引言

自动驾驶(AD)应用程序旨在承担驾驶员的驾驶责任。因此，这些系统具有很高的安全性和性能要求，这意味着它们不得对周围环境构成安全威胁，也不应阻碍周围的交通。这两个问题都要求在各种流量情况下对 AD 软件进行全面测试。为此，在模拟世界中进行虚拟化软件测试是一项关键技术，可在开发过程中获得快速反馈并支持系统的安全论据。模拟的环境的复杂性和要测试的方案的数量需要使用自动测试生成和评估技术。

通常，AD 应用程序具有功能块，这些功能块在概念上遵循如图 1a 所示的感知计划行为体系结构。在这种架构中，传感器例如基于照相机，激光雷达和惯性传感器来提供来自物理环境的(原始)信息。“Sense”组件将这些信息转换为车辆环境的模型。“计划”组件根据给定的当前环境决定要采取的机动措施，例如待在车道或变更车道上，然后由法案部分实现。“行为”组件通常包含几种(级联)反馈控制算法，这些算法控制车辆的执行器并与物理环境形成闭合回路。

(a)自动驾驶系统的高级架构

(b)Act 组件的仿真设置

图 1 系统架构和仿真设置

由于测试空间的高维度，因此无法对 AD 应用程序进行整体测试。因此，测试需要将测试问题仔细分解为可以单独解决的较小测试问题。在本文中，我们关注测试 AD 应用程序的 Act 组件。为了获得此设置，我们假设对 AD 应用程序进行以下分解。我们将 Sense 组件的测试与“计划”和“行为”组件的测试分开。为此，我们使用模拟器中的地面事实代替 Sense 组件。我们还会根据“计划”组件的决策将“计划”组件的行为分解为等效类，其中每个等效类都由所谓的逻辑场景表示，在这种情况下，行为组件(即被测软件)期望具有相同的行为。例如，在逻辑场景中可能存在这样一个示例，在 3 条车道的高速公路上，A 车跟随前车行驶，此时 B 车以低速驶入 A 车车道。

为了测试 Act 组件的正确行为，必须在特定的仿真框架中将逻辑方案实例化为具体方案。因此，每种具体情况都会在仿真框架中导致一个闭环仿真运行(测试)。针对给定的具体方案执行仿真需要使用逻辑方案中的不同参数的具体取值来刺激测试中的软件及其周围系统。在上面的示例中，这包括诸如车速，车辆之间的初始距离，路口定时或道路坡度之类的参数。由于它们的物理性质，这些参数是实值，因此使生成的测试空间无限大。在本文中，我们关注的问题是如何从给定的逻辑场景中有效地生成具体场景。我们使用基于搜索的测试代替使用随机测试或逻辑参数的固定网格化技术。

基于搜索的测试(SBT)是一种基于元启发式优化的自动测试生成方法。SBT 的基本思想是使用描述需求满足程度的定量度量(适应性函数)，并采用一种利用该度量自动为被测软件生成测试的优化程序。优化器尝试找到使定量指标最小化的参数评估，这反过来对于被测系统来说是最坏的情况。我们使用贝叶斯优化之类的优化算法，使得 SBT 实例可以支持连续参数空间。

在这篇经验文章中，我们报告了在 AD 应用程序中应用 SBT 的观察结果，这些应用程序可以从逻辑方案中生成具体方案。尽管 SBT 在表明该技术有用性的学术论文中取得了令人印象深刻的结果，但尚未在汽车工业中广泛采用。我们讨论了 SBT 在高速公路上的 AD 软件的三种不同逻辑场景中的应用(参见第三节)：自适应巡航控制，对抗环境下的车道保持和转向控制。基于 SBT 的这些成功应用，我们报告了我们在工具框架和规范方面的经验教训和面临的障碍(参见第四节)。这些经验教训并非特定于特定的实现，而是着重于使 SBT 成为 AD 域中一种方法的一般用法和标准。

我们研究的主要结果是(i)SBT 有效地发现了 AD 应用程序中的相关错误；(ii)用户的接受度取决于与现有工具链的无缝集成程度以及测试结果的反馈程序；以及(iii)对编写和调试规范的良好支持是必要的。

2 基于搜索的测试

图 2 显示了 SBT 的框架。测试任务是一种非正式的描述，由逻辑场景和规范组成(参见第一节)。该规范被正式化为可执行监视器(STL 监视器)，并且逻辑方案被实现为输入信号发生器。输入信号发生器，被测系统(SUT)和监视器组成一个模拟场景，在该模拟场景上执行测试。测试生成是由优化器驱动的，该优化器试图找到 SUT 的测试输入，以最大程度地降低 SUT 的性能。优化器的输出格式是实值的低维向量，以下称为参数。输入信号发生器将这些参数映射到具体场景上，并在技术上与 SUT 接口。

图 2 基于搜索的测试框架

我们在案例研究中使用的基于搜索的测试技术基于伪造工具，例如 Breach 和 S-TaLiRo。这些工具使用户可以分别在信号时态逻辑(STL)或度量时态逻辑(MTL)中提供闭环规范。这些逻辑是线性时序逻辑向连续时间和实值信号的扩展。此外，它们还具有强大的语义，该语义是实值而不是布尔值，并量化了给定信号对规范的满意程度或违反程度。伪造工具使用这些值来驱动优化循环，以便生成新测试，从而导致系统的测试困难。在 SBT 中，还有大量工作都是基于手工制定的性能指标，这些指标并非基于逻辑，而是着眼于搜索方面。对于我们的实验，我们专注于基于时间逻辑的技术。

我们选择不直接使用学术界的任何框架，而是针对 AD 应用程序的特定需求开发了自己的特定实现。尤其是，形式化的功能规范目前在汽车工业中并不是最新技术，这意味着这种框架必须提供调试规范的方法以及常见情况的规范模式。此外，用于软件开发和仿真的工具链已经非常复杂，因此必须尽可能减少工具开销。

为了使我们的实现最适合汽车行业的需求，我们做出了以下初步设计决策：

• 通过使用核心算法构建一个 C ++库，使该实现独立于仿真工具，从而可以为不同的工具提供接口。
• 我们没有将框架限制于时间逻辑运算符，以便在需要时让自定义运算符保持打开的可能性。
• 对于我们使用的工具，我们创建了紧密的工具集成。例如，对于 Matlab，过滤器包含在 Simulink 中。
• 我们没有构建自己的优化器，而是使用 Matlab 提供的现成的优化器(例如贝叶斯优化)，从而允许针对当前的特定 SBT 问题选择不同的优化器。

3 工业案例研究

在本节中，我们描述了在工业 AD 环境中选择的三个案例研究：自适应巡航控制(ACC)，车道保持和转向控制。这些案例研究是与来自不同业务部门，具有不同思维方式和工程文化的不同开发团队合作完成的。

3.1 自适应巡航控制

场景说明：第一个案例研究是针对高速公路情况的自适应巡航控制器(ACC)。当计划者决定停留在当前车道上时(可能跟随前方车辆)，此控制器将处于活动状态。总体任务是尽可能与其他车辆保持安全距离。这包括所谓的闯入，即在自我车辆前方的其他车辆的车道改变，这可能发生在潜在的不安全距离处。如果前面没有其他车辆，则应注意设定的速度，该速度可以是通过人机界面输入的乘客，来自感知的限速信息等的组合。

因此，控制器的目标是：(1)ACC1：保持与同一车道中前一辆车辆的速度相关的距离，(2)ACC2：在没有前车的情况下保持设定速度。

该系统的规格主要是根据物理量(例如速度和位置)定义的，因此需要进行闭环测试。因此，测试设置不仅包括控制器本身，还包括自我车辆和相关其他车辆的物理模拟(在这种情况下，使用商业工具 IPG CarMaker)。

我们使用的 ACC 软件处于开发的早期阶段，因此，我们希望使用此方法会发现一些违反规范的情况。

测试设置：通常，对于操作模式 ACC1 和 ACC2 以及它们之间的转换都有规范。这些中的每一个对应于要使用 SBT 测试的许多不同的逻辑方案。

在下文中，我们解释了 ACC 功能的三种特定逻辑场景，它们代表了不同的流量配置。每个配置都映射到特定的 SBT 问题。所有场景都有一个共同点，即实值测试参数位于物理环境中：我们不直接改变对被测系统的输入，而是在物理环境模拟中改变参数，以创建被测系统的各种情况应该做出反应，然后监视闭环响应。此案例研究的输入信号发生器将这些参数映射到 IPG CarMaker 的信号描述文件中。

规范 1：第一个逻辑场景涉及从 ACC2 过渡到 ACC1 的规范，在该规范中，当自我车辆处于设定速度控制中时，自我车辆接近另一辆车辆或被另一辆车辆闯入。我们假设在这种情况下没有其他车辆。对于这种逻辑情况，有两个参数是变化的：两辆车的初始速度。初始距离设置为固定(较大)量。假定前面的车辆具有恒定速度。

测试结果：图 3 显示了当自驾车驶向前车时的测试结果。使用上面给出的过去时间公式(7)的可靠语义和贝叶斯优化程序，针对此逻辑场景总共生成了 50 个测试，每个测试大约需要 5 分钟。应该注意的是，在线监视器的评估时间增加了不到 30 秒的仿真时间。与模拟时间相比，用于生成贝叶斯优化器的高斯回归模型的时间可以忽略不计。

图 3 从自适应巡航控制的速度控制到距离控制过渡的测试结果

规范 2：以下是我们针对情况 ACC2(无前车的设定速度控制)测试的一种规范。它描述了乘客对最佳设定速度变化的反应(使用机舱内部的控件)或公认的限速标志。

规范 3：另一个重要的场景是在我们已经关注了一辆车的情况下插入一辆车。此场景涉及三辆车：自我车，自我最初跟随的车和执行插入的车(请参见图 4，图)。

图 4 跟进一辆车时插入另一辆车

3.2 车道保持

方案说明：此案例研究涉及自动驾驶汽车通过转向和/或制动在挑战性条件下保持在车道内的能力。特别是，我们考虑了纵向和横向道路坡度，风和道路的曲率，这些因素可能共同导致车辆离开其指定的行驶车道。

测试设置：被测系统及其环境的仿真设置和界面与自适应巡航控制情况相同。但是，对于此处考虑的场景，没有前面的车辆。取而代之的是，改变道路参数，尤其是曲率和坡度(纵向和横向)，以及影响车辆的恒定风的角度和速度，车辆质量的分布以及车辆的设定速度，从而产生变化。在六维测试空间中。道路被建模为直线段，然后是左侧具有恒定曲率的曲线。

3.3 转向控制

场景描述：第三个案例研究涉及转向系统的低级控制器。控制器的目的是跟踪转向齿条的所需位置，该位置实质上定义了前轮相对于车辆底盘的方向。通过计算施加到电动机的电动机扭矩输出信号来执行此操作，以将机架移动到所需的机架位置。实际机架位置及其时间导数(机架速度)被反馈到控制器中。

测试结果：在早期开发阶段对控制器进行了测试。众所周知，并非所有可行参数值都满足规范。因此，我们更希望获得整个参数空间的规范满意度的概述，而不是单个失败的测试。特别是，应该确定规格满意度突然变化的区域。

4 结论

在本文中，我们介绍了从 AD 领域中选择的三个案例研究，并评估了 SBT 在案例研究中的应用。评估基于我们自己的 SBT 框架，该框架受 S-TaLiRo 和 Breach 的启发。我们讨论了在案例研究中吸取的一些教训。关键的教训是(i)SBT 在工业环境中运作良好；(ii)提供可行的反馈并将其无缝集成到开发人员的工具中，是接受该方法的关键；以及(iii)对编写和调试的良好支持规范很重要。

该经验报告的结果将有助于研究人员和从业人员将 SBT 广泛应用于工业实践中。

除了所报告的经验教训之外，未来的工作还可以集中在(i)在线信号生成，以识别被测软件的具有挑战性和任意形状的输入信号，(ii)在场景空间中搜索以自动构建有意义的场景，以及(iii)找到何时停止测试的参数。尽管前期工作前景看好，但仍有许多悬而未决的问题，尤其是在工业环境中。

致谢

本文由南京大学软件学院 2020 级硕士张松涛转述