車輛導航系統(tǒng)增量數(shù)據(jù)在線交換平臺設計*

曹劍東，楊 楊，羅明慧，張新豐

(1.交通運輸部科學研究院，北京 100029； 2.同濟大學新能源汽車工程中心，上海 201804)

2016178

車輛導航系統(tǒng)增量數(shù)據(jù)在線交換平臺設計*

曹劍東1，楊 楊1，羅明慧2，張新豐2

(1.交通運輸部科學研究院，北京 100029； 2.同濟大學新能源汽車工程中心，上海 201804)

本文中提出了一種在車輛導航系統(tǒng)中用于實時更新導航數(shù)據(jù)而進行增量數(shù)據(jù)在線交換的平臺，并針對數(shù)據(jù)的更新設計了導航地點和路線的增量數(shù)據(jù)的交換機制。該平臺以中心-終端交換式平臺為基礎，結合GPRS和FTP技術，實現(xiàn)了在車載導航設備與數(shù)據(jù)源服務器之間的在線數(shù)據(jù)交換。在此基礎上，采用終端請求模式，針對增量數(shù)據(jù)的請求、回復和文件傳輸分別設計了相應的數(shù)據(jù)交換機制。最后通過增量數(shù)據(jù)在線交換試驗，驗證了該平臺的可靠性與實時性。

車輛導航；增量數(shù)據(jù)更新；在線交換；導航地點；導航路線

前言

車輛導航系統(tǒng)是智能交通運輸系統(tǒng)的一個重要組成部分。目前傳統(tǒng)的車輛導航系統(tǒng)主要采用離線版本式的數(shù)據(jù)更新方法。這種方式步驟復雜，更新周期較長，難以保證數(shù)據(jù)的實時性[1-2]。因此，有必要為車輛導航系統(tǒng)增加在線數(shù)據(jù)更新的能力，以提高系統(tǒng)中地點和道路等數(shù)據(jù)的實時性。

車輛導航系統(tǒng)的增量數(shù)據(jù)更新是指以增量的形式，為行駛中車輛的導航系統(tǒng)提供導航數(shù)據(jù)的更新和擴展，以提高導航系統(tǒng)的數(shù)據(jù)實時性和導航能力。其難點在于如何實現(xiàn)對行駛中車輛進行實時的數(shù)據(jù)傳輸。

在目前的研究與應用中，一般通過建立融合無線通信技術的中心-終端式交換平臺來解決增量更新的問題。根據(jù)研究[3-4]，該平臺的信息中心可從內(nèi)容提供方獲取被查詢內(nèi)容的數(shù)據(jù)，移動終端向信息中心發(fā)出查詢請求，信息中心根據(jù)請求，查詢到滿足條件的內(nèi)容后，將數(shù)據(jù)以確定的數(shù)據(jù)格式構成數(shù)據(jù)包，發(fā)送給移動終端，從而實現(xiàn)移動設備與信息中心之間的數(shù)據(jù)交換。由于用Web服務架構建立傳輸通道，可使用無線通信技術建立移動的車輛終端與互聯(lián)網(wǎng)的通信連接，即可解決移動設備與信息中心之間在線數(shù)據(jù)交換的問題。

同時，還需要根據(jù)行駛中車輛的特點選擇合適的無線通信技術。可用于車載導航設備的無線通信技術包括GPRS，CDMA和藍牙等[5-6]，GPRS通信技術在實時數(shù)據(jù)傳輸中具有顯著優(yōu)點[7]，并已有研究建立了基于GPRS技術的移動設備通信鏈路[8]。為了實現(xiàn)增量數(shù)據(jù)的交換，在建立數(shù)據(jù)傳輸通道的基礎上，還需要確定合適的數(shù)據(jù)交換模式，常用的有中心推送模式和終端請求模式[2]，與中心推送模式相比，終端請求模式的系統(tǒng)擴展性較好，靈活性較高，成本較低。

根據(jù)以上分析，本文中選取結合GPRS技術與中心-終端式交換平臺，并采用終端請求模式，為車載導航設備的數(shù)據(jù)更新功能設計了增量數(shù)據(jù)交換機制，用以實現(xiàn)移動的車載導航設備與增量數(shù)據(jù)中心進行實時的數(shù)據(jù)交換。

