厦漳泉公交同城化信息查询系统的设计

冯惠英 林宇洪 纪自家

1. 福建林业职业技术学院，福建，南平353000

2. 福建农林大学，交通学院，福州350002

3. 厦门易维信息技术有限公司，福建，厦门361008

0 引 言

在中国，产业关联、人文相似的相邻城市已出现同城化趋势。同城化将促进区域一体化，提升区域整体竞争力，形成辐射力与竞争力越来越强的板块经济。同城化能够增进多个城市的相互交流，消除经济壁垒，增加就业机会，调节农产品价格，充分利用资源，提高市民生活水平[1]。

在同城化的背景下，原本分散于不同城市的市民在工作、生活中将会发生紧密的联系。市民需要频繁地来往于周边城市，环保、经济的公交车将是市民的首选出行方式，原有的各自为政的城市公交信息查询系统已不能满足群众需求[2]。

《厦漳泉大都市区同城化总体规划》提出将实现厦漳泉海陆空交通的无缝对接，力争2020年实现全城化[3]。在厦漳泉同城化进程中，研发智能公交同城化信息查询系统成为了迫切需求。

1 系统开发背景

在厦漳泉同城化进程中，三地均意识到公交同城化必须先行，2012年6月29日，投资2800万元的漳州角美公交枢纽站建成投入使用。该枢纽站汇集了3条同城化公交车线路：厦门853路（厦门轮渡—漳州角美）、厦门709路（漳州角美火车站—厦门海沧房产）、厦门830路（厦门旭日海湾—漳州角美镇）。三条线路受到了市民的欢迎，在调查中，市民认为常态化、密集化跨城公交线路的客运形式，比城际客运、出租车更加便利和便宜。可以预见，随着同城化进程的发展，承担同城化任务的公交线路将越来越多。

通过问卷调查了解到，因为交通信息的不对称，许多市民感到同城化线路距离远，不确定因素较多，担心误选了停运线路，导致出行失败。还有一些市民抱怨到了另一个城市后，不熟悉当地的公交线路，无法利用公交资源。因此公交优先的发展战略，不仅仅需要加强硬件设施的建设，还需要重视公交乘客的消费心理，只有公交乘客获得了良好的消费体验后，才会从内心真正支持并优先选择公交资源。因此建设一个透明的公交同城化信息查询平台，能够向市民提供更多的公交资源信息，鼓励并引导出行者优先使用公交。

2 系统架构的设计

设计系统架构如图1所示。三市公交总公司联合架设云服务中心，委托信息公司管理，设置通讯服务器，建立短信平台或Mobile Web手机网站，集中管理基础数据，并响应乘客发出的查询请求[4]。同时通讯服务器接收公交车车载 GPS通过GPRS方式发出的位置信息，判断公交线路是否拥堵停滞。接收接驳枢纽通过GPRS发出的运营状态信息，判断同城化线路、接驳线路是否停运，确保出行者获得的换乘方案均可执行[5]。在公交车运营状态改变、线路拥堵断班次时，及时通知路途上的乘客最新交通信息，帮助乘客调整换乘方案，改善公交乘客的乘车体验。使用短信平台或手机网站查询的方式，无需随身携带电脑，只需在手机上安装特定查询软件，方便了用户在出行移动中查询。无论手机硬件好坏，都能得到质量大致相当的信息服务，体现了云服务资源分享的公平性。

图1 系统架构Fig.1 The system architecture

3 短信平台的开发

问卷调查了解到，当地公交乘客喜爱手机短信查询换乘方案，因此在通讯服务器上架设短信平台，用于接收乘客发出的查询短信。把查询请求存入 SQL Server数据库，计算服务器随机选取一条查询请求，计算最优的换乘方案后，存回数据库。通讯服务器从数据库中检索已计算好的查询任务，把换乘方案以长短信的形式发送给乘客。

3.1 架构设计

以通讯服务器架设为短信平台为例，平台架构见图2，采用Microsoft Visual FoxPro 9.0开发。

