C-V2X功能场景仿真验证方法研究与实践

1  概述

汽车电子软件开发模型一般分为瀑布模型和V模型。如图1-1所示，瀑布模型的开发遵循从上到下的固定顺序，依次为需求分析、总体设计、详细设计、编码与调试、测试五个阶段，各阶段划分明确，以有序的方式来解决复杂的问题，尽可能地实现预期需求。瀑布模型中的每一个阶段都有对应的循环反馈，在后续开发阶段中发现缺陷时，可以把缺陷反馈到上一阶段进行修正。


图1-1 瀑布模型开发流程

在需求明确且稳定时，可采用瀑布模型进行软件开发，但在实际开发中，需求会因为各种原因发生变更，这样会给瀑布模型的开发带来很大的工作量，因为需求的变更意味着整个开发流程需要重新返回到需求分析阶段。且瀑布模型只有在项目后期才进行测试，难以在前期发现设计错误或纰漏，会带来研发成本增高、开发周期延长等风险。因此，大多数公司使用V模型来进行开发。如图1-2所示，传统V模型的左侧从上到下为需求分析、系统设计、子系统设计、软件设计以及编码实现，其中代码是开发人员基于详细的软件设计进行编写的；针对V模型左侧的每个开发阶段，右侧会有不同的测试阶段与之一一对应，依次为系统测试、集成测试、软件测试以及单元测试，如，软件产品的需求可在系统测试阶段得到验证。相较于瀑布模型，V模型的优势有：

•  具有较强的可追溯性；

•  能在开发前期进行测试验证，发现重大错误；

•  模型开发简单高效，能减少开发成本，提高开发效率


图1-2 V模型开发流程

随着嵌入式软件开发的规模以及复杂度越来越大，系统的安全性和实时性要求越来越高，在传统的V模型开发过程中人工编码或多或少会出现语句错误、代码缺陷等问题，且在代码中难以直观地表现出逻辑关系。此时可以将基于模型的设计（MBD）融入到V模型的开发流程中，如图1-3所示，结合系统仿真和代码自动生成技术，在开发流程中让各个功能以模块化的形式表现，自动生成相关的代码，减少代码的编写错误，同时能在各阶段验证相关功能的逻辑。


图1-3 融合MBD的V模型开发流程

融合MBD的V模型开发流程，首先需要定义仿真建模目标，即详细了解系统的需求。在系统设计阶段需要进行物理建模设计，随后在子系统设计阶段进行快速原型搭建，此时需要运用模型在环测试（MIL）对所搭建的算法模型进行功能以及完整性验证。之后将设计好的功能模块自动生成对应的产品代码，在单元测试、软件测试过程中，进行软件在环（SIL）以及处理器在环(PIL)测试，验证代码以及编译后的可执行文件与模型在功能上是否保持一致。然后进行MBD的最后一步：集成测试，对所集成的系统进行硬件在环测试（HIL），验证被测终端在真实硬件设备通信环境中是否满足车联网系统各应用功能的需求。剩下的测试步骤与传统V模型中的测试一致，如车辆在环测试（VIL）、实车测试等。下文将针对C-V2X功能场景各阶段的开发测试方法逐一介绍。

2  模型在环测试（MIL）

模型在环测试（MIL）是集成软件算法模型和被控对象模型（交通流模型、车辆动力学模型等）的闭环测试系统，通过相关测试用例对软件算法模型进行测试，在模型层面验证软件系统功能的正确性。基于模型设计(MBD)的前期将一个大的系统拆解成多个不同的子模块，然后将各子模块逐一分解为多个单一的功能模块，在支持模块化设计的仿真软件（例如Simulink）中，逐一搭建各单一功能模块模型，最终形成所需的算法模型，通过输入测试用例验证搭建的算法模型是否满足设计的功能需求。


图2-1 模型在环测试

以交叉路口碰撞预警（ICW）算法功能测试为例，当主车驶向交叉路口，与交叉路口侧向行驶的车辆存在潜在碰撞危险时，ICW需要对主车驾驶员进行预警，相关的MIL测试流程如图2-1所示。首先进行测试用例设计，基于测试用例在Simulink中搭建交通流模型、动力学模型等模型（模型结合），仿真环境搭建如下：

（1）依据ICW测试场景，设置交叉路口道路、红绿灯、交通标志、RSU等基础设施；

（2）依据ICW测试场景，设置近车、外部交通参与者的位置以及初始状态；

