阅读文献Performance Gains in V2X Experiments Using Distributed Simulation in the Veins Framework

2019 IEEE

摘要

摘要：仿真模型精度的提高导致了较高的计算工作量。一般来说，并行和分布式模拟是将模拟加速到可接受的运行时的一种技术。根据仿真模型的不同，并行或分布式仿真的适用性也有所不同。这也适用于耦合的V2X模拟，其中分布式计算可能有助于大幅提高性能。在这项工作中，我们确定了关于分布式V2X模拟的机会和可能性。因此，我们描述并评估了一种方法来分发同时交互和运行的已知静脉框架的多个实例。这些实例使用基于高级架构的混合协同仿真框架进行耦合。随着交通负荷的增加，可以测量出更高的加速速度

introduction

在模拟车辆通信时，仿真性能是关键之一。车辆与其他车辆的环境和空中的通信称为V2X（vehicle-to-everything）通信。为了通过网络通信仿真来实现真实的结果，需要模拟物理层上的每个传输包，这需要大量的计算工作。然而，这允许调查相关的无线电传输特性，如延迟或信道负载。通常，无线电传输的模拟是通过离散事件模拟(DES)与OMNeT++等工具依次完成的。巨大的计算复杂度和顺序计算导致了可行性问题，特别是当在更广泛的模拟时间框架内模拟大型场景时。

减少计算时间的一种方法是使用并行化。当使用DES作为建模范例时，并行化并不简单。在没有具体知识的情况下，每个事件都可能安排另一个事件，这些事件可能会破坏其他不知道它的并行运行的模拟线程的因果关系。使用传统的方法，防止错误的通信开销和等待时间可能超过并行化可能获得的性能增益。使用乐观的方法，通信开销和减少错误的努力可能会导致同样的问题.虽然在协同模拟设置中实现回滚通常是一项困难的任务，但在某些特定情况下，甚至可以想象回滚是根本不可能的，而且整个模拟将出现错误（例如，当模拟与真实世界的组件或数据提要交互时） 

并不是车辆通信领域的所有用例都允许如下所述的设置，因为通常没有可以相互独立模拟的尖锐的分区区域。相反，每个节点都可能会影响任何其他节点。即使它不太可能，而且使用起来很可疑，汽车也有可能广播一个信息，从一个汽车转发到另一个汽车，并跳过整个模拟世界。

然而，也有一些类型的问题，根据它们的本质，允许分离和分布式的治疗而不依赖。在实验允许分区的情况下，我们可以通过分布式模拟假设性能增益和缩放的可能性

本文旨在描述两种不同的同步机制组合的问题，即保守的高级体系结构(HLA)时间同步机制和veins连接SUMO和OMNeT++的原理，以及如何在没有死锁的情况下实现两者的结合。这种无死锁组合是必要的，以便能够以我们提出的方式在HLA上的多个Veins本文的结构如下：我们命名了相关的工作，展示了如何在命名的上下文中协调一个分布式模拟，并提出了这个问题和我们的解决方法，通过分布多个veins实例来加速V2X模拟。最后，我们评估性能收益，得出结论，并给出对未来方向的展望。

related work

在给出了关于所使用的工具和HLA的一些基本信息之后，我们概述了关于流量分布和通信模拟的相关工作。

Veins[15]是一个著名的模拟V2X通信的工具包。它结合了OMNeT++[19]和SUMO[11]。SUMO是一个微观交通模拟器，每个交通参与者都由一个实体表示，该实体具有速度、位置和目的地等属性。汽车跟驰模型用于计算行为。因此，根据期望的速度和先前车辆的速度和距离来计算车辆的加速度。OMNeT++是一个离散的事件模拟器，具有对网络流量的模拟能力并被广泛用于此目的。veins扩展了其特性，能够模拟802.11p通信，这是基于蜂窝的方法，关于车辆通信[18]的事实上的标准。为了实现这一点，Veins提供了一个针对802.11p的协议堆栈，并在TRACI上将单个SUMO和单个OMNeT++实例耦合。这允许在OMNeT++中拥有移动的对象和建模车辆通信。TraCI是SUMO的基于TCP的API，是在[20]中引入的。高层架构(HLA)是一个中间件概念，它支持分布式模拟[9]。虽然参与的模拟工具集称为联合，但每个参与者称为联合者。运行时基础设施(RTI)负责时间管理并协调联邦之间的数据交换。为了实现时间同步，想要继续发送一个TimeAdvanceRequest (TAR)并等待，直到他们收到一个time advancer grant (TAG)。当每个参与的联邦准备至少继续到T时，将时间T的TAG交给请求联邦.

