用于修改自主车辆的控制单元的方法和系统

摘要

本发明是一种用于修改配备有传感器的自主车辆的控制单元的方法，在该方法的过程中：在脱离事件之前的分析时间窗口中在该自主车辆的自主驾驶模式中执行的自主测试动作期间记录脱离相关数据(S40)；在模拟器装置中基于该脱离相关数据来生成用于该分析时间窗口的虚拟场景，并且执行第一虚拟运行，以使得该第一虚拟运行导致该虚拟场景中的脱离事件(S50)；基于该虚拟场景来标识控制单元的操作不恰当的组件(S60)；以及修改该控制单元的操作不恰当的组件，执行第二虚拟自主运行(S70)，并且检查是否在该第二虚拟自主运行中避免了该脱离事件。

说明书

技术领域

本发明涉及一种用于修改(具体而言—进一步—开发)自主车辆的控制单元的方法，其中该自主车辆配备有基础传感器，其中由基础传感器记录的传感器数据使得控制单元能够以自主驾驶模式控制该自主车辆。本发明还涉及一种用于修改自主车辆的控制单元的系统，以及对应的计算机程序产品和计算机可读介质。

背景技术

自主交通工具开发的安全测试是该过程的关键部分。在没有确保一切正常的情况下上路，尤其是在公共道路上，可能会导致自主车辆的控制系统准备不足以应对这种情况，并且可导致安全驾驶员应当进行干预的情况，甚至更糟的是发生事故。因此，从现有技术中已知用于安全测试的若干不同方法。

基于上述原因，扩展测试必须被完成。由此，已知用于模拟技术的许多方法，这些方法可帮助自主车辆的控制单元的开发。

在US 2017/0132117 A1中公开了一种用于为自主交通工具生成测试用例的方法和设备。测试用例生成基于中央数据库，该数据库的数据是从交通中的任何种类的真实交通工具获取的。该文献的方法的缺点是这种测试用例生成被认为适合开发基础控制单元；然而，它不被认为适合处置非预期情形。在与以上文献相对应的US 2017/0132118 A1中公开了一种用于自主交通工具的测试软件的方法和装置。

在Franck Gechter等人在第六届系统模拟进展国际会议SIMUL 2014发表的Towards a Hybrid Real/Virtual Simulation of Autonomous Vehicles for CriticalScenarios(面向用于关键场景的自主交通工具的混合真实/虚拟模拟)中公开了一种用于模拟各种情形的混合模拟技术。

提交给Elsevier 2011的预印本还有另一篇文章，Franck Gechter等人：VIVUS：虚拟智能交通工具城市模拟器：在车队评估的应用，其公开了用于构建虚拟现实的框架。不利的是，该模拟器在许多步骤中需要人类交互。其它模拟框架的公开内容可以在以下链接下找到：

·https://uk.mathworks.com/products/automated-driving/features.html

·https://uk.mathworks.com/help/driving/examples/model-radar-sensor-detections.

html

·http://www.vcrashusa.com/

模拟框架在DE 10 2007 053 501 A1中公开。在该框架中，创建从中生成许多类似场景的主场景文件。其它模拟框架在DE 10 2007 053 500 A1、DE 10 2008 027 526 B4、DE10 2011 088 805 A1、US 2016/0210383 A1和US 2017/0161414 A1中公开。

鉴于已知方法，存在对凭借其能够以比现有技术方法更高效的方式修改(进一步开发)自主车辆的控制单元以使其能够尽可能好地响应非预期情形的方法的需求。

发明内容

本发明的主要目的是提供一种用于修改自主车辆的控制单元的方法，该方法最大程度地避免了现有技术方法的缺点。

本发明的目的是提供凭借其能够以比现有技术方法更高效的方式修改(进一步开发)自主车辆的控制单元以使其能够尽可能好地响应非预期情形的方法。因此，本发明的目的是使得可以基于各场景(非预期情形)来进一步开发自主车辆的控制单元，这些场景无法在模拟器中正常构造并且通常将不会被由安全工程师(人工地)生成的情形覆盖。

基本地，本发明的目的是对自主车辆的控制单元进行进一步开发。换言之，最好在借助包含大量普通日常情况的数据库开发出基本控制框架之后，使其对非预期情形更加敏锐且更具响应性。

本发明的目的可通过如权利要求1所述的方法来达成。本发明的优选实施例在从属权利要求中被限定。

根据本发明的方法相比于现有技术方法的主要优点来自以下事实：本发明的框架在脱离事件，更具体地在连接到脱离事件的脱离报告上构建。脱离事件是非预期情形的结果，这些非预期情形由自主车辆的控制单元来处置。由于脱离对应于其中自主车辆再也无法控制其自身的情形，因此脱离事件直接指向自主车辆的控制系统的将被修改(进一步开发)的组件。

以上引用的现有技术方法中没有一种方法使用与脱离事件相对应的测试用例。因此，现有技术方法中不存在揭示自动驾驶中断(即，脱离)的原因的功能性，该分析导致对控制单元的将被修改(改进)的部分的高效标识。由此，在揭示(标识)要修改(改进)的控制区域方面，根据本发明的方法比现有技术方法更高效。本发明通过使用脱离前的所有可用信息并且只重构测试的相关部分以最大化场景测试流水线的可用性来聚焦于真实世界测试的仅仅关键部分。

总之，根据本发明，在发生脱离事件时创建(新)场景文件，而许多现有技术方法(诸如DE 10 2007 053 501 A1)使用现有场景文件来工作(或通过基于现有情形来生成新情形)。不像一些现有技术方法，根据本发明，车辆的集成传感器不被使用，但使用已被专门校准并添加至车辆的那些传感器(在许多现有技术方法中，只从自主车辆的内部行为(如制动、转向等)收集信息)。这些传感器的作用是重现场景，就像它们发生时那样。根据本发明，使用视觉上良好的确定性模拟器，由此运行可重复若干次，并且通过提供恰好相同的输入，将获取相同的输出。

因此，注意，借助于本发明，自主车辆的控制单元(控制单元—优选地是控制系统的一部分—优选地通过(控制)软件或通过软件和硬件元件的组合来实现)的弱点能够以高效的方式改进。换言之，通过将脱离事件用作要模拟的事件，被认为是非预期的事件可被捕获并处置。在模拟器中使用自主车辆的用基本情形(它在上文中被称为基本控制框架)而不是大量人工生成的测试事件训练的控制单元来处理脱离事件使根据本发明的框架是高效的，因为每个单一脱离事件在它被分析什么是脱离原因时导致控制单元的组件中的修改(开发)。因此，在本发明中，对控制单元的修改(开发)优选地开始于(已经开发出的)基础级控制单元，该控制单元将变得响应于非预期事件。

在根据本发明的方法中，基于脱离相关(日志)数据的虚拟世界(及其中的场景)的构建优选地被自动执行。此外，基于所记录(日志记录)的脱离相关数据，虚拟场景(包括具有其特性和行为的周围车辆)也被自动生成。根据模拟器中的确定性运行，脱离(自主模式中断)的原因可被重现、调试并且虚拟地修复。

在根据本发明的方法中，优选地不需要手动工作来将真实生活场景转换成虚拟场景，以使得不需要计及人类错误。从以下观点来看这也是有利的：场景的一些细节通过人类处理是非常难以或甚至不可能跟随的(例如，当交通中的除了自主车辆以外的车辆将被跟随时)。该方法生成真实生活场景的精确重现，该精度无法通过手动尝试基于可用记录重现场景来达到。由于根据本发明的方法优选地只需要计算能力，因此该方法能够高效地缩放，而不管可用的人力如何。所生成的日志文件是通用的，即意味着该文件不取决于单个虚拟模拟器或场景测试框架，因此该文件可以在任何系统中使用。

本发明的附加优点也在下文中描述。根据本发明，确认数据(在一些实施例中通过确认者传感器来生成)可优选地用于在脱离原因无法基于自主车辆的基础传感器来揭示时允许找到该原因。

此外，在本发明的框架中，不同级别的重测试在模拟中是可用的，其中控制单元在修改后的适当性可被检查(见步骤S70以及以后的附加验证步骤)。

换言之，本发明是一种基于所记录和经后处理的传感器数据来重建虚拟环境中的真实生活安全场景以用于自主车辆开发、测试和确认的方法。

