1、淺談交通部標準下的車輛衛星監控系統平臺關鍵技術摘要：本文通過研究交通運輸部于2011年頒布實施的強制標準道路運輸車輛衛星定位系統平臺技術要求及道路運輸車輛衛星定位系統終端技術要求的技術要求，分析了車輛衛星定位監控標準系統建設的意義，研究行業標準系統平臺建設的關鍵技術要點及處理方法。為交通運輸部車輛衛星定位監控系統行業標準系統平臺的建設提供技術方法建議。關鍵詞：衛星定位 營運車輛 數據庫 通信 分布式 聚合一、 引言目前GPS定位已被廣泛應用于交通運輸行業，它利用GPS的定位技術結合無線通信技術（GSM、CDMA、3G）、地理信息管理系統（GIS）等高新技術實現對車輛的監控，通過無線數字通道將車

2、輛定位和狀態信號輸送到車輛監控中心，然后通過GIS將位置信號用地圖語言顯示出來，最終可通過服務中心實現車輛的定位監控、防盜反劫、服務救援、數據上報、軌跡記錄等功能，并引申到其他相關服務。 當前國內GPS的應用發展勢頭迅猛，車載GPS的監控調度管理經過多年的發展和培育，已進入規模發展時期，交通運輸行業相關部門已充分意識到它在交通信息化管理方面的優勢。然而，當前GPS車輛監控管理市場上當前仍是各個廠家各自為陣，各個廠家的車臺終端和平臺軟件仍互不兼容，導致市場開拓和應用上困難重重，各個廠家為了爭奪市場，不惜降低成本、質量進行價格戰，同時在軟件功能上也常常為爭奪市場也無限制滿足用戶不切實際的

3、個性化需求，甚至有些用戶不惜免費提供平臺軟件。表現為當前的GPS系統用戶容量較小、功能定制性的特征明顯、功能不靈活、終端產品兼容性差等特點，總體來看這種局面不利于GPS行業的健康發展，也無法給運營商帶來可觀、規?；氖杖搿Ｈ绱藧盒愿偁幍沫h境情況下，非常不利于我國車輛衛星定位監控管理行業的良性健康發展。分析形成這種局面的原因，固然跟GPS監控目前自身的一些特點有關，例如，行業鋪蓋面廣，發展時間不足沒有行業統一標準等。但是也跟一些gps系統構建廠商急功近利急于推廣市場，沒有分析清楚用戶的真正需求，沒有研究摸透GPS監控系統的特點，采用的一些系統構建技術不合理、不到位有關。分析當前的許多聲稱成熟的G

4、PS監控管理系統，他們僅僅是從用戶應用功能角度出發，采用一些現成的技術簡單集成應用，他們所做的只僅僅是：1. 構建一個和車臺終端的通信服務器實現和車臺終端的通信和數據轉發；2. 在一臺物理服務器上安裝一個數據庫軟件，用來存儲系統的GPS數據和用戶數據；3. 采用現有的GIS引擎技術構建一個能展示車輛動態目標對象和車輛管理軟件；4. 根據實際用戶特定需求和現有一些特定廠家的車載終端協議功能被動構建系統。采用這樣的簡單方案，受過正規訓練的IT工作者在12年內應該能徹底掌握這些開發技術，并且在半年到一年內開發出符合一些特定功能要求的系統，但是這是最初級的層次。這樣簡單構建的系統在系統可靠性、安全性、

5、性能用戶數量都面臨較大的挑戰。交通行業監管為了解決這一行業難題，同時也看到GPS定位技術在車輛交通運輸行業的應用的廣大發展空間，歷時兩年，由交通部牽頭起草制定了道路運輸車輛衛星定位動態監控系統標準要求，力求規范并解決這一行業難題，對行業的車輛衛星定位監控平臺和車載設備終端進行規范。目前關于這一行業標準的各項標準文件已經發布，整個標準文件是經過整個業界進行了多次調研收集需求后，并且經過多次反復認證后形成的。應該說標準里面的對功能、性能、安全性的需求描述已經較為全面，且實現思路、設計流程經過業界專家的認證，標準在實現上已基本較為合理，能較好的滿足交通運輸行業對車輛衛星定位行業監控管理的通用要求。目

6、前該標準作為行業標準已經強制發布實施。有別于傳統的小用戶量定制型GPS車輛監控管理系統，目前標準中要求的系統的功能、技術、協議更合理，對系統容量、可靠性、性能、安全性要求更高。具體包括了平臺的功能技術要求、車載終端的功能技術要求、平臺和車載終端間數據交換協議的標準、平臺和平臺間協議交換標準。這些標準的出臺，很大程度上提高車輛衛星定位行業的準入門檻，同時規范了車輛衛星定位監控市場的秩序，避免了各自為戰重復研發，以及惡性競爭給行業發展造成的不良影響。另一方面，對各個系統和車載終端設備研制生產廠家的研發、制造能力要求都更高，并且對于各個產業運營商的系統建設和管理服務水平也有較高的要求。本文從系統平臺