根据[17]，车辆自设网络(VANET)仿真中最重要的问题是模拟车辆的运动。另一个挑战是无线通信的信道模型。这两个主要问题都可以通过veins使用SUMO和OMNeT++来解决。所包括的通道模型例如允许考虑物理方面，如障碍阴影[16]。最近的一项工作描述了如何将默认的二维信道传播模型扩展到三维[2]，这提高了精度，但也提高了网络模拟的计算努力。

对分布式和并行模拟的研究仍然是[7]的兴趣，并从根本上受到[6]和[4]的影响。此外，关于交通模拟的分布还有更具体的工作。在[3]中以dSUMO提出了第一种分发SUMO的方法。在[1]中，也使用了类似的方法来划分道路网，但在决策中考虑了交通参数（如密度）。

在[10]中研究了通过并行I/O操作来加速OMNeT++。VANET模拟的实时性能约束激发了在[14]中使用多解析方法。这种方法目前只考虑了流量仿真领域。根据我们的经验，这并不能解决大型VANET场景的性能问题。在这种情况下，一个详细的网络模拟提供了瓶颈，而不是流量模拟。

虽然研究是在并行网络模拟理论[12]和实践[13]，据我们所知，没有框架，允许分布式V2X模拟一方面，可以很容易地被研究人员另一方面来加快他们的实验。在[8]中描述了一个使用HLA概念结合不同模拟工具的框架。它支持多层次和多域模拟设置的组合。从交通域查看，街道网络的道路可以定义为要在这些点划分场景的边界链接,每个分区将由一个单独的流量模拟实例进行模拟，例如，SUMO，这些实例了解其对道路网络的负责部分，并采用进出车辆或通过规定的边界链接发送出口车辆。

本文的贡献是通过扩展框架的多领域方面，通过添加veins框架，从而扩展到一个通信领域。这使得分布式V2X模拟能够由研究人员通过所解决的框架的GUI轻松地设置和启动，

DISTRIBUTING V2X SIMULATIONS

 在相互连接的多个物理资源上分发运行模拟应该是可能的。因此，这种方法使用了三种通信类型来运行分布式静脉模拟。首先，使用每个分散的工作进程和仿真控制器之间的低级TCP连接，

• 向控制器表明工作任务的能力。
• 请求向工作器执行任务
• 仿真完成后，将结果发送给控制器

其次，利用HLA作为中间件运行仿真

• 同步联合的时间
• 协同交通领域内的数据交换

第三，保留了脉络实例中已有的信息交换方法 

• 在关联的SUMO实例和关联的OMNeT++实例之间交换数据
• 最小化通信延迟和模拟总线拥塞(因为这个类中的大多数信息与其他实例无关)

在下文中，将介绍所用工具的相关特征，并简要介绍工作器分布概念。之后，我们将展示如何在不陷入死锁的情况下结合HLA和V EIN的通信和同步机制。

A，工具

1）SUMO 由于SUMO是一种微观交通模拟工具，因此可以观察和修改每辆车的行为。自版本0.31起，SUMO允许通过TraCI连接多个客户端。 在SUMO开始之前，需要知道客户的数量。在第一个模拟步骤完成之前，每个客户端都需要连接到SUMO并设置其订单id。当模拟开始时，具有最低订单id的连接实例能够执行API调用，直到实例请求下一个模拟步骤。然后，轮到下一个客户端，直到每个连接的客户端都请求下一个模拟步骤。最后，SUMO是继续一个时间步骤和程序再次开始。在这种模式下，不可能让SUMO运行到任意的时间步，因为经典的方式是可能的。相反，时间步长在启动时设置并固定。

2) Veins,由于Veins通过连接OMNeT和SUMO来实现车辆通信的模拟，此连接的主要目的是同步两个模拟，并从SUMO到OMNeT获取车辆位置的更新。有了这些信息，无线通信可以在OMNeT上进行模拟。用户可以在此基础上编写应用程序，这些应用程序可以通过TraCI将数据传输回SUMO，从而影响车辆的行为。

一个示例性应用是Green Light Optimal Speed Advisory（GLOSA）应用的评估，其中车辆可以接收信号灯相位计时的信息，并调整自己的速度以减少不必要的加速和减速。因此，车辆的当前位置从SUMO发送到OMNeT。如果车辆接收到来自交通信号灯的广播消息，OMNeT将根据此信息（以及其他参数，如道路拓扑）进行计算。在这种情况下，车辆的GLOSA应用程序被触发，可以选择操作（例如，稍微降低速度）。最后，将选定的动作返回到交通模拟中，并可测量算法的效果和要评估的参数