1 車載導航增量數(shù)據(jù)的交換平臺

車載導航設備的數(shù)據(jù)交換平臺由增量數(shù)據(jù)中心Cn、車載導航設備Nm和通信網(wǎng)絡構成，如圖1所示。其中，增量數(shù)據(jù)中心儲存并傳輸增量數(shù)據(jù)；車載導航設備接收導航增量數(shù)據(jù)；無線通信網(wǎng)絡用于實現(xiàn)數(shù)據(jù)中心與導航設備之間的數(shù)據(jù)交換。

圖1 車載導航設備的增量數(shù)據(jù)交換平臺

1.1 車載導航設備

傳統(tǒng)的車載導航設備基于嵌入式主板，安裝GPS接收模塊、存儲設備、顯示設備和輸入設備。為使車載導航設備具有無線通信能力，在該平臺中安裝了GPRS模塊，因此需要嵌入式主板可外接串口設備以連接GPRS模塊。為了儲存不斷更新擴展的導航數(shù)據(jù)，為車載導航設備配置閃存卡作為外部存儲設備，其容量可根據(jù)應用的地理信息系統(tǒng)規(guī)模和更新速度進行估算。當所儲存的數(shù)據(jù)增長到閃存卡儲存上限時，可更換存儲空間更大的閃存卡。若無特殊說明，本文中車載導航設備均指可以進行在線增量數(shù)據(jù)交換的車載導航設備。

1.2 增量數(shù)據(jù)中心

在增量數(shù)據(jù)中心，多臺計算機服務器集群系統(tǒng)以局域網(wǎng)為主干，連接一定數(shù)量的服務器，通過其并行計算提高中心的請求處理能力[9]。通過增加中心的數(shù)量，形成多個中心為不同區(qū)域的車載導航設備群服務，可進一步增加可服務的用戶規(guī)模。

當多個增量數(shù)據(jù)請求進入數(shù)據(jù)中心時，在中心網(wǎng)關與局域網(wǎng)間設置的請求分配服務器根據(jù)局域網(wǎng)內(nèi)各服務器的負載情況，將請求分配給有較多空閑資源的服務器。服務器在使用增量數(shù)據(jù)時，則可從局域網(wǎng)上的數(shù)據(jù)庫服務器中提取，這樣既減少了數(shù)據(jù)占用的存儲空間，又保證了增量數(shù)據(jù)的一致性。在計算服務器處理完增量請求后，將增量數(shù)據(jù)放置在請求分配服務器中，由請求分配服務器通知發(fā)出該請求的車載導航設備到服務器下載增量數(shù)據(jù)。

1.3 增量更新

圖2 單個設備與非集群增量數(shù)據(jù)中 心構成的增量數(shù)據(jù)交換平臺

增量更新可在單個車載導航設備Nd和非集群的增量數(shù)據(jù)中心Ce的簡化模型下進行研究，如圖2所示。根據(jù)該模型設計的方法，結合計算機集群技術，可推廣到大規(guī)模車載導航設備的情況中。以下均在此模型下對增量更新問題進行敘述。

2 導航增量數(shù)據(jù)的交換模式

增量數(shù)據(jù)交換包括中心推送模式和終端請求模式[2]。在終端請求下，由車載導航設備主動發(fā)起數(shù)據(jù)請求，增量數(shù)據(jù)中心根據(jù)請求形成增量數(shù)據(jù)后，再由車載導航設備主動獲取數(shù)據(jù)。增量數(shù)據(jù)中心處于等待響應的工作狀態(tài)，可減輕增量中心的通信和計算壓力，且無需對導航設備的連接信息進行保存。為了便于增量數(shù)據(jù)的發(fā)送，可在增量數(shù)據(jù)中心將數(shù)據(jù)以文件的形式儲存，這樣僅根據(jù)文件的存儲路徑和文件校驗信息即可保證數(shù)據(jù)的準確。

由以上分析可見，增量數(shù)據(jù)的交換過程中存在增量數(shù)據(jù)請求、增量數(shù)據(jù)回復和增量數(shù)據(jù)文件3種類型的數(shù)據(jù)。

2.1 車載導航設備數(shù)據(jù)請求的發(fā)送

