1系統設計方案
1．1總體方案
城市智慧交通管理及決策依據的研究，意在以車聯網技術、ZigBee無線感測器網路技術、GPS定位及測速技術、GPＲS數傳技術、ＲFID射頻識別技術等技術手段，以車載終端、公交車站點終端、智慧手機、遠端監控PC終端作為資訊採集和查詢的終端載體，輔助交通管理部門、公交排程公司、道路管理處等部門，研究優化公共交通工具排程、道路改擴建優化的決策依據和方法。
1．2系統結構
系統分公交車終端、Taxi終端、私家車終端、公交站點終端，及前臺應用和後臺資料庫伺服器幾部分。車載終端通過ZigBee網路採集安全及空閒狀態資料，通過GPS提供實時位置、速度資訊，並通過GPＲS網路傳給伺服器。公交站點終端通過Zig-Bee網路採集大氣環境資料、車流量資訊，並通過網路傳遞給伺服器。同時，系統還可以與停車場智慧管理系統對接，為機動車司機提供停車場資訊服務。系統研究的基礎需要建立在一套基於車聯網技術的智慧交通管理平臺上。
2系統主要研究內容
系統主要包括交通管理和道路優化兩個方面。交通管理方面:主要包括公交車輛的實時執行監控機制、公交排程自動化機制、行人候車服務、行人自助打車機制、周邊停車場資訊聯動機制、交通事故上報及處理自動化機制、道路意見上報自動化機制、實時天氣服務、實時路況服務、道路維護資訊釋出機制等。道路優化方面:主要依據實時路況資訊、各公交站點上下班人數及時間統計，及通過車載終端上報的交通事故和道路意見、停車場的分佈及動態使用情況，資料匯入道路優化專家系統，經過資料探勘，分析易擁堵路段、易發生交通事故路段、上下班高峰期及人口出行密集區域，以及市民交通成本分析、城市交通狀態的發展趨勢分析，最終形成交道優化的智慧決策依據。綜合上述兩大方面，系統重點研究內容如下:
2．1智慧候車服務
通過電子站牌，即公交站點智慧終端，提供準確的公交車輛預到站服務，還可以提供實時路況查詢、智慧打車、天氣狀況等服務。
2．2公交車實時執行監控機制
基於物聯網、ZigBee和感測器技術，採集可燃氣體、門窗安全狀態、各站點各時間段行人上下車情況、實時車位及車速等資訊，供司機、公交排程人員控制車輛及排程提供依據;可為司機提供到達某站計劃用時與實際用時的比較服務。
2．3公交智慧排程機制
檢視某線路所有在執行車輛的位置資訊，可提前估算出下一班車到達時間，如壓車嚴重、車輛拋錨等情況，可提前做出排程方案，提高乘坐公共交通工具乘客的滿意度。
2．4智慧自助打車機制
通過智慧手機、公交站點智慧終端，可以實時檢視周邊計程車的位置和狀態，並且進行實時連線呼叫，立刻就可以得到計程車司機的回覆，無需中轉，可操作性強。減少出租車司機尋找客源的時間、油耗。
2．5實時路況服務
提供實時路況查詢服務，為行人、車主提供交通狀況參考，及時選擇合適的出行路線，避免擁堵，提升道路的綜合利用率。
2．6動態停車場資訊服務
為機動車司機提供周邊停車場資訊服務，包括位置、距離、規模、空位數、收費情況等。減少司機問路誤時、無處停車而違章停車等現象。
2．7交通事故快速定位、排除、預警機制
由過往車輛車主通過智慧終端平臺進行事故上報，由後臺交警部門的遠端監控中心快速定位及處理。當車輛即將到達交通事故發生地時，車載智慧終端提前提示司機前方發生事故，提前做好準備。
2．8道路優化意見上報機制
所有車主都可以通過智慧車載終端提交對道路優化資訊的機制和方法，操作便捷。交通管理部門可對資訊進行彙總，發現同一地點上報頻率高的意見則重點考慮。
2．9道路維護資訊釋出機制
車主可通過智慧車載終端直接檢視道路維護資訊的機制和方法，並在即將進入道路維修或封閉路段時，提前給予提醒，以便車主及時、正確地選擇其他路線，避免交通堵塞。
2．10智慧交通專家系統
系統研究意在通過大量的資料採集，深入挖掘，發現規律，給出道路優化的決策依據，減少人力成本和過多的主觀因素影響。
3核心技術及解決方案
3．1實時路況建模
以GPS位置、車速、車流量、道路本身引數，構建精準的實時路況模型，要比僅以車速建模的實時路況資訊更為準確。
3．2海量資料採集
公交車資料採集:包括上下車人數、公交安全監測、位置資訊三部分。上下車人數:採用紅外對射和13．56MＲFID讀卡器，統計公交車某時刻經由某站刷卡人數和上下車人數，並計算車上在乘人數，為計算上下班出行高峰、居住和工作密集區、公交車排程方案等提供資料依據，為等候公交的乘客提供公交剩餘載客能力資訊;公交安全監測:通過紅外對射或反射感測器檢測後門是否關閉;通過MQ2煙霧和可燃氣體檢測感測器檢測是否有可燃氣體洩漏，或者在無人情況時發生自然等;位置資訊:採用GPS模組，為等候公交的乘客提供最近一班公交的位置資訊，乘客可以有更多更好的選擇。公交站點資料採集:包括環境資料和車流量兩部分。環境資料:採用DHT11溫溼度感測器採集溫溼度，採用MQ135空氣汙染感測器採集當前環境質量。結合網路上釋出的天氣預報，一同為行人提供穿衣指數、出行建議;車流量資料採集:採用ＲFID射頻識別技術統計車流量資訊，為實時路況提供資料支援。計程車資料採集:包括乘客監測和位置資訊兩部分。乘客監測:採用人體紅外檢測感測器，為智慧打車提供周邊計程車狀態資訊;位置資訊:採用GPS模組，為智慧打車提供周邊計程車位置資訊。車輛定位及測速:以車載終端附帶的GPS模組，提供車位、車速的檢測，為實時路況提供資料支援。
3．3GPS資訊採集及分析
採集的GPS資料分析是基於NMEA-0183標準協議。車載終端GPS資訊採集模組選用了U-blox公司的GPS模組NEO-6系列，支援NMEA-0183和UBX二進位制協議，定位精度＜2．5m，支援SBAS，可控誤差＜2m。本系統中，根據NMEA-0183協議完成對GPS定位和測速資訊的採集和分析。NMEA-0183格式以“”開始，其中常用的語句有6句，本系統主要使用了GPＲMC和GPVTG。GPＲMC為推薦定位資訊，其中包含了GPS應用程式所需的時間、日期、位置、方向和速度等資料，是最常用的一條語句。資料樣例如下:$GPＲMC，161227．467，A，3721．2473，N，12157．3413，E，0．17，307．63，120578，*13＜CＲ＞＜LF＞，
3．4資料幀格式定義及分析
感測器資料、ZigBee資料、ＲFID資料、GPＲS資料等都封裝成固定格式協議，便於資料的彙總和分析。GPS參考NMEA-0183資料協議。
4．5ZigBee無線感測網路搭建
分為感測器模組和ZigBee節點兩層架構。感測器模組，以STM8微控制器進行感測器資料採集，輸出都是或者轉化為數字量及開關量，以串列埠TTL電平傳給ZigBee節點。ZigBee節點，基於最流行的TI公司的CC2530晶片，支援最流行的Zig-Bee2007協議棧。ZigBee節點採用星形網路拓撲結構。
3．6資料無線傳輸
感測器資料採集後，以ZigBee無線網路傳遞給嵌入式閘道器。嵌入式閘道器將感測器資料、GPS資料、ＲFID資料，以GPＲS行動網路方式與後臺伺服器之間進行資料傳輸，採用UDP協議，並自行定義資料幀格式。
3．7GPＲS2．5G業務資料傳輸
1)GPＲS網路數傳車載終端與伺服器的通訊選用GPＲS網路為主。GPＲS模組與車載終端處理器的通訊通過串列埠完成，處理器向GPＲS模組傳送AT指令以及資料。GPＲS模組連線網路後利用TCP/UDP協議與資料伺服器和應用伺服器進行無線通訊。車載終端通過GPＲS模組實現Internet的無線接入，將車載終端要傳送的資料通過GPＲS模組無線發給中國移動GPＲS網路的'內部伺服器中，然後再傳遞到事先設定的Internet上某IP地址處，即本系統中的遠端伺服器。遠端服務也可以向車載終端返回資料，或者對車載終端實施遠端控制。系統在這裡對傳輸的資料定義了一套協議，便於資料的後續處理。
2)網路連線使用GPＲS無線裝置做數傳的時候，在連線到外部資料網時通常有兩種方法:方法一:撥號上網:常見的如撥ATD*99＊＊＊#。方法二:指定Server的IP地址、Port埠號，使用特定的AT指令來連線到外部的資料網，即Internet。兩種方式各有特點:撥號上網方式採用的是外部協議棧，需要使用者自己實現PPP、TCP、UDP等協議棧。第二種方式則採用模組自帶的協議棧，使用者的底層應用程式不需要實現上述較為複雜的協議棧。二者各有優缺點。採用第一種方式，實現起來較為複雜，但是使用靈活，使用者的資料封裝比較靈活，可以適應使用者的特殊應用。採用第二種方式，由於自身帶有完備的通訊協議棧，所以使用者實現起來較為簡單但成本較高，資料的封裝格式也較為固定。
3)流量控制為了節省GPＲS網路流量，從傳輸協議、資料編碼、協議格式、資料庫操作四個方面做個全面考慮。傳輸協議:GPＲS網路按流量計費，傳送資料包由“IP頭+UDP/TCP頭+應用資料”構成。由於UDP頭比TCP頭小12位元組，並且TCP協議還需要三次握手等額外開銷，所以實際上資料傳輸效率UDP要比TCP高。通過應用層中超時重傳等功能完全可以滿足對UDP協議中少量丟包情況的處理。資料編碼:ASCII資料經過編碼體積將大大減少，但編解碼都需要時間，也就是需要犧牲一些CPU的處理能力。折中處理，進行簡單編碼，某些欄位內容用欄位編號代替。協議格式:應用資料需要按照協議規定進行組織，採用可變長度的資料協議，可以節省很多空間。資料庫操作:部分資料如公交乘客資訊，可在到達終點時一次性寫入資料庫伺服器，而無需每到一站就傳輸一次。
4)永久線上保活機制GPＲS是聲稱永久線上的，但是如果己連線鏈路長時間沒有資料傳送，會自動壓縮頻寬，或者把網路斷開，也就是形成虛連結。由於每次GPＲS接入Internet時，GPＲS模組都會獲得一個動態IP地址，每一次GPＲS網路地址都不一樣。所以在這種情況下，一旦連線斷開，則伺服器必然無法識別終端。心跳包就是為了保證每次建立的臨時連線，在資料傳輸過程中不改變。本系統中的保活檢測就是定時發心跳包產生流量，維持資料鏈路。當需長時間收發資料時，需要保證終端線上，否則一旦網路連線斷開，將會導致資料傳輸過程失敗。如何判斷連線是否正常，一般採用定時傳送簡單的通訊包即心跳包，如果在指定時間段內未收到響應，則判斷連線已經斷開。出於效率的考慮，採用客戶端主動向伺服器端傳送心跳包的方式實現線上保活機制。考慮到資費問題，心跳包長度無需過長。在有資料收發發生時，無需傳送心跳包;只有無操作時，才傳送心跳包。在傳送心跳包過程中，需要保證一旦有接收的資料過來，立即跳轉至接收處理程式，暫停心跳傳送。不主動收發資料時，每5分鐘一個心跳包，全天24小時線上僅需耗費10K左右的流量。且在訊號較弱、無法連線伺服器時，支援延遲機制，重要資料可先儲存，等訊號穩定後再發送。
4結語
與現有技術相比，系統在公共交通智慧化，交通訊息收集、處理和釋出，智慧交通專家系統等方面做了深入研究和優化。系統底層通過不同的硬體電路模組採集了多種資料資訊，為決策研究提供了資料基礎;網路層以ZigBee和GPＲS網路作數傳，基本不受天氣、地形、位置、距離的限制;應用層以Qt、Android作使用者介面、以嵌入式SQLite和MySQL作資料儲存，為人機互動和海量資料儲存提供了介面。系統研究的機動車覆蓋公交車、計程車、私家車，參與人覆蓋行人、司機、排程員、交警和道路管理處等，研究範圍全面、客觀，實現了真正的多位一體化。