馮惠英 林宇洪 紀自家
1. 福建林業職業技術學院,福建,南平353000
2. 福建農林大學,交通學院,福州350002
3. 廈門易維信息技術有限公司,福建,廈門361008
在中國,產業關聯、人文相似的相鄰城市已出現同城化趨勢。同城化將促進區域一體化,提升區域整體競爭力,形成輻射力與競爭力越來越強的板塊經濟。同城化能夠增進多個城市的相互交流,消除經濟壁壘,增加就業機會,調節農產品價格,充分利用資源,提高市民生活水平[1]。
在同城化的背景下,原本分散于不同城市的市民在工作、生活中將會發生緊密的聯系。市民需要頻繁地來往于周邊城市,環保、經濟的公交車將是市民的首選出行方式,原有的各自為政的城市公交信息查詢系統已不能滿足群眾需求[2]。
《廈漳泉大都市區同城化總體規劃》提出將實現廈漳泉海陸空交通的無縫對接,力爭2020年實現全城化[3]。在廈漳泉同城化進程中,研發智能公交同城化信息查詢系統成為了迫切需求。
在廈漳泉同城化進程中,三地均意識到公交同城化必須先行,2012年6月29日,投資2800萬元的漳州角美公交樞紐站建成投入使用。該樞紐站匯集了3條同城化公交車線路:廈門853路(廈門輪渡—漳州角美)、廈門709路(漳州角美火車站—廈門海滄房產)、廈門830路(廈門旭日海灣—漳州角美鎮)。三條線路受到了市民的歡迎,在調查中,市民認為常態化、密集化跨城公交線路的客運形式,比城際客運、出租車更加便利和便宜。可以預見,隨著同城化進程的發展,承擔同城化任務的公交線路將越來越多。
通過問卷調查了解到,因為交通信息的不對稱,許多市民感到同城化線路距離遠,不確定因素較多,擔心誤選了停運線路,導致出行失敗。還有一些市民抱怨到了另一個城市后,不熟悉當地的公交線路,無法利用公交資源。因此公交優先的發展戰略,不僅僅需要加強硬件設施的建設,還需要重視公交乘客的消費心理,只有公交乘客獲得了良好的消費體驗后,才會從內心真正支持并優先選擇公交資源。因此建設一個透明的公交同城化信息查詢平臺,能夠向市民提供更多的公交資源信息,鼓勵并引導出行者優先使用公交。
設計系統架構如圖1所示。三市公交總公司聯合架設云服務中心,委托信息公司管理,設置通訊服務器,建立短信平臺或Mobile Web手機網站,集中管理基礎數據,并響應乘客發出的查詢請求[4]。同時通訊服務器接收公交車車載 GPS通過GPRS方式發出的位置信息,判斷公交線路是否擁堵停滯。接收接駁樞紐通過GPRS發出的運營狀態信息,判斷同城化線路、接駁線路是否停運,確保出行者獲得的換乘方案均可執行[5]。在公交車運營狀態改變、線路擁堵斷班次時,及時通知路途上的乘客最新交通信息,幫助乘客調整換乘方案,改善公交乘客的乘車體驗。使用短信平臺或手機網站查詢的方式,無需隨身攜帶電腦,只需在手機上安裝特定查詢軟件,方便了用戶在出行移動中查詢。無論手機硬件好壞,都能得到質量大致相當的信息服務,體現了云服務資源分享的公平性。

