抢占智能驾驶“智高点”，仿真测试或将是必备的“加速剂”
在智能驾驶系统的开发中，参考V模型开发流程，仿真测试通常包含多个阶段：MIL（模型在环）—— 用于验证理论模型，软件在环（SIL）—— 测试软件组件，硬件在环（HIL）—— 集成硬件组件进行测试，车辆在环（VIL）—— 模拟车辆与环境的交互，以及实车道路测试（包括封闭场地和开放道路）。
自动驾驶系统开发V字流程
V模型的左半边代表开发阶段，此阶段仿真测试作为开发的一部分，主要用于验证设计的可行性和性能。在这个阶段，常用的仿真测试手段包括MIL和SIL，它们帮助工程师在早期发现潜在的设计问题。
V模型的右半边代表量产测试阶段。在此阶段，仿真测试主要用于回归测试和性能评估，以确保产品在生产过程中保持质量的一致性，并为产品交付和量产做准备。在这个阶段，常用的仿真测试手段包括HIL、VIL以及实车道路测试，这些测试手段能够提供更接近实际运行条件的评估。
在整个V模型过程中，仿真测试扮演着至关重要的角色，它不仅在开发阶段帮助验证设计，而且在量产测试阶段确保产品质量和性能。
1.MIL、SIL以及HIL之间的关联
MIL、SIL和HIL属于仿真测试的三种不同手段，用在车辆系统开发的不同阶段，并且具有不同的目的。这三种测试手段相互补充，确保车辆系统的开发在各个关键阶段都经过了严格的测试和验证，进而有效地提高系统的整体质量和性能，降低开发风险，并加快产品上市的时间。
昆易电子算法事业部总经理方志刚讲到：“从理论上来讲，在早期开发阶段，开发人员通常先使用Simulink等图形化编程环境来设计和实现算法模型，然后通过仿真执行这些模型，以验证它们的行为是否符合预期，这就是所谓的MIL阶段。
“一旦模型通过MIL验证，下一步是将Simulink模型转换成可执行的C代码。这个过程称为自动代码生成。然后，软件开发团队再将生成的C代码编译成适用于x86架构服务器的可执行程序，进行SIL测试，以验证软件组件在X86系统环境中的功能正确性。”
与运行SIL测试的x86架构服务器不同，汽车控制器更多的是使用ARM架构及专用的硬件加速芯片。因此，在SIL测试完成后，C代码需要针对目标控制器的硬件架构（如ARM）进行重新编译和优化，以生成可在控制器上运行的可执行程序，才能进行HIL测试。
另外，他还指出，“如果在SIL或HIL测试中发现问题，可能需要回到Simulink模型进行修改，然后重复代码生成和测试过程。同时，在开发过程中需要考虑软件在不同平台（x86和ARM）上的兼容性和性能。”
虽然MIL和SIL测试更多地关注功能的实现和验证，但它们也都涉及到初步的性能评估。同样，HIL测试虽然更侧重于性能方面的验证，但也必须确保硬件集成后的功能正确性。总之，所有这些测试都是为了确保最终系统在功能和性能方面都能满足设计规范和用户需求。
MIL/SIL/HIL三者的应用阶段和目的
正常来讲，对于智能驾驶系统开发，仿真测试也需要贯穿整个V模型开发和测试的全流程。但是，当前主流的仿真技术平台尚不能提供贯穿整个流程的全栈式仿真测试能力。因此，在智能驾驶领域，行业内也未能够严格遵循V模型的流程进行仿真测试验证。
亦佩捷(IPG)汽车设备(上海)有限公司总经理黄晓介绍说：“在智能驾驶领域，多数主机厂很难做MIL和SIL，主要原因在于，对于不是全栈自研的主机厂，他们没有供应商的Sensor模型、算法模型，甚至是Simulink模型，因此主机厂没有办法做MIL。
“另外，虽然理论上做SIL（包括云上SIL）的效率最高，但现在的客户大部分是从HIL开始做；SIL难做的主要原因就是主机厂与供应商之间、供应商A与供应商B之间，都无法无缝提供参数、算法和接口的开放。
“不同类型的企业以及针对不同系统层级做SIL所关注的点都不一样。供应商自己也可以做SIL，但供应商做的SIL只能是针对其自己的产品，没办法做整个系统的SIL，因为主机厂的车辆动力学模型也不太可能对他们开放。比如摄像头模组厂商针对摄像头模组本身也可以做SIL，但他们关注点可能在摄像头本身的性能和可靠性怎么样，比如识别率、图像质量以及噪声和干扰等，而不会关注具体的智驾功能。”
NI大中华区智驾业务发展经理王帅则从另外一个维度谈到：“SIL测试通常可以在本地单机或基于服务器的云仿真环境中进行，而HIL测试则基于真实的ECU硬件。这两种测试方法在实时性方面存在显著差异。HIL测试要求仿真环境必须以与实际传感器相同的帧率/速率提供输入，例如，如果摄像头的帧率是30fps，HIL测试中的仿真软件也必须以30fps的帧率向控制器提供输入，以确保测试的实时性。
“相比之下，SIL测试提供了更大的灵活性。在SIL测试中，可以进行加速或减速测试，仿真软件可以以不同的帧率（如100fps或1fps）输入给控制器，这在早期开发阶段或算法迭代中非常有用。
“此外，SIL测试由于其与开发端的接近性，以及与软件迭代的紧密关联，使得它在软件开发的早期阶段尤为重要。然而，随着系统开发的进展，HIL测试的实时性优势变得尤为关键，尤其是在集成和验证硬件与软件的交互环节。”
“SIL测试有助于快速迭代和早期问题发现，而HIL测试则确保了在实际硬件环境中的系统性能和安全性。目前行业上基本还是几种仿真测试手段相互结合使用的一个状态。”
总之，在V模型的每个开发阶段都有其侧重点和阶段目标。仿真测试的实现需要结合阶段目标来进行，每个阶段的测试场景和仿真策略都会根据测试目标的需求来选择。
2.低阶智驾与高阶智驾在仿真测试需求上的差异
在仿真测试中，低阶智能驾驶功能通常是基于一系列设计好的测试用例进行测试。测试用例可以简单理解为片段式的场景，是从相关驾驶情境中提取的关键部分，用以测试特定功能，并且测试评价标准相对简单。
同时，低阶智能驾驶的仿真测试主要集中在对规控算法的验证上。由于感知信号经过处理后会转换成object list，这种结构化的数据简化了对传感器模型的仿真要求。
然而，高阶智能驾驶功能涉及车辆在复杂环境下的感知、决策和控制，比如在一个六岔路口对周边的行人和车辆进行感知与规避。因此，主机厂在做仿真测试的时候，不仅要应对“后半段”的规控，还要对“前半段”的感知进行仿真测试。
高阶智能驾驶系统的架构复杂性，接口多样性，以及高频次的软件更新迭代需求，为仿真测试系统的设计和维护带来了一系列的挑战。
黄晓认为，最好能有一个统一的测试平台来管理各系统的接口，而不是使用不同的软件来管理不同的接口。“只有统一了，在维护层面才能为企业提供更多便利性。”
“目前来看，仿真测试还主要偏向于功能测试。因为功能测试给客户带来的效用和帮助更直观。他们可以快速通过仿真搭建测试场景，能够高效、快捷验证系统功能是否达标。”
他还提到，如果主机厂想验收供应商的交付质量，除了功能测试，还需要考察性能是否达标。“但是对于性能测试，则需要花更多的力气去搭建高精度的模型，我觉得目前在高精度的场景建模和传感器建模上都还存在挑战。”
在系统的开发过程中，苏州智行众维（IAE）研发副总高彪表示，“高阶智驾与低阶智驾在仿真测试的需求上确实存在显著的区别，这些区别主要体现在测试场景范围以及测试评价上。”
-
低阶功能的仿真测试重点在于车辆在特定条件下的响应，如检测车道线、前车距离变化等。测试场景所需要覆盖的路况和工况相对较为简单，测试评价多依赖于成熟的测试标准。
-
而高阶功能的测试场景需要根据智驾功能ODD覆盖不同的路况、天气环境和边缘情况，测试场景里程及场景多样性和覆盖度至关重要。尤其是当智能驾驶功能突破L2跨越到L3以后，“安全责任人”的角色也将发生转变，测试评价将会更关注累计安全行驶里程。
低阶智驾功能仿真测试VS高阶智驾功能仿真测试
总体而言，低阶智能驾驶功能的开发和测试主要依赖于基于测试用例的测试方法。这种方法侧重于验证特定功能在预定义条件下的行为和性能。相比之下，高阶智能驾驶功能的开发和测试则趋向于采用基于场景的测试方法，这种方法更加关注在复杂多变的交通环境中系统的整体表现。
3.高阶智驾仿真测试方案：纯视觉VS多传感器融合
目前，依据感知传感器配置的不同，高阶智驾方案大致可以划分为两大类：纯视觉方案和多传感器融合方案；而国内主流车企的高阶智能驾驶方案多倾向于采用多传感器融合方案，具体的融合级别可能因企业的技术路线和产品需求而有所不同。
随着深度学习技术在智能驾驶领域的发展和应用，BEV+ Transformer方案已经成为当下高阶智驾感知方案的主流选择。BEV+Transformer 最开始是在特斯拉的纯视觉方案上率先应用。紧接着，国内的企业又在此基础上做了一些调整和适配，应用在了多传感器融合方案上。
BEV+Transformer 技术的核心优势在于其能够在 BEV 空间中进行有效的多模态数据融合和处理，提高感知性能。它可以根据不同的需求和场景与前融合、中融合或后融合方案结合使用，并不是严格限定于特定的融合方案。但目前，BEV+Transformer 技术更常见于前融合和中融合方案中。
BEV+Transformer 架构应用在不同融合方案
与纯视觉方案相比，多传感器融合方案由于配置了更多种类和数量的传感器，因此在进行HIL仿真测试时，对计算能力的需求显著增加。此外，不同传感器的数据帧率可能存在差异，这要求仿真系统中的多种传感器模型和模拟器必须实现精确的数据同步，增加了仿真过程的复杂性。
黄晓表示， 在高阶智驾方案中，通常会采用前融合方案，在控制器内对传感器传输过来的原始数据进行融合。
在纯视觉智能驾驶方案中，摄像头的配置数量通常在7到11个左右，分辨率在2MP~8MP。由于摄像头捕获的原始数据是高分辨率视频流，因此在仿真环境中对算力的需求尤为突出。为了处理这些大量的图像数据，通常需要部署多个配备高性能显卡的服务器，以提供必要的计算能力支撑。
另外，他还指出，“在进行多传感器融合方案的仿真测试时，确保不同传感器之间的数据同步是一个复杂的问题。从软件的角度来看，需要实现精确的时钟同步和数据融合算法；从硬件的角度来看，可能需要特定的硬件支持和接口来实现传感器之间的同步。此外，为了满足实时性要求，整个仿真系统的效率也是一个重要考虑因素，包括数据传输速度、处理速度和计算资源的优化。因此，设计一个能够满足这些要求的仿真测试系统面临着技术和工程上的多重挑战。"
在多传感器融合方案中，确保数据传输的同步确实是一个不小的挑战。方志刚解释说“首先，仿真软件生成的各个传感器信号在时间上可能存在差异，这可能是由于仿真模型的计算延迟或数据处理方法的不同造成的。其次，不同传感器的数据传输速度也有所不同。例如，毫米波雷达的数据量相对较小，可能很快就能传输完成；而激光雷达和摄像头由于数据量大，传输时间可能需要几毫秒甚至几十毫秒。
“此外，各个传感器处理的帧率/频率也各不相同。例如，激光雷达可能是10Hz，摄像头可能是30Hz，毫米波雷达可能是13Hz。这些不同的帧率/频率进一步增加了数据同步的复杂性。
“因此，解决多传感器数据传输同步的问题需要综合考虑传感器的特性、数据传输速度、处理帧率以及同步机制的设计。这可能涉及到算法优化、硬件升级、通信协议改进等多个方面。”
另外，在高阶智驾多传感器融合方案的仿真测试中，确保融合效果的准确性也是一个关键挑战。王帅指出，为了提高融合效果，必须提供高质量的传感器仿真数据。这意味着仿真的数据不仅要真实反映传感器的特性，还要具有高度的同步性。在当前主流的BEV感知架构方案中，这一点尤为重要。例如，不同摄像头提供的数据之间的时间差通常应控制在1毫秒以内，以确保数据的实时性和一致性。只有当后端处理模块接收到这样高质量且高度同步的数据时，融合的结果才能更加精确，从而提高智能驾驶系统的感知能力和决策质量。
除此之外，高彪还提到了一点：相对传感器的场景可靠性，即场景模型构建的其中一项准则是保证传感器数据的准确性，针对多种传感器的情况下，在场景构建时也需要考虑不同类型的传感器特性。
因为每种传感器都有其独特的特性，如摄像头提供的是图像信息，毫米波雷达提供的主要是距离和速度信息，激光雷达主要提供点云信息。
并且，不同类型传感器需要考虑的失效模式也有很大的不同，需要场景模型中考虑去包含冗余和容错机制，以确保系统的鲁棒性。
另外，不同传感器对环境条件的适应性不同。例如，摄像头受到光照变化的影响比较大，而激光雷达受到雨雾的干扰比较大，场景模型需要考虑这些环境因素对每类传感器的影响。
总之，相比于纯视觉方案，多传感器融合方案因为涉及的传感器种类和数量较多，随之涉及到的传感器协议类型越多，传感器之间的同步机制和校验机制要求也越高。
4.高阶智驾在仿真测试上存在的挑战
1）场景覆盖度和仿真置信度问题
高阶智驾仿真测试对于场景库和测试用例需求，主要体现在以下几个方面：
高覆盖度：强调场景库尽可能覆盖ODD内的驾驶场景，确保测试框架从基本功能验证扩展至高阶复杂挑战的全面审视，包括但不限于常见驾驶情境、极端气候条件、低频出现的边缘情况，形成一套由浅入深、循序渐进的测试体系，以验证系统在各类工况下的稳定性和可靠性。
高真实性：在构建测试用例时，要求仿真环节总的交通参与者（包括行人、其他车辆等）不仅在物理行为上遵循真实世界的规律，还需在运动轨迹、交互逻辑上体现自然性和多样性，确保测试数据与实际情况高度吻合。
高复杂性：在设计测试用例时，同时并发多个交通参与者的动态行为，包括但不限于随机路径选择、非线性速度变化、紧急避险动作等，旨在创造高度复杂且难以预测的交互场景。
可重复性：要求测试用例能在一致的测试条件下被重复执行，确保每个测试用例均可进行回归测试。
黄晓认为当前高阶智驾仿真测试所面临最主要的两个问题是场景覆盖度和仿真置信度的问题。对于场景覆盖度，主要是指Corner cases覆盖度的问题，这些场景在我们日常驾驶中很少被碰到。虽然通过仿真手段可以非常快速地获取或制作一些Corner cases 场景，可以去复现，并不断的迭代。但仿真和测试之间还存在一个巨大的鸿沟，那就是仿真置信度的问题。
那么，仿真置信度不高又是哪些原因造成的呢？黄晓表示，仿真置信度问题主要来自两个方面：首先，仿真软件本身建模的问题。传统动力学模型置信度还可以，但是物理传感器模型、环境模型、天气模型、道路模型、交通流模型置信度如何，以及整个综合起来形成一个链条后，他们的加权置信度又会是多少？目前行业里还没有太多的验证案例。
其次，用户应用仿真测试的经验和能力问题。比如一家整车厂在做车辆动力学模型的时候，愿意花多少时间，愿意投入多少人，用哪个部门来做，不同部门的之间的沟通效率如何，都会影响到车辆动力学模型最终的置信度。
最后，他建议到：“业界应合力搭建仿真场景平台，并且全行业努力提升并验证仿真的置信度，这对于行业的长远发展将会是很大的助力。”
2）路采数据的通用性问题
某工具链公司的仿真负责人曾经提到，在用真实道路数据做仿真的情况下，一旦传感器的位置或者型号有变更，这一组数据的价值就会降低，甚至“作废”。也可以用神经网络对真实道路数据做调参，这种调参的智能化程度会更高一些，但可控性会比较弱。
当前，由于真实世界数据的复杂性和多样性，合成数据只能在部分情况下替代真实数据，高阶智驾仿真测试对路采的真实数据的依懒性还非常大。因此，路采数据通用性的问题，势必会给高阶智驾仿真测试的向前推进带来比较大的阻碍。
高彪解释说 ：“路采数据的通用性能力的强弱直接取决于测试中数据的使用策略。目前大部分企业在使用真实路采数据时，只是将路采数据按照域控制器的数据接口要求处理后进行数据回灌。这种使用方法确实对传感器安装位置、安装角度、型号，甚至车辆尺寸存在严格的一致性要求，一旦某个要素出现变更，测试数据就不再满足测试要求。
“为了进一步挖掘真实道路数据的应用，将路采数据重构为仿真测试场景，结合仿真工具，通过仿真建模调整传感器参数配置、安装位置、车辆型号等，实现路采数据的高通用性。”
3）法规和标准方面的问题
有业内人士提到，高阶智驾准入仍存在巨大法规空白，短期内尚不能实现大规模的公开道路测试，绝大多数的测试将会在仿真环境中完成。然而，智能驾驶仿真测试在法规与标准上仍存在缺失，尤其是针对高阶智能驾驶的仿真测试，缺乏统一的测试标准和评价体系。
高阶智驾技术的复杂性和安全性要求远高于传统的驾驶辅助系统，因此需要大量且深入的测试来确保其在公共道路上的安全性和可靠性。目前的公开道路测试受到区域性、成本、时间周期等方面的限制，这促使行业寻求并依赖仿真测试手段，同时也将推动仿真测试成为确保智驾系统安全准入和量产的关键环节。
在高阶智驾准入的问题上，高彪认为，车企在完善开发和测试流程的过程中，需要考虑与仿真更加紧密的结合，在不同的开发阶段更多地运用仿真进行V&V验证，从而缩短整体的开发验证周期并降低测试成本。
另外，他还提到：“在法规制定和政府监管方面，也可以合理运用仿真测评手段，以提升安全监管目标。对于仿真工具及场景库来讲，合理提升仿真的真实性以覆盖更广的测试需求，同时扩展有效场景数据实现更高的场景覆盖度是一直以来我们的目标。”
5.高阶智驾出海与仿真测试
据中汽协公布的汽车出口数据显示，2023年，我国全年累计汽车出口491万辆，其中传统燃油汽车出口370.7万辆，占比为75.5%。同时，大多数车辆所搭载的智能驾驶功能依然还是传统的低阶ADAS功能。
随着国内汽车需求的逐渐趋向于饱和，以及价格战的加剧，国内汽车行业纷纷将目光转向海外，将“内卷”逐渐化为“外卷”。对于中国车企而言，在向海外推广产品的时候，智能化是其主打的“标签”之一。因此，车企必然也希望能够将高阶智驾功能向海外推广。
对仿真测试行业而言，针对海外当地的仿真测试市场的需求将会大大增加。高彪提议，国内车企需要进行大量的具有海外当地特色的仿真测试以确保其智能驾驶系统在不同国家和地区的交通环境和法规要求下的安全性和可靠性，对应仿真测试场景就要相应适配海外当地的交通标志、道路规格、驾驶习惯和相关法规等。他们作为仿真测试企业，会提供定制化的测试方案，以帮助车企实现产品的快速本土化。
“除了需求增加，仿真测试行业也面临着不同国家数据合规的政策问题，同时仿真测试企业可能会与国际同行进行更多的合作和竞争，参与或推动相关测试标准和协议的制定，以实现国际市场的互操作性和统一标准，推动行业整体水平的提升。”他补充说到。
总之，高阶智驾功能的出海为仿真测试行业既带来了机遇，也带来了挑战。国内仿真测试行业需要不断创新和进步，以适应和满足全球化市场的需求，进而帮助中国车企将高阶智驾技术更快地推向海外市场。
原文链接：https://mp.weixin.qq.com/s/1_9X26yAB_9kouh1Gbe8hg