（1）工作层。考虑客户的手机号可能分属于不同的运营商，因此申请移动、联通或电信的短信网关（ISMG，Internet Short Message Gateway），用于接收和发送短信。

（2）控制层。控制层将实现对工作层的控制，使用CMPP（China Mobile Peer to Peer）协议实现对移动公司短信网关的控制，使用 SCIP（Short Message Gateway Interface Protocol）协议实现对联通公司短信网关的控制，使用 SMGP（Short Message Gateway Protoco）协议实现对电信公司短信网关的控制。

（3）缓存层。建立缓存层，短信平台在工作中会接收到大量垃圾短信，将收到短信暂存于缓存层，简单判断其格式是否符合系统定义的约定格式“（起点）#（终点）”，直接在缓存层删除垃圾短信，避免把垃圾短信送入后台数据层。另外，缓存层有助于缓冲并暂存收发短信，平衡工作层和逻辑层之间的速度差异。

（4）逻辑层。从已收短信表中获取查询短信，采用识别算法解析查询短信，把查询短信按约定格式转换成带起点、终点的查询请求，将查询请求存入 SQL Server数据库，并设置为“等待计算”的标识。随后，从数据库中检索具有“计算成功”标志的查询请求，提取换乘方案，把换乘方案形成短信内容，存入待发短信表，随即把“计算成功”标识改为“发送成功”标识。

（5）数据层。数据层建立在数据库服务器上，用于存储用户的查询请求。周边的计算服务器从数据库中随机提取标识为“等待计算”的查询请求，计算出换乘方案后，再回存于数据库中，并在该记录上设置“计算成功”的标志。在短信平台外，还有一些协同系统参与工作，例如公交GIS管理系统、同城化线路调度系统[6]。

图2 短信平台架构Fig.2 The SMS platform architecture

3.2 长短信技术开发

公交同城化换乘方案内容会比较复杂，因此普通70字的短信无法承载，必须开发长短信技术，长短信技术可以携带 70～2000字的信息内容。长短信PDU(Protocol Data Unit)数据包的编码规则必须遵循GSM 03.40规范[7]，本课题设计的编码见表1。首先制作长短信的短信头，按要发送的内容字数，建立分拆短信的数组，向分拆短信数组中存入每条短信的协议头。例如，要发送180个汉字的内容，将拆成三条分拆短信，取一随机数作为本次长短信唯一标识 ID，如 ID为“28”，三条分拆短信的协议头分别为，“050003280301”、“050003280302”、“050003280303”。将180个汉字的内容分解为三段分拆正文，字数分别为 67、67、46。把长短信的短信头、分拆短信的协议头与分拆正文组成一条分拆短信，把三条分拆短信分别存入数组。从数组中提取分拆短信，逐条送至短信网关发送。在用户手机上能显示成一条长短信，方便用户阅读。

表1 长短信编码表Tab.1 CSMS transmitting codes

4 同城化换乘算法的研究

同城化公交换乘算法与普通的单城市换乘算法不同，在收到查询短信时，首先判定起点、终点是否在同一城市：如果在同一个城市，使用单城市换乘算法即可；如果不处于同一个城市，则要：（1）先计算两城市中最便利的同城化线路的换乘方案，选优标准采用费用最低优先。选中同城化线路，则确定了一批匹配的接驳枢纽。（2）接着用单城市换乘算法计算起点至始发城市选中的接驳枢纽的换乘方案、计算目标城市选中的接驳枢纽至终点的换乘方案。（3）将“始发城市的换乘方案”+“同城化线路”+“目标城市的换乘方案”拼接成出行方案。为了保证乘客获得的出行方案可行，还必须利用车辆的位置信息、枢纽的运营信息判定所需线路是否处于正常通行状态。

4.1 搜索树算法

