CN115131964B - 隧道车流量感知系统 - Google Patents

Abstract

本申请涉及一种隧道车流量感知系统，包括WIFI探针设备和服务器；WIFI探针设备布置于隧道内，实时探测周围环境的WIFI信号并上传至服务器，服务器对WIFI信号进行数据处理用于表征隧道内的车流数据，并将车流数据反馈给车辆；服务器的数据处理包括：WIFI探针设备沿隧道布置有n个，第i个WIFI探针设备探测到的WIFI信号作为集合A，则第i‑1或i+1个WIFI探针设备探测到的WIFI信号作为集合B，通过集合A及集合B中的数组判断WiFi设备的移动方向，选取单向移动的WIFI信号组成集合C，对集合C进行去重或合并得到车流数据，本申请可为视距不良的后方来车提供驾驶决策支持，在保证高可靠度、考虑建设运营成本约束的前提下提高隧道运行效率和安全性。

Description

隧道车流量感知系统

技术领域

本申请涉及数据分析领域，具体涉及一种隧道车流量感知系统。

背景技术

在隧道交通事故中，机动车追尾是发生最多的交通事故形态，占60.1％；单车撞壁次之，占20.1％，而造成机动车追尾和单车撞壁的主要原因之一则是驾驶员超速行驶。

在部分长大隧道中，主要存在如下问题：

(1)由于光照条件不良造成亮度低，同时存在曲线段造成隧道壁的遮挡；

(2)目前在智慧公路交通状态感知中采用较多的雷视一体技术(即毫米波雷达融合视频检测技术)需要在较短距离布设较多感知设备及边缘计算设备(MEC用于雷达数据和视频数据的融合)，且隧道壁的反射效应使得雷达成像噪点增多，存在建设运营成本高、系统可靠度低等问题，在现阶段难以大面积成熟化推广。

发明内容

本申请的目的在于克服现有技术的不足，提供一种隧道车流量感知系统，考虑车辆驾驶员及乘员均携带手机，且WiFi或蓝牙设备开启处于较大概率。本项目针对上述问题，拟采用低成本、高可靠度的WiFi探针技术，借助采集各车辆内的WiFi信号，实现小空间粒度的交通流运行特征参数(包括各小区间段速度、密度、流量、各车车头时距及车头间距、速度稠密度等)采集。同时应用后台算法计算各小区段车辆数、聚集特征，为视距不良的后方来车提供驾驶决策支持，在保证高可靠度、考虑建设运营成本约束的前提下提高隧道运行效率和安全性。

本申请的目的是通过以下技术方案来实现的：

一种隧道车流量感知系统，包括WiFi探针设备和服务器；

所述WiFi探针设备布置于隧道内，实时探测周围环境的WiFi信号并上传至服务器，所述服务器对WiFi信号进行数据处理用于表征隧道内的车流数据，并将车流数据反馈给车辆；

所述服务器的数据处理包括：

所述WiFi探针设备沿隧道布置有n个，第i个WiFi探针设备探测到的WiFi信号作为集合A，则第i-1或1+1个WIFI探针设备探测到的WiFi信号作为集合B，通过集合A及集合 B中的数组判断WiFi设备的移动方向，选取单向移动的WiFi信号组成集合C，对所述集合 C进行去重或合并得到所述所述车流数据。

WiFi探针设备其实就是一个无线接入点，不断的向四周广播发送Beacon帧，通知附近的WiFi设备；而一般的WiFi设备例如手机，平板电脑等，也不停的发送Probe帧，去寻找附近可用的无线接入点。WiFi探针设备被布置在隧道内，实时探知周围环境的WiFi信息，一定的频率采取HTTP协议，发送POST请求，在建立HTTP三次“握手”的基础之上，后端服务器主动接收数据，通过服务器进行处理，再反馈给前端，通过OLED屏以及语音反馈给后续车辆，方便后续车辆对堵车等情况作出应对。