B.Drones

为了在不同的节点上部署仿真工具实例，我们使用被称为无人机的独立工作人员实现了这个概念。该方法使实例能够以协调的方式启动，并将其联邦成员连接到正确的HLA联邦。我们首先描述无人机，然后描述模拟控制器一侧的无人机池。

一旦启动，无人机将尝试通过TCP连接到模拟控制器，并反复宣布其可用性。公告包含其当前侦听主机地址和端口。同时，无人机监听传入的任务请求。同时，无人机监听传入的任务请求。任务请求由以下部分组成：GlobalTask、FederationName、FederateName、SimulationTool和ConfigFile。当收到并接受任务请求时，将向发送方发送肯定响应。然后，任务在任务列表中调度，并在运行无人机的主机上生成。通过这种方式，无人机能够同时产生多个任务。仅生成模拟工具是不够的。为了能够与其他相关的仿真实例通信，需要一个联邦成员在工具和HLA联邦之间进行调解。

因此，任务的FederationName和FederateName用于生成能够连接到关联HLA联邦的联邦成员。通过给定的仿真工具和配置文件，联邦成员能够生成该工具并基于HLA的时间管理控制仿真运行。仿真完成后，仿真结果将发送回仿真控制器，并以GlobalTaskId作为参考

另一方面，模拟控制器通过监听传入的无人机通知来管理可用无人机池。当收到未知无人机通知时，其地址与无人机主机上运行实例的计数器一起存储。当用户请求开始模拟时，控制器为每个所需的工具实例创建一个任务，并将其分配给可用的无人机。为了实现简单的负载平衡，此分配基于无人机的运行实例计数器。最后，任务请求通过TCP发送到指定的无人机。如果一切正常，每架无人机都会发出接收任务的信号。如果控制器未收到确认，则将任务重新分配给另一无人机。

C.信息流和时间同步

如前所述，现有框架通过HLA连接不同的工具。我们认为SUMO和OMNeT的过度数据交换可能会阻塞HLA总线，而这种信息交换方式不会带来任何必要的优势。因此，Veins实例中的经典信息交换应该保持不变。然而，显然需要在形成一个分布式V2X场景的多个V EIN实例之间进行同步和通信。否则，时钟将漂移，车辆无法正确地从一个V EIN实例转移到另一个V EIN实例。因此，我们从这两个世界中取其精华。我们将OMNeT和HLA中间件连接起来，为配置参数提供时间管理和数据交换功能。相应的包装器集成在OMNeT顶部的Veins逻辑中。此外，我们将SUMO和HLA中间件连接起来，用于时间管理、配置参数交换，特别是实例之间的流量传输。

此外，我们保留了OMNeT和SUMO之间现有的veins通信模型，用于更新节点的位置。通过这种方式，任何其他联邦成员都不感兴趣的数据直接在OMNeT和SUMO之间传输，而全局信息（如定时数据）通过联邦总线交换 

目前，该框架通过定期重复以下任务，按一个时间步长到一个时间步长进行，从而在分布式交通仿真中实现一致性：

• TimeAdvanceRequest(T)
  • –ReceiveInteractionsUntil(T−S)
  • –AdoptAt(T−S)
  • –TimeAdvanceGrant(T)
• ProcessUpdates
• SumoStep(T)
• CreateUpdates
  • –CheckBorders(T)
  • –TransferCars(T)

如第二节所述，分区之间的穿越是通过标记为边界链接的道路实现的。在一个时间提前到时间T被请求并且恰好在提前被批准之前，可能来自其他实例的交互将被接收。这些都有时间戳。此时，SUMO的模拟时间仍为atT−S。当通过HLA交互接收到进入的车辆信息时，接收的SUMO实例被迫立即采用一辆汽车。默认情况下，这将在下一个模拟步骤延迟发生。与非分布式运行相比，延迟采用会导致不正确的仿真状态