基于公交乘客最少换乘次数、最少站点的消费心理，设计用于单城市换乘查询的搜索树算法，见图3。以从站点A至站点B为例，算法过程如下：（1）查询直达方案：从起点A出发，途经A的所有公交线路均为主干，查询主干所有节点(公交站点)中是否出现B，如果出现多个B，则存在多种直达方案。如果未出现B，说明不存在直达方案，执行步骤2。（2）查询一次换乘方案：在主干上的所有节点绘制新的公交线路，成为第一层枝。查询第一层枝节点中是否存在B，如果未出现B，说明不存在一次换乘方案，执行步骤3。（3）查询二次换乘方案，在第一层枝上的所有节点上绘制新的公交线路，形成第二层枝，在第二层枝上查询是否出现B，如果未出现B，说明不存在二次换乘方案，搜索中止。厦漳泉的实验证明，二次换乘已能实现市内任意两个站点通达。如果未来出现两点之间二次换乘不能通达，说明当地公交网络有缺陷，应当对公交网络进行优化。为了避免出现死循环，一个公交线路号仅能在搜索树中出现一次。

图3 公交换乘搜索树Fig.3 The bus transfer searching tree

搜索树建立在数据库中，每个节点由五字段表达：prestat(前节点站点编号)、preline (前节点线路编号)、selfstat(本节点站点编号)、selfline(本节点线路编号)、selfleve(本节点枝的层级)。以查询二次换乘方案为例，在以A为起点的搜索树“A_tree”中，采用SQL查询指令“SELECT * INTO AtoB_2 FROM A_tree WHERE selfstat=B AND selflevel=2”，数据集“AtoB_2”的记录数即为从A二次换乘可达 B的方案数。使用SQL查询指令“SELECT * FROM A_treec WHERE selfstat =B1.prestat AND selfline=B1.preline”，能够逆推节点 B1的父节点信息，从而追溯获得从A至B的换乘方案。

4.2 折半查找算法

搜索树算法首先考虑换乘次数最少方案，接着考虑站点数最少方案，吻合了公交乘客的消费心理，是很理想的换乘算法。但在压力测试中也发现，临时构建搜索树，消耗了较多的计算资源，在公交高峰期，查询压力很大，系统响应会有明显的滞后现象。通过观察，早上七点半，下午五点半两个公交高峰期均为白天班线，而白天班线运营状态稳定，因此可以建立一个静态的“通联表”，记录任意两站点之间的换乘方案。

调用搜索树算法计算任意两点之间最优秀的 5个换乘方案，存入“通联表”，在“通联表”中设置检索编号，检索编号=起点编号×10000+终点编号。“通联表”建立好后，接到查询请求时，无须动态生成搜索树，而是直接计算检索编号，采用折半查找法从“通联表”中取出检索编号对应的换乘方案。

设“通联表” L = ( R1,R2,… ,Rn)，其中 Ri(1 ≤ i≤n)，用y表示检索号，在L中寻找特定检索号的过程可以表达为Ri·y=B，B指要查找的编号，当R1·y、 R2·y、 … 、 Rn·y 为有序排列，则无须顺序遍历寻找，可采用折半查找法。当表长为n，查找B成功时的查找次数最多为h次，则 n ≈ 2h-1。设表长 n = 2h-1，所以有：

以上数学推导证明了“采用折半查找法能够使查找长度按1/2的指数级缩小”。以厦门为例，厦门目前有1 454个公交站点，考虑到大多数公交线路有上下行差异，从起点至终点的公交线路不一定可逆，因此两两站点相通联组合为2 112 662个，采用折半查找算法平均仅用20.01次读表即可找到换乘方案，查找时所需要的内存空间为1个字段。采用顺序查找法则平均需要1 056 331次读表，查找时所需要的内存空间为1个字段。厦门目前有107条线路，考虑上下行差异，计214条线路，每条线路平均28个站点，即需要5992×5次读表获得各线路的途经站点信息，才能构建完整的搜索树，建树时所需要的内存空间为5992×5个字段。原本采用搜索树算法需要6.38s的查询任务，现采用折半查找算法仅需 0.01s，消耗的服务器资源微乎其微，因此在公交高峰期，可以承受巨大的并发查询压力，不会出现滞后的现象。