进一步的，所述WiFi信号包括车辆WiFi设备的ID信息及通过时刻，所述通过时刻是指对应WiFi探针设备探测到WiFi设备的时刻。

进一步的，所述服务器的去重或合并包括：

在所述集合C中，剔除通过时刻相同的WiFi设备的ID，仅保留一个用于表征车辆数据，得到集合D；

或，将通过时刻相同的WiFi设备的ID合并为一个，得到集合D。

进一步的，所述服务器的去重或合并包括：

在隧道口连续布置多个WiFi探针设备，在某一时刻t₁，第一个WiFi探针设备识别到若干Mac号，记为s₁：

s₁＝{a₁，a₂，...，a_n；b₁，b₂，...b_n；c₁，c₂，...，c_n；...}

在(t₁+Δt₁)时刻，其中Δt为某车从第一个WiFi探针设备到第二个WiFi探针设备所需要的时间，在第二个WiFi探针设备处又识别到若干Mac号记为s₂：

s₂＝{d₁，d₂，...，d_n；e₁，e₂，...，e_n；f₁，f₂，...，f_n；...}

取s₁∩s₂，s记为同一类Mac号，即记为同一辆车内的Mac号；

第三个WiFi探针设备在(t₁+Δt₁+Δt₂)时刻识别到若干Mac号：

s₃＝{m₁，m₂，...，m_n；n₁，n₂，...，n_n；k₁，k₂，...，k_n；...}

s∩s₃＝s_g，s_g记为同一类Mac号，s_g即所述集合D。

进一步的，所述WiFi探针设备在隧道口连续布置至少三个。

进一步的，所述服务器基于所述集合D中同一WiFi设备的ID通过任意两WiFi探针设备的时刻差，以及该任意两WiFi探针设备之间的布置间距测得表征该WiFi设备的ID所对应的车辆的平均速度。

进一步的，所述车流数据包括表征车辆信息的集合D以及车辆的平均速度。

进一步的，所述WiFi探针设备与服务器之间采用HTTP协议，发送POST请求，在建立HTTP三次“握手”的基础之上，服务器主动接收数据。

进一步的，所述WiFi探针设备探测过程中遍历WiFi的每一个信道进行扫描，每次扫描 1-2轮或更多。

本申请的有益效果是：本申请结合智慧道路技术的发展阶段，面向车路协同的实用化目标，基于隧道视距不良的特征，针对目前隧道内精细化感知所采用的毫米波雷达、视频监控的高成本及覆盖面低的问题，通过在隧道内布设WiFi探针设备，利用后台相关平台算法，实现隧道内每辆车的位置、小区间速度、车头间距、车头时距的精细化感知，从而识别隧道内交通异常事件，为后方车辆提供驾驶决策信息。本申请可在低成本的前提下实现对隧道内车辆的高可靠度精细化感知。

附图说明

图1为本申请实施例的原理框图。

具体实施方式

下面结合具体实施例进一步详细描述本申请的技术方案，但本申请的保护范围不局限于以下所述。

考虑车辆驾驶员及乘员均携带手机，且WiFi或蓝牙设备开启处于较大概率。本申请针对上述问题，拟采用低成本、高可靠度的WiFi探针技术，借助采集各车辆内的WiFi信号，实现小空间粒度的交通流运行特征参数(包括各小区间段速度、密度、流量、各车车头时距及车头间距、速度稠密度等)采集。同时应用后台算法计算各小区段车辆数、聚集特征，为视距不良的后方来车提供驾驶决策支持，在保证高可靠度、考虑建设运营成本约束的前提下提高隧道运行效率和安全性。

