基于GPRS的遠程監(jiān)控系統(tǒng)設計

　　1 引言

　　目前，對輸油管道、電力裝置等多個分散點進行監(jiān)控主要采用人工巡邏的方式，這種方式存在實時性差、成本高、無法對環(huán)境惡劣的地區(qū)進行監(jiān)控等缺點。隨著internet與移動通信技術的發(fā)展，這種傳統(tǒng)的監(jiān)控方案已無法滿足應用要求，亟待開發(fā)一種實時性好、可靠性高、價低易用的無線遠程監(jiān)控系統(tǒng)。GPRS能夠很好地解決上述問題。GPRS是在充分利用現(xiàn)有GSM網(wǎng)絡的基礎上，通過添加GGSN和SGSN實現(xiàn)數(shù)據(jù)的分組傳輸，從而將移動通信與Internet網(wǎng)絡聯(lián)系起來，是目前無線數(shù)據(jù)傳輸應用最廣泛的網(wǎng)絡。

　　2 系統(tǒng)硬件組成

　　輸油管道壓力監(jiān)控模塊的硬件結構框圖如圖1所示，系統(tǒng)由遠程監(jiān)控模塊和監(jiān)控中心PC機組成，它們通過GPRS網(wǎng)絡進行通信。遠程監(jiān)控節(jié)點由ARM模塊、GPRS模塊和傳感器模塊組成。其中，GPRS模塊主要用于數(shù)據(jù)的發(fā)送、接收以及短消息的接收;ARM模塊完成傳感器數(shù)據(jù)的編碼和TCP/IP封裝，控制GPRS模塊將數(shù)據(jù)發(fā)送到監(jiān)控中心，并接收和執(zhí)行監(jiān)控中心發(fā)送的控制命令;監(jiān)控中心為通過以太網(wǎng)卡連人Internet中的一臺具有固定IP的計算機，采用VB.NET開發(fā)工具調(diào)用Winsock控件編寫監(jiān)控軟件，用于接收、處理和顯示各個監(jiān)控點發(fā)送的數(shù)據(jù)，并對監(jiān)控點發(fā)送控制命令。

　　其中，GPRS模塊是無線數(shù)據(jù)傳輸?shù)暮诵牟糠?，本文采用西門子公司的MC39i，它提供一個標準的RS232接口用于與外部應用系統(tǒng)連接。

　　3 系統(tǒng)軟件設計

　　3.1 基于FreeRTOS的系統(tǒng)任務設計

　　根據(jù)嵌入式實時操作系統(tǒng)模塊化設計理念，將系統(tǒng)軟件設計劃分為主控任務MainTask()、與網(wǎng)絡連接任務GPRSConctTask()、數(shù)據(jù)傳輸任務xDataTrsmtTask()、短消息處理任務xSMSProc-Task()和傳感器任務xSensorStatTask()。任務之間采用信號量、隊列和郵箱等進行通信，其關系如圖2所示，其中MC39iSerialDrv()為串口驅(qū)動程序。

　　MC39iSerialDrv()為串口驅(qū)動函數(shù)，它負責將發(fā)送隊列xQSendToMC39i里面的數(shù)據(jù)發(fā)送給與MC39i相連接的串口。接收到數(shù)據(jù)后，將MC39i串口接收到的數(shù)據(jù)發(fā)送到接收隊列xQRecdFrom-MC39i中，數(shù)據(jù)的接收和發(fā)送是通過中斷服務子程序完成的。

　　GPRSConctTask()實現(xiàn)MC39i模塊與GPRS網(wǎng)絡的連接，是遠程數(shù)據(jù)傳輸?shù)幕A和關鍵。

{{分頁}}

　　3.2 基于狀態(tài)機設計GPRS連接任務

　　由于網(wǎng)絡和信號強弱等原因，可能導致節(jié)點與GPRS網(wǎng)絡連接的失敗。本文采用基于狀態(tài)機的結構設計方法對各個階段產(chǎn)生的錯誤進行處理，保障模塊與GPRS網(wǎng)絡建立可靠連接。程序狀態(tài)機如圖3所示。

　　3.3 基于uIP協(xié)議棧的傳輸層軟件設計

　　利用GPRS模塊進行數(shù)據(jù)傳輸時，數(shù)據(jù)格式須符合互連網(wǎng)絡的TCP/IP協(xié)議標準。xDataTrsmtTask()任務完成傳輸層和網(wǎng)絡層處理。根據(jù)系統(tǒng)狀態(tài)(UDP或TCP態(tài))，傳輸層處理方式不同。

　　TCP提供可靠的數(shù)據(jù)傳輸方式，其應用層協(xié)議也比較多，被廣泛應用于網(wǎng)絡通信領域。由于TCP的協(xié)議頭以及數(shù)據(jù)傳輸控制比較復雜，數(shù)據(jù)的傳輸效率較低，因而越來越多的實時小數(shù)據(jù)量的應用，更傾向于使用基于UDP的數(shù)據(jù)傳輸協(xié)議。