附图说明

下面参考附图通过示例来描述本发明的优选实施例，其中：

图1示出了具有各种传感器的示例性自主车辆；

图2是根据本发明的方法的实施例的各步骤的流程图；

图3是根据本发明的方法的另一实施例的一些步骤的流程图；以及

图4是根据本发明的方法的又一实施例的一些其它步骤的流程图。

具体实施方式

本发明是一种用于修改(开发、改进)自主车辆的控制单元的方法。在根据本发明的方法中应用的自主车辆配备有基础传感器，这些基础传感器被适配成记录传感器数据，基于这些传感器数据能够生成自主车辆周围的物体和环境的融合模型(该融合模型是基于从基础传感器(例如，来自作为基础传感器的一部分并且从该自主车辆朝外定向在不同方向上的相机)收集到的数据来生成、创建、构建的)，其中基础传感器记录的传感器数据使得控制单元能够以自主驾驶模式控制自主车辆，即控制车辆操作设备(在自主驾驶模式中转向轮、踏板和其它车辆操作设备由控制单元控制)。

因此，基础传感器使得自主车辆适合以自主驾驶模式行驶。出于该目的所需的不同种类的传感器从当前可获得的自主车辆是已知的(还参见以下图1的示例)。

如与图1相结合地示出的，存在最小的一组基础传感器(可被称为外部传感器或者用于检测自主车辆的环境的传感器，这些传感器从车辆向外“看”)，借助于该组基础传感器，自主驾驶是可达成的(就基础传感器而言为最小传感器包，借助于该传感器包能生成自主车辆周围的物体和环境的融合模型)。然而，通过使用附加传感器，控制可以变得更为复杂巧妙。

该方法包括如图2所示的以下步骤(对于每一步骤在图2中只显示该步骤的实质)：

-当控制单元处于第一状态时，由基础传感器在自主车辆的自主驾驶模式中执行的自主测试动作期间记录传感器数据，

-响应于被脱离事件触发，包括由基础传感器记录的传感器数据的脱离相关数据在该脱离事件之前的分析时间窗口中通过日志记录(记录、记录为日志)。

换言之，在以上步骤(图2中的步骤S40)中：在自主车辆的控制单元的第一状态中(即，当控制单元处于第一状态时)被脱离事件触发，包括由基础传感器记录的传感器数据的脱离相关数据(或简称脱离数据)在自主车辆的自主驾驶模式中执行的自主测试动作期间记录，所述记录是在该脱离事件之前的分析时间窗口中执行的。

因此，在第一步骤中，脱离相关数据被记录(通过日志记录)以供进一步使用；该步骤是在线执行的，即在自主模式中在测试行驶期间执行。

然后在模拟器装置中基于脱离相关数据来生成用于分析时间窗口的虚拟场景(即，对应于创建脱离事件之前的分析时间窗口的时间段的场景)，其中该虚拟场景包括具有基础传感器的虚拟对应物(即，具有与真实世界基础传感器相同的功能的虚拟传感器)的自主车辆的虚拟对应物，并且根据自主测试动作的第一虚拟自主运行是在自主车辆的虚拟对应物(自主车辆在该场景中具有其自己的角色，它也像周围环境中的物体及其行为那样被跟踪)在模拟器装置中使用控制单元的第一状态的情况下执行的，以使得第一虚拟自主运行导致虚拟场景中的脱离事件(图2中的步骤S50)。自主车辆的虚拟对应物具有作为现实中的自主车辆的真实基础传感器的对应物的虚拟传感器。自主车辆的虚拟对应物基于对外部世界进行检测(开始于明确定义的场景起始状态)的基础传感器的信号来控制，并且车辆操作设备在自主模式中由控制单元控制。

运行是自主的，即自主车辆的虚拟对应物由控制单元控制。第一虚拟自主运行根据自主测试动作来执行(在前一步骤中，该自主测试动作(即，同一自主测试动作)的数据已被记录)，这意味着自主车辆开始于与真实测试相同的状态并且随后它由控制单元自主地驾驶(即，也在虚拟世界中)。如果场景以可接受的质量(参见下文)生成(构造、创建、构建)，则真实场景被很好地重现，并且第一虚拟自主运行也将导致脱离(要求脱离，参见上文)。

该场景必须以这样的质量构建，以使其类似于现实，从而使得场景也在虚拟空间中导致脱离。为了实现以可接受质量构建的场景，可能必需使用确认数据。这是相关的，因为控制基于实际情况发生脱离，因此，为了在第一虚拟运行中重现脱离，必需尽可能与现实类似地构建周围动作(这对于在已经导致脱离的第一虚拟运行中的场景的时间段期间具有那些控制决策而言是必需的)。

真实场景的重构的质量可根据最近可用的重构技术来达成。这对于附加步骤虚拟地达到该步骤中的脱离是相关的，因为需要探查将基于脱离相关数据来虚拟地完成的脱离的原因。步骤S50和相继步骤基于在车辆的自主驾驶期间捕获的脱离相关数据来离线执行。

因此，在另一步骤(图2中的步骤S60)中，基于虚拟场景，标识控制单元的操作不恰当(不足)的组件(即，将被修改以避免已经发生的这种类型的脱离的控制部件)，其中脱离事件已经由控制单元的操作不恰当的组件的不恰当操作而导致。控制单元的组件可以是控制单元的每一个(自包含、独立)部件(例如参见下文)，它可被称为子单元。类似于控制单元，组件可通过控制软件的更多或更少的单独块(模块)或者通过软件和硬件的组合来实现。

此后，通过修改控制单元的操作不恰当的组件来基于控制单元的第一状态进入控制单元的第二状态(控制单元的第一和第二状态可被分别称为起始状态和升级状态)(即，控制单元的第二状态可以通过修改控制单元的所标识的组件来从其第一状态获得)，并且根据自主测试动作的第二虚拟自主运行是在自主车辆的虚拟对应物在其中模拟器装置中使用该控制单元的第二状态的情况下执行的(图2中的步骤S70)，检查在第二虚拟自主运行中是否避免脱离事件，并且在脱离事件在第二虚拟自主运行中得以避免的情况下存储控制单元的经修改组件。如果未在第二虚拟自主运行(即，对于第一次检查做出虚拟自主运行)中避免脱离，则可继续修改。在修改的后一阶段，可执行新的虚拟自主运行。修改规程可被考虑，以使得“第二”虚拟运行(也可被称为附加虚拟运行)对应于在最后成功修改后执行的虚拟运行。因此，中间虚拟运行可被认为是修改(开发)的一部分。

因此，控制单元的所标识组件的修改(开发)的目标是做出这一控制改进以使得自主车辆将使用改进的控制来避免脱离。第二虚拟自主运行也根据自主测试动作(它在自主模式中起始于与真实测试相同的状态)来执行，但自主车辆的虚拟对应物由控制单元的第二状态(即，通过修改获得的改进版本)来操作。目标是通过已对其执行适当修改(开发、改进)的经更新控制单元来避免脱离。

重要的是要注意，基本上两个单独的原因可能导致与自主车辆的安全驾驶员或者控制单元自身的中断相对应的脱离(参见以下示例)。在第一种原因的情况下，传感器执行的检测是准确的，但尽管知晓准确的融合模型控制单元仍做出不正确的决策。

这种原因的示例如下：传感器根据指定速度限制的路标(交通标志)已准确检测到最大速度可能为50km/h，但尽管检测准确，但控制系统尚未决定降低速度。在这种原因的情况下，基础传感器足以在模拟器中重现该场景(即，不需要可任选地应用的确认者传感器)。由此，图1所示的示例性传感器包足以重现上述类型的脱离(第一类型脱离)，对于该脱离不需要确认者传感器。在第一种脱离的情况下，通过基础传感器在分析时间窗口中生成的融合模型被发现是可接受的，即该融合模型保持不变。由此，如果脱离并非由融合模型的不准确性而导致，则(整个)融合模型被认为是可接受的，但可确定控制单元的控制决策将被修改。因此，在修改控制单元的所标识组件后，第二运行在同一融合模型中执行(在第一种脱离的情况下，经修改组件不负责构建融合模型，但它参与做出控制决策)。