参考图1所示，一种隧道车流量感知系统，包括WiFi探针设备100和服务器200以及显示设备300；WiFi探针设备100布置于隧道内，实时探测周围环境的WiFi信号并上传至服务器200，服务器200对WiFi信号进行数据处理用于表征隧道内的车流数据，并将车流数据反馈给车辆；服务器200的数据处理包括：WiFi探针设备100沿隧道布置有n个，第i个WiFi探针设备100探测到的WiFi信号作为集合A，则第i-1或1+1个WiFi探针设备100探测到的WiFi信号作为集合B，通过集合A及集合B中的数组判断WiFi设备的移动方向，选取单向移动的WiFi信号组成集合C，对集合C进行去重或合并得到车流数据。可选的，在一些实施例中，WiFi信号包括车辆WiFi设备的ID信息及通过时刻，通过时刻是指对应WiFi探针设备100探测到WiFi设备的时刻，显示设备300设置在隧道入口侧，用于实时展示隧道内的车辆情况。

更为具体的是，将隧道按照一定距离布设n个WiFi探针，设隧道进口处为第1个WiFi 探针，隧道出口处为第n个WiFi探针，其中n与隧道长度及隧道设计时速有关；通过部署于隧道中的WiFi探针采集行驶的车辆上WiFi设备的ID信息及通过时刻。当第i(0≤i≤n)个 WiFi探针采集到车辆信息后，并将探测到的ID信息及通过时刻制成集合，记为集合A；与WiFi探针i相邻的WiFi探针为WiFi探针i-1或WiFi探针i+1，WiFi探针i-1或WiFi探针i+1 探测到的ID信息及通过时刻组成集合，记为集合B；通过集合A及集合B中的数组判断WiFi 设备的移动方向，选取单向移动的WiFi设备的ID信息及通过时刻组成新的集合，记为集合 C；在所述集合C中，剔除同一个车辆上的WiFi设备的ID信息及通过时刻数组，得到集合 D；通过某车辆通过相邻两个WiFi探针的时刻t₁与t₂，通过两个WiFi探针的距离与通过时刻的差值计算出通过第二个WiFi探针的平均行程车速；通过计算部署在隧道上的每个WiFi探针之间的道路通行速度，组合得到整个隧道的通行速度，所述通行速度即车辆的通行速度；通过计算出的通行速度与隧道的限速进行比较，如果超速，后台服务器200发布指令通过语音以及显示屏来进行提醒，经过计算，当时间占有率增加，车流量降低时，使LED屏幕上显示出“注意行驶安全”或“您已超速”字样，提醒驾驶员减速，同时进行语音提醒。同时在视线不良路段或有必要的关键节点设置可显示隧道下游车辆实时分布的模拟图，提供给上游车辆供车辆驾驶人员决策。

可选的，在一些实施例中，服务器200的去重或合并包括：

在集合C中，剔除通过时刻相同的WiFi设备的ID，仅保留一个用于表征车辆数据，得到集合D；

或，将通过时刻相同的WiFi设备的ID合并为一个，得到集合D。

可选的，在一些实施例中，服务器200的去重或合并包括：

在隧道口连续布置多个WiFi探针设备100，在某一时刻t₁，第一个WiFi探针设备100识别到若干Mac号，记为s₁：

s₁{a₁，a₂，...，a_n；b₁，b₂，...b_n；c₁，c₂，...，c_n；...}

在(t₁+Δt₁)时刻，其中Δt为某车从第一个WiFi探针设备100到第二个WiFi探针设备100 所需要的时间，在第二个WiFi探针设备100处又识别到若干Mac号记为s₂：

s₂＝{d₁，d₂，...，d_n；e₁，e₂，...，e_n；f₁，f₂，...，f_n；...}

取s₁∩s₂，s记为同一类Mac号，即记为同一辆车内的Mac号；

第三个WiFi探针设备100在(t₁+Δt₁+Δt₂)时刻识别到若干Mac号：

s₃＝{m₁，m₂，...，m_n；n₁，n₂，...，n_n；k₁，k₂，...，k_n；...}

s∩s₃＝s_g，s_g记为同一类Mac号，s_g即集合D。

可选的，在一些实施例中，WiFi探针设备100在隧道口连续布置至少三个。

