辛欣,宋金宝,万丁玮,许宁
(1.北京牡丹视源电子有限责任公司,北京 100191;2.中国传媒大学信息工程学院,北京 100024)
公交车辆信息实时查询系统
辛欣1,宋金宝2,万丁玮1,许宁1
(1.北京牡丹视源电子有限责任公司,北京 100191;2.中国传媒大学信息工程学院,北京 100024)
本文针对北京等城市公交系统的特点,探讨了在公交汽车上广泛安装GPS的情况下,如何利用移动交通检测技术解决预报公交车到站时刻问题,并提出了一个基于浮动车技术预报到站时间的解决方案。这种新的候车预报方法有着报时相对准确、实时性强、建设成本低、覆盖范围广等优点。
计算机应用技术;智能公交;候车时间预报;浮动车技术
乘客在等公交车时最关心的莫过于公交车辆的到站时间,同时对研究城市交通管理也有很大的帮助,因此对公交车辆到站时间的准确估算有着十分重要的意义[1]。
现有的公交查询系统大多只采集和报告公交车的当前位置,也有个别的能提供到站时间,有的是根据计划时间、有的是根据公交车当前速度和到站距离计算出来。但这样往往与实际情况有较大偏差,准确性也会超出乘客能够接受的范围,尤其是北京等这种堵车严重的城市,路面交通情况的复杂性给准确估算车辆到站时间带来了很大困难。
本文针对北京等城市公交系统的特点提出了一个利用移动交通检测技术实现“公交车辆信息实时查询系统”的解决方案,利用安装了卫星定位和移动通信设备的探测车(又称浮动车)在行驶过程中的实时车辆信息,将其应用到交通信息服务、交通管理和交通诱导等方面,最重要的是本解决方案可通过电子站牌、互联网和移动互联网等方式提供各公交车的预计到站时间等信息。
公交车辆信息实时查询系统解决方案的系统结构如图1所示。
如图1所示,本系统由如下几大部分组成:
图1 解决方案的系统结构
1)通过车载GPS终端对运营中的公交车进行GPS定位,该部分能够将定位后的坐标存储在车载终端内,然后使用终端内搭配了移动通信运营商的SIM卡通信模块,将定位的坐标信息数据通过移动网络发送到公交车辆监控中心。
原始定位数据的数据结构及类型说明如表1所示。
表1 原始定位数据结构及类型说明
上述 Longitude、Latitude为车辆的地理坐标;Speed为车辆的瞬时车速;Direction为方向可以用于判定车辆的行驶方向。
2)在全市建立一个智能公交数据处理中心,通过电信专线实时接收来自公交车辆监控中心的公交车辆定位数据并进行处理,智能公交数据处理中心定时把处理结果——任意公交车到任意车站的预计到站时间发送给移动电视台、移动互联网站、固定互联网站等前端。
3)在电视图像信号或广播信道中加入数据广播信号,所有车队只要利用相应的解调器都能收到数据广播信号,每一车队只从广播数据中提取本车队的信息即可。实现一网两用,不用一个车队建一套系统,这样做建设运维成本低、信息共享性好。
4)所有电子站牌通过相应的解调器都能收到数据广播信号,每一站牌只从广播数据中提取本站牌所需信息即本路车到达本站的预估时间加以显示。
5)乘客可通过接入相关网站或通过手机接入移动互联网查询乘车相关信息。
本解决方案的基本思路是,利用不同路公交车在线路上的交错重合性和它们在站名上规范统一性,把行进中的某路公交车辆前方各站最当前通过的本路或其他路车的站间行驶时间的逐站累加作为本辆车到达前方各站的预估时间。
本解决方案的核心部分是智能公交数据处理中心,处理中心的基本工作原理如图2所示。
图2 数据处理中心结构
数据处理中心结构的说明以及数据处理的过程如下。
2.2.1 静态数据与动态数据
静态数据是指那些不随时间变化、随时间变化不大或者更新周期长的信息,与路网和车辆相关的信息均属静态数据,如表2至表6所示。
表2 公交车站信息表
表2为所有公交车站的信息表,每一个公交站点占用一行。
表3 公交车站GPS信息表
表3为所有公交车站的GPS表,每一站点占用一行,用站点代号索引一行。
数据结构定义说明:
建立此表的目的是,由于浮动车数量大、匹配速度要求高,采用传统算法难以满足浮动车位置匹配要求。为此,本文根据北京等城市各路公交车在站名上规范统一的特点,在车站间建立公交车的GPS匹配点集合,只处理GPS坐标落入匹配点集合的汽车位置信息,并且由于站名规范统一,所以站点的GPS坐标的建立与维护与各路公交车没有关系,全市只要建立和维护一张表就可以了。两站之间可以根据实际需要和经济性设有任意多个坐标匹配点,坐标匹配点越多越易于到站时间的测量,但成本也越高。
假定一站之内基本是匀速行驶,可利用这一站已行驶时间和上述“C”和“D”项计算出这一站总行驶时间。
上述“D”项为0时表示此位置就是站点位置,建议在站点位置上要发送GPS坐标信息,北京市“9”字头车GPS已实现自动检测进站位置并报告站名,所以把这一位置信息发送出去完全可行。
表4 公交线路信息表
表4为一座城市所有路公交车的信息表,每一路车占用一行,用公交车路号的代号索引一行。
数据结构定义说明:支线和区间车也算作一路公交车。
表5 公交线路上行方向车站信息表
表5为一座城市所有路公交车的信息表,每一上行站占用一行,用公交车路号的代号索引一行。
数据结构定义说明:站点序号为0xff,表示这路车经过此站点但不停车,即快车等。
表6 公交线路下行方向车站信息表
表6为一座城市所有路公交车的信息表,每一下行站占用一行,用公交车路号的代号索引一行。
数据结构定义说明:站点序号为0xff,表示这路车经过此站点但不停车,即快车等。
还有其它一些静态表,此处不一一列出。
动态数据是指随时间具有明显变化的信息,比如车辆的行驶定位数据,如表7、表8和表9所示。系统依据相关公交车的静态信息和车辆的动态信息,通过一定算法确定相关车站的预计到站时间。
表7 车辆状态信息表
表8 相邻站点最当前实际运行时间
表9 公交车辆与公交线路的下送信息
还有其它一些动态表,此处不一一列出。
2.2.2 行驶定位数据接收与预处理过程
由于数据处理中心接收汽车上发信息是随时的和随机的,并且这些信息中也有可能会包含错误的信息,而数据处理中心的处理过程是周期的和定时地,因此,我们需要建立一个数据接收与预处理的服务器,其功能是将公交车实时上传的数据进行检查、筛选、计算并保存到数据库中,该过程主要完成以下几项功能:
1)将接收到的数据进行筛选,剔除一些异常数据和噪声,如经度/纬度错误,速度错误(小于0或大于60)等;
2)根据GPS提供的坐标值与表3进行匹配,保留车辆的定位点处于目标道路匹配点集合中的车辆定位数据;
3)将有效的车辆定位数据进行计算或处理,并依据处理结果对数据库中的表7的D、E、F项(当表3的“D”项为0时)或G、H(当表3的“D”项不为0时)项进行更新。
2.2.3 数据处理过程
数据处理过程周期地将经过预处理后的信息通过计算和转换得到乘客和车队所需的各汽车站预计到站时间,基本过程如下:
数据处理中心遍历表7,通过表5找到表7的站点序号对应的站点代号,依据站点代号查询表8“B”项与它相同的记录。
查到后,若表7“E”项的值比表8“C”项的值晚,用表7“E”项的值更换表8“C”项的值。在此情况下,若上述两个时刻之差大于设定阈值,用表7“E”项的值减去表7的“F”项的值,并将此结果去更换表8的两站之间实际运行时间;否则,表8“D”项的值与表7“E”项的值减去表7“F”项的值的结果进行累加并取平均值,以剔除红绿灯误差。
若表7“G”项的值比表8“E”项的值晚,用表7“H”项的值更换表8“F”项的值。
数据处理中心再对每一路车的上行/下行的表9部分进行如下处理:
设立临时变量并将其清零,从本路车的第一站开始处理。
通过表5找到表9的站点序号对应的站点代号,依据站点代号查询表8的相关位置,比较表8的“C”项和“E”项,若前者比后者的时刻晚,取两站之间实际运行时间累加到临时变量中,若前者比后者的时刻早但它们之差小于设定阈值,取两站之间实际运行时间累加到临时变量中,否则把两站之间估算的行驶时间累加到临时变量中。若前者或后者更晚的一方比当前实际时间早且其差值大于设定阈值,即在一段时间内没有公交车经过,可根据公交车路号的代号得到此路车在表4的站间规定行车时间,把它累加到临时变量中。把临时变量中的内容置到表9的这一站的“下一趟车预计到站所用时间”处。
若表9的这一站的“本站至下一站之间车辆总数”不为零,将临时变量清零。
重复上述过程直到这路车的这一方向的最后一站。
把数据处理完毕后新生成的表9保存到数据库中。
2.2.4 数据下发过程
数据处理中心定时地将表9从数据库中读出,经过数据打包后通过电信专线传至电视台/广播电台前端和网站,电子站牌和公交车队的相关电视广播接收器接收这些嵌入在电视广播节目中的数据。乘客可通过电子站牌、固定或移动上网查询得到车辆的位置和预计到站时间等信息,公交车队也可接收这些信息进行公交车调度和管理。
1)对于移动交通检测系统,一个最基本的问题是探测车的数量。以往的移动交通检测系统的实践证明如果探测车数量太少,则交通信息的精度较低;如果探测车数量太多,交通信息的精度不会明显提高,反而使系统成本显著增加。一般情况下,在城市道路上覆盖率为5%即可达到满意效果。北京市交研中心搭建的“浮动车交通信息采集系统”,参与的出租车在8000辆左右,每辆车大约每分钟上传一个GPS点数据,每天接收到的数据量约900万条。浮动车数据对于五环内(含五环)次干路以上路网的覆盖率达到90%以上。
北京市交通委就是利用浮动车数据计算出的路面交通情况,并以图片的方式显示出来,绿色表示路面畅通,红色表示路面拥堵,该实时数据可在北京交通网上查询。
2)以北京为例,由于公交线路重合性,即一路公交车线路上各站之间几乎都与其他公交线路有重合,因此每一路公交车前后两辆车之间出现其他路车的概率很高,因此站间有探测车的时候非常多;再者各路车在高峰期间发车间隔都在5、6分钟以内。
可以看出像北京这样公交路网密度大、公交车数量多(大约600个以上的公交线路)的城市非常有利于使各路公交车互为其他路公交车提供到站时间的参照值。
3)路面交通状况有惯性,道路拥堵情况的变化是比较平缓的,所以若干站之内后面车辆的行进时间完全可以用前方最当前经过车辆的行车时间来预估,而且本解决方案也能把路面交通状况的突然变化及时反映出来。
4)关于本方案的核心部分——智能公交数据处理中心的海量计算问题。我们以北京市公交线路作为实验数据,在普通PC机上设计了一个智能公交数据处理中心的模型,模拟处理对象为608路车、5439*2(2代表上下行)个站点,它的处理周期为30秒,即在30秒钟之内就能够把5439*2个站点遍历一遍,遍历过程中根据这期间全市的公交车车载GPS上传的新数据,把响应站的到站时间进行更新。
5)系统尽量采用通用的、规范的、标准的、商用的技术、设备或设施,不但考虑了建设的可行性,还考虑了日后运维的可行性。这样实现的可行性高,建设起来容易而且成本低廉,今后运营、维护、维修也简单容易,成本也低,否则这一系统难于投入建设、难于长期运行。
6)随着科学技术的发展,在智能公交技术方面会涌现出新的技术或算法,由于本系统核心部分完全采用软件实现,所以利用更先进的技术或算法进行替换就可以很容易的对本系统进行改造或优化。
本文探讨了在公交汽车上广泛安装GPS的情况下,如何利用移动交通检测技术解决预报汽车到站时刻问题,并提出了一个基于浮动车信息系统的解决方案,重点描述了浮动车数据采集、地图匹配和到站时刻估算方法。这种新的候车报时方法有着建设成本低、覆盖范围广、数据精度高、实时性强、报时相对准确等优点,它的实现和推广应用将会对交通管理和服务提供良好的支持,缩短广大乘客的候车时间和乘车时间,有利于公交乘客方便出行。
由于本方案的核心部分——智能公交数据处理中心完全由软件实现,所以很容易与其它测速系统对接,比如与路口测速装置相对接,并视情况改进算法,就能提高报时的准确性。
[1]周鑫欣,武小光,徐辉,辛欣.一种公交信息查询方法和系统[P].中国:201020502833.5.
[2]徐宁,王文元,徐辉,辛欣.一种公交信息采集和查询系统[P].中国:201020502834.X.
[3]张晓春,吕北岳,杜清运.基于车载GPS技术的交通浮动车检测系统设计研究[J],ITS通信,6(3),2004:82-83.
[4]张存保,杨晓光,严新平.移动交通检测系统中探测车的样本数量[J].中国公路学报,20(1),2007:132-133.
[5]张孜,徐建闽,吴一民.基于Web GIS的车辆移动定位系统的设计与实现[J].长安大学学报:自然科学版,2006,26(2):39-42.
[6]彭春华,蒋新华.基于GPS的实时机车运行信息传输系统[J].交通运输工程学报,4(2),2004:105-108.
[7]侯莎莎.同一时段的路况差别咋这么大?[EB/OL].http://bjrb.bjd.com.cn/html/2010-10/28/content_331849.htm,2010.
[8]北京交通发展研究中心.一种新型的交通信息采集系统——浮动车交通信息采集系统研究[EB/OL],http://www.bjtrc.org.cn/show.asp?id=47&intType=4,2007.
Real-time Query System of Transit Vehicle Information
XIN Xin1,SONG Jin-bao2,DING Wei-wan1,XU Ning1
(1.Beijing Peony Digital Video Electronics Co.,Ltd,Beijing 100191;2.Communication University of China,Beijing 100024)
This article discussed how to forecast public transportations’arrival time using motion transportation examination technology under the condition that GPS are installed on most of the buses,and proposed a solution of forecasting arrival time based on floating cars technology.The new forecasting method has some advantages such as forecasting arrival time relative exactly,high real-time,low construction cost,wide usage and so on.
computer application technology;APTS;forecasting waiting time;floating cars technology
U495
A
1673-4793(2011)04-0066-06
2011-05-20
辛欣(1958- ),男(汉族),山东泰安人,北京市工业技术开发中心高级工程师,Email:biicxinx@126.com
(责任编辑
:龙学锋)