在另一(第二)种原因的情况下，检测是不准确(正确)的，并由此不准确的融合模型已经在实时融合期间生成(换言之，由基础传感器在分析时间窗口中生成的融合模型在该分析时间窗口的至少一部分中被发现是不可接受的)，于是自主车辆对该不准确融合模型做出反应，并且脱离是对该不准确融合模型的这一反应的结果(参见以下示例，其中自主车辆的距离估计(作为自主车辆的融合模型的一部分)是不准确的)。在此情况下，可以设想基于对记录的后续分析，可生成准确的融合模型，但可能将需要确认数据(例如，激光雷达设备的数据，细节参见下文)以在模拟器中重现该情形，因为检测的不准确性无法借助于基于可用记录和日志的方法来校正。

这一脱离也可在自主车辆的控制单元进入不确定状态时设想，其中这发起将控制给回到安全驾驶员。对于该情形，简单的示例是被设计用于高速公路的控制框架(软件)无法以稳定方式检测自主车辆前面的车道和路面。

根据以上细节，在第二种脱离的情形中，不准确的融合模型以通过场景的融合以及重构来实时生成。如果对控制单元的操作不恰当的组件的标识是正确的并且对该控制单元的修改是成功的，则融合模型将被正确地重构，根据经改进的控制单元该融合模型变得对于分析时间窗口的整个长度是可接受的(例如，当在修改控制单元之前距离估计是不准确的时候，先前通过融合被放置在错误估计的距离处的物体将在修改后被准确地放置)，并且脱离将被避免(将确认数据用于第一种脱离时的情形参见下文)。

在图2的上述实施例中，通过在模拟器中执行第二虚拟自主运行来测试控制单元的第二状态(所谓的第二控制软件状态)是最后步骤。

在第一种脱离的情况下，当控制单元已被修改成具有通过融合创建的与控制单元的第一状态的失败运行(运行至脱离)相同的模型空间中的第二状态时，自主车辆在模拟器中行驶。如上所述，在第一种脱离的情形中，脱离并非由不准确的融合模型导致。通过控制单元的第二状态，预期是在执行第二虚拟自主运行时避免脱离事件(即，该场景在关键点后继续)。

在第一种脱离的实施例中，以上步骤优选地继以另一可任选验证步骤。在该步骤中，控制单元在连接到脱离报告的真实记录(即，作为脱离相关数据的各部分)上被再次测试。这可以是附加验证步骤，借助于该步骤控制单元的安全性可被增强。这是因为如果控制软件被训练以获得更多细节并用更多种类的数据进行测试，即环境被更好地重现，则结果将会更好。因此，在该实施例中，如果通过基础传感器在分析时间窗口中生成(创建、构建)的融合模型在该分析时间窗口中被发现是可接受的，则在执行第二虚拟自主运行后，在自主车辆的虚拟对应物在模拟器装置中使用控制单元的第二状态来将脱离相关数据(基础传感器的传感器数据以及可任选的其他日志类型数据)给予该自主车辆的虚拟对应物的基础传感器的虚拟对应物的情况下，执行根据自主测试动作的第三虚拟自主运行。

在该附加可任选步骤中，自主车辆的控制软件(单元)是在特殊状态中测试的，在该特殊状态中所有传感器数据都来自原始记录(即，利用原始传感器数据)。然而，原始命令(转向轮角度、踏板位置)不被执行；这些参数仅仅与脱离报告中的日志的先前数据相比较，并且检查结果且在比较在特定限值之间的情况下接受结果。还可能发生：车辆不仅在原始脱离附近做出不同行为，而且它在更长的区间上不同地行驶，因此严重情形通过不同行为来避免。这可通过以下动作来测试：在使用真实记录时将在前一步骤中做出的命令与其中在模拟器中测试控制单元的第二状态的前一步骤的日志的命令相比较。这不是一种容易的测试方式，因为如果车辆更大程度地偏离其原始路径，则记录被去同步。然而，可以在控制单元的第二状态的模拟器测试期间确定该控制单元实现的经修订的控制软件是否能通过原始记录来测试。

在路试期间，自主交通工具可由安全驾驶员手动驾驶或者可处于自主模式。当车辆自己驾驶时，它使用若干不同传感器的数据来做出关于是否制动、加速或转向的决定。在自主车辆上使用的传感器可以是相机、雷达、激光雷达或GPS；HD地图数据或者任何其它信息源(参见以下图1所示的示例)也可用于决策。然而，并非所有传感器都适合高速驾驶(诸如高速公路)，主要是因为传感器的等待时间(细节参见下文)。

在一示例中，自主车辆30配备有以下传感器(该外部传感器包被优化以用于在高速公路上行驶，但也可适用于其他类型的道路)。传感器的参数如下。位置(pos)值在“前(x)、左(y)、上(z)”坐标系中以米为单位给出，原点(具有[0,0,0]坐标的位置)被放置在车辆的后轴的中间投影到地面上的地方。偏航、俯仰和侧倾值以度为单位给出。

·F_RADAR_C,pos:[3.6,0,0.76],yaw_pitch_roll:[0,-20,0](图1中的传感器10被布置在一定高度且距原点3.6m处(在汽车的前面板上)；间距值是-20，这意味着它略向道路上倾斜)

·F_MIDRANGECAM_CL,pos:[1.885,0.2,1.2],yaw_pitch_roll:[0,-2,0](图1中的传感器12)

·F_MIDRANGECAM_CR,pos:[1.885,-0.2,1.2],yaw_pitch_roll:[0,-2,0](图1中的传感器16；传感器12和16与前向对称轴对称布置，彼此之间相距40cm)

·F_LONGRANGECAM_C,pos:[1.885,0,1.2],yaw_pitch_roll:[0,0,0](图1中的传感器14，该相机传感器14被布置在前向对称轴上，即传感器12和16的中间)

·M_WIDE_L,pos_meter:[0.03,0.75,1.2],yaw_pitch_roll_deg:[-85,30,0](图1中的传感器24)

·M_WIDE_R,pos_meter:[0.03,-0.75,1.2],yaw_pitch_roll_deg:[85,-30,0](图1中的传感器26，传感器24和26以与传感器12、14和16相同的高度被布置在车辆的两侧)

·B_MIDRANGE_C,pos_meter:[0.15,0,1.45],yaw_pitch_roll_deg:[180,-7,0](图1中的传感器22，该传感器以比传感器12、14、16、24、26更大的高度被布置在前向对称轴上)

·IMU_PRIMARY(图1中的传感器18)

·GPS_PRIMARY(图1中的传感器20；传感器18和20被布置在前向对称轴上)

传感器10、12、14、16、22、24、26从传感器的位置开始以符号拱形表示，并变得更宽。

传感器10是布置在车辆30的前面板处的雷达。可选地在自主模式中的融合中使用雷达传感器10。可优选使用传感器12和16来在车辆前部进行距离测量；传感器12和16是构成适用于在车辆前部测量物体离车辆的距离的立体相机对的中程相机。传感器14是长程(例如，针孔型)相机，该相机优选地被使用，因为在立体相机的实际画面中远距离物体是非常小的(通过布置在车辆上的相机作为传感器记录视频片段，可以对该视频片段进行逐画面分析)。借助于长程相机传感器14，可获取在融合中优选的远距离物体的更好图像(以获取关于在自主车辆前面的车辆的特定信息，例如车辆颜色、使用车灯和转向信号等)。在所示示例中，传感器10、12、14和16可用于探查自主车辆前面的环境。

另外，车辆30配备有传感器24和26，这些传感器是相机，优选地是鱼眼(侧视)相机，以用于看见车辆侧面的物体。如果车辆超过自主车辆30或者自主车辆30超过另一车辆，则可由这些相机来进行记录。在所示示例中，传感器22也被布置在车辆30上，该传感器22是看见车辆30后部的相机。借助于该相机传感器22，自主车辆30后面的场景可被探查(例如，正在接近的车辆以及比车辆30慢且在相机传感器22的画面上变得越来越小的车辆)。

为了测量车辆30的位置和倾角，GPS(全球定位系统)传感器20和倾斜传感器18(IMU-惯性测量单元)被布置在车辆30上。这些传感器的位置在图1中示出。