可选的，在一些实施例中，服务器200基于集合D中同一WiFi设备的ID通过任意两WiFi探针设备100的时刻差，以及该任意两WiFi探针设备100之间的布置间距测得表征该WiFi设备的ID所对应的车辆的平均速度。

可选的，在一些实施例中，车流数据包括表征车辆信息的集合D以及车辆的平均速度。

查阅相关规范可知(详见表1和表2)，如果使用WiFi探针进行探测，应在半径30米以内采集效果较好(π×30×30＝2800，即2800平米的覆盖面积)，如果地势空旷则能达到50—100米，极限距离为1000米，能够较好的覆盖隧道；WiFi共有13个信道，因为手机与路由器的信号分布在不同的信道中，所以采集时须将13个信道遍历扫描一遍，每个信道扫描约需250毫秒，即扫描一轮约需3秒钟(信道切换时间)；经验值为扫描1轮可采集80％左右，扫描2轮可采集95％以上，所以建议一般在一个地方停留等待扫描1～2轮。考虑到我国隧道限速在60-80km/h左右(具体以隧道入口前方限速标志为准)，由于隧道内空间小光线差，隧道不但有限速抓牌，同时隧道内行驶时还禁止变道超车，隧道里变道超车都十分容易影响其他车辆的正常行驶。另外，一般隧道内行车的距离保持100米以上，如果隧道比较长，则需要根据提示来保持相对应的安全行车距离。根据WiFi探针测量的范围和车速调查的第85位车速(最高限速)以及车辆所保持的安全车距，又考虑到经济性，我们以10s(经验值)作为一个间距进行WiFi探针测量的布设。假设最高限速为v(x)，间隔时间为t(x)，布设间距为：x₀＝α·v(x)·t(x)，其中α为修正系数，受车身长度、车道宽度、经济性等多个因素所制约。为了达到对车辆位置的实时监测，并且确保位置信息的准确性，即每时每刻都能获得在隧道上行驶车辆的准确位置信息，所以WiFi探针设备100的识别范围必须覆盖整个隧道。考虑到车道的宽度，车道数等，在本实施例中根据模拟计算后最终得到布设间距约为150-250m，其具体取值取决车辆速度。

表1隧道限速与车道宽度

表2车型与车身长度的关系

可选的，在一些实施例中，WiFi探针设备100与服务器200之间采用HTTP协议，发送POST请求，在建立HTTP三次“握手”的基础之上，服务器200主动接收数据。HTTP协议定义Web客户端如何从Web服务器200请求Web页面，以及服务器200如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器200发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器200以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器200信息、响应头部和响应数据。本单元采取HTTP协议，发送POST请求，在建立HTTP三次“握手”的基础之上，后端服务器200主动接收手机Mac号等数据，通过服务器200进行处理。MySQL是一个关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。因此本团队决定采用MySQL数据库进行交通参数数据的存储。MySQL数据库分为服务层、核心层、存储引擎层三个部分。

可选的，在一些实施例中，WiFi探针设备100探测过程中遍历WiFi的每一个信道进行扫描，每次扫描1-2轮或更多。

更为具体的，本团队采用的WiFi探针设备100为双网卡，全信道，全协议的WiFi探针设备100，可以采集手机的Mac和信号强度、手机距离探针设备的距离、手机是否连接WiFi、手机连接的WiFi的SSID和Mac地址、手机曾经连接的WiFi的信息、手机是否处于睡眠状态、探针设备的经纬度和地址等，最终数据格式为JSON格式。

本申请依托WiFi探针设备100，可以对交通流小区段速度、密度、流量、车头间距、车头时距等交通状态全参数的获取。此外，本系统主要依靠电子设备的Mac号进行配对，无需常规的视频等非结构化数据获取及融合，降低了系统数据维度、减少了数据处理量，从而缩短了系统计算反映时间，为提供准实时甚至实时的精细化状态感知服务奠定了基础。