在使用时间步长S继续SUMO之后，会检查实例自己的边界。如果出站边界链接上有新的车辆，则发布HLA交互来释放和转移受影响的车辆到邻近的实例。图2的蓝色区域(A)描述了带有一个Veins和另一个SUMO实例的一个循环的摘录。在这个例子中，一个SUMO (2SUMOWrapper)和一个V eins (1Veins)进程(即另一个SUMO和一个OMNeT++实例)通过一个HLA联邦连接。

                                        图2，导致死锁的信息和同步流

 在现有架构的基础上，采用当前的V eins流程，不进行修改是无法工作的。由于SumoStep()和TAR()是两个相互竞争的同步组件，因此该机制会陷入死锁。从图2中可以看出这一点。红色区域(C)从未到达。这是SUMO在第III-A1小节中提出的多客户端概念的结果。对于每个仿真时间步，每个实例只能一个接一个地进行TraCI调用。每个实例都必须通过调用SumoStep()来表示它想继续执行下一个时间步骤，然后下一个实例就可以执行它对当前时间步骤的调用。

考虑到这一点，死锁可以在图2黄色区域(B)的前三条生命线中识别出来。1o++ Fed调用SumoStep(T)， 1SUMOFed调用SumoStep(T)。然后，1O++Fed与1SUMO仿真在TraCI上进行交互，然后对HLA RTI进行TAR(T+S)。同时，1SUMOFed希望与1SUMO模拟进行交互，但必须等待1O++Fed完成，这将由1O++Fed的SumoStep(T+S)调用进行信号传递。另一方面，1O++Fed在调用SumoStep(T+S)之前需要收到TAG(T+S)。这是永远不会发生的，因为1SUMOFed将不得不调用TAR(T+S)，而且已知1SUMOFed在执行TAR(T+S)之前被卡在相互作用阶段。 

死锁问题的解决方法如图3所示。在Veins的OMNeT++部分注入的联邦包装器必须改变现有的交互和时间同步顺序。首先与仿真进行交互，然后调用SumoStep(T)。此时，必须确保在SumoStep(T)和TAR(T+S)调用之间没有进行Vein中的TraCI调用。这尤其适用于处理在SumoStep()调用后接收到的订阅。这样，SUMO连接器和OMNeT++连接器的逻辑就扭曲了‘

 IV. EVALUATION

我们通过模拟一个带有36个配备了智能交通灯(ITLs)的9x9曼哈顿网格道路网络来评估我们方法的性能收益。模拟是在运行i7-2600 cpu的3.40 GHz专用桌面计算机上进行的，其中Ubuntu 18.04.3 LTS作为操作系统运行，拥有四个CPU核，一个veins实例的单线程SUMO和OMNeT++进程可以在自己的物理核上运行。每个仿真工具都使用单独的机器。我们使用了在第III-B小节中描述的任务分配和编排过程。仿真控制器在另外一台机器上运行，在四个veins实例和一个单独的SUMO实例耦合在一起的情况下，最多可以连接6台计算机。这些计算机被直接插入千兆以太网交换机

使用PoRTIco[21]作为开源HLA实现。每个实验的结果都是通过运行每个模拟场景的7次重复并平均性能测量得到的。所使用的街道路线图如图1所示 

为了对itl建模，我们实现了一个简单的GLOSA[5]应用程序。所有的itl都在不断发送信号数据，每辆车都运行一个接收应用程序，接收这些数据并对其做出反应。在评估场景中，itl广播它们的id、当前信号阶段和每个受控链路当前阶段的剩余时间。这是做20赫兹和每波短消息。根据时间信息、itl的位置知识以及车辆的位置和速度，进入车辆的逻辑可以决定车速调整是否有助于避免在路口停车。

汽车定期从四面八方进入地图，直接穿过地图。对于流量模拟，该场景运行的步长分别为100 ms和1000 ms。通过这个设置，我们模拟了360秒的道路交通，总共产生了1453辆车。在模拟的时间框架内，没有任何车辆能够直接通过地图完成行程。因此，我们可以观察到加速效应与负载的相关性。为了获得一个基本的事实，该场景使用一个经典的veins 4.6实例进行模拟，只进行了很少的修改，当然，没有任何分布特性。    

     

此外，还对该场景进行了分布式仿真。这是通过一个纯SUMO实例与一个(1v1)，两个(2v1)和四个(4v1) Veins实例分别耦合完成的。因此，Veins的实现已经如本文所述进行了修改，使静脉能够从其他实例发送和接收汽车，并在HLA联邦中同步运行。如入门文章中所述，我们的方法适用于不需要在分区边界之间进行无线电通信的合适场景。由于采用单向通信，干扰距离小于itl到系统边界的距离，因此选择的GLOSA场景适合分布式。这意味着没有无线电消息将跨逻辑分区，因此在理论上可以假定与非分布式运行相同的结果。4v1设置的分区如图1所示。