數(shù)據(jù)請求由車載導航設備發(fā)送。為保證請求成功被數(shù)據(jù)中心接收，采用重復請求的方法進行數(shù)據(jù)請求，即車載導航設備在等待期間內(nèi)持續(xù)發(fā)送相同的數(shù)據(jù)請求消息，直至收到數(shù)據(jù)中心的回復消息。通過這種方法可避免由于移動數(shù)據(jù)網(wǎng)絡的連接不穩(wěn)定而造成請求發(fā)送失敗的問題。

數(shù)個內(nèi)容完全相同的子請求構成了一個請求單元，多個請求單元構成了車載導航設備Nd的數(shù)據(jù)請求集合R：

R={ri,j|i=1,2,…,n;j=1,2,…,m(i)}

式中：ri,j為一個子請求；i為子請求父序，表示ri,j所表示的子請求在數(shù)據(jù)請求集R中的序號，n表示集合中所包含的請求單元的總數(shù)；j為子請求子序，表示ri,j在父序為i的請求單元中的序號，m(i)表示序號為i的請求單元中包含的子請求數(shù)量。

由于車載導航設備的性能限制，不可能非常密集地對請求進行重復發(fā)送，因此需要在相同的子請求發(fā)送間設置一時間差以滿足系統(tǒng)的數(shù)據(jù)處理能力。時間差的具體數(shù)值可通過網(wǎng)絡狀況估計。在數(shù)據(jù)請求集R中子請求的時間排列依據(jù)以下兩個原則。

(1) 同父序連續(xù)排列 相同父序i的子請求ri,j，在時間軸上總是按序號j遞增連續(xù)排列。

(2) 回復中斷 車載導航設備收到來自數(shù)據(jù)中心的回復后，即刻停止對當前子請求發(fā)送。

增量請求集R中各子請求在時間軸上的排列如圖3所示。其中，ai是對增量請求集R中父序為i的子請求的回復。

圖3 增量子請求在時間軸上的排列

子請求的信息中應包括導航設備的增量數(shù)據(jù)要求、導航設備的ID和表示子請求的編號i和j。根據(jù)以上信息，數(shù)據(jù)中心可得知導航設備的需求，對車輛進行識別，并確定子請求所屬的請求單元。描述這些信息所需的數(shù)據(jù)量較小，可采用多級分段的文本格式，如圖4所示。

圖4 增量數(shù)據(jù)請求的文本格式

其中，類型碼用于表示增量數(shù)據(jù)請求的類型，如表1所示。正文中是請求的主要內(nèi)容，包含上文中提到的各種信息。校驗碼用于校驗所接收到的請求文本是否有損壞，采用奇偶校驗。

表1 增量數(shù)據(jù)請求文本的類型碼

2.1.1 導航地點增量數(shù)據(jù)請求

導航地點增量請求文本格式如圖5所示。

圖5 增量數(shù)據(jù)請求的基本文本格式

其中，K為車載導航設備Nd的ID，n為子請求父序數(shù)，m為子序數(shù)，T為設備Nd中的導航地點標識。

2.1.2 導航路線數(shù)據(jù)請求

導航路線數(shù)據(jù)的增量請求消息中包擴導航起點坐標(x0,y0)和目的地坐標集合{(xi,yi)}，其文本格式如圖6所示。其中x0為起點的經(jīng)度，y0為起點的緯度；xi為目的地的經(jīng)度，yi為目的地的緯度；L為導航終點的數(shù)量。

圖6 路徑規(guī)劃能力增量請求的文本格式

2.2 數(shù)據(jù)中心的增量描述

數(shù)據(jù)中心根據(jù)收到的數(shù)據(jù)請求的內(nèi)容進行計算，并作出相應的回復。回復用來告知車載導航設備增量數(shù)據(jù)的信息，如增量數(shù)據(jù)文件的存儲路徑等。

與增量數(shù)據(jù)請求的重復請求方法相配合，為避免多次回復造成網(wǎng)絡堵塞，數(shù)據(jù)中心對于同一父序的子請求序列，只回復收到的第一條校驗正確的子請求，對后續(xù)請求不做回復。設對子請求ri,j的回復為Θ(ri,j)，則有

(1)