本申请拟建立的基于WiFi探针的隧道交通流状态精细化感知系统，分别考虑隧道运营管理者对于交通流运行的宏观状态(即考虑隧道内车辆的宏观分布、交通事件的识别等)与车辆驾乘人员对于交通流运行的微观状态(如最近车辆与本车的位置关系及速度差、车头时距等)，面向隧道运营管理者建立中心型交通状态监测系统，面向车辆驾乘人员建立边缘集中型诱导系统(如路侧LED屏幕对各车辆的提示诱导)，充分满足了各方需求，提高了设备的利用效率和实用性。

以上仅是本申请的优选实施方式，应当理解本申请并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围，则都应在本申请所附权利要求的保护范围内。

Claims (7)

1.一种隧道车流量感知系统，其特征在于，包括WiFi探针设备和服务器；

所述WiFi探针设备布置于隧道内，实时探测周围环境的WiFi信号并上传至服务器，所述服务器对WiFi信号进行数据处理用于表征隧道内的车流数据，并将车流数据反馈给车辆；

所述服务器的数据处理包括：

所述WiFi探针设备沿隧道布置有n个，第i个WiFi探针设备探测到的WiFi信号作为集合A，则第i-1或i+1个WiFi探针设备探测到的WiFi信号作为集合B，通过集合A及集合B中的数组判断WiFi设备的移动方向，选取单向移动的WiFi信号组成集合C，对所述集合C进行去重或合并得到所述车流数据；

在所述集合C中，剔除通过时刻相同的WiFi设备的ID，仅保留一个用于表征车辆数据，得到集合D；

或，将通过时刻相同的WiFi设备的ID合并为一个，得到集合D；

具体的所述服务器的去重或合并包括：

在隧道口连续布置多个WiFi探针设备，在某一时刻t₁，第一个WiFi探针设备识别到若干Mac号，记为s₁：

s₁＝{a₁，a₂，...，a_n；b₁，b₂，...，b_n；c₁，c₂，...，c_n；...}

在(t₁+Δt₁)时刻，其中Δt₁为某车从第一个WiFi探针设备到第二个WiFi探针设备所需要的时间，在第二个WiFi探针设备处又识别到若干Mac号记为s₂：

s₂＝{d₁，d₂，...，d_n；e₁，e₂，...，e_n；f₁，f₂，...，f_n；...}

取s₁∩s₂＝s，s记为同一类Mac号，即记为同一辆车内的Mac号；

第三个WiFi探针设备在(t₁+Δt₁+Δt₂)时刻识别到若干Mac号：

s₃＝{m₁，m₂，...，m_n；n₁，n₂，...，n_n；k₁，k₂，...，k_n；...}

s∩s₃＝s_g，s_g记为同一类Mac号，s_g即所述集合D。

2.根据权利要求1所述的隧道车流量感知系统，其特征在于，所述WiFi信号包括车辆WiFi设备的ID信息及通过时刻，所述通过时刻是指对应WiFi探针设备探测到WiFi设备的时刻。

3.根据权利要求2所述的隧道车流量感知系统，其特征在于，所述WiFi探针设备在隧道口连续布置至少三个。

4.根据权利要求3所述的隧道车流量感知系统，其特征在于，所述服务器基于所述集合D中同一WiFi设备的ID通过任意两WiFi探针设备的时刻差，以及该任意两WiFi探针设备之间的布置间距测得表征该WiFi设备的ID所对应的车辆的平均速度。

5.根据权利要求4所述的隧道车流量感知系统，其特征在于，所述车流数据包括表征车辆信息的集合D以及车辆的平均速度。

6.根据权利要求1所述的隧道车流量感知系统，其特征在于，所述WiFi探针设备与服务器之间采用HTTP协议，发送POST请求，在建立HTTP三次“握手”的基础之上，服务器主动接收数据。

7.根据权利要求1所述的隧道车流量感知系统，其特征在于，所述WiFi探针设备探测过程中遍历WiFi的每一个信道进行扫描，每次扫描1-2轮或更多。