SUMO的停车场仿真

github地址： https://github.com/JunXie-ZH/SUMO_Tutorial/tree/main/Parking

在SUMO中实现停车场仿真需要掌握三个部分的工作（如图1），分别为：

本章节将围绕这三部分工作对SUMO停车仿真进行详细介绍。

在SUMO中，停车设施由元素*定义，该元素定义在.add.xml*文件中。

一个元素**详细定义如下：

元素**包含的各个属性定义：

从元素**所具备的属性，我们进行了如下的总结：

对于③，在示例中，roadsideCapacity=5，**元素个数为10个，因此该停车区域的总容量为15个车位，在仿真中的可视化如图2：

停车设施的构建可以通过netedit编辑器实现，用户可以在已有道路路网的基础上，根据使用需求在合适的区域构建停车设施。

Step 1 用netedit编辑器打开路网文件(.net.xml)，在Network模式下，点击上方工具栏[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5vxOmxzn-1643112936687)(./pic/addtionalMode.png)] 打开Additional mode(或点击上方菜单栏 Edit–>Additional mode打开)。在界面左侧Additionals中，点击Additional elements的下拉菜单选择parkingArea；

Step 2 完成上一步后，即可点击某个车道构建停车区域。在SUMO中，停车区域与车道是绑定的，表示为车辆需通过该车道进入该停车区域。一个车道上可以构建多个停车区域（图4.a），也可以只构建一个停车区域（图4.b）,并可以在左侧的属性栏中的修改该停车区域的属性：如id，roadsideCapacity等，详细可见表1。

停车是出行的其中一个环节，在前面的章节中，我们介绍了如何加载车辆的出行需求，停车需求的加载则是在出行需求的基础上进行实现的。停车需求的实战加载方式如图1所示主要有三种：直接在*.rou.xml文件中编写，通过netedit编辑器加载，通过TraCI*进行动态加载。

首先可以直接在*.rou.xml文件中编写实现停车需求的加载。停车需求在.rou.xml*文件中的编写是在出行的基础上完成的，我们以一个出行（trip）为例：

我们在一个OD级的个体出行需求的基础上，添加了一个*元素，使其要停靠在一个parkingArea中。对于parkingArea*的选择：

因此，在OD级的车辆出行需求中，停车区域最好选择在终点路段，或者采用路径级车辆出行需求，为车辆指定出行路径，并在路径中间路段的停车场进行停车：

以上均是个体级的停车需求在*.rou.xml*文件中的表示，对于集计型的交通需求（OD级与路径级）同样可以加载停车需求。

OD级：

路径级：

netedit编辑器提供了可视化界面来进行停车需求的加载，但本质上还是为了生成一个*.rou.xml*文件来加载停车需求。

Step 1 如上所述，停车需求是在出行需求的基础上完成的，因此，首先在编辑器中加载好对应的出行需求，各粒度出行需求的编辑方式在前面已经介绍。假设已经创建了一个个体OD级出行需求，如下图：

Step 3 将停车需求的各项属性设置好后，点击车辆在出行过程中需要停留的停车区域（需要在出行路径上），即可给该需求添加上停车行为；

Step 4 点击保存后，打开保存好的*.rou.xml*文件，可以看到，相应的停车需求生成成功。

在实际的一些应用中，通过直接在*.rou.xml文件中编写和通过netedit编辑器来加载停车需求并不方便，这时候可以通过TraCI来动态加载出行需求和停车需求。TraCI动态加载需求的方式更加灵活，可以在每一个仿真步长中判断是否添加出行需求，且借助Python*的部分工具可以实现对车辆运动的精准监控。

我们以一个简单的例子来介绍如何通过TraCI动态加载停车需求。仿真时间一小时，每半分钟加载一个车辆出行需求，OD均为a–>e，并均在parkingArea_e停放100秒。应用的TraCI相关命令有traci.route.add、traci.vehicle.add以及traci.vehicle.setParkingAreaStop。