式中ai為數(shù)據(jù)中心對父序為i的數(shù)據(jù)子請求的回復。當數(shù)據(jù)中心收到校驗錯誤的子請求時，將拋棄該條子請求不作處理；而當車載導航設備收到回復，但檢查到校驗錯誤時，應繼續(xù)發(fā)送同樣內(nèi)容的子請求。

增量數(shù)據(jù)回復主要以描述信息為主，所含數(shù)據(jù)量小，同樣可使用文本格式。增量數(shù)據(jù)回復文本采用與增量數(shù)據(jù)請求相同的多級分段的格式，如圖7所示。

圖7 增量數(shù)據(jù)回復的基本文本格式

其中，類型碼如表2所示。由于增量回復數(shù)據(jù)長度較短，同樣可采用簡單的奇偶校驗。

表2 增量數(shù)據(jù)回復的類型碼

2.2.1 導航地點增量數(shù)據(jù)回復

導航地點增量數(shù)據(jù)回復用于告知車載導航設備增量數(shù)據(jù)文件的獲取方法，內(nèi)容包括增量數(shù)據(jù)文件的數(shù)量、所有文件的存儲路徑和校驗信息。

設增量數(shù)據(jù)文件集合為

F={ft|t=1,2,…,D}

(2)

式中：ft為增量數(shù)據(jù)文件；D為文件的數(shù)量，若D為0，則說明車載導航設備與數(shù)據(jù)中心的導航地點數(shù)據(jù)已同步。設ft的文件路徑為βt，文件校驗信息為γt，則增量數(shù)據(jù)回復的文本格式如圖8所示。

圖8 導航地點增量數(shù)據(jù)回復的文本格式

考慮到車載導航設備的負載，為減少文件校驗占用的資源和時間，實際中根據(jù)文件的字節(jié)長度作為校驗信息。

2.2.2 導航路線增量數(shù)據(jù)的回復

回復的內(nèi)容須包括文件在增量中心服務器上的存儲路徑和文件的校驗信息。設所發(fā)送的最佳導航路線文件為f，文件儲存路徑為β，校驗信息為γ，則導航路線增量數(shù)據(jù)回復的文本格式如圖9所示。

圖9 導航路線增量數(shù)據(jù)回復的文本格式

回復文件同樣可根據(jù)文件的字節(jié)長度進行校驗。

2.3 增量數(shù)據(jù)文件的傳輸

通過對回復文件中導航數(shù)據(jù)儲存路徑的解析，導航設備可從數(shù)據(jù)中心的服務器中獲取所需的導航數(shù)據(jù)。對于文件的獲取，可通過FTP(File Transfer Protocol)技術來實現(xiàn)。FTP文件傳輸協(xié)議是基于TCP/IP協(xié)議向用戶提供文件傳輸服務的網(wǎng)絡協(xié)議之一。本文中所述的增量數(shù)據(jù)交換平臺由于采用了GPRS模塊，因此可使用TCP/IP協(xié)議，增量數(shù)據(jù)文件的傳輸則可通過FTP技術實現(xiàn)[12]。

FTP是基于客戶-服務器模型設計的，這種模型可與增量數(shù)據(jù)交換平臺相結合，使平臺具有FTP文件傳輸能力，如圖10所示。

圖10 基于FTP傳輸文件的增量數(shù)據(jù)交換平臺

為實現(xiàn)圖10中的結構，需要在車載導航設備上加入FTP客戶端模塊，在數(shù)據(jù)中心加入FTP服務器端模塊。車載導航設備通過FTP客戶端向FTP服務器端發(fā)出文件操作請求，即可從數(shù)據(jù)中心的服務器上獲取增量數(shù)據(jù)文件。

設車載導航設備向數(shù)據(jù)中心服務器獲取增量數(shù)據(jù)文件集合為

F={fi,t|i=1,2,…,P;t=1,2,…,D(i)}

(3)

式中：fi,t為增量數(shù)據(jù)文件，i為回復序，與數(shù)據(jù)請求順序對應；t為單次數(shù)據(jù)請求需獲取的文件集合內(nèi)的序，稱為增量數(shù)據(jù)文件序；D(i)為單次增量的文件數(shù)量。單次增量的文件集合可描述為

Fi={fi,t|t=1,2,…,D(i)}

