鮮活農(nóng)產(chǎn)品物流實時監(jiān)控系統(tǒng)設計
加入技術(shù)交流群
3．1 數(shù)據(jù)包收發(fā)和處理模塊
數(shù)據(jù)包收發(fā)和處理模塊主要負責從Internet上獲取來自無線終端的信息數(shù)據(jù)。設計時必須考慮的是車輛的移動性，以及如何能實時地將數(shù)據(jù)傳送到監(jiān)控中心服務器等問題。
車載終端需要傳送數(shù)據(jù)時，首先將所收集到的信息數(shù)據(jù)進行基于TCP／IP的打包處理，打包過后的數(shù)據(jù)通過GSM網(wǎng)絡將數(shù)據(jù)傳送給最近的BSS(基站子系統(tǒng))，BSS會和最近的SGSN通信，其后SGSN通過GPRS網(wǎng)絡將數(shù)據(jù)發(fā)送到GGSN，在GGSN對該數(shù)據(jù)包進行相關(guān)處理后，將該數(shù)據(jù)發(fā)送到Internet或X．25網(wǎng)絡。進入到Internet上的IP數(shù)據(jù)包可以很容易地傳輸?shù)?a class="contentlabel" href="http://cafeforensic.com/news/listbylabel/label/物流">物流過程監(jiān)控中心。因此，監(jiān)控中心數(shù)據(jù)包的收發(fā)和處理模塊只需考慮接收和處理來自Intenet的IP數(shù)據(jù)包。
3．1．1 數(shù)據(jù)幀格式設計
本系統(tǒng)主要功能是記錄農(nóng)副產(chǎn)品的狀態(tài)，每次傳輸?shù)臄?shù)據(jù)量小而且突發(fā)性強，因此采用UDP協(xié)議傳輸數(shù)據(jù)。同時，由于UDP協(xié)議為不可靠的傳輸協(xié)議，其并不提供數(shù)據(jù)傳送的保障機制，因此實現(xiàn)時必須添加保障信息傳輸可靠性的確認機制。在本系統(tǒng)中，當監(jiān)控中心向終端發(fā)送數(shù)據(jù)時，要求終端返回接收正確或錯誤的確認信息，監(jiān)控中心收到正確的確認信息后數(shù)據(jù)下傳進程才完畢。否則，監(jiān)控中心將在規(guī)定的時間內(nèi)重發(fā)，直到收到正確的確認信息或發(fā)送次數(shù)標志溢出才終止。
在數(shù)據(jù)包收發(fā)和處理模塊設計實現(xiàn)過程中最主要的就是對數(shù)據(jù)包進行操作，車載終端和物流過程監(jiān)控中心在交互通信過程中，所涉及的主要數(shù)據(jù)幀類型包括：
GPS數(shù)據(jù)包：GPS數(shù)據(jù)包是由車載終端上的GPS模塊獲得的GPS信息交給車載終端后，由車載終端上的程序進行封裝的。
車載終端注冊信息幀：車載終端開機后需要首先在監(jiān)控中心進行注冊，只有注冊通過才能通過監(jiān)控中心對車載終端進行實時地跟蹤和管理，車載注冊信息就是由車載終端發(fā)送給監(jiān)控中心請求注冊的報文。
車載終端客戶登錄幀：車載終端登錄后，操作人員需要使用自己的用戶ID通過車載終端登錄到監(jiān)控中心系統(tǒng)，監(jiān)控中心根據(jù)這一信息來實現(xiàn)車載終端和客戶的關(guān)聯(lián)。
車載終端發(fā)送登記商品信息幀：在物流起點需要將運輸貨物的信息通過車載終端傳送到監(jiān)控中心。這一信息主要是將運輸貨物和車載終端進行關(guān)聯(lián)。信息中會包含貨物運輸所需要的溫度和濕度限制，監(jiān)控中心根據(jù)這一信息來判斷貨物的實時運輸條件是否滿足要求，如果越界則會發(fā)出警報。
車載終端發(fā)送地理位置幀：車載終端可以實時地查詢自己所在的位置信息，這一信息通過車載終端向監(jiān)控中心上報GPS信息獲得，監(jiān)控中心根據(jù)GPS信息查詢GIS地圖數(shù)據(jù)庫獲得車載終端所在位置的名稱，再傳遞給車載終端。這樣車載終端就可以知道運輸車輛當時所在地理位置的名稱。
各類數(shù)據(jù)幀設置的數(shù)據(jù)格式統(tǒng)一采用ASCII字符，同時在GPRS／CDMA網(wǎng)絡無信號的情況下使用短信方式傳輸，短信格式與數(shù)據(jù)幀的格式定義保持一致。數(shù)據(jù)幀定義示例如圖4所示。本文引用地址：http://cafeforensic.com/article/162030.htm
3．1．2 數(shù)據(jù)包的收發(fā)
移動終端通過GPRS網(wǎng)絡向監(jiān)控中心發(fā)送數(shù)據(jù)時，終端應用程序要先對數(shù)據(jù)封裝，再通過AT命令控制GPRS模塊發(fā)送。具體實現(xiàn)時的步驟如下：
(1)對數(shù)據(jù)進行UDP封裝，將采集到的待發(fā)送的信息數(shù)據(jù)放到UDP格式的數(shù)據(jù)段中，對此幀UDP數(shù)據(jù)和8字節(jié)首部信息一起按規(guī)則計算，生成UDP校驗和，完成UDP數(shù)據(jù)封裝。
(2)根據(jù)IP協(xié)議為此幀UDP建立20字節(jié)的IP頭，對IP頭進行校驗計算，得出IP頭的校驗值，完成IP封裝。
(3)完成PPP封裝，PPP格式的標志字符為0x7E，在進行PPP封裝前先要檢查數(shù)據(jù)中是否有標志字符，當遇到字符0x7E時，連續(xù)傳送2個字符0x7D和0x5E，以實現(xiàn)標志字符的轉(zhuǎn)義，當遇到轉(zhuǎn)義字符0x7D時，連續(xù)傳送2個字符0x7D和0x5D，以實現(xiàn)轉(zhuǎn)義字符的轉(zhuǎn)義。
(4)將數(shù)據(jù)放入PPP幀格式的信息段中，生成CRC校驗，完成PPP封裝。
(5)終端通過AT命令控制GPRS模塊向網(wǎng)絡發(fā)PPP呼叫，建立PPP通信鏈路連接，并發(fā)送封裝好的數(shù)據(jù)。
3．1．3 數(shù)據(jù)包的處理
在接收到數(shù)據(jù)包之后，根據(jù)數(shù)據(jù)包類型的不同，選取相應的處理流程。如ACK包是屬于接收方在自己正確無誤接收到發(fā)送方發(fā)的數(shù)據(jù)包后，所反饋回的一個確認數(shù)據(jù)包；而對于正常的數(shù)據(jù)包，將調(diào)用相關(guān)的解包過程函數(shù)。根據(jù)收到的包的類型轉(zhuǎn)而進入相關(guān)處理模塊，對于整個物流過程中所采集到的各項信息數(shù)據(jù)將實時存儲在數(shù)據(jù)庫當中。
如果有要發(fā)送的報文，可經(jīng)過監(jiān)控中心上層程序，按照幀格式封裝好后直接調(diào)用發(fā)送接口函數(shù)發(fā)送。當然監(jiān)控中心也可以主動發(fā)出請求，這樣就可直接調(diào)用發(fā)送處理進行報文的封裝，然后調(diào)用發(fā)送函數(shù)進行發(fā)送。
3．2 數(shù)據(jù)存儲模塊
數(shù)據(jù)存儲模塊將讀取的數(shù)據(jù)包進行解析校驗，若校驗正確將實時存入后臺數(shù)據(jù)庫，并發(fā)送反饋信息給GPRS終端，可用于實時溫濕度曲線圖顯示、實時數(shù)據(jù)顯示和溫濕度報警指示。
3．3 軟件界面模塊
軟件界面模塊分為多個功能模塊，其中實時溫濕度曲線顯示、數(shù)據(jù)的統(tǒng)計分析、數(shù)據(jù)庫查詢與數(shù)據(jù)管理和用戶管理等人機操作是基于SQL Servet數(shù)據(jù)庫事件觸發(fā)機制來完成的。軟件的通信啟動、關(guān)閉服務以及車載終端及溫濕度采集模塊參數(shù)設置等界面操作是調(diào)用通信動態(tài)鏈接庫的發(fā)送函數(shù)來完成的。
4 結(jié)語
本系統(tǒng)依托國家發(fā)改委國債項目“全國大中型農(nóng)產(chǎn)品批發(fā)市場信息化建設項目”擴展部分的關(guān)鍵系統(tǒng)研發(fā)，針對的主要對象是全國大中型農(nóng)產(chǎn)品批發(fā)市場鮮活農(nóng)產(chǎn)品物流過程，開發(fā)成型的監(jiān)控系統(tǒng)，通過該信息系統(tǒng)對從產(chǎn)地到全國各大批發(fā)市場運輸過程中產(chǎn)品的狀態(tài)進行監(jiān)測。
從系統(tǒng)測試及使用結(jié)果看，本系統(tǒng)基本滿足了設計需求。但是也存在一些不足，如無線數(shù)據(jù)傳輸時間延遲的存在，導致監(jiān)控中心收到的車輛監(jiān)控數(shù)據(jù)不能真實反映移動車輛的實時狀態(tài)；車輛定位的實時性與通信費用的矛盾；系統(tǒng)功能上，可進一步增強傳統(tǒng)車輛監(jiān)控平臺的GIS功能，如規(guī)劃功能、緊急援助等。系統(tǒng)構(gòu)架上，可進一步利用Web Service技術(shù)改良鮮活農(nóng)副產(chǎn)品物流過程監(jiān)控系統(tǒng)的架構(gòu)模式。
評論