基于IP2022芯片可支持GPRS的GPS終端設計

　　在GPS終端軟件設計方面，為了便于以后擴展，采用了嚴格的分層結構，具體的軟件結構如圖3所示。

　　2.2.1 串口驅動模塊

　　利用串口驅動模塊來完成對串口的操作，向上層提供對串口參數配置的功能，并在有數據收到或者發送完畢的時候通過IndicateReceive、IndicateSend回調函數向上層報告，上層軟件可以調用Send、Receive來進行收發。

　　2.2.2 網絡驅動模塊

　　在硬件中的GPRS模塊只是提供了一種硬件信道，與服務器之間的數據連接必須通過軟件完成。在通信時，軟件首先通過GPRS模塊特有的命令(一般為AT+CGMD)與GPRS網絡連接，再通過PPP協議建立數據鏈路，最后就可以通過TCP/IP協議與遠程的服務器通信了。這一部分與網絡操作的功能都放在網絡驅動模塊中加以實現。與串口驅動模塊類似，網絡驅動模塊也提供了數據傳輸的一些服務。

　　2.2.3 橋接模塊

　　由于串口是一個慢速連接，主機與串口的通信有時甚至是單字節操作，如果對于每一個這樣小的通信都單獨通過一個TCP包發送的話，譬如說一個字節的數據，這將產生一些41字節的分組：20字節的IP頭，20字節的TCP頭以及1字節的數據。如果在高速網絡上(例如局域網)，這一些小分組通常不會引起麻煩，但是如果在GPRS這樣的網絡上(平均往返時間高達數百ms)，則會增加擁塞出現的可能性，并將會使網絡的效率極其低。在通常的TCP/IP實現中，一般采用Nagle算法來解決這個問題。但是在Ubicom的協議棧中沒有這個功能，因此，必須自己實現這個算法。考慮到對下層硬件結構的無依賴性，筆者將其放在橋接模塊中實現，而不是放在網絡驅動模塊中實現。在算法實現中，當有串口數據到來時，對于小分組，并不立即就將其發出，而是等待一段時間(200s左右)，如果在這段時間中再沒有小數據到來，那么將其發出，否則將數據進行累計后發出。當然有些系統要求立即發出，那么也可以通過配置取消這種功能。經這樣實現后，效率有了很大的提高，具體的效果可以參考后面的實驗數據。

　　2.2.4 輔助模塊

　　在上面一些模塊的介紹中可以看到，其中有一些關鍵性的數據必須支持用戶自己配置，例如串口通信速度、停止位、網絡驅動模塊中GPRS所要連接的APN、賬戶、密碼、工作模式(是作為服務器運行還是客戶端運行)、靜態IP還是動態IP等。這一部分數據由配置模塊存儲在外部存儲器里，每次系統啟動的時候再由配置模塊載入。在輔助模塊中還包括一個重要的子模塊：遠程管理模塊，它實現對GPS終端的遠程管理，包括遠程跟蹤和遠程更新程序。系統的運行情況通過統計模塊進行統計，然后可以通過遠程管理模塊進行上報。

　　2.2.5 系統監控模塊

　　對于放在遠程的一個無人看管的系統來說，最重要的一點就是容錯能力，必須能夠在任何錯誤的情況下自動恢復到正常運行狀態，這一部分就是通過系統監控模塊實現的。在GPS終端中，經常出現的異常包括有TCP連接中斷和網絡連接中斷，這兩種錯誤是有區別的，解決的方法也不一樣。TCP連接中斷指的是TCP連接進入異常狀態，不能在該連接上進行數據的收發工作。這種錯誤產生的原因是GPRS網絡有時會進入偽死狀態，而導致雖然還在網絡上，但是數據的收發工作無法進行。通過在每個連接上設置一個收發超時計時器可以發現這種錯誤。當有數據傳輸時即復位計數器，如果計數器超時，則表明TCP連接中斷，此時應該根據工作模式而采取不同的處理。如果是工作在客戶端模式，需要再次與服務器連接，如果工作在服務器模式，則只需要簡單的斷開連接即可。