示例中的基础传感器可以是在车辆30上示出的所有传感器，除了雷达传感器10、针孔相机传感器14、倾斜传感器18和GPS传感器20以外。然而，如果这些传感器也是基础传感器的一部分，则融合很有可能能够以更好的精度完成。更少或其它传感器(例如，单个相机传感器，而不是传感器12和16)可能足以担当基础传感器。类似地，还可增加传感器数量以给出作为脱离相关数据的一部分的数据。因此，脱离相关数据可包括各种传感器的记录和日志。

可任选地，自主车辆配备有内部传感器，这些传感器被适配成测量自主车辆的车辆操作设备的状态，具体而言是转向轮、油门和制动踏板的状态(车辆操作设备可以是车辆操作所需并且需要在自主车辆以自主模式驾驶时被控制的其它设备)，但使用这些传感器并非必需并且这些传感器并非必需被布置在自主车辆中。在自主车辆中，车辆操作设备(例如，转向轮、油门和制动踏板)由控制单元操作，但这些车辆操作设备的状态并非必需被持续检查(测量)。内部传感器具有作为确认者传感器的角色。

如果发生某一非预期事情或者交通工具在不应当的情况下尝试机动，则安全驾驶员可干预并拿回对交通工具的部分或完全控制权。这些事件被称为脱离，并且当脱离事件发生时，交通工具基于直到拿回控制权已经发生了什么来生成报告(该报告的元素，更一般地它被称为脱离相关数据，本发明在后文中使用)。当拿回控制权时，该报告优选地自动生成。该报告(脱离相关数据)包括来自先前数分钟(即，适当选择的时间窗口)的所记录的所有传感器数据以及来自交通工具的日志，其中不同的软件状态和变量值可被观察到。该报告稍后可用于进一步分析脱离原因。

自主车辆的安全场景测试使得能够通过提供模拟器的虚拟环境来对自主车辆的控制的开发过程进行快速迭代。在模拟器的虚拟环境中，车辆控制软件可以在不同情形中确认并且对照不仅开发者预期而且安全要求来测试(不仅进行真实路试，而且还使用模拟器来开发控制软件是高效的)。实时地按原样重新创建真实世界位置和情形，逼真的模拟器对于可缩放测试至关重要。使用本发明的框架(可被称为场景流水线)，能够以精细的细节创建不同的道路场景。

独立的场景编辑器工具用于这些任务(即，用于虚拟地生成场景)。交通工具、行人和动物可被首先放置到场景中，然后它们可根据其进一步沿道路的移动来参数化。若干不同选项对交通工具可用，例如车辆类型、颜色和附件可以在大量生成之前被定义。初始速度可被设置并且稍后可基于各种计时器或事件来改变。

由于大量动态测试可以在场景期间定义，因此能创建甚至高度复杂的情形。在场景在虚拟模拟器中的执行期间，可检查若干条件以查看自主(自我)交通工具是否表现得如预期那样，例如它是否保持车道和目标速度，执行超车并且能安全地驶出高速公路(仅仅作为示例)。

软件经修改(开发)的自主交通工具控制单元可以通过在同一计算机上运行或者通过在网络上相连接来连接到模拟器。在模拟期间，模拟器提供交通工具控制软件所请求的所有传感器数据，这与在真实生活中会发生的方式相类似(所有这些数据，例如相机画面、范围值，基于所模拟的场景来生成，该场景先前已经在测试期间基于自主交通工具的传感器数据来生成)，并且交通工具控制软件以与它在路试期间相同的方式处理所返回的数据。换言之，在模拟器中生成完整场景(具有包括自主车辆自身在内的参与方车辆，以及来自自主车辆的周围的其它物体)，并且自主车辆的传感器的虚拟对应物对该场景(即周围虚拟世界的场景)进行测量和记录。控制软件可将控制消息发回到模拟器，该模拟器服从这些消息并执行从交通工具软件接收到的所请求的加速、制动和转向命令。

通过在模拟器中使用该测试方法，能够确保在进行路试之前自主交通工具软件的所有相关模块都是可靠且可操作的。由于真实世界位置能够在模拟器中建模，因此控制单元甚至可以在相同的路段上虚拟地进行测试，这些路段稍后将在真实生活中被测试，由此能够为通常出现在特定位置的任何问题做好准备。

创建人为情形可帮助开发覆盖在真实生活中可能仅仅非常罕见地发生的不同的个别案例，但这些情形通常非常缺乏现实意义(sterile)，只能在极端环境(vacuum)中测试特定功能。诸如此类的情况通常出现在现有技术的方法中，其中由于大量的测试用例，意图覆盖个别案例。然而，真实的个别案例非常难以生成并且无法简单地通过将测试用例数增加至非常高的数目来覆盖。借助于本发明来解决该困难，本发明基于发生脱离的情况来进行开发(即，特殊个别案例捕获通过本发明完成)。

在进行路试时在自我(自主)交通工具周围可存在若干其它交通工具，并且它们可立即执行非预期机动、制动或转向等。通过使用来自路试的所有(路试)记录和脱离报告，特定案例可以就像发生在真实生活中那样被重新创建和测试，并且覆盖与人为测试相比范围大得多的示例(控制单元的功能)。这给予开发者以下选项：虚拟地重复相同的场景以进一步分析可能的问题并相应地修复它们。个别案例经由脱离事件来“捕获”，因为脱离事件始终由将被进一步开发(修改)的控制(融合算法、控制协议、来自布置在自主车辆上的传感器的不足信息)的操作导致。

根据本发明，能够在交通工具控制软件中确认变更并在早先失败的恰好相同的情形中对其进行测试并且查看已经做出的变更是否的确提高了软件质量，是非常优选的。即，换言之，当对同一场景(该虚拟场景在修改控制软件的适当组件之前已显示脱离，就像在真实生活中那样)测试控制软件的新版本时，通过改进的控制软件来避免脱离。不再需要花费时间驾驶到特定位置，或者尝试在真实世界中重新创建相同的情形，因为这在虚拟模拟器中能够容易地完成。该可能性不仅减少花费在开发(个别案例，由此需要开发控制软件的弱点可通过脱离来高效地捕获)上的时间和成本，而且还可测试原本不可能重现的一些案例。具有许多参与者的场景可以是很好的例子。考虑例如四辆车：不可能重现这些车辆高速处于弯道中的位置。

由于与环境的细微差异可能很重要，因此在虚拟环境中重新创建特定情形是确定性结果的关键(例如，用于在测试相同软件状态时取回脱离事件)。手工进行这项工作不仅非常耗时，而且甚至是不可能的(例如，当要跟随其他汽车的移动时)，因此，使这一过程自动化是获得所需结果的唯一方法。

在以下部分中，用于场景生成的融合被详细描述。为了与本领域中使用的命名一致，融合模型(其是融合数据创建的结果)将与由融合创建的空间模型结合使用(在融合不同的数据源时它还可用于该步骤本身)。离线创建的空间模型可被简称为模型空间(因此，模型空间通过后处理生成)。这两个模型包含环境的所有必要信息(在线控制；离线重构)。融合是基于各种相机、传感器、GPS、导航和地图数据进行实时组合和更新的，并由自主交通工具控制逻辑用来确定做什么(该控制逻辑基于该环境信息来做出关于如何继续的决策)。

尽管融合数据创建的过程不在本文的范围内，但某些方面应被纳入考虑。当在至少10Hz以上运行时，控制逻辑可被认为是安全的，因此甚至在高速下也能相对较快地做出决策。以例如130km/h行驶将导致有机会每3.6米(10Hz)做出一次决策，并由此可被认为是安全的。为了实现这一性能，只能使用那些可以在该时间帧内生成可靠的数据的传感器，因此从触发请求数据的信号，传感器的捕获以及分析算法的处理应提供足够的时间来更新融合模型并做出控制决策，并且这些加在一起不应花费超过最多100毫秒。可以在自主车辆上使用的常规相机的等待时间为15-21毫秒，而普通雷达可能需要25到45毫秒才能产生可被算法使用的数据。因此，以上提到的时间段覆盖从触发到捕获传感器数据的时间。传感器数据不时地(由固定的时间区间隔开)被控制利用，由此可被指派用于分析和控制决策的时间取决于以上提及的等待时间。