7、建設的角度出發，淺談一下個人對交通行業標準系統平臺建設的一些看法，并提出一些潛在的問題和可能的解決辦法。二、 數據庫的訪問速度限制問題。當前的主流單機數據庫系統的情況下，限于磁盤I/0的訪問速度，一般每秒只有20006000之間插入存儲性能。由于車輛衛星定位監控管理系統具有數據量大、數據頻次高、實時性強的特點，總體對數據庫的處理能力要求比較高。根據標準要求要支撐10萬輛以上車輛使用，如果每輛車每隔30秒上報一條數據的話，要求系統每秒鐘的處理插入速度應該要求在3千條以上，而在峰值的時候應該更多，同時還要考慮數據庫的其它查詢應用操作。因此，如果在普通的單機數據庫環境下，常規數據庫的做法必然成為車輛

8、接入數量增加的瓶頸。而通過增加硬件性能，例如引入基于傳統的以小型機/大型機作為載體的集中式數據庫系統固然可以在一定程度上解決數據瓶頸的問題，但是系統構建成本較高，而且當車輛數多到一定程度時處理能力也不一定能滿足應用的需求。因此，對車輛衛星定位系統平臺的建設，需要考慮使用其它的數據庫解決方案，這里建議采用分布式數據庫系統或數據庫集群等技術來解決數據存取的訪問瓶頸問題。可以從幾個方面共同提高發揮數據庫的性能。首先，通過數據庫自身的一些特性來優化使用數據庫，降低數據庫的對磁盤IO的訪問次數。通過使用數據庫記錄批插入技術，使用動態交換緩存表等操作方法降低數據庫的訪問頻次，充分發揮單機數據庫的性能。對于

9、數據庫的并發查詢，通過一些關鍵表數據預處理技術，以及對一些關鍵數據緩存的策略實現提高查詢性能其次，通過數據庫的集群鏡像技術，以及通過代理軟件實現讀寫分離，以避免讀寫操作不互相影響，以解決數據庫訪問性能瓶頸。例如，在MySql下，數據庫采用成熟的MySQL-HA-Proxy、Amoeba等代理軟件方案等，使讀寫操作分離，當然也可以自己編寫數據庫代理軟件實現讀寫分離的方案。對于數據庫的并發查詢，通過集群的負載均衡技術的讀寫分離，可以一定程度上降低數據庫讀操作對寫操作造成的影響。此種方案可以作為系統車輛數和業務數據不是非常多的情況下的一種較優解決方案，例如，在10萬輛以下車載終端接入的情況下，可以較

10、好的滿足要求。再次，通過引入數據庫分庫設計的思想解決大數據量數據并發操作的問題。對于系統平臺的車載終端接入數據量達到一定程度時，系統對某些表的操作很頻繁，單純的數據庫操作達到每秒幾千次寫操作時，這時采用單一的數據庫主機的方式很難達到性能要求，需要考慮引入數據庫分庫設計的方法來解決業務增長帶來的數據庫壓力問題。分庫設計是最好的解決系統數據庫訪問瓶頸的解決辦法，但實現復雜。一種比較好的分庫方法是通過按照行關鍵字對數據庫表進行拆分或是一種分庫選擇，然后通過引入數據庫代理層軟件，在數據庫代理層定義需要進行行數拆分的表和拆分規則，屏蔽拆分方式對應用程序系統的改造，使之對開發人員透明。目前業界實現了該種分

11、庫規則的代理數據庫，屬于開源的數據庫代理中間件有PGPool-II，PGPool-II是一個工作在PostgreSQL數據庫服務器和PostgreSQL數據庫客戶端之間的中間件。當然根據采用的數據庫類型不同可以采用相應的數據庫分庫代理軟件或者自己編寫數據庫代理軟件實現分庫規則。三、 系統平臺數據通信問題。車輛衛星定位監控平臺最大的特點就是數據量巨大，數據實時性強，因此數據通訊機制直接影響到整個系統的穩定性及性能。影響因素有并發通信能力、數據處理能力以及數據處理速度。以標準要求的10萬輛車載終端將帶來每秒將帶來的是40M左右的通信流量，如果用普通的數據通信處理方式，勢必造成數據在中心服務器的阻塞

