dSPACE自动驾驶仿真技术深度解析

周末听了一场与仿真相关的会议，对其中dSPACE的分享感慨良多。借此机会，来谈谈对于仿真，我们目前还需要什么。

对自动驾驶而言，仿真的重要性已经不需要再强调。从车企，科技公司，互联网公司纷纷入局抢蛋糕就可见一斑。这其实是完全可以理解的，因为开发和测试自动驾驶系统实在是太费钱了。相比起来，仿真确实性价比极高。但现在据我了解，目前的仿真有一些固定的痛点，大部分的企业也因为这些痛点对仿真的感情很复杂，虽然主观上都想尽可能地用好仿真，但客观上都没有最大化仿真的价值。

痛点描述起来很简单：不够真和不好用

自动驾驶系统是安全第一的系统，测试是保证系统安全的重要手段。但测试必须能准确反应出系统的功能和性能才能发挥作用。仿真实际上完成了一个从物理世界到虚拟世界的映射，这个过程必然伴随着gap。由传感器模型生成的图像畸变是否能和真实传感器保持一致？在进行测试时能否考虑所有相关的物理效应？ 如果系统的关键输入特征同真实情况有明显差异，那么测试结果非但不能保证系统安全，反而会给出错误的引导。

够真吗？

dSPACE分享中就有相当一部分就谈到了如何保证虚拟仿真模型精度。思路倒也清晰，直接介绍了“一头一尾”， 即车辆动力学模型精度和感知传感器模型精度。前者展示了仿真数据和实车数据的吻合曲线。后者则是直接展示了虚拟摄像头和实际摄像头的成像畸变效果对比，以及毫米波雷达模型照射典型形状目标的仿真结果。但在如何构建这些模型方面，dSPACE并没有深入展开。

但dSPACE的仿真方案中有另一个做对了的feature。我想强调一点的是，车辆机械设计时都有做过基于有限元的动力学分析，HIL仿真软件讲求实时性，不可能取代机械动力学有限元分析软件。dSPACE主动认识到了这一点，因而重点强调了方案对其他模型的集成支持。比如对于车辆动力学模型，可以利用ModelDesk自动导入ADAMS分析结果作为参数，到ASM车辆动力学模型。对于感知传感器模型等，作为PEGASUS项目的一员，dSPACE利用标准传感器接口（OSI）来解耦环境模型和传感器模型，并支持Function Mock-up Units(FMU)，用户可以轻松集成传感器供应商提供的，能更好仿真自身产品的自研模型。不得不说，上面这个feature是一个亮点，通过以上基础工具支撑，这个自动驾驶仿真方案变得开放，松耦合。站在用户角度，就可以针对实际需求获取高质量的模型参数，集成高质量的零部件模型。

好用吗？

再谈谈不好用这个痛点，目前的仿真方案大都有自己的局限性。一套好的仿真方案应该能满足用户的各种需求，在此基础上应该给予用户比较高的自由度，但同时也能帮助用户确定仿真的界限，对一些标准和基础工具应该做好封装，不能增加用户的工作量。这些需求看起来是互相矛盾的，要做好这些，需要将仿真方案做好的解耦，针对各个子模块则要紧跟当前的仿真趋势，了解用户的核心痛点，进而选择合理的技术封装方案。

dSPACE将感知仿真方案解耦为了经典的三种类型：前端仿真，原始数据信号仿真和目标对象仿真。对每个类型的仿真都采用硬件在环的形式实现。

对于前端仿真，也即原始信号仿真。因为采用的是真实传感器，所以数据本身的真实性较强。在自动驾驶系统开发的早期，对于传感器选型这一重要工程，就可以基于此类型仿真测试不同传感器的性能。这部分对于用户而言，适配性强，不需要做任何破解，在用户输入信息有限的情况下也可以完成，因而现在需求也越来越多。前端仿真的设备成本相对较高，此外也需要有较多基础技术储备，因为必须深入了解传感器原理才能知道如何为真实的传感器提供虚拟的环境信号，进一步地，才知道如何打通闭环系统。因此这部分往往只有专业的仿真方案供应商在做。

多传感器融合仿真

dSPACE考虑目前多传感器融合的趋势，现在能支持V2X、Radar、Camera、Ultrasonic等多种传感器的前端仿真。其中对于V2X，dSPACE目前可以仿真GNSS、DSRC、LTE以及5G，同时支持主流的欧美及中国V2X标准，更关键的是可以和场景仿真形成闭环。对于Radar，dSPACE的回波模拟器对每个目标都可以仿真相对距离，相对速度（多普勒效应），RCS（反射截面积），方位角和俯仰角等基本属性，且能控制幽灵目标的出现，这就基本满足了Radar仿真测试的全部需求。值得一提的是，他们可以支持多款Radar，还包括目前比较火的4D Radar。摄像头是最适合前端仿真的，但目前他们的视频方案还不支持多目摄像头、棱镜畸变效果以及像素级别故障注入，这本质上还是因为视频暗箱方案（摄像头前端仿真）本身的局限性。另外值得一提的是，方案中谈到了可以保证1ms的实时和同步，从业者应该都了解这两个性能指标有多重要。

