自动驾驶仿真

自动驾驶仿真

在整个汽车工作流程中应用 C-V2X 测试解决方案

自动驾驶拥有极其巨大的潜力，有可能改变我们的出行方式。它不仅有望永远改变车辆的设计和制造，还会永远改变汽车的所有权乃至整个交通运输业务。要实现全自动驾驶的目标，开发人员需要开发极为复杂的软件，软件中融入的人工智能（AI）必须能够正确理解从周边基础设施和车载传感器阵列接收到的实时数据流，并据此做出相应动作。因此：为了对这些系统的功能、性能和安全性进行彻底验证，开发人员越来越依赖于在实验室中进行精密的仿真和测试。自动驾驶仿真（ADE）平台很早便开始在整个汽车设计工作流程中使用，目前已经非常成熟，能够仿真测试在公路上行驶的车辆中所部署的各种新技术。

了解 V2X 通信的作用

与高级驾驶辅助系统（ADAS）关联度最高的传感器有雷达、激光雷达、超声波传感器和摄像头。通过车联网（V2X）无线器件获得的外部输入可以给这些传感器提供额外的重要数据。V2X 通信的核心目的是通过广播消息的方式提供标准化的安全服务，即通过广播提醒每一辆车注意周围的其他车辆以及它们的位置、轨迹和速度。车辆通常使用5.9 GHz 频段中的无线链路与其他车辆以及交通信号灯等路侧单元进行通信。这种通信的覆盖范围达到 300 米，且不受视距限制，因此车辆能够“看见”并探测到可能被建筑物、树木等障碍挡住的其他车辆。

从短期来看，欧洲（C2C 论坛）、北美（SAE）、中国（C-SAE）和其他地区的标准机构纷纷以使用场景的形式对 V2X 应用进行了定义。从长远来看，很多应用（例如 5GAA 所考虑的应用）在开发时都需要依赖 V2X 信息以及其他传感器数据。总的说来，这些因素决定了在设计支持 V2X 的 ADAS 时，必须对其进行多大规模和范围的测试。

利用测试和仿真

根据相关标准，我们必须在不同的情况和条件下对包含 V2X 的系统的功能和安全性加以验证。随着此类测试的广度和深度不断增加，驾驶真车在封闭道路或公共道路上进行测试很快变得不仅成本过于昂贵，而且不切实际并蕴藏极大风险。

长期以来，为确保功能安全性，车辆的开发一直以 ISO 26262 框架和相关的 V 模型为准则（图 1）。根据该图，基于模型的测试从左上角开始，从上往下需要经历三个级别的测试：系统、子系统和模块。在这里，整个车辆的测试要求最终分解为底层模块和元器件的测试要求。右边基于硬件的测试则正好与之顺序相反，从下往上需要经历模块测试、功能测试、集成和系统测试三个级别。

如果是通过电子方式实现的功能，这种方法与原始设备制造商（OEM）及其一级供应商开发的电子控制单元（ECU）有关系。将这些功能设计到软件或硬件中需要遵循 V 模型所示的整体系统架构。在这个示例中，V 模型右侧的活动组成了对整个车辆功能和安全性的验证。

执行对 V2X 系统的无线测试

对于 AV 和 V2X 应用而言，车辆本身是更大规模交通系统的一部分。该系统还包括“网络设备”组件（例如传输交通信号灯序列数据的路侧单元）。在元器件级别进行测试最经济高效，不过如果是使用真实车辆测试此类元器件的基本功能，则成本可能极其高昂，尤其是功能缺陷有可能对人员、财产和车辆造成伤害。

我们假设 V2X 是 V 模型框架内的一个示例。毫无疑问，无论是交付单独的 V2X 应用还是交付嵌入到更大规模系统中的 V2X 应用，测试都具有至关重要的意义。具体来说，我们需要在V2X 通信堆栈的不同层级以及应用层进行测试。可靠、可重复的 V2X 通信需要依靠复杂的软件来实现，需要依靠通信堆栈上下层中的多个角色发挥作用。在对 V2X 车载单元（OBU）进行 V 模型右侧所示的测试时，测试无线调制解调器的功能及其标准一致性通常采用的方式与无线行业测试移动电话和数据设备的方式相似。测试要求映射到 ITS 堆栈和 OSI 模型上，如图 2 所示。下方的边栏详细描述了蜂窝 V2X（C-V2X）OBU 的测试流程。

OBU 的测试生命周期

对于所有蜂窝无线器件而言，物理层和数据链路的测试通常由芯片制造商和器件厂商使用无线测试仪和相关工具完成。在进行第一步验证时，此类工具可以仿真必要的网络元件来与被测器件建立无线链路，从而实现必要的射频和调制测量。

举一个例子：对于 C-V2X OBU，PC5 车辆对车辆（V2V）无线链路必须要使用芯片中的无线层和低层协议堆栈。这些堆栈必须经过测试，多年以来，无线行业已经开发出一系列能在无线层和协议层开发过程中使用的测试解决方案。通过对这两层进行认证可以确保使用不同厂商芯片的器件具有互操作性。

3GPP 和 GCF 等机构针对调制解调器的不同层指定了标准化测试。除了验证互操作性之外，这些测试还可以确保调制解调器满足距离和数据吞吐量等要求。此类测试通常使用具有独立调制解调器及协议测试工具和校准参数物理层测量的无线测试仪。

此外，与相关区域 ITS 堆栈定义的数据传输有关系的协议由 ITS 堆栈厂商负责实施（例如，欧洲定义的系统中的 GeoNetworking 以及北美的 IPv6 和 TCP/UDP）。集成了上层 ITS 堆栈的 OBU 也要进行测试，从而确保发送和接收正确的 V2X 消息类型和内容。C-V2X OBU 和路侧单元（RSU）的认证制度仍有待完成。在美国，OmniAir 联盟率先创建了一组明确的测试例，其中涵盖了每个 OBU 和 RSU 必须通过才能获得认证的技术规范。

与车辆的融合

一旦通过单独的测试确认 OBU 能够成功发送和接收指定的消息，接下来就是验证车辆能够在应用层正确使用这些消息来指导驾驶员，如果是自动驾驶汽车（AV），则是直接采取行动。应用由使用场景来描述，而使用场景则由 OEM 或一级供应商的工程师负责解释并在车辆中实现。在这个等级上，输出与驾驶员的人机界面（HMI）显示器相连，或最终连接车辆的控制界面。我们仍然可以在 OBU 或集成的远程信息处理控制单元（TCU）上测试简单的应用。然而，随着高级应用开始涉及 HMI 之外的控制面，闭环系统测试将变得更加实用。在 V 模型中，它通过在右侧从下往上直至系统测试来表示。

请下载此文档以了解更多信息。