12、問題。系統建設除了要申請足夠接入帶寬外，還需在程序上進行業界關鍵技術的應用，并要優化設計，避免關鍵數據堵塞延時問題。首先，解決平臺和車載終端間的實時通信問題處理。標準中已制定了采用TCP、UDP協議進行中心和車載終端間數據通信，每個終端在連入系統的時候就要建立起一個長連接，整個系統在滿負荷情況下要同時維持十萬數量級的長連接，在如此數據量的長連接下，如何在保證數據實時性的情況下有效提高單臺接入服務器的客戶端連接數，就成為系統設計時必須考慮的問題。目前常規的TCP通訊IO模型一般只能維持單臺服務器2000個左右的客戶端長連接，如果以此數目推算，系統要接入所有十萬臺車載終端，則需要幾十臺左右的通信前

13、置機，極大的增加了系統的硬件開銷。建議系統可以采用了當前TCP通訊中最高級的完成端口IO模型，該IO模型實現復雜，要成熟化穩定運行需要大量的系統實際實踐才能演變出車輛衛星定位監控行業業務相匹配的架構，但是比較好的選擇方案之一。其次，解決系統平臺的服務器設備間的數據交換的可靠性、及時性。在大數據量協議交換的數據量情況下，如何保證系統平臺的服務器設備間的數據交換的可靠性、及時性也是需要重要考慮的。系統平臺服務器設備間往往存在雙向的數據通訊要求，特別是車輛的位置數據定時上傳，數據量大，發送頻次高，在通訊峰值中，會出現短暫的鏈路擁堵情況，這時，客戶端要下發命令到服務器就會無法即時下發或者得不到及時響應

14、，嚴重影響了系統的響應時間。通過引入雙通道通訊機制，特別是在用戶操作終端與服務器端建立兩個通訊通道，一個是數據通道，一個是指令通道，數據通道專門負責常規的GPS定位數據上傳，圖片數據上傳等，該類數據允許在系統忙時部分丟失數據，而指令通道則專門負責對實時性要求比較高的常規指令的執行，以及系統設備間認證和鏈路維護指令傳輸作用，該通道需保證數據的及時性和可靠性。系統最終可以通過通信中間件的設計，實現滿足雙通道通信機制的通信中間件，作為各個中心軟件設備間的通信用途要求，同時達到構件復用的目的。再次，引入數據分類優先處理規則。對于系統中一些數據通道的數據需進行優先級分類，并根據優先級別進行轉發處理，例如

15、，報警類的數據需保證其得到盡量及時，并優先得到處理。當平臺系統中存在大量的車輛終端同時向GPS數據中心服務器上報數據時，可能會造成 GPS 中心服務器的數據延遲，在這種情況下，GPS 中心服務器將優先把延遲數據中的報警信息報文和命令應答報文發送到GPS監控指揮工作站，使客戶能夠及時處理報警信息。 最后，做好數據通信的流控機制。為了保證系統的通信和業務處理的正常進行，還需對系統的通信處理引入流控機制。在整個系統中，數據從車載終端發出，依次經過運營商系統、接口服務器、系統接入前置機、業務服務器，最后存儲到數據庫服務器中，監控調度工作站再從數據庫獲取需要的數據呈現給用戶?？梢钥闯?， GPS車載終端是

16、數據的生產者，數據庫服務器是數據的消費者，而系統接入前置機和業務服務器則是中間的流通環節。GPS車載終端的數量和匯報的頻率決定了數據生產的速度，而數據庫服務器的數據處理能力決定了數據消費的速度。 數據流通示意圖 拋開運營商的系統，要保證整個系統數據流通的穩定，需要盡量提高消費速度，即數據庫服務器的處理能力，還要確保中間流通環節系統接入前置機和業務服務器的穩定暢通。在實際的設計中，系統接入前置機和業務服務器都各自擁有一個數據緩沖隊列，當前一個流通環節產生阻塞時，所接收的數據都將會緩存在這個隊列里面。在極端的情況下，當緩沖隊列滿時，為了保證數據傳輸的穩定性，在保證重要數據（如報警數據、車載終端應答

17、數據等）的情況，對車載終端數據進行部分丟棄并產生系統報警。四、 引入分布式、負載均衡實現機制，保證擴展性。系統平臺的車輛接入總量一般都是隨著業務的開展而逐漸增長，系統架構應該滿足橫向與縱向的擴展的需求。在無需修改程序，不需要移動數據庫數據的情況下，通過一些簡單的設備安裝，參數配置，實現支持系統內各設備的平穩升級，進而提高系統的車載GPS終端與操作終端工作站的接入數量，這是車輛衛星定位監控系統平臺的基本要求。在實際部署系統服務器的時候，應該根據系統當前的車載終端接入量與階段業務增長預期，采取階段性增長的部署方案，從1萬輛接入的服務器部署到5萬輛的服務器部署再逐步增長到10萬、20萬量的部署。如果

