在智能驾驶系统的开发中，参考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毫秒以内，以确保数据的实时性和一致性。只有当后端处理模块接收到这样高质量且高度同步的数据时，融合的结果才能更加精确，从而提高智能驾驶系统的感知能力和决策质量。
除此之外，高彪还提到了一点：相对传感器的场景可靠性，即场景模型构建的其中一项准则是保证传感器数据的准确性，针对多种传感器的情况下，在场景构建时也需要考虑不同类型的传感器特性。
因为每种传感器都有其独特的特性，如摄像头提供的是图像信息，毫米波雷达提供的主要是距离和速度信息，激光雷达主要提供点云信息。
并且，不同类型传感器需要考虑的失效模式也有很大的不同，需要场景模型中考虑去包含冗余和容错机制，以确保系统的鲁棒性。
另外，不同传感器对环境条件的适应性不同。例如，摄像头受到光照变化的影响比较大，而激光雷达受到雨雾的干扰比较大，场景模型需要考虑这些环境因素对每类传感器的影响。
总之，相比于纯视觉方案，多传感器融合方案因为涉及的传感器种类和数量较多，随之涉及到的传感器协议类型越多，传感器之间的同步机制和校验机制要求也越高。