在停车场的实践过程中，经常会遇到这种情况：当车辆行驶到系统为其分配的停车区域时，发现已经无空闲的停车位。此时车辆是无法在该区域进行停车的，在这种情况下，车辆可以在道路上等待，直到该停车区域出现了可用的停车位。但是在现实场景中，司机会根据自己的需求与实际情况重新选择一个新的停车区域，因此，SUMO中也提供了让车辆重新选择一个停车区的功能。

针对停车区重选择行为，在SUMO中可以通过定义*中的元素来实现。该元素中会定义一组可以相互用作替代的停车区，定义在.add.xml*文件中，示例如下：

**的相关定义属性如下：

的属性主要是begin: rerouter生效的开始时间，以及end: rerouter生效的结束时间。

**的各个属性含义如下表所示：

通常而言，在以下两种情况时会触发停车的rerouter：

由于备选停车区域可能有多个，如上例，加入车辆初始的目标停车区域为parkingArea_a，若该停车区域已满，那么车辆则会根据一些因素的权重设置，选择parkingArea_b与parkingArea_c其中一个进行停车。相关的因素如下表：

SUMO会根据每个备选停车位的上述因子相对应的属性值，最终得出一个评估值 P i P_i Pi​。根据评估值的大小来决定选择哪一个备选停车位。 f j f_j fj​为第j个因子的值， α j \alpha_j αj​为第j个因子的权重。 P i = ∑ j = 0 n α j f j P_i=\sum_{j=0}^{n}\alpha_j f_j Pi​=j=0∑n​αj​fj​ 若用户未对这部分因子进行设置，则默认parking.distanceto.weight因子的权重为1，其余因子的权重均为0，即可只有parking.distanceto.weight生效。另外需要注意得是，当**元素具有属性 visible="true"时，因子的值均是准确的；若visible=“false”，各项因子的值均为一个随机数，即便一个备选停车区域停满了也很有可能被选中作为重新选择的停车区域。

用户定义这些因子的权重，可以在*元素或*元素中定义：

随着城市汽车保有量的不断增长，停车问题愈发突出，体现在：城市停车位短缺巨大，我国车位配比远低于全球平均水平；停车资源缺乏统一管理，城市停车位空置率高。为了缓解停车难问题，降低车辆寻找停车位的难度，提高整体的停车效率，相关的学者们提出了各种停车管理模型来优化停车管理，这些管理模型的验证则是需要仿真来进行。

在本章节的实例中，我们来实现一个简单的智能停车场管理系统。如下图，该系统主要包含两个模块：停车场状态感知模块与车位选择模块。感知模块我们将实现两种程度的感知系统：半感知与全感知，车位选择模块我们将对贪婪策略与随机选择策略进行实现。另外，该场景的实现将主要基于TraCI进行。

我们首先构建如图11所示的停车场路网，出入口分别有两个。

构建该路网的小技巧：可以利用netgenerate.exe工具，先构建一个方格路网，再通过删减部分路段从而构建如图11所示的停车场路网。相关命令示例：

在该路网的基础上，在部分路段中构建停车区域，如图11所示：

本场景中，分别实现了两种程度的停车场状态感知模块：半感知与全感知。

在半感知的条件下，车辆仍然可能出现抢占车位资源的现象，导致不必要的巡航时间。而在全感知的条件下，则能够真正实现高效停车。

我们定义了一个类Half_perception来实现半感知模块。此次仿真场景中我们暂时只需要感知各个停车区域的占有率，因此该类下只定义了两个函数。在有更加多元化的感知需求时，同样可以直接在该类下添加函数实现。

在有了Environment类后，感知模块的初始化函数也需要变动，以全感知为例：我们会将Environment类中的ParkingInformation输入到感知模块，在此基础上将各个区域的容量信息加入。

在此基础上，我们要实现贪婪策略将变得较为容易，在Allocation类下加入实现贪婪策略的函数Greedy_allocation。函数需输入车辆进入停车场的入口：

由此我们即可实现贪婪策略。

下面我们将整个场景的所有代码展示出来：我们在全感知条件下实现场景，每个入口的车流量为2 veh/min，停车时间为[200s,300s]中的随机数，仿真时长为一小时，车位选择策略为贪婪策略：