18、系統不支持這種靈活伸縮，就會給客戶造成較大困擾。在橫向擴展上，若一開始部署的服務器所支持的車輛接入量較少，則在業務增長到一定程度后，出現系統瓶頸，就會影響系統的正常使用；而一開始部署服務器所支持的車輛接入量過多的話，若業務增長預期緩慢，則會造成大量的資源浪費；在縱向擴展上，若系統架構無法滿足業務的擴展需求，則無論添加多少服務器都無濟于事。當系統平臺內接入的客戶端數目達到一定數目，各接入服務器也自然增長到相當規模，此時設備間通訊的路由就變得錯綜復雜，若各設備所承擔的任務如果沒有做很好的統籌管理，就容易出現部分設備繁忙，而部分設備空閑的現象，直接的影響就是系統內各服務器尚未有效發揮資源的情況下，就

19、出現了運行瓶頸。為了解決以上描述的問題，同時也為了解決系統關鍵設備單點故障問題，可以在系統內引入負載均衡機制，主要是為了協調系統內各設備的工作，需要考慮的機制有：（1）車載GPS終端與通信前置機之間的負載均衡機制；（2）通信前置機與業務服務器之間的負載均衡機制；（3）企業工作站與接入服務器之間的負載均衡機制；（4）業務服務器與接入服務器之間的負載均衡機制。當然為了保證這么多服務器設備間的協同工作，系統還需引用一些技術輔助實現。例如，全局的緩存服務器技術、關系型內存服務器技術、一致性哈希算法策略使用等，這里就不詳細介紹。五、 大批量的車載終端圖標在地圖上的刷新顯示問題。對于GPS車輛定位管理系統

20、需要最終展現給管理者大量車輛記號在地圖上的實時位置，當車輛數多，并且車輛位置更新變化頻繁時，對于系統操作終端車輛位置在地圖上的刷新展示的壓力非常大。一般的做法是來一個車輛位置信息就在地圖上更新變化位置，這種實現方法在主流的工作站PC電腦根本處理不過來。即便通過緩存技術，定時批量更新位置信息也最多只能支撐到1000-2000個車輛記號圖標在地圖上刷新顯示。而對于交通部行業標準要求的10萬輛級別車輛的實時刷新顯示問題，一般的做法更是難上加難。因此需要引入一些算法和實現手段進行特殊處理。在GIS行業中顯示大量POI記號數據時，我們經常引用到通過地圖聚合解決大量poi在屏幕上顯示雜亂無章的問題。這里我

21、們也可以借用GIS里常用到的地圖聚合原理來實現大量動態車輛圖標在地圖上的刷新顯示問題。只是有別于poi的聚合顯示是靜態的，可以根據地圖的縮放級別預先處理好，而車輛衛星定位監控系統的車輛圖標記號是動態變化的，需要根據車輛位置、地圖縮放動態計算聚合的圖元。實踐證明這種方法非常有效的，同時可以解決大量車輛圖標重疊雜亂無章展示的問題。六、 大量圖片、視頻數據的存儲訪問問題。車輛衛星定位監控系統的重要功能是拍照和視頻采集功能。當車載終端和接入的用戶終端越來越多，系統上傳的圖片或采集的視頻文件數量將越來越多，例如：在同一時刻，1萬個車載終端同時拍照向中心上傳圖片數據時，中心系統的對數據存取效率和存儲空間是

22、要重點考慮的問題，要不勢必形成系統業務處理的一個瓶頸，同時也對系統的存儲空間要求提出了挑戰。傳統的做法企業在存儲超過1TB以上數據文件時，一般是采用DAS/NAS/SAN架構。此類架構存儲幾十TB以下數據還可以接受，但成本很高，比如采用NAS，一般搭一套2TB左右的系統，就需要花費100萬左右，而若使用SAN架構，成本還會更高。因此對于構建車輛衛星定位監控管理系統這類的成本不能要求太高的系統，為了存儲訪問更大量的數據文件，需要改變原有的思想，采用新的架構，建議采用分布式文件系統解決方案。目前可以借鑒的分布式文件系統的解決方案有谷歌的GFS與Hadoop的HDFS，以及阿里巴巴的ADFS分布式文件系統解決方案，具體的這些分布式文件系統的解決方案實現原理這里不細說，可以參考相關的資料。由于車輛衛星定位監控管理系統平臺需要的存儲訪問的文件粒度比較小，這里偏向于采用阿里巴巴ADFS分布式文件系統的存儲訪問的解決方案?；蛘呋谠擃愇募到y的解決方案原理，可以在此基礎根據車輛衛星定位監控系統的特點進行適宜性的改進以