在测试高速公路的某些部分时，控制单元和布置在车辆中的传感器(传感器系统)必须处理源自高速的问题。基本方面是相机的检测范围(视野)以及控制单元的反应时间。一个相关的问题可能是，在由相机记录的图像中，相距100米的汽车可能很小，以至于可能导致检测算法不准确。另一方面，在城市行驶的情况下，交通的速度要慢得多，然而环境要多样化得多(交通标志、交通信号灯、斑马线、自行车道等)，并且交通参与者的数量更多，并且行为可能以多种方式表现。当车辆在高速公路上行驶时，它们沿着车道或变道行驶，在城市中，则有许多十字路口、驶出车道等。人行道上有许多行人、自行车骑手、过山车骑手或其他交通方式的骑手，其行为无法轻易估计和/或不一致。

根据本发明，确认数据(例如通过确认者传感器来记录)在一实施例中可以在无法基于基础传感器(也可被称为传感器基础包)来适当地重现场景的情况下被优选地使用。如上所述，可能需要在第二种脱离(即，不准确融合模型的生成被揭示)的情况下使用确认数据。该确认数据被应用于确认场景的至少一部分(无法基于基础传感器的数据来以足够好的质量重现的那部分，该部分可以是用于整个分析时间窗口的空间的一部分，但可以是用于该分析时间窗口的一部分的周围空间的全部或一部分)，即为了探查并标识融合模型的不准确细节。

确认数据是不一定在融合中使用但能够以可靠方式提供环境的地面实况数据的数据源和/或一种类型的数据。

确认数据可以是并非实时用于控制的任何(导出)数据。即使慢且无法实时使用，确认数据也能帮助提高离线生成的空间模型的质量，即重现周围环境和物体的更精确的表示。

产生确认数据的确认者传感器(确认传感器)可以是例如雷达或激光雷达，但原始视频片段也可被用作经离线适当处理的确认数据的源(在此情形中确认数据是从相同的传感器(相机)数据获取的，当汽车以不同方式处理的自主模式行驶时，其会在实时融合期间使用)，因为甚至最慢的检测算法在场景生成的预处理部分中(即，在重现该场景时)也是可行的，并且这些数据可以比限速下实时使用的数据精确得多，因为现在不需要实时产生输出。

因此，在根据本发明的方法的实施例中，优选地在通过基础传感器在分析时间窗口中生成的融合模型被发现在该分析时间窗口的至少一部分中是不可接受的情况下，在生成虚拟场景时使用(应用)确认数据以便基于将该虚拟场景的确认场景部分的确认模型与用于分析时间窗口的至少一部分的该确认场景部分的融合模型相比较来确认该确认场景部分，并且控制单元的操作不恰当的组件通过将该确认场景部分的确认模型与用于该分析时间窗口的至少一部分的该确认场景部分的融合模型相比较来标识(该融合模型是时间相关的，它可针对分析时间窗口的每一时间步创建；确认数据可以在整个分析时间窗口期间使用，但它也可在该窗口的一部分中使用，因为在其它时间段中融合模型是可接受的)。虚拟场景的确认场景部分是该场景的特定部分。该场景由关于周围物体的时间相关数据表示，即，确认场景部分可以是例如对应于专用车辆的接近移动的数据。

除了来自脱离相关数据的融合模型之外，该场景部分还将具有确认模型。

用于以可接受质量构建该场景的确认数据还帮助标识控制单元的操作不恰当的组件。

由此，标识是基于虚拟场景做出的，但如果确认数据可用，则该确认数据将对该标识做出贡献，因为更好质量的场景已经使用该确认数据来获取。

基于确认场景部分的确认模型与融合模型的比较，这样的区别可以在模型中找到，基于该区别可标识出控制单元的哪一个组件负责这些区别(具体而言，哪一个组件负责与确认模型的偏离，该确认模型在许多情况下被认为是地面实况)。

考虑到距离估计示例，将阐明融合模型中的距离不同于在确认模型中观察到的距离。由此，控制单元的合适的(负责的)距离估计组件将被进一步开发(即将被修改)是清楚的。

确认数据由单独的确认者传感器记录，或者可以从基础传感器获取，基础传感器的不同处理的数据也在融合中使用。对于可从基础传感器获取的确认数据而言，上述原始数据是个好示例。

原始相机数据由用于在融合中使用的快速算法处理。然而，通过较慢、更复杂的算法进行处理以获得更精确的检测，可以从原始数据中获得确认数据(即，在这种情况下，确认数据是借助于从原始数据中生成离线算法的确认数据获得的)。

使用较慢的处理，它无法在融合中使用。

确认例如示出并发车辆的距离估计错误，即在融合模型中将其放置在错误的位置。当控制单元的负责该估计的组件被修改时，估计将借助于经修改的、进一步开发的控制单元(通过其第二状态)来恰当地做出。

由于距离估计组件是操作不恰当的组件，因此在此示例中，与在控制单元的第一状态下生成的融合模型相比，在使用控制单元的第二状态下生成的融合模型将有所变化。

在另一实施例中，自主车辆配备有被适配成记录确认数据的确认者传感器。

确认者传感器可以是任何传感器，即它还可以是其数据用于在线融合，但其离线处理的数据适用于确认的传感器。在此情形中，确认数据是从其数据在实时融合中(例如当确认数据是原始数据时)使用的传感器获取的。

然而，在一实施例中，确认者传感器可以是只从其获取确认数据的单独传感器(例如，该传感器的数据不适合在融合中使用，参见这方面的激光雷达传感器说明书)。由此，该确认者传感器不同于基础传感器。

在一实施例中，确认者传感器是激光雷达设备。

激光雷达传感器的等待时间在100-250毫秒之间，并由此无法在高速公路上或在高决策制定频率下实时使用。因此，激光雷达可以例如在低速下用于融合，但主要仅仅用于测试，因为激光雷达设备非常昂贵，无法将其安装在每辆自主车辆上。类似的考虑对雷达有效；它们的功能应由其它(即基于相机的)传感器来提供。

然而，传感器捕获的数据之后仍可以进行离线软件校正(例如，高速记录的激光雷达数据可能会失真，可以通过适当的软件来纠正这种失真)被可用作用于改进融合数据的地面实况数据。

因此，软件改进的激光雷达数据也可用作确认数据。

由此，确认者传感器的角色是帮助纠正基于传感器数据构建用于模拟场景的融合模型。

为此，距离估计算法的不准确性可以是好示例(细节参见下文)：在实时融合模型中，另一辆车的距离估计为130米，如果仅使用此信息，则在基于脱离报告构建的场景中，这辆车的起始距离为130米(即，自主车辆将具有足够的时间来执行变道机动)。

确认者传感器的角色是纠正这种类型的不准确信息(不准确距离估计)。

假设在自主车辆上布置了激光雷达，当超车开始时，它可以准确地检测到(红色)车辆在自主车辆后方80米处。

因此，如果确认者传感器的数据被用来改进基于日志制成的场景，则(红色)车辆在改进的场景中也将处在80米处，并且然后将没有足够的时间来模拟超车。

与此同时，在此情形中确认者传感器帮助找到控制单元的要修改(开发)的部分：从确认数据(80m)可以明显看出，控制单元的距离估计算法有待改进。

根据上述细节，在将激光雷达设备用作确认者传感器的实施例中，控制单元的距离估计组件被标识为控制单元的操作不恰当的组件，并且该距离估计组件(测量汽车周围任何方向的距离，例如在汽车前面、在汽车后面或在汽车侧面)被修改以用于基于该控制单元的第一状态来生成该控制单元的第二状态。

对距离的估计可借助于激光雷达设备来确认。

因为用于估计自主车辆前方的物体的距离的传感器优选地是立体相机对，因此该方向上的距离优选地以良好的准确性估计。

然而，“看到”自主车辆后面的传感器是被定向成记录来自自主车辆后面的场景的片段的单个相机(在图1的示例中)，因此可设想使用该传感器的数据的距离估计组件(算法)将被开发以在各种情况下达到良好的准确性。

在以下部分中描述融合的一些细节。

融合数据应包含在任何给定时间的所有周围交通工具的以下参数。

仅应对那些可以在整个场景中进行跟踪的交通工具进行建模，或者是否可以基于GPS或地图数据(例如，它在高速公路坡道、十字路口等处离去)给出交通工具为何突然出现或消失的有根据的猜测。

目标是滤除检测错误，其可以是突然出现和消失的此类“物体”。

由此，该过滤无法导致丢失附近车辆，其行为对于控制自主车辆是相关的。

