部分自动驾驶系统的复杂功能，例如高速公路巡航，不仅难以开发，而且系统还必须要保证在任何时候、任何环境下都具有超出其预期功能的安全行为。在真实交通中，车辆必须处理无数场景，并需要通过测试验证，因为并非所有的测试都可以在道路上进行。即使是直接与 ECU 一起实时工作的仿真解决方案，目前也因数据量过大而出现过载。
测试对象和测试分布
我们必须具有直接通过待测控制单元和控制单元网络进行的（或在道路上进行的）关键测试。为了满足所需的测试次数，大部分测试必须在软件在环 (SIL) 系统上执行，在此过程中需要虚拟化测试对象。该解决方案的重点是待测物 (SUT)，即待测功能的实际代码。我们有多种提供虚拟测试对象的技术方法：例如，您可以通过适当的接口将代码作为完整的可执行单元集成到仿真系统中。dSPACE 正通过“container”技术实现这种集成。此外，您还可以集成产品级代码，尤其是虚拟 ECU (V-ECU) 的代码。dSPACE SystemDesk 提供了总线连接、操作系统配置等产品级代码集成过程中的所有功能。为了确定测试对象虚拟化的方法，我们必须精确定义测试范围。无论是测试单个功能、整个 ECU 软件，还是要测试特定的完整效应链，这些测试对象的因素最终决定了 SUT 的设计。
仿真结构
第二个方面是仿真架构，其中涉及仿真系统及其基础架构。SIL 技术的使用使仿真不再依赖于实时和专用硬件。通过 VEOS，dSPACE 成功推出了基于 PC 的仿真和集成平台，其可作为 SIL 测试的基础。这种多功能性尤其重要，原因有二：首先，可以采用任意细节程度对环境进行仿真。除了电机或电池模型外，这还包括传感器模型，它可以仿真对象列表、传感器真实感数据等所有相关的细节。其次，我们的目标是轻松增加测试设置，以获得更大的测试吞吐量。云系统（公共和客户数据中心）使用容器 (container) 和编排技术为多个并行实例化过程提供平台。dSPACE 提供了包含 VEOS 装置等内容的预配置容器，将其工具与云系统无缝集成。
测试目标
这使得对测试的需求急剧增加。最终，我们通过在仿真过程中完成一系列特定的交通场景来实现验证，其中包括合成场景的仿真和变化。但是，对驾驶测试过程中记录的测量数据进行回放也将是验证的核心部分。首先，必须确定测试的实际来源，或者根据 Pegasus 方法确定车辆必须成功完成的场景。基本上，这些是相对少量模板的变体，称为逻辑场景。例如，必须在不同条件下，测试各种车型在市内交通中的特定避撞情况（例如另外一辆车突然改变车道），而基本情况保持不变。
一旦有一组基本场景可用，就可以用它生成大量特定测试案例。从逻辑场景的配置开始，算法会生成最终的特定场景，然后在仿真过程中执行这些场景。简单算法可实现排列、各个参数的同步设置或随机过程。更先进的算法会试图通过优化方法或人工智能来识别关键场景。
在测试设置中，另一方面经常被低估：即整个过程必须自动化，同时实现集中配置。未来的验证将不会集中在定义复杂的测试过程上，而是集中在本质，即可测量的测试案例属性。这些属性可以通过为仿真记录的测量值计算出来。
这样的优势在于其公式较直观，例如，两辆车的相对速度可以从各自的速度中得出。这些属性是在仿真期间或之后计算的，但对实际测试过程没有影响。因此，我们可以在闭环操作中始终使用固定的测试过程。此外，我们无需手动定义测试步骤。
结论
自动驾驶的发展改变了 OEM、传统供应商和平台提供商之间的基本合作模式。合作的重点不再是交付完成的 ECU，而是集成分布式车辆功能并尽早对其进行验证，并且可能需要跨公司进行验证。在此过程中的基本原则是：错误发现得越早，纠正错误的成本就越低。我们通过共享仿真和测试基础架构实现了新的协作形式，但最终只解决了这种协作模式的众多挑战之一。验证海量场景是自动驾驶面临的核心挑战之一。因此，dSPACE 基于场景的测试将以上这三个方面作为基础。它们考虑了上述许多方面，但其中某些因素可能非常复杂。由于 dSPACE 致力于成为一站式验证流程供应商，因此我们在每个领域都能够提供解决方案。
利用我们的工具链，您只需点击几下鼠标即可完成功能验证或 ECU 网络仿真，同时还能确保高测试覆盖率和场景变化。此外，用户还能够随时向开发人员提供有关其代码质量的反馈。因此，我们可以减少所需的驾驶测试人员和驾驶测试次数，达到一种可控的水平。
《dSPACE杂志》，2020年1月出版
