楊 帆，車現法，陳 波，孫建軍

(1.廣東省南粵交通云湛高速公路管理中心，廣州 510100；2.中國公路工程咨詢集團有限公司，北京 100070；3.廣東華咨圣泰科技有限公司，廣州 510530)

0 引言

物聯網在現代交通、環(huán)境監(jiān)測、工業(yè)數據傳輸、車聯網等方面的應用越來越廣泛和深入，按照廣東省交通運輸行業(yè)建設目標，到2025年，基本形成數字化采集體系和網絡化傳輸體系。作為物聯網組成部分的傳感器，集數據采集、傳輸、融合分析等功能于一體，在物聯網體系中扮演著關鍵角色，其中數據傳輸控制是保證數據高效傳輸、有效獲取的關鍵。

傳感器網絡作為分布式系統(tǒng)，節(jié)點資源有限，包括有限的數據處理能力、有限的存儲空間和有限的數據帶寬。由于不同行業(yè)的應用具有不同的特點，基于傳感器和遠程服務器之間應用層通訊控制協議很難具有統(tǒng)一標準，這就給不同行業(yè)的物聯網數據傳輸控制帶來了較大的挑戰(zhàn)。

1 高速公路物聯網數據傳輸控制協議現狀

高速公路機電系統(tǒng)(監(jiān)控系統(tǒng)、收費系統(tǒng)、通信系統(tǒng)、防雷系統(tǒng)等)由大量的機電設備構成，及時、有效地獲取設備運行狀態(tài)參數，是建設數字化采集體系和網絡化傳輸體系的目標和要求。機電系統(tǒng)設備運行狀態(tài)具有其自身特點，表現為：運行狀態(tài)正常或狀態(tài)變化在允許范圍屬于常態(tài)化現象，而狀態(tài)異常或狀態(tài)變化超出允許范圍屬于極小概率事件，因此，狀態(tài)數據在長時間基本保持不變或微小變化，狀態(tài)數據冗余度很大。

高速公路機電設備運行狀態(tài)等基礎數據的傳輸控制普遍采用以下兩種模式，一種是傳感器作為客戶端，主動周期性獲取數據上傳遠程服務器端；另外一種是傳感器作為服務器端，接收遠程或本地客戶端查詢并進行數據反饋。這兩種模式存在共同的特點，傳感器無論作為客戶端或服務器端，利用底層傳輸協議(如TCP、UDP或GPRS等)上傳數據，其應用層不進行傳輸控制，即所謂的透明傳輸，應用層傳輸控制均交由上位機進行。采用以上兩種數據傳輸模式，雖然傳感器運行負荷大大減小，但數據傳輸的控制、處理、存儲等交由上位機進行，勢必會造成以下問題的出現：

(1)有悖于分布式系統(tǒng)策略，網絡各節(jié)點運行負荷不均衡，系統(tǒng)穩(wěn)定性存在潛在隱患。

(2)加重了上位機運行負荷，對其軟硬件性能提出了更高要求。

(3)在傳感器節(jié)點軟硬件性能較大提高的情況下，沒有充分挖掘和利用其資源，是對資源的浪費。

(4)固定周期數據查詢，難以兼顧既要能夠及時獲取異常狀態(tài)數據，又要減少數據冗余度。

2 高速公路物聯網數據傳輸控制協議方案

基于分布式網絡系統(tǒng)策略，利用傳感器節(jié)點軟件件資源，在充分研究高速公路防雷設備運行狀態(tài)特點的基礎上，本文提出了一種基于UDP/IP協議的應用層數據傳輸控制協議，較好地解決了當前高速公路普遍采用的數據傳輸模式帶來的諸多問題，即兼顧及時獲取異常狀態(tài)數據，又大大降低了數據冗余度，網絡節(jié)點運行負荷更加均衡，系統(tǒng)性能顯著提高。

2.1 協議要點

將數據輪詢、分析判斷功能前移致傳感器，減小輪詢周期，以保障異常狀態(tài)數據及時獲取。異常狀態(tài)數據在一個輪詢周期內能夠及時獲取并上傳，而相鄰2個周期狀態(tài)數據未變化或狀態(tài)數據變化在允許范圍內的，可以不進行上傳，即所謂“及時上傳”和“定時上傳”機制。

及時上傳：傳感器依照輪詢周期進行數據查詢，當本次狀態(tài)數據與前次發(fā)生變化或超出閾值，則立即上傳；數據未變化或未超出閾值，不上傳。

定時上傳：在定時上傳時間，無論數據是否變化都須上傳。

2.2 協議說明

2.2.1 協議初始化

傳感器運行參數(輪詢周期、定時上傳周期、數據判斷門限等)由服務器端配置，傳感器啟動運行連接服務器，服務器下發(fā)傳感器配置信息(參見2.2.3節(jié))。

