智能动态微协同的交通管理系统及方法与流程

1.本发明实施例涉及交通管理技术领域，尤其涉及一种智能动态微协同的交通管理系统及方法。


背景技术：

2.在城市公共交通管理系统中，经常遇到两种极端情况，一种是乘客过少导致公交车空跑，另一种是公交车过少，导致乘客在站点等待时间过长。相关方案是采用定点发车制，或者根据乘坐高峰或低谷来调整发车密度，但是这两种方案均需要乘客来适应发车时间，无法在微观上动态适应乘客需求，很大程度上限制了乘客的出行灵活性，且无法对车辆资源进行充分利用，对于部分无法调整时间的乘客而言仍然需要长时间等待。


技术实现要素：

3.本发明实施例中提供了一种智能动态微协同的交通管理系统及方法，以实现不影响公交系统发车计划的前提下，通过公交车之间的微协同配合，提高公交车辆的利用率，同时减少乘客的等候时间。
4.第一方面，本发明实施例中提供了一种智能动态微协同的交通管理系统，所述系统包括：交通管理设备以及预设协同配合线路组内不同行驶线路的公共交通设备；其中：
5.所述交通管理设备配置为，将乘客乘坐需求信息通过组播共享给协同配合线路组内的各个公共交通设备；其中所述乘客乘坐需求信息包括第一行驶线路中待协同行驶站点以及待协同行驶站点的目标乘客数量；
6.每个公共交通设备配置为，将公共交通设备自身的设备位置信息通过组播在协同配合线路组内进行共享；
7.目标公共交通设备配置为，在到达待协同行驶站点之前，依据在协同配合线路组内共享的各个公共交通设备的设备位置信息，确定所述目标公共交通设备自身是否距离待协同行驶站点最近；
8.所述目标公共交通设备还配置为，若确定距离待协同行驶站点最近，且所述目标乘客数量满足所述目标公共交通设备到达所述待协同行驶站点时的剩余乘客承载量条件，则在目标公共交通设备对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点，以在待协同行驶站点实现微协同配合载客。
9.第二方面，本发明实施例中还提供了一种智能动态微协同的交通管理方法，所述方法包括：
10.交通管理设备，将乘客乘坐需求信息通过组播共享给预设协同配合线路组内的各个公共交通设备；其中所述乘客乘坐需求信息包括第一行驶线路中待协同行驶站点以及待协同行驶站点的目标乘客数量；
11.每个公共交通设备，将公共交通设备自身的设备位置信息通过组播在协同配合线路组内进行共享；所述公共交通设备隶属于预设协同配合线路组内不同行驶线路的公共交
通设备；
12.目标公共交通设备在到达待协同行驶站点之前，依据在协同配合线路组内共享的各个公共交通设备的设备位置信息，确定所述目标公共交通设备自身是否距离待协同行驶站点最近；
13.若确定距离待协同行驶站点最近，且所述目标乘客数量满足所述目标公共交通设备到达所述待协同行驶站点时的剩余乘客承载量条件，则在目标公共交通设备对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点，以在待协同行驶站点实现微协同配合载客。
14.本发明实施例中提供了一种智能动态微协同的交通管理方案，目标公共交通设备到达待协同行驶站点之前，目标公共交通设备依据在协同配合线路组内共享的各个公共交通设备的设备位置信息，确定目标公共交通设备自身是否距离待协同行驶站点最近；进而，若目标公共交通设备确定距离待协同行驶站点最近，且目标乘客数量满足目标公共交通设备到达待协同行驶站点时的剩余乘客承载量条件，则在目标公共交通设备对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点，以在待协同行驶站点实现微协同配合载客。采用本技术方案，虽然无法完全让公交车辆适应乘客，但是可以通过公交车之间的微协同和线路显示的动态修改在微观上动态让公交车辆适应乘客需求，实现对车辆资源的充分利用，减少乘客在站点的等待时间，提高乘客的出行灵活性。
15.上述发明内容仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
16.通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
17.图1是本发明实施例中提供的一种智能动态微协同的交通管理系统的结构框图；
18.图2是本发明实施例中提供的一种智能动态微协同的交通管理方案中的行驶路线的示意图；
19.图3是本发明实施例中提供的一种智能动态微协同的交通管理系统的结构框图；
20.图4是本发明实施例中提供的一种智能动态微协同的交通管理方法的流程示意图。
具体实施方式
21.下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出与本发明相关的部分而非全部结构。
22.在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安
排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
23.图1是本发明实施例中提供的一种智能动态微协同的交通管理系统的结构框图。本技术实施例可适用于对公共交通设备进行协同管理，通过公共交通设备之间的微协同配合实现载客的情况。如图1所示，本技术实施例中的智能动态微协同的交通管理系统100，可以包括：交通管理设备110以及预设协同配合线路组内不同行驶线路的公共交通设备120。其中：
24.交通管理设备110配置为，将乘客乘坐需求信息通过组播共享给协同配合线路组内的各个公共交通设备120；其中乘客乘坐需求信息包括第一行驶线路中待协同行驶站点以及待协同行驶站点的目标乘客数量。
25.每个公共交通设备120配置为，将公共交通设备自身的设备位置信息通过组播在协同配合线路组内进行共享。
26.目标公共交通设备120配置为，在到达待协同行驶站点之前，依据在协同配合线路组内共享的各个公共交通设备120的设备位置信息，确定目标公共交通设备120自身是否距离待协同行驶站点最近。
27.目标公共交通设备120还配置为，若确定距离待协同行驶站点最近，且目标乘客数量满足目标公共交通设备到达待协同行驶站点时的剩余乘客承载量条件，则在目标公共交通设备120对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点，以在待协同行驶站点实现微协同配合载客。
28.参见图2，可预先将相互协同配合进行载客的不同行驶线路的公共交通设备配置到同一个预设协同配合线路组内，该预设协同配合线路组内各个公共交通设备通过组播共享消息，任一公共交通设备通过组播发送消息，那么该预设协同配合线路组内的其他公共交通设备均能获知到该通过组播发送消息。可选地，根据公共交通设备的行驶线路中行驶站点，可以将行驶线路中行驶站点间距离在预设距离范围内的行驶路线的公共交通设备配置到同一个预设协同配合线路组内，这样可以尽量让行驶路线接近的公共交通设备来相互配合协同，降低公共交通设备协同配合时的行驶距离。
29.参见图1与图2，预设协同配合线路组内可包括至少两种行驶线路的公共交通设备。比如“48路”与“56路”的公共交通设备，“48路”的公共交通设备的行驶线路中可以包括a1、b1、c1以及d1等行驶站点，而“56路”的公共交通设备的行驶线路中可以包括a2、b2、c2以及d2等行驶站点。当其中一条行驶路线中一个或多个行驶站点存在乘坐需求时，即当乘客需要在行驶站点上车时，可将该存在乘客乘坐需求的行驶站点作为需要公共交通设备之间进行协同载客的待协同行驶站点。此时，可将预设协同配合线路组内的各个行驶路线中待协同行驶站点所在的行驶路线，记为第一行驶路线。
30.参见图2，预设协同配合线路组内的各条行驶路线的公共交通设备进行相互协同配合时，各条行驶路线的公共交通设备上的智能处理模块均会发送igmp协议加入226.1.1.1指示的组播组，以便各个公共交通设备120可以接收交通管理设备110发送的目的地址为226.1.1.1的组播消息。交通管理设备110可以将该第一行驶路线中待协同行驶站点的乘客乘坐需求信息通过组播发送到相互协同配合的预设协同配合线路组，这样条行驶路线的公共交通设备均可获知待协同行驶站点的乘客乘坐需求信息。
31.参见图2，对于预设协同配合线路组内不同行驶线路的公共交通设备，每个公共交通设备120上的智能处理模块可以自身携带gps定位设备，可以实时获取公共交通设备120自身的设备位置信息，并将公共交通设备120自身的设备位置信息通过组播共享通告给预设协同配合线路组内各个公共交通设备120。
32.参见图2，预设协同配合线路组内的公共交通设备120上的智能处理模块不仅携带gps定位设备，同时还携带预设协同配合线路组内的各个公共交通设备的行驶线路地图。为了便于描述逻辑关系，可从各个公共交通设备中选择任意一个公共交通设备作为目标公共交通设备，这样只需要描述目标公共交通设备的执行逻辑就可阐述其他公共交通设备作为目标交通设备时的执行逻辑。目标公共交通设备按照携带的行驶线路地图以及预设协同配合线路组内各个公共交通设备(包括目标公共交通设备自身)的设备位置信息，计算预设协同配合线路组内各个公共交通设备分别到达待协同行驶站点的距离，按照计算结果可以获知哪个公共交通设备距离待协同行驶站点最近，即可获知目标公共交通设备120自身是否距离待协同行驶站点最近。
33.参见图2，以交通管理设备110共享的乘客乘坐需求信息可以包括存在乘坐需求的第一行驶线路中待协同行驶站点b2以及待协同行驶站点b2的目标乘客数量为例，正常情况下，需要“56路”的公共交通设备前往待协同行驶站点b2进行载客。但是由于预设协同配合线路组内的“48路”与“56路”等公共交通设备收到交通管理设备110共享的乘客乘坐需求信息时，其中“48路”的公共交通设备刚驶离a1站向b1站行驶，而“56路”的公共交通设备刚从始发站出发向a2站行驶。此时，“48路”与“56路”等公共交通设备可以共享各自的设备位置信息，每个公共交通设备均各自计算一下“48路”与“56路”等所有公共交通设备与待协同行驶站点b2之间的距离，判断一下自身是否距离待协同行驶站点b2最近。
34.如果目标公共交通设备120确定自身距离待协同行驶站点最近，那么倾向自身来协同配合前往待协同行驶站点进行载客，但是考虑到待协同行驶站点的目标乘客数量可能比较多，在判断目标公共交通设备距离待协同行驶站点最近的情况下，还会继续判断目标乘客数量是否能够满足目标公共交通设备到达待协同行驶站点时的剩余乘客承载量条件。如果目标公共交通设备120到达待协同行驶站点时的剩余乘客承载量大于或等于目标乘客数量，则表明目标乘客数量是能够满足目标公共交通设备到达待协同行驶站点时的剩余乘客承载量条件。
35.考虑到目标公共交通设备采用第二行驶路线，第一行驶路线与第二行驶路线属于预设协同配合线路组内不同行驶线路，因此不必局限在自己的第二行驶路线，可以选择对自己的第二行驶路线进行协同配合修改，确定并提示将第一行驶线路中待协同行驶站点添加到第二行驶路线中形成新的行驶路线，目标公共交通设备可以按照新的行驶路线协同配合前往第一行驶路线的待协同行驶站点进行载客，并提示目标公共交通设备的司机进行确认，通过在公交车之间的微协同配合修改任务路线，提高公交车辆的资源利用率，尽可能降低待协同行驶站点的乘客等待时间。
36.可以理解的是，第一行驶路线、第二行驶路线本身是一种代指，可以是指预设协同配合线路组中任意行驶路线，通过“第一”、“第二”区分不同行驶线路，用于更好的表述方案逻辑，以避免可能引起的逻辑上的冲突问题。
37.参见图1与图2，在提示将第一行驶线路中待协同行驶站点添加到第二行驶路线中
形成新的行驶路线后，如果目标公共交通设备的驾驶员同意并确认协同配合，则目标公共交通设备的智能处理模块以组播的方式发送允许微协同配合接送乘客的确认应答消息，通告其他公共交通设备不需要前往。如果在发送允许微协同配合接送乘客的确认应答消息之前，收到了来自预设协同配合线路组内其他公共交通设备的允许微协同配合接送乘客的确认应答(由于是各自计算因此有可能其他公共交通设备认为自己距离待协同行驶站点最近)，则目标公共交通设备不再发送允许微协同配合接送乘客的确认应答，并修改回原来的行驶路线计划，并提示司机确认。
38.在本实施例的一种可选方案中，参见图1，在本技术实施例提供的智能动态微协同的交通管理系统100中，目标公共交通设备120具体用于，将第一行驶线路中的待协同行驶站点以及与待协同行驶站点关联的其他行驶站点临时添加到所述目标公共交通设备对应的第二行驶线路中。
39.其中，与待协同行驶站点关联的其他行驶站点包括第一行驶线路中沿行驶前后顺序位于待协同行驶站点之后的行驶站点和/或在待协同行驶站点上车后对应下车的行驶站点。
40.一种方案是，如果“48路”公交车作为目标公共交通设备认为自己距离待协同行驶站点b2最近，则“48路”公交车的车载智能处理模块确定并提示目标公共交通设备需要前往协同行驶站点b2接送乘客，并将显示的线路由原先的“始发站
‑
a1
‑
b1
‑
c1
‑
d1
‑
终点站”修改为“始发站
‑
a1
‑
b2
‑
b1
‑
c2
‑
c1
‑
d2
‑
d1
‑
终点站”，即将第一行驶线路中沿行驶前后顺序位于待协同行驶站点之后的行驶站点全部添加到第二行驶路线。
41.另一种方案是，如果待协同行驶站点b2的乘客全部只去第一行驶路线中的行驶站点c2而不去其他行驶站点，则进行行驶路线协同配合修改时，可以将显示的线路由原先的“始发站
‑
a1
‑
b1
‑
c1
‑
d1
‑
终点站”修改为“始发站
‑
a1
‑
b2
‑
b1
‑
c2
‑
c1
‑
d1
‑
终点站”，即仅将在待协同行驶站点上车后对应下车的行驶站点添加到第二行驶路线，避免目标公共交通设备在第一行驶路线中不存在乘坐需求的行驶站点进行停留，进而减少停留时间。
42.在本实施例的一种可选方案中，参见图1，在本技术实施例提供的智能动态微协同的交通管理系统100中，交通管理设备110还配置为，响应乘客对第一行驶线路中待协同行驶站点的乘坐请求，统计待协同行驶站点的目标乘客数量以及在待协同行驶站点上车后对应下车的行驶站点。
43.对于第一行驶路线中的各个行驶站点，例如，假定第一行驶路线中的行驶站点b2聚集了一些乘客，部分需要去c2站，部分需要去d2站，此时乘客可以选择在终端应用app上向交通管理设备110提交行驶站点b2的乘坐需求。这样交通管理设备110对触发该行驶站点的乘坐需求进行统计，统计得到待协同行驶站点的目标乘客数量以及在待协同行驶站点上车后对应下车的行驶站点。交通管理设备110以组播的方式向预设协同配合线路组内不同行驶线路的公共交通设备发送乘客乘坐需求。
44.在本实施例的一种可选方案中，参见图1，在本技术实施例提供的智能动态微协同的交通管理系统100中，目标公共交通设备120还配置为，在检测到向第一行驶线路中待协同行驶站点逐步靠近时，在目标公共交通设备120上对外显示第一行驶线路的各个行驶站点，提示待协同行驶站点的乘客准备乘车。
45.目标公共交通设备120还配置为，在检测到自身位置离开第一行驶线路中待协同
行驶站点且向第二行驶线路中行驶站点靠近时，在目标公共交通设备120上对外显示第二行驶线路的各个行驶站点，提示行驶站点的乘客准备乘车。
46.参见图2，以“56路”为第一行驶路线，“48路”为目标公共交通设备的第二行驶路线为例，在目标公共交通设备快到达待协同行驶站点b2之前，目标公共交通设备120上车载的智能处理模块通过自身携带的gps定位设备发现距离待协同行驶站点b2比较接近时，将目标公共交通设备120的线路显示屏幕修改为“56路”对应的第一行驶路线，这样待协同行驶站点b2的乘客就知道可以乘坐目标公共交通设备了。
47.继续参见图2，当目标公共交通设备离开待协同行驶站点b2而接近第二行驶路线中的行驶站点b1时，目标公共交通设备通过自身携带的gps定位设备发现距离行驶站点b1车站比较接近，则将目标公共交通设备120的线路显示屏幕修改回“48路”对应的第二行驶路线。类似的，接近第一行驶路线中行驶站点c2时修改为“56路”对应的第一行驶路线，接近第二行驶路线中行驶站点c1时修改为“48路”对应的第二行驶路线，接近第一行驶路线中行驶站点d2时修改为“56路”对应的第一行驶路线，接近第二行驶路线中行驶站点d1时修改为“48路”对应的第二行驶路线，这里不再继续阐述。如此，车内乘客知道依旧可以到达想去的车站，而车外乘客也可以按照原先理解乘坐公共交通设备。
48.根据本发明实施例中提供的智能动态微协同的交通管理方案，虽然无法完全让公交车辆适应乘客，但是可以通过公交车之间的微协同和线路显示的动态修改在微观上动态让公交车辆适应乘客需求，即仅需要再公交车之间进行动态微协同，就可以实现临时执行功能更改的任务，实现对公交车辆资源的充分利用，减少乘客在站点的等待时间，提高乘客的出行灵活性。
49.在上述实施例的基础上，可选地，参见图1，在本技术实施例提供的智能动态微协同的交通管理系统100中，目标公共交通设备120还配置为，若目标乘客数量不能满足到达待协同行驶站点时的剩余乘客承载量条件，则向司机发送不能微协同配合的提示信息，并在司机确认不参与微协同配合时确定目标公共交通设备在待协同行驶站点不满足微协同配合条件。
50.参见图2，以“48路”的公共交通设备为目标公共交通设备为例，如果目标公共交通设备120处于满载状态，或者目标公共交通设备120到达待协同行驶站点时的剩余乘客承载量大于或等于目标乘客数量，或者目标公共交通设备120存在其他临时紧急任务不能前往，则表明目标乘客数量是不能够满足目标公共交通设备120到达待协同行驶站点时的剩余乘客承载量条件，在提示将第一行驶线路中待协同行驶站点添加到第二行驶路线中形成新的行驶路线进行路线修改的同时，会向司机发送不能微协同配合的提示信息，司机可以按下“不能微协同配合”的按钮确认不参与微协同配合。
51.可选地，目标公共交通设备120还配置为，在待协同行驶站点不满足微协同配合条件时，通过组播在协同配合线路组内共享携带微协同配合暂停标识的设备位置信息，向预设协同配合线路组内的其他公共交通设备提示不参与待协同行驶站点的微协同配合。
52.可选地，在确定目标公共交通设备120在待协同行驶站点不满足微协同配合条件时，例如目标公共交通设备120满载，向司机发送不能微协同配合的提示信息，司机可以及时按下“满载”按钮。此时，当目标公共交通设备120收到交通管理设备110组播发送的乘客乘坐需求信息时，目标公共交通设备120发送设备位置信息中携带“满载”标记，预设协同配
合线路组内其他公共交通设备收到消息时，就会排除满载车辆来计算距离待协同行驶站点最近的车辆。
53.在上述实施例的基础上，可选地，参见图1，在本技术实施例提供的智能动态微协同的交通管理系统100中，目标公共交通设备120还配置为，在检测到预设协同配合线路组内其他公共交通设备距离待协同行驶站点最近，且其他公共交通设备未在预设时长内确认参与待协同行驶站点的微协同配合时，延迟随机时长后通过组播在预设协同配合线路组内发送提醒消息，提示其他公共交通设备确认是否参与待协同行驶站点的微协同配合。
54.参见图1与图2，如果目标公共交通设备认为预设协同配合线路组内一公共交通设备a距离待协同行驶站点b2最近，但却迟迟未收到该公共交通设备的微协同配合的确认应答(由于各自计算有可能该公共交通设备自己不认为距离待协同行驶站点b2最近)，则延迟一段随机时长(通常预设一个时间段，比如10s，取0
‑
10s的随机值)后，以同样组播向预设协同配合线路组内发送提醒消息，共享给公共交通设备a。设置随机值的好处在于，避免同一时刻各个设备都发送消息，以组播方式提醒好处在于，最先发送提醒的公共交通设备发送提醒消息后，其他公共交通设备收到后不再重复发送提醒消息给公共交通设备a。
55.继续参见图1与图2，公共交通设备a收到提醒消息后，则公共交通设备a上智能处理模块修改行驶线路，并通过人机界面提示司机确认。如果公共交通设备a通过与司机交互，司机按下了“否决”按钮，则公共交通设备a的智能处理模块以同样组播组的方式发送否决应答，其他公共交通设备则各自计算剩余的其他公共交通设备中距离待协同行驶站点b2最近的公共交通设备，然后最近的公共交通设备负责协同配合修改线路前往待协同行驶站点，并与司机确认。
56.图3是本发明实施例中提供的一种智能动态微协同的交通管理系统的结构框图，本发明实施例在上述实施例的基础上对前述实施例进一步优化，本发明实施例可以与上述一个或者多个实施例中各个可选方案结合。如图2所示，本技术实施例中提供的智能动态微协同的交通管理系统100，可以包括：交通管理设备110、预设协同配合线路组内不同行驶线路的公共交通设备120以及与目标公共交通设备120配合同步运动的目标侦测设备。其中，
57.目标侦测设备130配置为，在目标公共交通设备120从一个行驶站点到达第一行驶线路中待协同行驶站点之前，执行基站切换侦测操作，分别收集至少两次基站切换后目标侦测设备130周围的无线局域网媒体访问控制mac地址。
58.目标侦测设备130还配置为，基于至少两次基站切换得到的无线局域网mac地址的交集，确定目标公共交通设备120到达待协同行驶站点时的剩余乘客承载量，并上报给交通管理设备110以及目标公共交通设备120。
59.目标公共交通设备120配置为，在到达待协同行驶站点之前，依据在协同配合线路组内共享的各个公共交通设备120的设备位置信息，确定所述目标公共交通设备自身是否距离待协同行驶站点最近。
60.目标公共交通设备120还配置为，若确定距离待协同行驶站点最近，且目标乘客数量满足目标公共交通设备到达所述待协同行驶站点时的剩余乘客承载量条件，则在目标公共交通设备对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点，以在待协同行驶站点实现微协同配合载客。
61.在一种可选方案，参见图2与图3，交通管理设备110配置为，将各个行驶站点的无
线网络接入点的mac地址下发给目标侦测设备。目标侦测设备130具体可配置为，在侦测到位于第一行驶线路中待协同行驶站点之前的上一个行驶站点的无线局域网mac地址的情况下，收集侦测到第一次基站切换后目标侦测设备130周围的无线局域网mac地址以及收集侦测到第预设次基站切换后所述目标侦测设备周围的无线局域网mac地址，得到分别收集至少两次基站切换后的无线局域网mac地址。
62.为了公共交通安全，要求公共交通设备上不允许站人或者尽量少站人，在此要求下，需要尽量准确的了解各个公共交通设备上乘客承载量。设定每个行驶站点都有无线网络接入点wifi ap并具有无线局域网媒体访问控制mac地址侦听功能。同时，公共交通设备的司机配置有侦测设备具备侦测功能，例如司机的手机安装有对应的app，该app驱动手机打开wifi mac地址侦听功能。
63.交通管理设备110将每个行驶站点的无线网络接入点wifi ap的无线局域网mac地址wifi mac下发给目标公共交通设备的司机的目标侦测设备。当目标侦测设备侦听到行驶站点的无线局域网mac地址后，做好无线局域网mac地址收集准备，并检测无线基站切换的动作。此时并不收集，以免收集到大量无用的无线局域网mac地址。
64.在5g时代，通常200米
‑
300米会设置一个基站，因此当目标公共交通设备行驶在从一个行驶站点到达第一行驶线路中待协同行驶站点的路上时，目标公共交通设备配合同步运动的目标侦测设备130很容易检测到基站的切换。在目标侦测设备做好无线局域网mac地址收集准备并在第一次检测到基站切换时，侦听一次周围的无线局域网mac地址，这些无线局域网mac地址包含了目标公共交通设备上的所有乘客终端设备的无线局域网mac地址，但也包含部分城市周边的其他设备的无线局域网mac地址。
65.在从一个行驶站点到达第一行驶线路中待协同行驶站点过程中，目标侦测设备130继续侦听基站切换信息，在第预设次(例如可以为第3次)基站切换时，但在到达第一行驶线路中待协同行驶站点之前，再收集一次目标侦测设备130周围的无线局域网mac地址。由于wifi信号一般只有300米，经过2个基站距离，上一次收集的非公交车上乘客的无线局域网mac地址在本次肯定收集不到。取两次收集的无线局域网mac地址集合的交集，这个交集就是目标公共交通设备上的乘客的精确无线局域网mac地址集合，即可得到目标公共交通设备到达待协同行驶站点时的剩余乘客承载量，进而目标侦测设备将此无线局域网mac地址交集上报给交通管理设备与目标公共交通设备。
66.采用上述方案，公共交通设备的司机通过目标侦测设备在基站切换时侦听获得wifimac收集时间点，并通过站点之间的两次收集，取交集获得公交车乘客的准确wifimac集合,例如第一次收集时间点选择在检测到车站wifimac之后的第一次基站切换。第二次检测时间点选择在检测到车站wifimac之后的第n次基站切换，可以精准获得目标公共交通设备到达待协同行驶站点时的剩余乘客承载量。
67.交通管理设备110在组播下发乘客乘坐需求信息时，包含相应行驶站点的目标乘客数量。而目标公共交通设备120在发送允许微协同配合接送乘客的确认应答决定时，同时还会上报目标公共交通设备到达待协同行驶站点时的剩余乘客承载量。如果剩余乘客承载量少于交通管理设备下发的待协同行驶站点的目标乘客数量，则组播组内的剩余的其他公共交通设备继续选择距离待协同行驶站点最近的公共交通设备，在待协同行驶站点承担微协同配合接送乘客职责。
68.可选地，交通管理设备110还配置为，获取目标侦测设备130上报的目标公共交通设备120到达各个行驶站点时的剩余乘客承载量，通过解析目标公共交通设备120经过每一个行驶站点的剩余乘客承载量变化得到各个行驶站点的乘客上下车情况，预估各个行驶站点的潜在乘客数量以更新目标乘客数量。
69.参见图2，为了公共交通安全，要求公共交通设备上不允许站人或者尽量少站人，在此要求下，需要尽量准确的了解各个站点的乘客需求，但是，并不是所有的乘客都会通过app来预约上下车需求，公交系统需要了解这部分未预约却有实际乘坐需求的乘客，并合理调度公交车，保证每位乘客有座位。在两个行驶站点之间收集两次无线局域网mac地址集合，取交集可以得到目标公共交通设备上的乘客的精确无线局域网mac地址集合。
70.目标侦测设备130将交集上报给交通管理设备110，交通管理设备110通过分析公共交通设备每经过一个行驶站点的无线局域网mac地址集合交集变化，就可获知每个行驶站点的乘客上车和下车情况。乘坐公共交通设备的乘客很多是上班族，上下车站点有规律，交通管理设备110通过统计分析，可以发现相当一部分无线局域网mac地址经常在一行驶站点上车(例如a1站点)，而在另一个行驶站点下车(b1站点)。交通管理设备110将此部分无线局域网mac地址下发到各自的行驶站点(站点a1)。
71.当行驶站点的无线网络接入点wifi ap在行驶站点侦听到交通管理设备110下发的这部分无线局域网mac地址之后，可以主动将侦听到这部分无线局域网mac地址上报给交通管理设备110。这样，即使这部分乘客没有主动预约上车需求，交通管理设备110也知道有这部分乘客的潜在乘坐需求，以此预估更新各个行驶站点的目标乘客数量。
72.在本实施例的一种可选方案中，参见图2与图3，目标侦测设备130配置为，在对至少两次基站切换得到的无线局域网mac地址进行交集处理之后且到达第一行驶线路中待协同行驶站点之前，若再次侦听到基站切换则将交集处理后得到的无线局域网mac地址交集提交给移动网络的注册管理服务器，以及控制注册管理服务器根据基站切换时的基站标识确定管理终端重切换表中临时记录的无线局域网mac地址。
73.相应地，目标侦测设备130还配置为，获取提交给移动网络的注册管理服务器无线局域网mac地址交集与临时记录的无线局域网mac地址之间的无线局域网mac地址交集，以得到目标公共交通设备120到达待协同行驶站点时的剩余乘客承载量。
74.其中，终端重切换表中记录有切换基站后发送一次重切换消息的支持移动网络的终端设备的无线局域网mac地址，以及在发送重切换消息时支持移动网络的终端设备切换的基站标识。
75.即使采用上面的无线局域网mac地址交集方案，同样还是会有一定的分析偏差，因为现在很多便携式电子产品均支持wifi上网，这就产生了很多虚假的乘客。为了进一步精确，这里优化如下：乘客的支持移动网络的终端设备在检测到基站切换时，需要新发送一次“重切换”消息给移动网络的注册管理服务器，消息内部携带支持移动网络的终端设备的wifi mac地址信息。移动网络的边缘基站侦听到“重切换”消息后，将自身基站id插入到消息中，然后透传给注册管理服务器。
76.注册管理服务器管理一张“重切换”表格，包含手机的imei信息、wifimac地址信息、最新的基站id、表项生成时间。比如，这个表格为每个支持移动网络的终端设备保留5个表项(可预设)。支持移动网络的终端设备切换一次基站均会发送一次“重切换”消息给注册
管理服务器，“重切换”表格里就生成一个表项。当支持移动网络的终端设备第六次切换基站需要生成第六个表项时，则支持移动网络的终端设备对应的第一个表项会被覆盖。
77.当目标侦测设备130取在行驶站点之前两次收集的无线局域网mac地址集合的交集，算出目标公共交通设备上乘客精确无线局域网mac地址集合时，等待下一个基站切换。在侦测到基站切换之后，目标侦测设备130将该无线局域网mac地址交集发送给移动网络的注册管理服务器。注册管理服务器根据最新切换的基站id查询所有的表项，并提取wifi mac地址信息，形成一个临时wifi mac地址集。将该临时wifi mac地址集与目标侦测设备提交的无线局域网mac地址交集再次取交集。由于普通的便携式电子产品虽然有wifi上网功能，但一般不会插移动卡，不会与移动网络产生交互，因此，临时记录的wifi mac地址一般都是支持移动网络的终端设备产生；又考虑到最新切换的基站id相同，因此，这个交集就是目标公共交通设备上乘客的支持移动网络的终端设备的wifi mac地址集合。
78.根据本发明实施例中提供的智能动态微协同的交通管理方案，虽然无法完全让公交车辆适应乘客，但是可以通过公交车之间的微协同和线路显示的动态修改在微观上动态让公交车辆适应乘客需求，即仅需要再公交车之间进行动态微协同，就可以实现临时执行功能更改的任务，实现对公交车辆资源的充分利用，减少乘客在站点的等待时间，提高乘客的出行灵活性。通过与移动网络的注册管理服务器配合，实现更为精确的wifimac集合，从而计算公交车上乘客数量。每个移动手机在切换基站后需要发送一次“重切换”消息，内含本手机的wifimac信息。移动网络的边缘基站收到“重切换”消息后，在消息中插入本基站的id，并透传该消息给注册管理服务器。根据最新切换的基站id获取临时wifimac集合，协助司机app获得新的更为精准的wifimac集合。
79.图4是本发明实施例中提供的一种智能动态微协同的交通管理方法的流程示意图。本技术实施例可适用于对公共交通设备进行协同管理，通过公共交通设备之间的微协同配合实现载客的情况。如图4所示，本技术实施例中的智能动态微协同的交通管理方法，可以包括以下步骤：
80.s410、交通管理设备，将乘客乘坐需求信息通过组播共享给预设协同配合线路组内的各个公共交通设备；其中所述乘客乘坐需求信息包括第一行驶线路中待协同行驶站点以及待协同行驶站点的目标乘客数量。
81.s42、每个公共交通设备，将公共交通设备自身的设备位置信息通过组播在协同配合线路组内进行共享；所述公共交通设备隶属于预设协同配合线路组内不同行驶线路的公共交通设备。
82.s430、目标公共交通设备在到达待协同行驶站点之前，依据在协同配合线路组内共享的各个公共交通设备的设备位置信息，确定所述目标公共交通设备自身是否距离待协同行驶站点最近。
83.s440、若确定距离待协同行驶站点最近，且所述目标乘客数量满足所述目标公共交通设备到达所述待协同行驶站点时的剩余乘客承载量条件，则在目标公共交通设备对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点，以在待协同行驶站点实现微协同配合载客。
84.在上述实施例的基础上，可选地，在目标公共交通设备对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点，包括：
85.将所述第一行驶线路中的待协同行驶站点以及与待协同行驶站点关联的其他行驶站点临时添加到所述目标公共交通设备对应的第二行驶线路中；
86.其中，所述与待协同行驶站点关联的其他行驶站点包括所述第一行驶线路中沿行驶前后顺序位于待协同行驶站点之后的行驶站点和/或在待协同行驶站点上车后对应下车的行驶站点。
87.在上述实施例的基础上，可选地，在目标公共交通设备对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点之后，还包括：
88.在检测到向第一行驶线路中待协同行驶站点逐步靠近时，在所述目标公共交通设备上对外显示第一行驶线路的各个行驶站点，提示待协同行驶站点的乘客准备乘车；以及，
89.在检测到自身位置离开第一行驶线路中待协同行驶站点且向第二行驶线路中行驶站点靠近时，在目标公共交通设备上对外显示第二行驶线路的各个行驶站点，提示行驶站点的乘客准备乘车。
90.在上述实施例的基础上，可选地，在目标公共交通设备对应的第二行驶线路中临时添加第一行驶线路中待协同行驶站点之前，还包括：
91.所述目标公共交通设备，在所述待协同行驶站点不满足微协同配合条件时，通过组播在协同配合线路组内共享携带微协同配合暂停标识的设备位置信息，向预设协同配合线路组内的其他公共交通设备提示不参与所述待协同行驶站点的微协同配合。
92.在上述实施例的基础上，可选地，所述方法还包括：
93.若所述目标乘客数量不能满足到达所述待协同行驶站点时的剩余乘客承载量条件，则向司机发送不能微协同配合的提示信息，并在司机确认不参与微协同配合时确定在待协同行驶站点不满足微协同配合条件。
94.在上述实施例的基础上，可选地，在确定所述目标公共交通设备自身是否距离待协同行驶站点最近之后，还包括：
95.在检测到预设协同配合线路组内其他公共交通设备距离所述待协同行驶站点最近，且所述其他公共交通设备未在预设时长内确认参与所述待协同行驶站点的微协同配合时，所述目标公共交通设备延迟随机时长后通过组播在协同配合线路组内发送提醒消息，提示所述其他公共交通设备确认是否参与待协同行驶站点的微协同配合。
96.在上述实施例的基础上，可选地，所述目标公共交通设备上设置有配合同步运动的目标侦测设备，所述方法还包括：
97.在目标公共交通设备从一个行驶站点到达第一行驶线路中待协同行驶站点之前，目标侦测设备执行基站切换侦测操作，分别收集至少两次基站切换后所述目标侦测设备周围的无线局域网媒体访问控制mac地址；以及，基于至少两次基站切换得到的无线局域网mac地址的交集，确定目标公共交通设备到达所述待协同行驶站点时的剩余乘客承载量，并上报给交通管理设备。
98.在上述实施例的基础上，可选地，收集至少两次基站切换后所述目标侦测设备周围的无线局域网媒体访问控制mac地址，包括：
99.在侦测到位于第一行驶线路中待协同行驶站点之前的上一个行驶站点的无线局域网mac地址的情况下，所述目标侦测设备收集侦测到第一次基站切换后所述目标侦测设备周围的无线局域网mac地址以及收集侦测到第预设次基站切换后所述目标侦测设备周围
的无线局域网mac地址，得到分别收集至少两次基站切换后的无线局域网mac地址。
100.在上述实施例的基础上，可选地，基于至少两次基站切换得到的无线局域网mac地址的交集，确定目标公共交通设备到达所述待协同行驶站点时的剩余乘客承载量，包括：
101.所述目标侦测设备在对至少两次基站切换得到的无线局域网mac地址进行交集处理之后且到达第一行驶线路中待协同行驶站点之前，若再次侦听到基站切换则将交集处理后得到的无线局域网mac地址交集提交给移动网络的注册管理服务器，以及控制注册管理服务器根据基站切换时的基站标识确定管理终端重切换表中临时记录的无线局域网mac地址；
102.所述目标侦测设备获取提交给移动网络的注册管理服务器无线局域网mac地址交集与临时记录的无线局域网mac地址之间的无线局域网mac地址交集，以得到目标公共交通设备到达待协同行驶站点时的剩余乘客承载量；
103.其中，所述终端重切换表中记录有切换基站后发送一次重切换消息的支持移动网络的终端设备的无线局域网mac地址，以及在发送重切换消息时支持移动网络的终端设备切换的基站标识。
104.在上述实施例的基础上，可选地，所述方法还包括：
105.所述交通管理设备获取所述目标侦测设备上报的目标公共交通设备到达各个行驶站点时的剩余乘客承载量，通过解析目标公共交通设备经过每一个行驶站点的剩余乘客承载量变化得到各个行驶站点的乘客上下车情况，预估各个行驶站点的潜在乘客数量以更新目标乘客数量。
106.在上述实施例的基础上，可选地，所述方法还包括：
107.所述交通管理设备响应乘客对第一行驶线路中待协同行驶站点的乘坐请求，统计待协同行驶站点的目标乘客数量以及在待协同行驶站点上车后对应下车的行驶站点。
108.本发明实施例中所提供的智能动态微协同的交通管理方法可应用于上述本发明任意实施例中所提供的智能动态微协同的交通管理系统，具备该智能动态微协同的交通管理系统相应的功能和有益效果，未在上述实施例中详尽描述的技术细节，具体可参见本技术任意实施例中所提供的智能动态微协同的交通管理系统。
109.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
110.注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。