对于原始数据仿真，真实和仿真的分界在感知的前端。具体而言，在进行仿真测试时，须屏蔽真实的传感部分取而代之为物理感知传感器模型。基于原始数据进行仿真是必要的，自动驾驶是个系统工程，控制器在实际工作时，性能受感知模块对系统的影响非常大。比如，因为涉及大量的数据传输，所以模块对系统CPU负载影响比较多，同时这部分也是系统延迟的痛点区域。此外，系统需要处理基于不同latency的数据带来的同步问题。下游定位和规划模块能不能容忍特定的延迟值？在高负载时传感器丢帧对系统影响有多大？这部分都是通过注入原始数据进行评估的。

相比于前端仿真，使用物理感知传感器模型的方式可以有更大的场景灵活性和操作灵活性。我们可以不局限于真实传感器周围的少部分场景，而是创造多种多样的虚拟场景。同时通过设置物理传感器的属性，又可以方便的同时测试多种类型的传感器，调整同步状态，甚至调整数据量等。而这对系统性能的分析非常重要。

传感器数据建模

传感器数据建模也需要非常多的专业知识。目前dSPACE的摄像头模型能支持高保真度画面及灯光、天气效果，支持棱镜仿真配置,仿真畸变,暗晕,色差,等效果，也支持成像器仿真配置,如输出模式,色彩深度等。对于我前面提出问题，这些就基本可以满足测试需求了。

主动传感器的建模难度更高，因为要考虑的物理现象相对更多更复杂，相关的技术储备也相对更少。对于毫米波雷达模型，dSPACE的方案是以光线追踪技术为核心的，也考虑了镜面反射和散射和多路径传播，自适应波速发射。对于激光雷达模型，dSPACE提到他们可以支持固态或机械式LIDAR，支持果冻效应和天气影响。在我看来，这些核心特征建模之后，这些传感器就能发挥出比较大的价值了。

当真实和仿真的分界线在应用的前端时，就是决策规划系统测试了，真值目标可以在最大程度上避免建模不精确的影响，且其和场景测试耦合是最紧密的，因此这也是业界当前最能被广泛的仿真方式。但输出目标其实也不是一件简单的事情。不同控制器对输出类型的要求不一，不同算法重点关注的目标特征也不尽相同。对于这一点，dSPACE除了提供包括3D和2D边框、坐标和速度、车道、车道线、交通标志和信号灯等基本的各种输出目标之外，还允许用户自定义信息, 从而避免了目标列表中缺少“目标”的尴尬。

另外，输出目标也有自己对“真”的需求，除了常见的物体表面颜色，反射率等基本特征需要保证合理之外，dSPCAE还提出了感知范围，工作频率等更上一层的特征。另外还有一个关键点是通信的真，这一点dSPACE则是通过残余总线仿真实现的，而且基本涵盖了CAN、以太网等基本通信方式。

自动驾驶仿真——场景搭建

最后我们还是谈谈场景吧，这也是以前的我重点研究的方向。对各大自动驾驶仿真供应商来说，对场景的支持也是必不可缺的。

对自动驾驶系统测开发和测试而言，dSPACE展示了如下图所示的经典方法论。1.通过评估潜在风险将known risks最小化至可接受范围，如有必要,通过提升功能或限定适用范围将危险场景移至known safe states区域。而这需要基于标准法规场景,功能场景通过Verification实现。2. 需要将unknown risks尽可能最小化至可接受范围;将每个发现的危险场景移至known risks。而这则需要基于危险工况场景,自然驾驶场景通过Validation(确认)实现。

当然，为了解决长尾问题，我们也需要对场景进行泛化，通过重组参数场景测试系统在各种场景下的表现。

基于以上基本需求，dSPACE针对法规场景，设计了包含了如AEB2020以及LSS等的NCAP场景库。对于危险工况场景，则支持导入GIDAS、CIDAS，进而复原事故静态道路环境和故动态交通参与物轨迹(PCM)。对于自然驾驶场景，则引入了UAI工具来标注原始数据，来提取动态场景信息，并能结合道路、定位等信息综合为场景描述文件，进而打通了整个闭环，实现了虚拟场景生成的自动化。当然，以上大多都是对功能场景的支持，dSPACE可以将各类场景抽象成逻辑场景，并通过参数重组，衍生出更多具体的实际场景，从而让不同来源的场景通过泛化真正发挥出价值。

总结

越早做好仿真，就能越早实现自动驾驶。在这个领域，能同时做好仿真精度高以及工具完整好用，就一定能占到足够的市场。目前越来越多的仿真供应商认识到了这一点，也在朝着这个目标一点点前进。大环境还是欣慰的。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删