检测错误主要出现在融合中，并且同时不存在于确认数据中。

然而，当可以在确认数据的时间序列中清楚地跟踪物体，并且该物体同时又没有(清楚地)出现在融合数据中时，则很可能是检测失败，这可能是由于控制单元的组件的不恰当操作的结果。

因此，后一种案例还可帮助标识控制单元的操作不恰当的组件。

需要关于这些周围交通工具的以下参数(足够跟踪这些车辆)：

·以m/s为单位的速率(速度)

·与自我(自主)车辆的以米为单位的距离和以度为单位的角度

·相对于自我车辆的交通工具的车道标识符(id)

·以度为单位的相对于自我车辆的航向

以下是可选参数(优选具有这些参数)：

·以米为单位的宽度和长度

·离车道中心的以米为单位的估计距离

·附件

·颜色

·型号

·灯光和转向信号状态

以上必需和可选参数中的绝大多数都可以从自主车辆的相机传感器做出的记录中获取；传感器的示例性布置在图1中示出，如以上介绍的。

为了调查周围的车辆，大多数情况下使用了位于汽车前部的相机以及位于其后部的相机。速度和距离可以从这些相机的记录中获取。

当自主车辆接近(跟随并靠近)一车辆时，该车辆在记录中变得越来越大。

通过由相机传感器12和16构成的立体相机，该车辆的距离可被容易地获取，以及它相对于该自主车辆的速度可被测量(知道自主车辆的实际速度，还可计算出绝对速度)。

可从后部相机传感器22获取关于从后面接近该自主车辆的车辆的这些参数，然而具有较低准确性。

为了获得更好的准确性，还可将立体相机对附连到自主车辆的后部。

还可通过分析记录来主要从相机传感器12、16和22(可选的传感器14)的记录中获取车道标识符和航向。

可以从记录中获取诸如周围交通工具的宽度等其它可选参数。

然而，为了获得长度及其附件(如果有)，侧部相机传感器24和26也可被使用。

周围交通工具离车道中心的估计距离及其颜色和型号也是可以从相机记录获取的信息。

通过分析记录(例如，特定长度的视频记录)，还可获取关于周围交通工具的灯光和转向信号状态的信息。

为了准备场景，相关的是定义脱离事件之前的用于处理报告的时间段(脱离事件对应于安全驾驶员需要从交通工具拿回控制权的时刻)；该时间段的长度是相关参数。

相关的是确定是否可通过更早的机动来避免脱离，并且如果可以，则将创建更长的场景以寻求避免所发生的事件的选项(在更长时间段中，自主车辆有更多的选项选择)，或者如果脱离是特定于位置或短动作序列，则只创建短场景。

融合数据被优选地在由场景生成器处理之前准备，这通过减少噪声以了解环境在发生脱离之前是怎么样的；这优选地是自动化的。

融合数据在某些情况下可能不准确，这也可能是脱离的原因(请参见上面的第二种脱离)。

因此，在此情形中，为了正确地重新创建状态，确认者传感器被优选地使用(如果可用)以提供可被使用的附加信息。来自确认者传感器的数据在一优选实施例中根据以下步骤利用：

1.报告相关部分中的所有交通工具都经过迭代并单独处理。

测试交通工具在每一帧之间的移动，如果移动幅度不自然，则会标记相关帧。交通工具在这些标记帧中的位置将需要内插在最后和下一稳定位置之间。

2.确认者传感器中可用的数据与融合模型进行匹配。所有交通工具都经过迭代并被测试到确认者传感器的数据和融合数据重叠的程度。

通过找到由确认者传感器检测到的、在检查部分的整个长度上重叠最多的问题，此信息可用于纠正融合精度并填充必需插值的位置。

交通工具的航向在此也应被检查并且在需要时由确认者传感器中可用的信息来纠正。

交通工具在通过融合生成的模型空间中的位置可以是不连续的，而与此同时这些交通工具也可在借助于确认数据生成的模型空间中找到。在该后一模型空间中，交通工具位置持续地变化。

尝试在上面的步骤中的这两个模型空间之间建立对应关系。为此，调查这两个模型空间中的车辆之间的重叠。

因此，关于车辆的信息可以从这两个模型空间中优选地考虑。

如上所述，确认数据优先考虑可能的检测错误，并且不会省略任何相关的车辆。

3.在标识了交通工具的经纠正路径之后，应该对出现和消失的交通工具进行测试。如果一交通工具突然消失且另一交通工具出现在其位置，则可做出融合模型不正确的假设。

如果可获取关于交通工具外观(如颜色或型号)的信息并且它们匹配，则这两个交通工具可以在融合中安全地合并。否则，如果确认者传感器的数据示出持续移动的物体，则合并甚至可以在没有外观信息的情况下执行。

借助于确认数据，对交通工具的持续跟踪也可在以上步骤1中被标记的帧中实现。

在以下部分中，描述了用于生成场景的一系列示例性步骤：

1.创建初始状态：

a)如果地图数据基于GPS位置可用，则给定路段被加载或创建。

b)如果没有地图数据可用，则处理融合数据并且基于融合中可用的检测到的道路模型来创建车道和车道连接(地图创建、加载和生成不在本文的范围内，但这些也可由已知方法根据a)点或b)点来完成)。

c)沿所有交通工具的所有可用数据设置起始位置和速度(速率)。

d)为自主车辆确立基于安全要求的测试条件(例如，速度变化、车道保持、安全间隔等)以及脱离原因。脱离原因优选地由安全驾驶员给出，即为何从自主车辆拿回控制权。该信息可以在搜索控制单元的操作不恰当的组件时有帮助。然而，这仅仅在虚拟模拟器中测试场景的时候是必需的，并且可以在处理日志时被省略。

以下注意点d)。

由安全部门(该部门负责实施各种车辆安全标准)确定的参数值需要由车辆在特定情况下观察(例如，不能超过限值或者距离不能小于限值，参见下文)。上述参数、速度变化意味着自主车辆的目标速度(将被维持)在没有好的理由的情况下不能变化超过例如5％(好的理由，即例外可以是在路上检测到障碍物、在自主车辆前面有慢车、或者需要在特定路段更缓慢地行驶)。

参数“车道保持”对应于接近车道标记(可以有多接近这些标记)。在理想情况下，当测试车道保持功能时，自主车辆不靠近车道标记超过10厘米，甚至在急转弯中。

参数“安全间隔”对应于在自主车辆前面离车辆的距离(该参数也可用时间参数来表征)。一般而言，期望以(至少)1.5秒的跟随时间跟随车辆行驶，这与该车辆的速度无关，因为它可能随时制动，或者可能会出事故。

2.每“t”秒(即，根据适当的时间步长)处理一次融合数据：

在该步骤中，创建加时间戳的日志(以下被称为场景日志)，该日志稍后可被馈送至场景生成器。

该日志应包含对每一交通工具发生的动作的关键字，以及改变其沿其路径的移动的交通工具行为的其它变化。

以下事件应被记录在日志中(也参见上文中的来自周围交通工具的所需参数)：

·出现：交通工具id、位置、航向、初始速度

·消失：交通工具id、最后已知位置、航向、速度

·速度：交通工具id、目标速度

·变道：交通工具id、源车道id、目标车道id(这表示以下确切时机：交通工具已被指派到与它早先所处的车道不同的车道)

·车道中心距离：交通工具id、离车道的假想中心线的以米为单位的符号距离

·车灯状态：交通工具id、灯名(刹车、转向信号左、右等)、灯状态(开、关)

以上事件列表应以在假定交通工具的线性移动时场景中的交通工具在任何给定时间的位置将匹配实时融合数据中可用的位置的方式生成。

换言之，必须以获得与在自主车辆行驶期间创建的情形等价的情形的方式构建场景。简言之，场景必须还以与自主车辆所发生的真实情形相同的方式导致脱离事件。

一旦日志完成，它就可被转发给场景生成器，该场景生成器可基于实际框架来创建场景文件。

尽管场景生成和运行时环境的实现不在本文的范围内，但可以说所生成的日志文件在以下意义上将会是通用的：可准备任何种类的场景测试框架以使得能够处理该日志文件并将其转换成有效场景，这意味着将不会限制对已知系统的使用，并且任何本领域技术人员都应能够准备到此类框架的转换(例如转换到开放文件格式openScenario)。