　　對于網絡連接中斷的情況探測起來比較困難，一般是通過監測長時間沒有數據通信來判斷。如果一旦發生此類錯誤，則需要重新進行網絡的連接工作。

　　由于軟件難免會有一些未曾發覺的錯誤，在發生此類錯誤的時候則由硬件看門電路復位系統，并且在下次軟件啟動時將此類錯誤發生過的信息遠程傳送到服務器。

　　3 服務器端軟件的設計

　　GPS服務器程序可以采用兩種方式與遠程的GPS終端建立連接，一種是采用TCP方式，另外一種是采用串口通信方式。在采用串口通信方式時，需要編制一個虛擬串口驅動程序，將一個TCP連接模擬成為一個串口，這樣服務器就可以像操縱M12一樣對遠程的GPS終端進行操作了。

　　GPS服務器和遠程GPS終端之間的通信協議采用了原始的M12通信命令，核心模塊在GPS服務器和M12之間進行了數據透明轉發的作用。M12支持有兩種通信數據格式： 一是Motorola二進制數據指令格式，在采用Motorola二進制格式時，通信速率可以保證在9600bps;另一種是NMEA-0183格式，其通信速率只有4800bps，同時在初始化GPS時還需要加入由Motorola二進制轉化為NMEA-0183的指令。因此建議使用Motorola二進制數據格式。

　　在此設計當中，關鍵的環節在于兩個方面，一是連接的建立，二是M12的初始化。GPS終端返回的定位信息數據格式如下：

　　@@Eamdyyhmsffffaaaaoooohhhhmmmmvvhhddtntimsd imsdimsdimsdimsdimsdimsdimsdsC。

　　時間信息：m月，d日，yy年， h小時，m分，s秒。

　　位置信息：aaaa緯度，oooo經度，hhhh橢球高度。

　　在所有信息終止的前的一個字節為校驗和，是所有信息字節的“異或”。

　　收到數據后，只要對數據進行解碼，就可以獲得定位信息以及時間。

　　4 服務器端的考慮

　　在GPRS聯網中，必須注意的一個概念是APN。在登陸GPRS時，采用的APN不同，GPS終端和服務器之間所能采用的方式也有所不同。

　　如果采用公網APN(cmnet)，那么服務器端只要有一固定公網IP即可，此時Radius服務器由移動公司提供，GPS終端上網后的IP也是由移動公司的Radius服務器隨機分配的。GPS終端與服務器必須經過NAT(Network Address Translation，網絡地址變換)后才能通信，而從我們數據服務器看過去的GPS終端的IP地址也不是它的真正地址。因此，GPS終端與數據服務器之間的連接只能由GPS終端發起，換言之，即GPS終端只能工作在客戶狀態。在采用公網時雖然可以節省開支，但需要考慮安全性問題，因為這時候是與Internet直接連通的，并且客戶之間也不可以直接訪問。

　　與公網APN相對應的一種方式是采用私有APN，即用戶向移動申請一個APN號。在采用這種方式時，所有登陸這個APN的用戶可以通過IP地址互相訪問，因此在數據量比較小的時候甚至可以采用一個也使用GPRS終端的用戶做服務器。Radius服務器的設置比較靈活，可以采用移動公司的Radius服務器，也可以自建一套Radius服務器。自建Radius服務器的最大好處就是GGSN會將驗證信息發送給我們，我們可以根據號碼或者其它信息為其分配一個靜態IP地址，非常適合GPS終端作為服務器運行。

　　Radius服務器可以采用一些商用的服務器，但從實踐中看，自己編寫一套Radius服務器可能更加適合GPRS。

　　5 結 論

　　對系統進行了全面的測試，在傳輸效率上面，本系統表現的非常良好，連接上網絡的時間僅需要3s左右。在使用Class 12的GPRS模塊時，傳輸速率可以達到38kbps的上傳速度以及44kbps的下傳速度。對于一般的數據采集設備能夠保證數據的及時傳輸，在發生GPRS網絡短暫失效時，可以在網絡恢復后的10s內重新在線，基本上保證了無間斷傳輸，因此可以滿足GPS用戶的需要。