（3）设置外部光照、气象等外部影响因素；

（4）设置车辆动力学模型，其中包含车辆参数调节，如悬架、发动机、转向等相关参数；

（5）规划车辆路径，以满足ICW的场景测试需求。

搭建好的的测试场景模型不断向算法模型发送外部交通要素以及近车的相关信息数据，同时算法模型基于其算法逻辑输出预警结果，然后将算法预警结果与测试用例中的预期预警结果进行比对，检查预警算法是否能在规定的时间预警以及是否出现了误报、漏报等情况，达到验证预警算法的目的。

MIL测试系统所具备的功能优势主要有:

•  预警功能算法模型和场景模型具有良好的可读性，可直观看出预警算法的运行逻辑；

•  有利于开发人员在开发初期发现预警错误等问题，降低开发周期和开发成本；

•  高动态性，可随时调节各模型参数，方便进行修改验证。

3  软件在环测试（SIL）

软件在环测试系统通过交通流模型、车辆动力学模型等构成的功能场景模型进行所需业务数据的模拟收发，与封装好的算法代码形成一个闭环测试系统。通过SIL在早期开发过程中对软件代码进行测试，可确保在开发过程中尽早发现代码生成过程中的一些问题，例如代码生成工具的错误设置导致生成的代码有误。如图3-1所示，车联网SIL测试场景中的被测对象是基于MIL中的算法模型自动生成的代码，SIL用封装好的代码替代Simulink环境中MIL测试的算法模型，其他工作流程与MIL一致，用于C-V2X车联网功能场景正确性的验证。


图3-1 软件在环测试

如图3-2所示，在代码生成正确的情况下，同时输入相同的测试用例，理想情况下一定会得到相同的测试结果（即偏差<=阈值），即测试通过，否则，则表明代码生成过程中存在错误。SIL测试中的算法代码需实现的功能与MIL测试中的算法模型功能应该是一致的，且SIL的测试用例也需要和MIL保持一致。


图3-2 MIL与SIL功能一致性验证

4  处理器在环测试（PIL）

软件在环测试（SIL）主要验证模型自动生成的代码与模型在功能上的一致性，而SIL自动生成的代码是在PC上运行的，一般PC的浮点数处理精度会比被测终端的嵌入式处理器要高，所以可以通过PIL测试来验证测试用例在处理器上的运行结果是否与软件上的运行结果一致。

在仿真软件中搭建以ICW为例的功能场景，场景的搭建步骤及测试用例与SIL一致，被测终端通过硬件通信方式与PC建立连接，实现通信。PC将测试系统中的测试业务数据（本车在交叉路口运动状态数据和位置数据、远车在交叉路口运动状态数据和位置数据、路侧消息等外部交通要素数据）发送给被测终端，经过被测终端的预警算法处理，判断两车在交叉路口是否有潜在的碰撞风险，输出预警信息返回到PC的仿真软件中，形成完整的PIL测试过程。如图4-1所示。


图4-1 处理器在环测试

PIL测试系统的主要优势有：

•  验证编译后烧录在处理器上的可执行文件的功能逻辑与SIL中的模块功能逻辑是否一致，避免在研发后期发现可执行文件缺陷等问题；

•  可以依据可执行文件在处理器上的运行时间来优化预警算法及硬件配置。

5  硬件在环测试（HIL）

PIL系统中使用的目标硬件仅仅是被测终端的处理器，而不是完整的被测终端产品。在车联网系统应用开发过程中，需要HIL来进行集成测试，以验证软件在真实被测终端的逻辑功能。HIL系统中使用的目标硬件是完整的被测终端产品，与实时机、信号模拟器、GNSS信号发生器、V2X信号发生器以及信道模拟器等设备建立连接，模拟在真实通信环境下与其他车辆终端、路侧设备之间的数据交互，验证被测终端是否满足设计要求。

在仿真软件中搭建以ICW为例的功能场景，场景的搭建步骤及测试用例与PIL一致。将仿真软件中的卫星信号数据通过GNSS发生器发送给被测终端，用于模拟交叉路口近车的定位信息；将近车车辆状态信息通过信号模拟器发送给被测终端,用于模拟被测终端接收近车数据；将仿真软件中远车车辆信息、路侧信息、道路、天气等外部交通要素数据，通过V2X信号发生器生成V2X标准通信数据（BSM、RSI、RSM、MAP、SPAT等），经由信道模拟器发送给被测终端，其中信道模拟器模拟车联网功能场景中真实的信道环境；被测终端经过算法处理，输出预警信息或其他功能信息返回给仿真软件，与预期结果进行对比，形成完整的hil测试过程。如图5-1所示。