圖1 系統架構Fig.1 The system architecture
問卷調查了解到,當地公交乘客喜愛手機短信查詢換乘方案,因此在通訊服務器上架設短信平臺,用于接收乘客發出的查詢短信。把查詢請求存入 SQL Server數據庫,計算服務器隨機選取一條查詢請求,計算最優的換乘方案后,存回數據庫。通訊服務器從數據庫中檢索已計算好的查詢任務,把換乘方案以長短信的形式發送給乘客。
以通訊服務器架設為短信平臺為例,平臺架構見圖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
公交同城化換乘方案內容會比較復雜,因此普通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
同城化公交換乘算法與普通的單城市換乘算法不同,在收到查詢短信時,首先判定起點、終點是否在同一城市:如果在同一個城市,使用單城市換乘算法即可;如果不處于同一個城市,則要:(1)先計算兩城市中最便利的同城化線路的換乘方案,選優標準采用費用最低優先。選中同城化線路,則確定了一批匹配的接駁樞紐。(2)接著用單城市換乘算法計算起點至始發城市選中的接駁樞紐的換乘方案、計算目標城市選中的接駁樞紐至終點的換乘方案。(3)將“始發城市的換乘方案”+“同城化線路”+“目標城市的換乘方案”拼接成出行方案。為了保證乘客獲得的出行方案可行,還必須利用車輛的位置信息、樞紐的運營信息判定所需線路是否處于正常通行狀態。
基于公交乘客最少換乘次數、最少站點的消費心理,設計用于單城市換乘查詢的搜索樹算法,見圖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的換乘方案。
搜索樹算法首先考慮換乘次數最少方案,接著考慮站點數最少方案,吻合了公交乘客的消費心理,是很理想的換乘算法。但在壓力測試中也發現,臨時構建搜索樹,消耗了較多的計算資源,在公交高峰期,查詢壓力很大,系統響應會有明顯的滯后現象。通過觀察,早上七點半,下午五點半兩個公交高峰期均為白天班線,而白天班線運營狀態穩定,因此可以建立一個靜態的“通聯表”,記錄任意兩站點之間的換乘方案。
調用搜索樹算法計算任意兩點之間最優秀的 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,消耗的服務器資源微乎其微,因此在公交高峰期,可以承受巨大的并發查詢壓力,不會出現滯后的現象。
折半查找算法適合于運營狀態穩定的白天班線,以承受海量查詢壓力。在夜間許多線路會陸續停運,切換為搜索樹算法,利用運營狀態動態地創建搜索樹,以確保出行方案可實現。
本次設計的查詢系統已投入試用,云服務系統架設在廈門某信息公司的機房,集中管理三地公交資源數據。目前通訊服務器采用短信平臺的形式,統一響應三地市民發出的查詢請求。
跨城換乘查詢舉例如下:云服務系統收到市民發出的查詢短信“1#廈門大學#漳州教育學院”后,系統根據功能號“1”判定為查詢換乘方案,模糊查詢起點最近的公交站有“廈門大學站”,終點最近的公交站有漳州市的“教育學院站”,從而判斷起點、終點不在同一個城市。調用“同城化線路換乘算法”,獲得廈門至漳州費用最低的同城化線路為“廈門853路”、接駁線路為“漳州23路”,從而確定接駁樞紐站為“角美樞紐站”。調用“搜索樹算法”或“折半查找法”計算從“廈門大學站”至“角美樞紐站”的最佳方案,再計算“角美樞紐站”至“漳州教育學院站”的最佳方案,將三段方案拼成完整的公交出行方案。根據車輛位置信息,估算起點站的公交車到站時間。最后系統回應短信內容為“廈門大學站乘廈門841路12站至海滄房產站,換乘廈門853路26站至角美樞紐站,換乘漳州23路37站至漳州教育學院站。廈門841路車約6分鐘后到達廈門大學站”。
公交信息查詢舉例如下:云服務系統收到市民發出的查詢短信“2#853”后,系統根據功能號“2”判定為查詢公交資源信息。系統則在三個城市的線路表、站點表中模糊檢索關鍵詞為“853”信息,猜測用戶擬查詢廈門853路公交車的詳情。隨后系統把廈門853路公交車上下行途經站點、上下班時間以長短信的形式發回給用戶。
同城化發展戰略將實現地區經濟一體化,消除商業活動的壁壘,讓生產要素自由流動。在這一進程中,公交同城化必須先行,拉近城市之間的生活距離。本系統為廈漳泉市民提供了統一的公交同城化查詢平臺,設計了搜索樹算法實現了最優換乘方案的求解,并應用折半查找算法對搜索樹算法進行了改良,提高了計算能力[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.