　　3.3.1 基于uIP的TCP數(shù)據(jù)傳輸方式的實現(xiàn)

　　本文基于uIP TCP/IP協(xié)議棧實現(xiàn)TCP數(shù)據(jù)傳輸方式。uIP是由Adam Dunkels編寫的源代碼免費開放的微型TCP/IP協(xié)議棧，傳輸層協(xié)議實現(xiàn)了UDP和TCP，鏈路層PPP協(xié)議可以作為uIP下面的設備驅(qū)動來實現(xiàn)，uIP系統(tǒng)底層和應用程序之間的關系如圖4所示。應用程序必須提供一個回應函數(shù)給uIP，數(shù)據(jù)傳輸任務周期性調(diào)用UIP_AP-PCALL()函數(shù)處理事件的發(fā)生。

　　進行TCP數(shù)據(jù)傳輸之前，首先通過調(diào)用uIP協(xié)議棧提供的uip_connect()函數(shù)與監(jiān)控中心的監(jiān)控軟件建立一個TCP連接，TCP連接的三次握手均由uIP協(xié)議棧的uip_process()函數(shù)完成。

　　默認情況下，uIP協(xié)議棧的發(fā)送和接收共用一個緩沖區(qū)，當uIP處理緩沖區(qū)內(nèi)數(shù)據(jù)時，必須關中斷，為了提高系統(tǒng)實時性，我們將其改為雙緩沖區(qū)模式。系統(tǒng)每個時鐘節(jié)拍分別對發(fā)送和接收緩沖區(qū)進行掃描，如發(fā)現(xiàn)緩沖區(qū)非空時，由uIP協(xié)議棧處理。接收數(shù)據(jù)時，uip_process()對接收緩沖區(qū)內(nèi)數(shù)據(jù)進行TCP和IP 協(xié)議頭解析，并將應用數(shù)據(jù)發(fā)送到In-Buffer[]中。發(fā)送數(shù)據(jù)時，由uip_process()完成發(fā)送緩沖區(qū)OutBuffer[]中數(shù)據(jù)的TCP/IP封裝，再調(diào)用uIP驅(qū)動程序PPPSendData()進行鏈路層PPP協(xié)議頭的封裝，并將封裝的數(shù)據(jù)發(fā)送到發(fā)送隊列xQSendToMC39i中。

　　3.3.2 UDP數(shù)據(jù)傳輸?shù)膶崿F(xiàn)和改進

　　設計中采用對數(shù)據(jù)包進行編碼和增加握手的方式實現(xiàn)UDP數(shù)據(jù)傳輸可靠性的改進。通過給每個UDP數(shù)據(jù)包加上一個順序增加的ID號，區(qū)別各個不同的數(shù)據(jù)包，利用它來對丟包的檢測。握手過程如圖5所示。設計中采用UDPIDProc()函數(shù)完成握手功能，發(fā)送的數(shù)據(jù)備份在一個緩沖區(qū)中，每次接收到確認包后將對ID進行檢驗，如果ID正確則將備份的數(shù)據(jù)刪除。如60 s內(nèi)未收到正確的ID確認信息，則采用新的ID將備份的數(shù)據(jù)重傳，當重傳失敗時，可以進行報警，從而實現(xiàn)了一種改進的可靠性較高的UDP數(shù)據(jù)傳輸方式。

　　4 系統(tǒng)測試

　　本文利用兩個數(shù)據(jù)傳輸模塊和監(jiān)控中心組成測試系統(tǒng)對數(shù)據(jù)傳輸性能進行測試。最高重傳次數(shù)設置為3，超過最高重傳次數(shù)后，通過短消息方式將數(shù)據(jù)發(fā)送到用戶手機上。模塊每20 min向監(jiān)控中心發(fā)送一次數(shù)據(jù)，監(jiān)控中心每天發(fā)送兩次控制命令到各個模塊，分別采用改進的UDP和TCP進行傳輸。經(jīng)測試，系統(tǒng)工作20天內(nèi)未出現(xiàn)死機等異常情況;模塊與GPRS網(wǎng)絡連接成功率為100%(本文中增加了檢錯重試機制)。測試結果如表1所示。

　　GPRS網(wǎng)絡中UDP傳輸有效率大于99%，TCP傳輸有效率約為100%。本文設計的遠程監(jiān)控系統(tǒng)采用經(jīng)改進的UDP數(shù)據(jù)傳輸方式能檢測到丟包，通過多次重傳可以成倍降低UDP傳輸方式的丟包率，可以根據(jù)需要設置系統(tǒng)將一直重傳到數(shù)據(jù)成功到達為止，從而實現(xiàn)數(shù)據(jù)傳輸成功率為100%。

　　5 結 論

　　本文給出的遠程監(jiān)控系統(tǒng)的設計方案具有可靠、實時、穩(wěn)定、通用和低成本等優(yōu)點，實現(xiàn)了TCP和經(jīng)過改良的UDP兩種數(shù)據(jù)傳輸方式，可以滿足多種數(shù)據(jù)傳輸領域的要求。