(4)

可見，F(xiàn)i與增量回復ai一一對應。當ai為導航地點增量數(shù)據(jù)回復時，D(i)為與增量數(shù)據(jù)組數(shù)相關的非負整數(shù)；當ai為導航路線增量數(shù)據(jù)回復時，D(i)為1。由此，通過在增量數(shù)據(jù)回復ai中對Fi進行的描述，使車載導航設備可根據(jù)文件路徑向數(shù)據(jù)中心提取增量文件集合Fi。圖11顯示了單次增量數(shù)據(jù)交換中增量數(shù)據(jù)的請求、回復和增量數(shù)據(jù)文件的傳輸。

圖11 車載導航設備與數(shù)據(jù)中心間單次增量數(shù)據(jù)傳輸

由于不同類型的增量數(shù)據(jù)回復文件信息描述的協(xié)議不同，因此在解析文件信息時也有著不同的步驟，以下分別敘述。

2.3.1 導航地點增量數(shù)據(jù)回復文件

設導航地點增量數(shù)據(jù)回復如圖12所示。

圖12 車載導航設備收到的導航地點增量數(shù)據(jù)回復

由回復可知，回復文件數(shù)量為D，文件路徑為βt，校驗信息為γt，t為文件序，滿足

t=1,2,…,D

(5)

因此，可根據(jù)文件路徑βt獲取對應增量數(shù)據(jù)文件，設為ft，其校驗信息為γt，若滿足

λt=γt,t=1,2,…,D

(6)

則增量數(shù)據(jù)文件獲取成功，否則重新獲取校驗失敗的增量數(shù)據(jù)文件。

由此，可設計車載導航設備Nd獲取導航地點增量數(shù)據(jù)文件的步驟如下：

(1) 建立與增量中心Ce的FTP連接；

(2) 令獲取文件序t=1；

(3) 若t≤D，根據(jù)文件路徑βt從FTP服務器端提取到增量文件ft，若t>D，則獲取結束；

(4) 若ft的校驗信息λt=γt，則校驗正確，令t遞增1，返回步驟(3)，若λt≠γt，則校驗錯誤，直接返回步驟(3)。

2.3.2 導航路線增量數(shù)據(jù)文件

設導航路線增量數(shù)據(jù)回復如圖13所示。由回復可知，導航路線文件在服務器的儲存路徑為β，校驗信息為γ。

圖13 車載導航設備收到的導航路線增量數(shù)據(jù)回復

因此，可根據(jù)文件路徑β獲取導航路線文件，設為f，其校驗信息為λ，若λ=γ，則文件獲取成功，否則重新獲取導航路線文件。

3 增量數(shù)據(jù)在線交換的試驗驗證

為檢驗以上增量數(shù)據(jù)數(shù)據(jù)交換平臺及機制，進行了數(shù)據(jù)交換的試驗。車載導航設備基于嵌入式計算機構建，采用的CPU是主頻300MHz的ARM處理器CPU，內(nèi)存64MB，外存為2GB的SD存儲卡，而GPRS模塊則采用了WAVECOM Q2403A。增量中心基于臺式機構建，采用主頻為3GHz的雙核CPU，內(nèi)存2GB，且通過固定網(wǎng)絡直接連接到互聯(lián)網(wǎng)中。開發(fā)工具均采用Microsoft Visual C++2005。

為驗證增量數(shù)據(jù)交換機制，對車載導航設備發(fā)送增量數(shù)據(jù)請求和數(shù)據(jù)中心返回增量數(shù)據(jù)回復的過程進行了試驗。試驗中，分別記錄車載導航設備發(fā) 出10次增量數(shù)據(jù)請求，獲得回復的耗時Δt，如表3所示，其中i表示增量數(shù)據(jù)請求的父序。

表3 車載導航設備獲得回復的耗時

試驗結果顯示，每次增量數(shù)據(jù)請求獲得數(shù)據(jù)中心的回復耗時都保持在4～5s左右，基本可以滿足對增量數(shù)據(jù)交換實時性的要求。

同時，對增量數(shù)據(jù)文件的FTP傳輸方法進行了試驗，試驗中文件的傳輸平均速度達到10kB/s，基本可以滿足增量數(shù)據(jù)文件的傳輸需求。