图5-1硬件在环测试

HIL测试系统的主要功能及优势包括：

•  测试验证被测终端在完整系统中是否满足车联网系统应用功能需求；

•  测试验证被测终端及算法在特定场景中的容错能力（如丢包、信道衰落等场景）；

•  加快车联网终端产品的研发进度，减少不必要的实车测试成本及缩短产品开发周期。

6  车辆在环测试（VIL）

车辆在环测试（VIL），主要验证被测终端集成到真实车辆环境下的功能。实车通过与实时机、GNSS信号发生器、V2X信号发生器、信道模拟器等仪器设备建立连接，模拟实车在多种场景下的功能表现是否满足设计要求。在车联网系统的开发流程中，被测终端经过HIL测试后，逻辑算法功能在真实被测终端得到了初步验证，但HIL测试的整车环境是基于动力学模型搭建的，模型与真实车辆相比，其精度存在一定差异。此时可以引入车辆在环测试（VIL）对终端设备进行更加精准的逻辑功能关系验证。

如图6-1所示，针对V2X应用功能场景测试，VIL测试系统主要包含测试系统实时机（含仿真软件）、GNSS信号发生器、V2X信号发生器、信道模拟器、集成被测终端的实车。在测试系统实时机中建立V2X功能测试场景，把仿真软件中的本车卫星定位数据通过GNSS信号发生器发送给被测终端；将车辆的转向、油门、刹车等控制信息发送给实车，使实车的转向、速度、加速度等参数能匹配仿真场景中设定的运动状态；其他车辆信息、路侧信息、道路、天气等外部交通要素数据通过V2X信号发生器生成后，以V2X标准通信数据格式（BSM，RSI、RSM、MAP、SPAT等）经信道模拟器发送给被测终端；被测终端经过算法处理，输出预警信息或其他功能信息，输出信息通过实车的HMI进行展示（触觉、视觉、听觉等），并与预期结果进行对比，形成完整的VIL测试系统。


图 6-1 车辆在环测试

VIL测试系统的主要优势包括：

•  基于实车搭建各类车联网仿真场景，能提高测试真实性和准确性；

•  能高度仿真测试各类真实车联网环境中的危险工况，降低实车道路测试的风险和测试成本；

•  可以尽早发现实车与V2X测试终端交互过程中的功能缺陷。

7  驾驶员在环测试（DIL）

驾驶员在环测试（DIL），主要是评估驾驶员的反应时间以及测试驾驶员在干预驾驶情况下的系统功能。驾驶员在环测试系统是一种通过测试系统实时机、动态驾驶员模拟舱（驾舱）、被测终端、GNSS信号发生器、信号模拟器、V2X信号发生器、信道模拟器等设备联调而成的“人-车-环境”测试系统。

在测试系统实时机中建立V2X功能测试场景，将仿真软件中的本车数据以及卫星定位数据分别通过信号模拟器和GNSS信号发生器发送给被测终端，仿真软件中的远车信息、路侧信息、道路、天气等外部交通要素数据通过V2X信号发生器生成后以V2X标准通信数据格式（BSM，RSI、RSM、MAP、SPAT等）发送给被测终端。被测终端经过算法处理，输出预警信息或其他功能信息。输出的信息通过动态驾驶员模拟舱的HMI展示出来（触觉、视觉、听觉等），驾驶员在收到相关提示或功能性消息后，采取变道、制动等措施来避免发生危险。动态驾驶模拟舱通过记录消息提醒时间与驾驶员的操作时间计算得出驾驶员反应时间及被测终端在驾驶员干预后的系统功能表现情况。


图 7-1 驾驶员在环测试

DIL测试系统的主要优势包括：

•  在台架上即可采集驾驶员的驾驶习惯信息及驾驶员反应时间；

•  可以对被测终端在开展了人工干预后的系统功能开展测试。

8  总结

C-V2X终端产品在规模化商用之前，需要在V2X功能场景的功能、性能、稳定性和鲁棒性等方面进行全面的测试验证。V模型开发流程和MBD开发方法的融合，保障了研发人员可以将更多的精力投入到算法设计和测试验证工作中，加快产品开发迭代速度的同时，也保证了产品的质量。