可选地标记的是自主(自我)交通工具的移动中的各种动作，这些动作预期在场景中以相同的方式执行，例如加速、制动、变道等。

这些动作可以在安全定义的条件下进行额外测试，但可以进行不同的评估。

例如，如果交通工具控制软件通过更早地切换车道或甚至更晚地切换车道来避免脱离，如果汽车之前已经切换车道，并且由于某种原因，它在测试中不再变道；这可指示在给定原始的变道是合理移动的情况下控制软件中的非预期部分已经改变(主要目的是在修改控制单元的组件后避免脱离，并且这也在该情形中达成：起始于某一起始状态的场景已经在控制单元的第一状态下在脱离中结束并且在该控制单元的改进的第二状态下避免该脱离)。

尽管以上描述仅仅聚焦于来自周围环境的交通工具，但任何其它参与者(例如，行人、动物等)也可被观察到并在场景中使用相同的方法且仅仅通过添加关于新参与者的新事件来重新创建。

在图3中，示出了场景生成(创建)和评估的工作流。

在步骤S100中，场景由安全工程师如下定义。

定义场景应在什么路段上运行(多少起始车道、驶出或合并车道、交叉路口、弯道等)、交通工具最初应被如何放在路段上及其起始速度和元信息(交通工具类型、颜色、附件等)。

接着，在场景的每一步骤中定义要发生的不同动作(变速、变道等)。

测试交通工具控制软件所对照的不同条件也被定义并且设置预期以及所接受的限值。

在另一步骤S110中，所定义的场景通过在独立场景编辑器中创建场景测试框架来转换成该场景测试框架。

起始位置、计时器、事件和不同动作全都可以在那里指定以匹配由安全工程师给出的场景描述。

在连续步骤S120中，然后可以在虚拟模拟器中执行所创建的场景。

这将使得所定义的交通工具大量出现，等待交通工具控制软件连接到模拟器(由此将在发生脱离事件时由现实中使用的相同的控制软件版本来测试)。

一旦万事俱备，场景就开始执行，运行事件和计时器等。

在该场景期间，自主交通工具软件驾驶的车辆被紧密监视以使得可测试所定义的条件(参见以上1d点)。

一旦一个条件达到活跃状态(意味着这一条件的限值已被违背)或者交通工具到达其目标，模拟就停止，并且生成详细日志文件，该文件稍后可被进一步分析，作为重放来回放，或者可从该文件收集任何有用信息。

测试可优选地隔天完成。

每一次运行的结果被比较以查看控制软件性能在各种情形中是被提高还是降低。

在图4中描述了在本发明的一实施例中应用的自动场景创建的工作流。

在预备步骤S200(被标记为“使自主交通工具具有传感器”)中，自主交通工具安装有相机和所有必需传感器以用于常规路试。

如果想要使用通常不在融合中使用的附加的确认者传感器(例如，雷达或激光雷达)，这些设备也被安装到交通工具。

该步骤将不针对每一次测试完成，而是必须只在自主车辆准备好进行测试时完成一次。

在下一步骤S210中，自主车辆前进至旨在执行自主测试的区域，它可以被手动驾驶到那里(它也可被自动驾驶到那里，但在该情形中到该测试区域的道路也是测试的一部分)。

在步骤S220中，当到达指定测试区域时，安全驾驶员将控制给予交通工具以将该交通工具切换至自主模式。

该测试按计划执行，但可能在发生脱离事件时被非预期事件中断，并且控制从自主车辆回到安全驾驶员。

若干测试可以在没有这一非预期事件的情况下完成，然而当非预期事件发生时，捕获该事件以及脱离报告(日志)。

根据本发明，捕获非预期事件是有利的，如在本说明书全文中描述的，在发生脱离事件时获取的信息被用来开发自主车辆控制。

因此，在步骤S230中，当发生某一非预期事情时，安全驾驶员干预并拿回控制权，或者交通工具控制软件发信号通知该驾驶员并自动给回控制(脱离可以按这两种方式发生)。

此时，生成脱离报告并且迄今为止的所有日志和传感器信息都被收集和链接在该报告中以便于访问。

在另一步骤S240中，一旦路试终止并且交通工具返回到办公室，则脱离报告被复制到办公室服务器，并且可被转发给处理软件链，即脱离报告被下载。

在步骤S250，首先报告由框架解析，并且离线重构融合模型以具有用于该场景的模型空间(使用传感器的数据，在脱离报告被后处理时离线重新创建在测试期间在线创建的融合模型)。

融合数据仅仅是脱离相关数据的一部分(即，脱离报告的一部分)。若干不同的数据从该数据包(优选包括确认数据)利用；在该步骤中这些数据被收集并同步以创建用于场景的模型空间。

然后，在下一步骤S260中，确认者传感器数据由不同软件分析以创建物体的加时间戳的列表以及任何相关元信息。

因此，这种类型的确认者传感器(例如，激光雷达)被适配成列出周围物体。一般而言，确认数据可以是可离线检索的任何种类的辅助信息。

这是对其进行在线(即在自主车辆的自主模式中)利用是不可能的信息。

因此，在确认者传感器能够识别所有周围物体的情况下这是不必要的。

相反，目标是能够借助于所有确认数据源来覆盖所有相关物体。

此后，执行以下步骤：清理融合(确定融合的哪一部分是模糊的)、减少噪声以及将来自确认者传感器的数据合并到可用融合空间。总之，这些步骤可被采取至步骤S270，其被标记为“更新并细化融合模型”。

融合数据已经在前一步骤中改进。

路段现在可被分析，并且必需的部分能够以所选道路描述符格式创建，例如开源openDrive和openCRG(步骤S280)。

而且，场景日志(基于该日志可执行场景)现在可被生成以供进一步使用。

在下一步骤S 290中，所生成的日志可被馈送至场景编辑器，该编辑器可自动创建日志中描述的场景并保存场景文件，该文件可被立即转发至模拟器并在测试中执行。

在具有任意(示例性)所选参数值(参数值对于每一个示例是任意选择的，不同的具体参数值用于说明)的以下不同示例被描述为示出本发明的某些方面。

首先，描述了一个简单的示例，该示例与上面的示例相关联，在该示例中，借助于确认者传感器标识不准确的距离估计。

下文中，详述该示例的新方面。

自主车辆以100km/h的速度在高速公路上行驶在外车道的绿色车辆之后，绿色车辆的速度比该自主车辆的速度低10km/h。

当自主车辆与绿色车辆仅相距100m时，它认识到需要超车才能保持其当前速度。

它指示转向，开始改变车道，然而在内车道中，一辆当前距离为80m的红色车辆以130km/h的速度驶近。

该情形导致脱离，因为接近的车辆太靠近了。

脱离原因是内车道的车辆未被准确地检测到(它未被观察到，或者它被观察到但被估计处在较大的距离或者具有较低的速度，等等)。

在运行从上述示例的相机记录和日志创建的场景的情况下，从场景模拟预见到在虚拟场景中，模拟的自主车辆也将执行超车，然后如果在模拟器中应用了与真实测试中相同的控制软件版本(控制单元的状态相同)，则它将真正开始超车。

换言之，场景必须以良好的质量构建以使得在控制软件自从导致脱离事件的测试以来尚未被改变的情况下也将导致脱离。

假定这在模拟器中相应地实现，车辆表现得就如同在测试期间那样。

此后，控制单元失败的根源可被寻找(脱离是该失败的结果)。

在以上示例中，超车在自主车辆的控制单元中是被允许的，因为距离估计算法估计接近车辆的距离为130m，但现实是它处在80m。

在找到失败根源后，距离估计算法已被修改(开发)，并且现在它给出了失败限值内的估计(例如，它估计接近车辆的距离为83m)。

因此，在控制单元中认识到应该执行超车，但是在使用经修改的距离估计算法的控制单元版本中不允许开始超车。

由此，脱离将被避免。

如果与超车逻辑相对应的模块也已经同时被修改(开发)，则可发生以下情况：控制软件决定不超过距自主车辆前方100m处且速度低10km/h的车辆。