4 結論

針對目前車輛導航系統(tǒng)數(shù)據(jù)更新的不足，本文中提出了可增量更新的車輛導航系統(tǒng)，并對導航地點數(shù)據(jù)增量方法進行了研究，結果表明：車載導航設備的數(shù)據(jù)交換平臺構建了車載導航設備與數(shù)據(jù)中心間交換增量數(shù)據(jù)，以及車載導航設備融合增量數(shù)據(jù)的物理平臺，為行車中的增量數(shù)據(jù)在線交換提供了基礎；導航增量數(shù)據(jù)交換機制設計了增量數(shù)據(jù)在線交換的機制，為導航地點數(shù)據(jù)增量及路徑規(guī)劃能力增量制定了增量數(shù)據(jù)格式，從而確保了行車條件下增量數(shù)據(jù)傳輸?shù)恼_性和穩(wěn)定性。

通過增量數(shù)據(jù)在線交換的試驗，驗證了本文設計的車輛導航系統(tǒng)增量數(shù)據(jù)在線交換平臺在數(shù)據(jù)傳輸方面具有較高的實時性，且可滿足用戶對數(shù)據(jù)傳輸能力的需求。

[1] 李連營,李清泉,趙衛(wèi)鋒,等.導航電子地圖增量更新方法研究[J].中國圖象圖形學報,2009(14):1238-1244.

[2] 宋鶯.導航電子地圖動態(tài)更新核心技術研究[J].計算機系統(tǒng)應用,2008(5):69-72.

[3] BETTINI C, CESA-BIANCHI N, RIBONI D. A distributed architecture for management and retrieval of extended points of interest[C]. 25th IEEE International Conference on Distributed Computing Systems Workshops,2005:266-272.

[4] BETTINI C, RIBONI D. Context-aware web services for distributed retrieval of points of interest[C]. IEEE Computer Society Washington, DC, USA,2007.

[5] 胡錢錢,李莉.導航電子地圖的更新機制與技術方法[J].地理信息世界,2008,6(1):77-82.

[6] 李玉,李小涵,王可立.導航電子地圖數(shù)據(jù)增量更新模式探討[J].地礦測繪,2009,25(3):4-6.

[7] 呂捷,張力軍.GPRS技術[M].北京:北京郵電大學出版社,2001.

[8] 沈金龍,劉景芝.移動分組交換通信——GPRS[J].南京郵電學院學報,1999,19(3):73-75.

[9] 鐵玲,諸鴻文,戎蒙恬.具有區(qū)分服務等級的可擴展并行服務器集群[J].計算機工程,2001,27(1):28-29.

[10] 曾碧卿,陳志剛.服務器集群系統(tǒng)研究[J].計算機應用研究,2004(3):186-187.

[11] 陳華平,孫清揚.可擴展并行Web服務器集群的實現(xiàn)技術[J].計算機工程與應用,2002(3):139-151.

[12] 龔斌,季宏濤.FTP協(xié)議分析及其客戶端程序實現(xiàn)[J].小型微型計算機系統(tǒng),1997,18(5):26-29.

Design of Online Exchange Platform for IncrementalData in Vehicle Navigation System

Cao Jiandong1, Yang Yang1, Luo Minghui2& Zhang Xinfeng2

1.ChinaAcademyofTransportationSciences,Beijing100029; 2.CleanEnergyAutomotiveEngineeringCenter,TongjiUniversity,Shanghai201804

In this paper, an online exchange platform of incremental data for the realtime updating of navigation data in vehicle navigation system is proposed, and the exchange mechanism of incremental data of navigation poins of interest and route is designed for data updating. Based on the center-terminal exchange platform and combined with the technologies of general packet radio service and file transfer protocol, the platform achieves the online data exchange between on-board navigation device and data source server. On this basis and by adopting terminal request mode, the corresponding data exchange mechanisms are designed for the request, reply and message transmission of incremental data respectively. Fianally, an online exchange test of incremental data verifies the reliability and realtime performance of the platform.

vehicle navigation; incremental data updating; online exchange; navigation POI; navigation route

*國家863計劃項目(2013AA12A026)資助。

原稿收到日期為2015年10月19日，修改稿收到日期為2016年1月4日。