(1)若傳感器未收到配置信息，則以“延遲重發(fā)周期”循環(huán)發(fā)送“請求配置信息”，直至獲取到配置信息。

(2)若傳感器收到服務器下發(fā)的“無配置信息”(參見2.2.6節(jié))，傳感器停止數據查詢，依照(1)進行。

圖1 協議初始化

2.2.2 協議實現

(1)傳感器首次數據查詢，數據本地保存，并上傳服務器。

(2)傳感器依照“輪詢周期”查詢數據。

開關量查詢：若前后兩次數據有變化，則上傳，否則不上傳，本地保存。

模擬量查詢：若任意一路模擬量數據超出門限值，則上傳，否則不上傳，本地保存。

開關量和模擬量查詢：判斷開關量是否有變化，有變化則上傳；若無變化，判斷任意一路模擬量數據是否超出門限值，若超出則上傳，否則不上傳，本地保存。

(3)“定時上傳”時不進行數據判斷，數據直接上傳，并本地保存。

(4)若查詢數據，采集器未反饋，則清除本地數據，不上傳數據，依照步驟(1)進行。

(5)網關解析配置信息成功后，上傳“解析成功”數據包，依照最新配置信息運行；網關解析配置信息失敗后，上傳“解析失敗”數據包，繼續(xù)依照前次配置信息運行。

(6)服務器在運行過程中會主動下發(fā)配置信息，網關接收到下發(fā)的配置信息后，覆蓋原配置信息，然后依照步驟(1)進行。

圖2 協議實現

2.2.3配置信息數據結構

報頭輪詢周期定時周期門限1門限2門限3心跳周期重發(fā)周期數據長度數據報尾1Byte2Byte2Byte1Byte1Byte1Byte1Byte1Byte2ByteNByte1ByteF2xx xxxx xxxxxxxxxxxxxx xxxx ……DD

報頭標識：0xF2，長度1字節(jié)。

輪詢周期：傳感器數據查詢時間周期，長度2字節(jié)。

定時周期：傳感器固定數據查詢并上傳周期，長度2字節(jié)。

門限1、門限2、門限3：模擬量及時上傳數值門限，長度1字節(jié)。

重發(fā)周期：傳感器未收到配置信息，重新發(fā)送“請求配置信息”時間周期，長度1字節(jié)。

數據長度：數據段字節(jié)數量，長度2字節(jié)。

報尾標識：0xDD，長度1字節(jié)。

2.2.4 狀態(tài)信息數據結構

報頭模塊地址數據長度數據報尾1Byte2Byte1byteNByte1ByteFFxx xxxxxx xx ……DD

報頭標識：0xFF，長度1字節(jié)。

模塊地址：傳感器模塊標識，系統(tǒng)范圍內數值唯一，長度2字節(jié)。

數據長度：數據段字節(jié)數量，長度1字節(jié)。

報尾標識：0xDD，長度1字節(jié)。

2.2.5 申請配置信息數據結構

報頭模塊地址報尾1Byte2Byte1ByteF1xx xxDD

報頭標識：0xF1，長度1字節(jié)。

模塊地址：傳感器模塊標識，系統(tǒng)范圍內數值唯一，長度2字節(jié)。

報尾標識：0xDD，長度1字節(jié)。

2.2.6 無配置信息數據結構

報頭模塊地址標識報尾1Byte2Byte1Byte1ByteF2xx xxEEDD

報頭標識：0xF1，長度1字節(jié)。

模塊地址：傳感器模塊標識，系統(tǒng)范圍內數值唯一，長度2字節(jié)。

標識：固定“EE”，表示該傳感器模塊無配置信息。

報尾標識：0xDD，長度1字節(jié)。

2.2.7 配置信息解析成功數據結構

報頭數據報尾1Byte(N)·Byte1ByteFA配置信息去除報頭(F2)和報尾(DD)DD

報頭標識：0xFA，長度1字節(jié)。

數據：配置信息去除報頭(F2)和報尾(DD)后的數據。

報尾標識：0xDD，長度1字節(jié)。

2.2.8 配置信息解析失敗數據結構

報頭數據報尾1Byte(N)·Byte1ByteFB配置信息去除報頭(F2)和報尾(DD)DD

報頭標識：0xFB，長度1字節(jié)。

數據：配置信息去除報頭(F2)和報尾(DD)后的數據。

報尾標識：0xDD，長度1字節(jié)。

3 結語

針對高速公路防雷設備運行特點，在研究當前機電狀態(tài)數據傳輸控制模式的基礎上，充分利用傳感器軟件資源，提出了一種物聯網應用層數據傳輸控制協議。該協議已在云湛高速公路防雷監(jiān)測系統(tǒng)等多個項目得到實踐應用，應用結果表明，該協議既均衡了網絡節(jié)點負荷，又兼顧了數據及時獲取和數據冗余度問題，使系統(tǒng)運行的穩(wěn)定性得到較大提高，達到了應用要求。