由此，变道时的距离估计失败不会发生。结果，自主车辆的速度被降低，但没有完成任何其他事情。这被解释为失败的行为。由此，这也是基于脱离事件创建的场景的有价值的结果，因为如果自主车辆不应比100米更靠近具有低10km/h的速度的车辆是安全预期，则这也可在虚拟环境中被修复以设法避免以下情形：未作出超车，而是自主车辆仅仅以降低的速度跟随另一车辆。

这是其中超车可通过简单的变道来做出的高速公路示例。

在由于车道保持问题引起的脱离的情况下，沥青的质量可能是一个相关的因素。

在一个示例性的测试路线中，露出了只有几米长的部分，其中道路已经用新的沥青重建，因此(涂漆的)车道分隔标记不容易被检测到(在许多情况下，新的沥青比平均路段要暗；因此，检测可能会将它观察为阴影而不是路面)，并由此自主车辆频繁地移位到其它车道。

这是开发人员不希望引起问题的事件，但是，基于测试以及在测试期间发生的脱离(在当前示例中，不想要的变道导致脱离)，控制软件必须为这种情况准备就绪是清楚的。在此情形中，如果环境已经手工建模以用于模拟器，则上述路段的准确模型将由专用图型设计师来准备，并且可设想道路的每一处细节的重构将不会是足够准确的(例如，图形设计师很可能不会认为沥青的质量是相关的，并且不会强调与之相对应的细节)，并由此在模拟器中不会发生失败。

因此，从基于脱离生成的场景中期望：如果所应用的控制软件版本相同，则汽车应以与测试期间相同的方式运行，并且由于场景的运行而失败，就像在真实测试中一样。如果这没有发生，则场景重现将被进一步开发至这一准确性。

当场景的精度未达到可接受的限值时，这可以是各种原因的结果(例如，某些车辆的移动不够精确、各种灯光环境、各种天气状况、不同的车道标记质量等)。

鉴于具体原因，适当的工具或方法改进场景精度。

可导致脱离的附加示例性情形在下文中描述。

可发生：另一方向车道中的车辆通过传感器融合被纳入到自主车辆的车道中。

该问题将在负责为车辆排定车道的算法中被寻找并修复。

如果在历史中错误地定位的车辆一直改变它的车道或者如果还存在给出较慢但较精确的车道排定的可用算法，则该脱离的原因可由基础传感器重现，否则需要使用确认者传感器。

在后续示例中，较小的车辆正跟随一货车，并突然开始超过该货车。

这两辆车在相同的方向上在自主车辆前面行驶。一开始，货车、小型车辆和自主车辆处在同一(外)车道。

小型车辆从其车道变到内道以超过货车，并由此自主车辆将直接在货车后面行驶。

货车被自主车辆的传感器精确地识别，但它突然检测到大得多的物体代替了小型车辆(超车开始时)，自主车辆从中推断出小型车辆正在快速驶近。

该问题可通过适当地跟踪(通过所谓的实例跟踪)检测到的交通工具来解决。如果小型车辆在货车旁边的相邻车道中被准确地检测到，则该情形可由基础传感器重现。

实例跟踪通过融合做出。简而言之，在实例跟踪期间，所有交通工具都有一个编号，并且只要这些编号对于自主车辆是“可见的”(可检测到的)，就可以借助这些编号来跟踪交通工具。

然而，如果对小型车辆的检测在它开始超过货车时失败并且不存在对此进行识别(甚至在离线运行中)的检测算法，则该问题只能借助于确认者传感器来解决。

在另一示例中，车辆(将被自主车辆检测到以用于控制该自主车辆)正在晴朗天气中在高速公路上行驶并到达天桥下。由于突然变暗环境，检测在此刻丢失。

由此，当它从黑暗中出来时，它会突然被检测到(汽车来自“无处”，可以被控制器解释为快速驶近)，并且自主车辆同时开始制动，这可能导致脱离。

该情形将最有可能借助于基础传感器重现。

在对长多厢货车(货车挂车)进行超车的过程中，以下情况有时可能发生：极长的物体被适当的算法检测为单独车辆(货车)有时可能发生。

为了重现该情形，使用基础传感器的数据也是足够的，因为该问题是由以下事实导致的：物体(货车)可以被传感器“看见”达太长时间。

在强烈的日晒中，当太阳接近地平线时，车道由于路面的亮度大而无法被检测到。这是特殊情形，它最有可能无法在缺少确认者传感器的情况下被解决，因为相机记录不包括关于车道标记的真实信息。

然而，如果激光雷达被用作确认者传感器，则太阳位置不关紧要且车道标记可被优选地检测到(由于其从路面的轻微凸起)。

由此，尽管相机记录未给出车道标记的有用信息，但对场景进行虚拟测试是可能的，因为作为确认者传感器的激光雷达帮助重构车道标记。

在一示例中，自主车辆正在强侧风中行驶。

在超过较大货车时，自主车辆可能突然在侧面被风撞击，并且使车辆略更强烈地倾斜。

如果所应用的检测算法是灵敏的，则这可恶化其结果，并且可设想例如车道标记将不在道路模型中恰当地表示(道路模型变得倾斜，由此它不适合相机检测，这可导致轨迹规划中的扰乱并因此可导致脱离)。

该情况可以由基础传感器重现；如果例如IMU(惯性测量单元)被应用为车辆中的基础传感器，则可检测到车辆的道路保持不是恰当的(如在正常情况下)，但该车辆略倾斜地行驶。

该信息可以在运行时用于基于软件的自动纠正，但此类情形也可被设想，其中负责纠正该效应的算法(控制单元的组件)未恰当地操作。

如果体验到即使利用IMU传感器测得的数据也无法重现该情形，则只有在使用确认者传感器(例如，激光雷达，基于该激光雷达的数据可检测到倾斜)的情况下，才能期望适当的重现。

如上所述，IMU传感器并非必需被应用为基础传感器之一。

控制软件初始化的脱离在该控制软件进入如上所述的不确定状态时发生。

这可由任何硬件故障(例如，关键相机停止)导致，但这也可以是环境的结果(例如，车道标记或路面无法在自主车辆前面被检测到，由此无法计算轨迹)。

自然地，硬件故障需要修复该硬件，但是可以借助于修改(开发)控制单元的组件来修复其他原因(相机记录受干扰、GPS信号或摄像机信号)。

若干不同的故障可通过控制自主车辆来优选地处置。

只要自主车辆可安全地行驶，它将甚至在例如相机停止的情况下行驶。

然而，当该自主车辆再也无法安全地行驶时，它给予驾驶员信号并给回控制权。

在许多情况下，导致脱离的是其他交通参与者(例如，一些参与者的位置被错误地检测到)，但在其他情况下，有问题的情形可源自环境，而与其他交通参与者无关。

由此，用于根据本发明的方法的框架必须以它将能够记录所有重要细节以及虚拟地对其进行重现的方式生成(构建)。

环境的这些重要细节可被归类为多个组。动态物体可以是交通工具、行人或动物。

静态物体(地点固定)可以是例如交通灯、交通标志。

后面这些的位置和定位将最有可能不改变，因此还能依赖于地图数据，该地图数据必须与可以在记录中找到的问题相组合，由此这些是更容易处置的。

天气、太阳位置或阴影可被认为是动态环境参数(因素)，而建筑物和桥梁或者路面变化以及车道标记中的缺陷的位置可被认为是静态环境参数。

对于这四个较大组(动态和静态物体、动态和静态环境参数)中的每一者，需要单独的算法，该算法检测记录中的给定特性或特定细节，并且经由与脱离相结合地生成的日志来在模拟器中对其进行显示。

本发明还涉及一种用于修改自主车辆的控制单元的系统，其中对该控制单元的修改通过根据本发明的方法的实施例来执行。

该系统可以电连接到自主车辆的控制单元以执行对其的修改。

还可设想一种计算机程序产品，其包括指令，这些指令在由计算机执行该程序时导致该计算机执行根据本发明的方法的实施例。

计算机程序产品可由一个或多个计算机执行。

本发明还涉及一种包括指令的计算机可读介质，这些指令在由计算机执行时使该计算机执行根据本发明的方法的实施例。

该计算机可读介质可以是单个或者包括更多单独的片段。

本发明当然不限于以上详细描述的优选实施例，而是附加变体、修改和开发在权利要求书所确定的保护范围内是可能的。

此外，可由任一任意从属权利要求组合限定的所有实施例属于本发明。