??? 摘 要: 借助內容提供商SP的運行平臺構建基于短信的無線測控系統(tǒng)" title="測控系統(tǒng)">測控系統(tǒng)，拋棄了傳統(tǒng)的手機對手機的通信模式，而將前端改為SP接入，并且給鏈路上的短信封裝了靈活的通信協(xié)議" title="通信協(xié)議">通信協(xié)議，從而在一定程序上提高了系統(tǒng)的整體性能，具有良好的可擴展性和移植性。
??? 關鍵詞: 短信? SP? 通信協(xié)議? 無線測控
?
??? 目前，無線測控系統(tǒng)已經(jīng)廣泛地運用在車輛監(jiān)控、無線抄表、小區(qū)傳呼、工業(yè)數(shù)據(jù)采集系統(tǒng)等眾多領域之中。常用的無線數(shù)據(jù)傳輸方式主要有以下兩種：無線數(shù)傳電臺以及公用移動通信網(wǎng)。前者雖然實時性較高，傳輸速率也較快，但是由于其系統(tǒng)建設周期長，投資費用高以及需要一定高度的基礎設施與之配合等缺點，導致其使用不是非常普遍。近年來，隨著GSM、PHS等網(wǎng)絡的迅猛發(fā)展，手機短信網(wǎng)絡的覆蓋面越來越廣，系統(tǒng)的可靠性越來越高，重要的是該無線網(wǎng)絡不需要用戶進行自行維護。由于上述原因，在慢速測控系統(tǒng)中基于手機短信網(wǎng)絡的無線測控系統(tǒng)變得越來越普及。
??? 以往討論較多的基于短信的測控系統(tǒng)往往是手機對手機的模式[1]，即監(jiān)控中心與遠程終端都是通過手機模塊來進行短信數(shù)據(jù)的互傳。這種模式的主要缺點是很難實現(xiàn)一點對多點的數(shù)據(jù)傳輸。本文介紹一種借助內容提供商SP(Service Provider)的運行平臺來構建基于短信的無線測控系統(tǒng)。該系統(tǒng)在監(jiān)控中心端通過網(wǎng)絡直接與移動運營商的短信網(wǎng)關相連，避免了在監(jiān)控中心端使用手機模塊，因此可以較為容易地實現(xiàn)一點與多點之間的數(shù)據(jù)通信，大大提高了短信收發(fā)的頻率。
1 系統(tǒng)基本結構
??? 本系統(tǒng)在設計時所針對的短信網(wǎng)絡是中國電信的PHS網(wǎng)絡。系統(tǒng)采用一點對多點的雙向通信方式，一點即為數(shù)據(jù)監(jiān)控" title="數(shù)據(jù)監(jiān)控">數(shù)據(jù)監(jiān)控中心，多點則為多個遠程終端。每個遠程終端連接一個受控設備，受控設備為支持Modbus協(xié)議的PLC。
??? 本系統(tǒng)的設計分成三個部分：數(shù)據(jù)監(jiān)控中心、遠程終端以及短信鏈路上的通信協(xié)議。數(shù)據(jù)監(jiān)控中心發(fā)送應用于遠程終端的控制命令，并且接收來自遠程終端的回復信息。其前端通過SP方式接入中國電信的PHS短信網(wǎng)關，所有短信的收發(fā)都需通過短信網(wǎng)關來與短信中心進行交互。遠程終端負責連接PLC，接收、解析并傳遞來自監(jiān)控中心的控制命令；同時將PLC返回的信息以短信形式發(fā)送給數(shù)據(jù)監(jiān)控中心。通信協(xié)議的作用則是為了改善短信鏈路上的固有缺陷，進一步提高系統(tǒng)的性能。
??? 系統(tǒng)的拓撲結構和分層模型分別如圖1、圖2所示。
?
2 數(shù)據(jù)監(jiān)控中心設計
??? 數(shù)據(jù)監(jiān)控中心采用SP方式接入短信網(wǎng)絡，設計分成SP接口軟件和人機交互軟件兩個部分。
2．1 SP接口軟件
??? 傳統(tǒng)監(jiān)控中心的設計是通過一個或多個手機模塊以無線的方式接入短信網(wǎng)絡[1]。其缺點是增加了系統(tǒng)的硬件成本，更重要的是短信收發(fā)的頻率受到短信模塊自身能力的限制（較好的工業(yè)模塊每秒僅能處理1～2條短信)，從而使監(jiān)控中心無法對多個終端同時進行訪問，降低了發(fā)送端的實時性。在接入方式改為SP以后，監(jiān)控中心就可以以短信網(wǎng)關作為橋梁，以有線網(wǎng)絡的方式直接與短信中心進行短消息" title="短消息">短消息的交互，因而大幅度提高了數(shù)據(jù)監(jiān)控中心的短信收發(fā)頻率。
??? SP和模塊的發(fā)送性能對比如表1所示，在進行大話務測試時，SP每秒5條的發(fā)送成功率亦為100%。與原系統(tǒng)相比，SP還具有以下優(yōu)點：(1)減少了短信在空中駐留所帶來的延時。(2)增加了監(jiān)控中心發(fā)送的數(shù)據(jù)的實時性。(3)增強了系統(tǒng)的可靠性（SP與短信網(wǎng)關底層通過TCP/IP協(xié)議傳遞數(shù)據(jù)）。(4)可以同時收發(fā)短信（收發(fā)依賴于多個不同的線程）；而模塊在一個時刻只能處理一個請求。(5)SP接入為軟件接入，便于前期開發(fā)、后期維護和系統(tǒng)升級。
???
??? SP接口軟件負責整個數(shù)據(jù)監(jiān)控中心與短信網(wǎng)關之間的短消息交互，它與短信網(wǎng)關之間采用SMGP協(xié)議進行通信。SMGP協(xié)議是一個基于數(shù)據(jù)包的交互式協(xié)議，底層通過TCP/IP協(xié)議傳遞數(shù)據(jù)包，每個數(shù)據(jù)包都包含請求標識，代表數(shù)據(jù)包的用途。SP與短信網(wǎng)關之間的通信為長連接[2]，并采用Client/Server方式交互信息，SP作為Client端，網(wǎng)關作為Server端。
??? SP接口軟件在通過SMGP協(xié)議與短信網(wǎng)關進行數(shù)據(jù)交互時需采用特定的API函數(shù)，該類函數(shù)由短信網(wǎng)關設備供應商提供。最主要的API函數(shù)有以下幾種[2]：
??? InitSMGPAPI(Parameter)：初始化短信網(wǎng)關的API函數(shù)，應用程序只需調用一次此函數(shù)。
??? SMGPSendSingle(Parameters)：向短消息網(wǎng)關發(fā)送1條短消息到一個終端用戶。
??? SMGPSendBatch(Parameters)：向短消息網(wǎng)關發(fā)送1條短消息到多個終端用戶。
??? GetSendBatchResp(Parameters)：讀取群發(fā)的某一條短消息的標識及其發(fā)送結果。
??? SMGPDeliver(Parameters)：連接短消息網(wǎng)關，等待接收屬于本SP的短消息。
??? 因此，SP接口軟件的核心就是利用以上函數(shù)處理好兩個線程（發(fā)送線程和接收線程）及其分別對應的兩個緩沖區(qū)（發(fā)送緩沖區(qū)和接收緩沖區(qū)）之間的關系。為了保障SP的發(fā)送性能，發(fā)送線程還配有重發(fā)機制。SP接口軟件工作流程圖如圖3所示。
?
2．2 人機交互軟件
??? 人機交互軟件負責與用戶進行溝通。其設計可分成監(jiān)控軟件、數(shù)據(jù)庫管理軟件和協(xié)議處理軟件三個部分。
??? 監(jiān)控軟件采用GE Fanuc 的iFIX 軟件。它具有易于擴展和集成、易于與數(shù)據(jù)庫相結合、易于采用分布式網(wǎng)絡結構等優(yōu)點。本系統(tǒng)中，iFIX用于生成控制遠程PLC的Modbus監(jiān)控命令。
??? 數(shù)據(jù)庫管理軟件采用SQL Server 2000,它可以方便地與iFIX 進行接口。iFIX全面支持ODBC API接口[3]，可直接把實時數(shù)據(jù)寫入一個或多個關系數(shù)據(jù)庫中，并可將數(shù)據(jù)從關系數(shù)據(jù)庫寫回到iFIX 實時數(shù)據(jù)庫中。
??? 協(xié)議處理軟件主要進行通信協(xié)議的處理接收iFIX軟件的Modbus監(jiān)控命令，并將其進行協(xié)議封裝后提交給SP接口軟件；同時將接收緩沖區(qū)內的短信進行協(xié)議解析，并返回給iFIX。
3 遠程終端設計
3．1硬件設計
??? 與傳統(tǒng)的遠程終端相似，硬件由典型的MCU、存儲器擴展、復位電路、電平轉換以及相應的短信模塊所組成。另外，由于MCU是通過串口" title="串口">串口上的AT命令與短信模塊進行通信的，且MCU與受控的PLC之間的通信也是通過串口上的Modbus命令進行的，因此，本系統(tǒng)還需加上串口擴展電路，即將原MCU上的串口由一個轉為多個。硬件核心框圖如圖4所示。
?
3．2 固件設計
??? 遠程終端固件采用C語言設計，使用μVision3作為開發(fā)環(huán)境。固件結構可以分為三層：UART層、AT命令層以及協(xié)議層。這樣處理的優(yōu)點是結構清晰，便于移植[4]。
??? UART層：該層面向串口數(shù)據(jù)流，它將串口讀寫的函數(shù)進行了封裝，并采用中斷驅動模式對串口數(shù)據(jù)進行處理。在中斷服務程序中，僅對由固件實現(xiàn)的兩個緩沖區(qū)（UART發(fā)送和接收緩沖區(qū)）進行操作。
??? AT命令層：該層面向手機模塊，主要完成發(fā)送短信、接收短信和刪除短信這三個功能。它從UART接收緩沖區(qū)中提取出AT命令，或者生成AT命令并填入UART發(fā)送緩沖區(qū)。
??? 協(xié)議層：該層與人機交互軟件的協(xié)議處理軟件相對等，主要進行通信協(xié)議的處理，將來自AT命令層的短信內容進行解析，恢復出原始Modbus控制命令，然后將其發(fā)送給PLC；并將來自PLC的回復信息按照協(xié)議要求進行打包，提交給下一層的AT命令層處理。
4 通信協(xié)議
4.1協(xié)議的特性
??? 短信本身雖然具有一些無法比擬的優(yōu)點（如通信鏈路不需自行維護），但是它也隱含著一些特殊的缺陷，比如短信到來的無序性（后發(fā)先到）、延時的不確定性（易產生過期短信）、抗攻擊性弱（無法自行判斷短信是否合法）以及短信內容有長度限制（每條短信116個字節(jié)）。這一系列的缺陷都將給系統(tǒng)的可靠性和實時性造成影響，如果不加以適當?shù)奶幚韺е孪到y(tǒng)崩潰。因此，本系統(tǒng)在短信鏈路上引入了自定義的通信協(xié)議，即監(jiān)控中心與遠程終端之間交互的短信均需經(jīng)過該通信協(xié)議進行封裝。該協(xié)議提供的主要特性包括：
??? (1)數(shù)據(jù)完整性：配有數(shù)據(jù)校驗機制，確保短信在傳輸過程中沒有傳輸錯誤。
??? (2)安全性：自動剔除非法短信（包括號碼非法、內容非法以及時間非法）。
??? (3)可靠性：命令與回復通過序列號一一對應。
??? (4)認證：配有認證機制，確保短信來自正確的信息源。
??? (5)加密：對原始數(shù)據(jù)進行加密，防止其被未經(jīng)授權的讀取。
??? (6)分片：對內容過長的短信進行自動分割,分別封裝在序列號相同而分片號不同的短信中予以發(fā)送；接收端將分片短信予以組裝。
??? 通信協(xié)議的幀結構如表2所示。
?
4.2 協(xié)議的處理過程
??? 接收時協(xié)議處理的實際上就是對多消息緩沖區(qū)的維護：程序在內存單元中開辟N個緩沖區(qū)（稱為多消息緩沖區(qū)），用于緩沖接收到的合法短信。每一個緩沖區(qū)可以容納最多5條分片短信，且該緩沖區(qū)內所有短信的序列號必須相等或者相差N的倍數(shù)（N即為開辟緩沖區(qū)的個數(shù)）。接收方的協(xié)議處理流程圖如圖5所示。
?
??? 表3反映了在網(wǎng)絡狀況不好時協(xié)議所帶來的良好性能。從表中數(shù)據(jù)含義可以看出：剔除一條延時過長的短信可降低網(wǎng)絡阻塞的程度，保證其后續(xù)短信能夠按時到達。因此，加了協(xié)議的系統(tǒng)比不加協(xié)議的系統(tǒng)其平均延時從57.6秒降低至15.8秒，大幅度提高了系統(tǒng)的實時性能。
?
5 系統(tǒng)運行情況
??? 本系統(tǒng)進行了測試以驗證系統(tǒng)的可行性。測試系統(tǒng)采用兩個遠程終端及相應模擬PLC，PLC站號定為21和44。數(shù)據(jù)監(jiān)控中心分別以10秒和15秒為間隔同時向兩臺PLC發(fā)送Modbus控制命令，且等待回復時間均設為命令的發(fā)送間隔，超時的回復短信均作為命令失敗處理。系統(tǒng)測試結果如表4所示。
?
??? 從表中可以看出，由于短信固有延時的存在，只要給回環(huán)系統(tǒng)加了時延限制，其成功率就無法達到100%。但是適當調整時延后，成功率仍可達到95%左右。因此，本系統(tǒng)適合于數(shù)據(jù)量較小的、突發(fā)性以及對延時要求不太高的無線測控系統(tǒng)。
本文構建了一個基于SP接入的無線測控系統(tǒng)。該系統(tǒng)較為容易地實現(xiàn)了一點與多點之間的數(shù)據(jù)通信，提高了監(jiān)控中心端短信的收發(fā)頻率，且靈活的通信協(xié)議進一步保障了系統(tǒng)的性能。因此，它可以較為容易地移植到類似的控制領域中去。
參考文獻
[1] 高鋒，季瑞松.基于GSM的短信模塊TC35在遠程抄表上的應用[J].電工技術，2004,9:32-35.
[2]?基于固定電話網(wǎng)的信息終端及綜合信息系統(tǒng)技術規(guī)范：第七分冊短消息網(wǎng)關（SMGP）協(xié)議V2.0.[S].CT/T6.2004.
[3]?汪曉平. PLC可編程控制器系統(tǒng)開發(fā)實例導航[M].北京:人民郵電出版社，2004:334-365.
[4]?LABROSSE J J．嵌入式系統(tǒng)構件[M].北京: 機械工業(yè)出版社，2002:49-82．