4.3 两种换乘算法联合使用

折半查找算法适合于运营状态稳定的白天班线，以承受海量查询压力。在夜间许多线路会陆续停运，切换为搜索树算法，利用运营状态动态地创建搜索树，以确保出行方案可实现。

5 运行实例

本次设计的查询系统已投入试用，云服务系统架设在厦门某信息公司的机房，集中管理三地公交资源数据。目前通讯服务器采用短信平台的形式，统一响应三地市民发出的查询请求。

跨城换乘查询举例如下：云服务系统收到市民发出的查询短信“1#厦门大学#漳州教育学院”后，系统根据功能号“1”判定为查询换乘方案，模糊查询起点最近的公交站有“厦门大学站”，终点最近的公交站有漳州市的“教育学院站”，从而判断起点、终点不在同一个城市。调用“同城化线路换乘算法”，获得厦门至漳州费用最低的同城化线路为“厦门853路”、接驳线路为“漳州23路”，从而确定接驳枢纽站为“角美枢纽站”。调用“搜索树算法”或“折半查找法”计算从“厦门大学站”至“角美枢纽站”的最佳方案，再计算“角美枢纽站”至“漳州教育学院站”的最佳方案，将三段方案拼成完整的公交出行方案。根据车辆位置信息，估算起点站的公交车到站时间。最后系统回应短信内容为“厦门大学站乘厦门841路12站至海沧房产站，换乘厦门853路26站至角美枢纽站，换乘漳州23路37站至漳州教育学院站。厦门841路车约6分钟后到达厦门大学站”。

公交信息查询举例如下：云服务系统收到市民发出的查询短信“2#853”后，系统根据功能号“2”判定为查询公交资源信息。系统则在三个城市的线路表、站点表中模糊检索关键词为“853”信息，猜测用户拟查询厦门853路公交车的详情。随后系统把厦门853路公交车上下行途经站点、上下班时间以长短信的形式发回给用户。

6 总 结

同城化发展战略将实现地区经济一体化，消除商业活动的壁垒，让生产要素自由流动。在这一进程中，公交同城化必须先行，拉近城市之间的生活距离。本系统为厦漳泉市民提供了统一的公交同城化查询平台，设计了搜索树算法实现了最优换乘方案的求解，并应用折半查找算法对搜索树算法进行了改良，提高了计算能力[8]。在压力测试时，4台计算服务器可以应对 24 000条/h的查询压力。本架构计算能力具有优秀的扩展性，如果以后不能满足实际需求，根据新增加的工作压力大小，挂入适量的计算服务器即可。

[1] 余舒悦．厦漳泉大都市区同城化建设的条件分析与对策思考[J]．台湾农业探索，2012，(3)：40-43．

[2] 王明浩，庞革平，谢振华．广西北部湾经济区开启“同城化”[N]．人民日报，2013-06-22 (1)．

[3] 李志清，王婷，吴继贵．厦漳泉物流同城化发展研究[J]．物流工程与管理，2012，34(10)：29-32．

[4] Scanaill C. N., Ahearne B., Lyons G. M. Long-term telemonitoring of mobility trends of elderly people using SMS messaging[J]. IEEE Transactions on Information Technology in Biomedicine, 2006, 10(2):412-413．

[5] Swadesh Kumar Samanta, John Woods, Mohammed Ghanbari. A business model for mobile commerce applications using multimedia messaging service[J].International Journal of Business Information Systems, 2010, 5(4): 418-439．

[6] 林春水，林宇洪，郭建钢．基于BPNN的高速公路风雨天气限速系统的设计[J]．交通运输工程与信息学报，2013，11(3)：35-39，57．

[7] Samanta S.K., Woods et al. Special delivery: an increase in MMS adoption[J]． IEEE Potentials,2009, 28(1): 12-16.

[8] 林宇洪，沈嵘枫，邱荣祖．南方林区林产品运输监管系统的研究[J]．北京林业大学学报，2011，33(5)：130-135．