评价结果见表1、表2、图4、图5。为了便于区分步长为100ms时实验的不同曲线，我们对模拟结果采用了跨度为1%的局部加权散点图平滑(图6)。

对于表I和表II, 7个重复的性能测量值是在整个模拟时间360秒内的平均值。在100毫秒的情况下，只有4v1拓扑比经典运行速度快，而在1000毫秒的情况下，可以观察到2v1设置的性能提高。

看看图4和图6中步长为100 ms的场景，可以注意到，在低负载(0 s 150 s的模拟时间)下，经典静脉的运行速度比任何其他拓扑都快。这是可以理解的，因为HLA的时间管理开销是固定的，交通灯和车辆之间的通信量也相对较低。活动车辆的数量在右边的y轴上标记。即使没有活动车辆或计划的通信事件，时间开销仍然保持不变。

 在[8]中，仅一次提前周期的平均持续时间为102 ms。这个数字可以在这次评估中再次发现。关于每个仿真步骤的计算时间，几乎每个分布式仿真步骤都有一个大约100毫秒的下限。随着越来越多的车辆向itl前进，复杂性不断增加，这种开销被计算工作所克服，性能也明显提高。除了周围的SUMO实例覆盖了路线图的外部部分，1v1设置并没有很好的机会通过分发来加快静脉部分，因此大多比经典运行要慢。

对于这两种步长，在经典的vein和1v1运行中可以观察到类似的峰值。由于峰值在不同的复制上持续存在，它们可能是由道路交通模式造成的。在这些点上，车辆和ITL算法的结果可能会超载一个瓶颈。除了小的峰值，在1000 ms场景下，静脉和1v1运行在320 s时的陡升是显著的，而其他运行的性能保持稳定。

 1000 ms步骤少,因此交通之间的相互作用和通信模拟,可以清楚的看到性能的2 v1和4 v1(图5),仿真时间350年代和360年代之间,活跃的汽车的数量超过1400,在veins中一个仿真步骤的时间是4269.7毫秒,7286.3毫秒,958.4毫秒、1v1、2v1、4v1的平均时间分别为517.3 ms。

为了验证，我们提取了每辆车和每一个模拟时间步长为1000 ms的4v1场景的浮动车数据。我们将其与经典的V eins参考运行的数据进行了比较。不幸的是，数据集并不完全匹配。然而，当比较每辆车在每个模拟时间步长的位置时，误差为10厘米，我们最终发现在1453次行程中只有24次失误，专注于第一眼看到的性能提升，这就足够了，特别是在整个比赛中有大量的主动赛车。对于未来的应用，需要调查这些不一致的原因。 

五、总结与今后工作

我们已经能够证明，可以对veins模拟出一个适当的V2X模型进行分布式仿真，这种分布式仿真可以显著提高性能，并为大规模场景提供了可扩展性。

即使验证的结果让人满意，但是与未分配的仿真运行相比，为了将来的应用需要实现模拟状态给完全一致性，因此必须要确定消除某些车辆的位置最小偏差的原因。

在这种情况之下，我们的方法只有能够将场景道路网络的不同区域分割为独立的通信岛时才有效额，如第四节中的GLOSA场景中所做的一样，不允许任何消息跨越系统边界，否则信息将丢失而导致不一致。

除了在GLOSA场景外，该约束并不限制分布式veins仿真在一系列的其他用例上的应用（如，路侧单元在可变时间段广播可确定的信息，，如路线指示、拥堵警告或交通计数时，对交通状况影响的调查）换句话说，如果存在无线电信息无法到达的空间区域，则该方法是适当的。随后，这些区域非常适合作为矿脉实例之间的边界。特别是，如果真实城市需要模拟这种V2X问题，那么这些无通信区域很有可能存在。随着场景（和分区）大小的增加，性能收益也会增加。

然而，也存在着一些有趣的V2X问题，我们的方法无法适用于解决这些问题，特别是当两个移动车辆之间的通信。因此，研究在系统边界上分发虚拟短消息的可行性是很有诱惑力的。另一个有趣的步骤是在V2X仿真中自动检测独立和可分离的区域，创建一个在线特别模拟分布。具有回滚功能的乐观方法可能是实现这一点的第一步。然后可以替换在模拟开始之前定义一次配电拓扑的步骤。如果实现了可分离区域的识别，则可以改进负载平衡并进一步提高性能。