衛(wèi)星工程數(shù)據(jù)低流量推送系統(tǒng)的設(shè)計與實現(xiàn)

盧 山 ，胡 鈦 ，李 虎

（1.中國科學院國家空間科學中心衛(wèi)星運控技術(shù)實驗室，北京100190；2.中國科學院大學北京100049）

現(xiàn)有的主流科學衛(wèi)星任務(wù)系統(tǒng)中的數(shù)據(jù)推送子系統(tǒng)采用 C/S（Client/Server）、B/S（Browser/Server）架構(gòu)共存的系統(tǒng)方案。C/S架構(gòu)中的消息傳遞機制是由服務(wù)器基于CCSDS協(xié)議數(shù)據(jù)格式與處理方法進行下行數(shù)據(jù)包解析后統(tǒng)一組播發(fā)送數(shù)據(jù)包給客戶端，客戶端接收處理得到所有的工程數(shù)據(jù)，然后客戶端應(yīng)用根據(jù)配置顯示關(guān)注的參數(shù)數(shù)據(jù)。在B/S架構(gòu)中，Web服務(wù)器接收組播消息得到所有工程數(shù)據(jù)，用戶通過Web應(yīng)用選取感興趣的參數(shù)通過HTTP協(xié)議推送實時獲取所選工程參數(shù)。

移動應(yīng)用采用C/S架構(gòu)的消息傳遞機制缺點是推送而來的大量冗余工程參數(shù)數(shù)據(jù)造成的流量浪費。另外在B/S架構(gòu)中，HTTP協(xié)議推送是建立在長連接的基礎(chǔ)上[1]，其通信效率比較低，依賴于服務(wù)器與瀏覽器之間的嚴格持久連接要求[2]。

目 前 MQTT（Message Queue Telemetry Transport）協(xié)議在即時移動通訊系統(tǒng)中有較多應(yīng)用[3-5]。本文通過將科學衛(wèi)星工程參數(shù)名進行編碼，生成固定長度的字符串作為主題名的方法，大大減少了MQTT協(xié)議接收“發(fā)布”控制報文時的可變報頭空間。進一步降低數(shù)據(jù)推送的流量消耗。

1 移動端平臺的推送機制現(xiàn)狀

目前的推送技術(shù)分為兩類，一類是基于HTTP的Ajax技術(shù)[6]與HTML5規(guī)范的 WebSocket技術(shù)[7-9]；另一類是基于TCP協(xié)議的通用消息中間件技術(shù)，比如XMPP協(xié)議、SIMPLE協(xié)議等[10-11]。但是它們在流量、功耗、傳輸方面都未充分考慮移動互聯(lián)網(wǎng)與物聯(lián)網(wǎng)的特點。

MQTT是IBM提出的基于TCP協(xié)議的輕量級發(fā)布訂閱模型的協(xié)議。MQTT起初是IBM在開發(fā)物聯(lián)網(wǎng)設(shè)備時使用的簡單消息中間件協(xié)議，通過不斷發(fā)展完善并將其開源。在2014年11月，MQTT v3.1.1版本成為OASIS標準，并在同年6月正式納入ISO標準體系。

2 MQTT協(xié)議介紹

MQTT是封裝在TCP協(xié)議基礎(chǔ)上的點對點應(yīng)用層協(xié)議[12]。MQTT的控制報文包括CONNECT報文、CONNACK報文、PUBLISH報文、PUBACK報文、PUBREC報文、SUBSCRIBE報文等，共14種控制報文。MQTT所有控制報文的報文結(jié)構(gòu)都分為四部分，包括固定報頭、剩余長度、可變報頭和有效載荷部分[2]，如圖1所示。

圖1 MQTT控制報文格式

MQTT協(xié)議的控制報文都包含固定長度為1字節(jié)的固定報頭，從第2字節(jié)開始，最長到第五個字節(jié)結(jié)束[13]。剩余長度部分最長為4字節(jié)的字段標識剩余長度值，表示當前MQTT協(xié)議控制報文的剩余部分字節(jié)數(shù)，包括可變報頭和有效載荷部分，但不包括用于編碼剩余長度字段本身的字節(jié)數(shù)。剩余長度字段采用變長度編碼方案，當剩余字節(jié)數(shù)小于127時，剩余長度用1字節(jié)標識。當剩余字節(jié)數(shù)大于127時，每字節(jié)的低7位用于表示數(shù)據(jù)，最高位標識是否延續(xù)?？勺儓箢^位于剩余長度標識字節(jié)與有效載荷之間，可變報頭的內(nèi)容根據(jù)報文類型而不同，包含報文標識符、協(xié)議級別、協(xié)議名、連接標志位、遺囑標志位、QOS等級位、遺囑保留位、用戶名標志、密碼標志和連接保持標志位等。其中“發(fā)布”報文的主題名為主要部分。

3 系統(tǒng)設(shè)計與實現(xiàn)

考慮到兼容性，在不影響現(xiàn)有任務(wù)支持系統(tǒng)基礎(chǔ)上，本文設(shè)計的MQTT協(xié)議的科學衛(wèi)星工程數(shù)據(jù)推送系統(tǒng)分為三部分，分別為MQTT服務(wù)端、工程數(shù)據(jù)適配器端和移動端應(yīng)用，并在MQTT協(xié)議的可變報頭位置進行了主題名優(yōu)化處理。具體架構(gòu)方案如圖2所示。

圖2 MQTT協(xié)議的科學衛(wèi)星工程數(shù)據(jù)推送總體架構(gòu)圖

3.1 系統(tǒng)需求功能描述

空間科學衛(wèi)星運行系統(tǒng)主要包括測控系統(tǒng)、科學應(yīng)用系統(tǒng)、任務(wù)支持系統(tǒng)、數(shù)傳地面接收站系統(tǒng)?？臻g科學先導專項運行系統(tǒng)按照運控計劃實施接收數(shù)據(jù)接收工作，主要有來自測控系統(tǒng)的下行遙測數(shù)據(jù)和來自數(shù)傳地面接收站的下行數(shù)傳科學數(shù)據(jù)，任務(wù)支持系統(tǒng)按照數(shù)據(jù)包格式約定將這些數(shù)據(jù)進行預處理及加工得到用戶需要的工程數(shù)據(jù)。

用戶在移動端應(yīng)用進行勾選感興趣參數(shù)操作，在軌衛(wèi)星過境時或者工程參數(shù)回放時，用戶可以進入可視化界面等待MQTT服務(wù)器推送的數(shù)據(jù)進行可視化。

3.2 服務(wù)端器部署

本文中的MQTT服務(wù)端[6，14]主要分3個層次，分別是MQTT協(xié)議層、應(yīng)用層、數(shù)據(jù)持久層。第一層是MQTT協(xié)議層，是MQTT協(xié)議的控制報文生成與發(fā)送層，它通過使用套接字對TCP協(xié)議按照控制報文格式進行封裝并通信。第二層是應(yīng)用層，包括話題統(tǒng)計模塊、服務(wù)器狀態(tài)監(jiān)視模塊、連接狀態(tài)監(jiān)視模塊、用戶管理模塊、數(shù)據(jù)庫模塊等，這一層完成整個服務(wù)器端的邏輯工作。第三層是數(shù)據(jù)持久層，數(shù)據(jù)持久層通過配置文件或者命令行的方式進行配置的初始化。初始化后，為應(yīng)用層中的數(shù)據(jù)庫模塊提供方法調(diào)用，實現(xiàn)在文件中存儲數(shù)據(jù)與讀取數(shù)據(jù)。

3.3 工程數(shù)據(jù)適配器設(shè)計實現(xiàn)

3.3.1 工程數(shù)據(jù)適配器設(shè)計

工程數(shù)據(jù)適配器功能與BS端架構(gòu)的Web服務(wù)器類似。主要完成3個功能：一是根據(jù)XML配置文件解析并完成參數(shù)主題名的優(yōu)化，最后存入哈希表中；二是接收來自任務(wù)運行系統(tǒng)的組播數(shù)據(jù)并根據(jù)哈希表中的相關(guān)參數(shù)解析每個組播數(shù)據(jù)包中的工程參數(shù)；三是將每個工程參數(shù)封裝為MQTT協(xié)議的“發(fā)布”報文后以優(yōu)化的主題名進行消息推送。以上功能設(shè)計主要考慮UDP組播格式、工程參數(shù)配置文件和MQTT主題名設(shè)計。

1）UDP組播格式說明：

組播數(shù)據(jù)包的格式如圖3，每個組播數(shù)據(jù)包為一個邏輯參數(shù)包。組播數(shù)據(jù)包中的參數(shù)序號、源碼、物理量、閾值合法性對應(yīng)不同的參數(shù)，隨著參數(shù)的增多，組播數(shù)據(jù)包變大。

圖3 組播數(shù)據(jù)包格式說明

2）工程參數(shù)配置文件說明：

任務(wù)支持系統(tǒng)將經(jīng)預處理得到的工程數(shù)據(jù)后，先進行解包操作得到各工程參數(shù)數(shù)據(jù)，然后按照工程參數(shù)配置文件進行打包轉(zhuǎn)發(fā)到工程參數(shù)數(shù)據(jù)輸出端。配置文件有兩種形式，一種是記錄式文本配置文件，另一種為XML格式配置文件。本文涉及系統(tǒng)選用XML格式作為配置文件，其結(jié)構(gòu)如圖4所示。

圖4 XML格式配置文件

XML文件的根節(jié)點為Satellite，它的子節(jié)點為多個Package節(jié)點，Package節(jié)點對應(yīng)組播UDP包中的邏輯數(shù)據(jù)包標識，name為其屬性；Package節(jié)點的子節(jié)點為一個Set節(jié)點，該節(jié)點對應(yīng)工程數(shù)據(jù)的一類集合；Set節(jié)點的子節(jié)點為多個Parameter節(jié)點，該節(jié)點的內(nèi)容為每一項參數(shù)的描述信息；其中，Parameter子節(jié)點中的No節(jié)點對應(yīng)組播UDP包中的參數(shù)序號，Length節(jié)點對應(yīng)物理量長度，Size節(jié)點對應(yīng)源碼長度。

工程數(shù)據(jù)適配器通過源碼長度值與物理長度值確定組播數(shù)據(jù)包中每個參數(shù)的數(shù)據(jù)段范圍完成解析數(shù)據(jù)包操作。

3）MQTT主題名優(yōu)化策略：

由于參數(shù)名和邏輯數(shù)據(jù)包名為中文字符串，一般采用GBK或者UTF-8編碼。如果直接使用參數(shù)名或邏輯數(shù)據(jù)包名作為主題名，這種情況下由于“發(fā)布”報文的可變報頭部分包含主題名，這會增加傳輸可變報頭時的數(shù)據(jù)流量。

本文通過將參數(shù)名與邏輯數(shù)據(jù)包名進行重新編碼形成主題名的策略，減少主題名在報文中空間使用。本文將可變長的參數(shù)名與邏輯數(shù)據(jù)包名空間映射到固定長度主題名空間，從而達到MQTT協(xié)議主題名優(yōu)化目的。每次客戶端與服務(wù)器端進行訂閱、發(fā)布只需要通過優(yōu)化后的主題名列表進行信息交互，降低服務(wù)器端向客戶端推送數(shù)據(jù)的流量使用。

因此工程數(shù)據(jù)適配器以編碼后的參數(shù)名、邏輯數(shù)據(jù)包名命名主題會大大減少可變報頭大小，實現(xiàn)更低流量的推送與接收。

3.3.2 工程數(shù)據(jù)適配器實現(xiàn)

工程數(shù)據(jù)適配器在初始化階段完成第一個功能。首先進行XML配置文件初始化參數(shù)配置哈希表容器，遍歷XML文件中的Package節(jié)點，通過Parameter節(jié)點下的ParaCode節(jié)點獲得邏輯數(shù)據(jù)包標識，并保存到Package結(jié)構(gòu)體，每遍歷完一個Parameter節(jié)點將其添加到Parameter的哈希表中，每個Parameter的哈希表中分別保存著參數(shù)序號、源碼長度、物理量長度、參數(shù)名、主題名的結(jié)構(gòu)體信息。當所有參數(shù)遍歷完成之后將Parameter的哈希表頭節(jié)點添加到Package的哈希表中。同理，依次添加其他Package節(jié)點。。最后哈希表保存了工程數(shù)據(jù)適配器從XML文件中解析后獲得的配置信息。

當接收到來自任務(wù)支持系統(tǒng)的組播UDP數(shù)據(jù)后，根據(jù)組播UDP包中的邏輯數(shù)據(jù)包標識查找Package哈希表對應(yīng)的Package，然后根據(jù)組播UDP數(shù)據(jù)包中的參數(shù)序號查找Parameter哈希表中對應(yīng)的參數(shù)以獲得源碼長度和物理量長度。如果參數(shù)物理量長度為0，則只推送源碼，否側(cè)只向主題名推送物理量。由于每個邏輯數(shù)據(jù)包中的參數(shù)代號為0的參數(shù)處于保留狀態(tài)。所以將每個組播UDP數(shù)據(jù)包的星上時推送到對應(yīng)邏輯數(shù)據(jù)包標識中對應(yīng)的0參數(shù)序號的主題名上。完成單個組播UDP數(shù)據(jù)包的解析與向?qū)?yīng)主題的發(fā)布后，接收組播UDP的socket進入阻塞狀態(tài)等待接收下次組播UDP數(shù)據(jù)包的到達。

3.4 移動端應(yīng)用

本文的移動端應(yīng)用基于Android MVC框架模式[4，15]?？刂茖油ㄟ^主要完成封裝MQTT協(xié)議與發(fā)送、接收MQTT報文，并操作模型層。模型層根據(jù)可視化層中數(shù)據(jù)的類型的需要，通過單例模式實現(xiàn)模型層。視圖層主要是通過依賴基于Java Canvas控件開發(fā)的開源框架實時完成曲線的繪制。

在可視化界面中，每個參數(shù)的星上時作為橫坐標軸，參數(shù)的物理量作為縱坐標。參數(shù)對應(yīng)星上時來自邏輯參數(shù)邏輯包對應(yīng)星上時主題，物理量來自參數(shù)對應(yīng)主題。

在每次客戶端初始化時，必須先訂閱解碼表所在主題，并設(shè)置工程數(shù)據(jù)適配器推送解碼表時采用Retain的方式，以便所有客戶端訂閱編碼表主題時都能獲得解碼表。

4 系統(tǒng)測試及結(jié)果分析

本文的測試通過模擬在線任務(wù)支持系統(tǒng)向工程數(shù)據(jù)適配器發(fā)送一段時長約10分鐘的工程數(shù)據(jù)包進行測試。這段測試數(shù)據(jù)源是由科學衛(wèi)星過站時在軌運行任務(wù)支持系統(tǒng)從測控系統(tǒng)接收到的遙測工程數(shù)據(jù)，再由任務(wù)支持系統(tǒng)發(fā)送的組播UDP包，最后進行本地保存的方式獲得。測試系統(tǒng)通過模擬任務(wù)支持系統(tǒng)發(fā)送組播UDP數(shù)據(jù)包實現(xiàn)科學衛(wèi)星過站時的下行科學衛(wèi)星工程數(shù)據(jù)流程。

由于任務(wù)支持系統(tǒng)發(fā)送的是組播UDP數(shù)據(jù)包，系統(tǒng)測試必須考慮由于發(fā)送頻率過高導致UDP的丟包問題[16]。任務(wù)支持系統(tǒng)發(fā)送的UDP數(shù)據(jù)包是按照將地面接收系統(tǒng)或測控接收系統(tǒng)發(fā)出的TCP數(shù)據(jù)流進行解包再打包的流程操作的，因此會有時間間隔。只要工程數(shù)據(jù)適配器在時間間隔內(nèi)完成UDP包的解包與推送操作就可以將程序?qū)е耈DP丟包的問題解決。測試系統(tǒng)播放的是一段時長為10分鐘的遙測工程數(shù)據(jù)文件。如果在10分鐘內(nèi)回放完畢所推送的數(shù)據(jù)量，與在更短的時間內(nèi)回放完畢所推送的數(shù)據(jù)量一致，就可以認為工程數(shù)據(jù)適配器沒有因為程序在解包與推送時耗時過長造成UDP數(shù)據(jù)包丟失。

4.1 測試方法

本地保存的UDP數(shù)據(jù)為連續(xù)的UDP數(shù)據(jù)包流，為了模擬任務(wù)支持系統(tǒng)發(fā)送的組播UDP包，需要根據(jù)任務(wù)支持系統(tǒng)內(nèi)的約定格式進行發(fā)送，即一個UDP數(shù)據(jù)包為一個邏輯數(shù)據(jù)包并包括其下所有參數(shù)。實際每個組播UDP數(shù)據(jù)包的結(jié)構(gòu)進行拆包后再發(fā)送。

測試系統(tǒng)通過拆包后發(fā)送UDP數(shù)據(jù)包的方式模擬任務(wù)支持系統(tǒng)發(fā)出的組播UDP包。工程數(shù)據(jù)適配器收UDP包后進行解包與推送到服務(wù)端，同時移動端應(yīng)用訂閱感興趣主題。當服務(wù)端收到工程適配器的發(fā)布消息后推送到移動端應(yīng)用，最后由移動端應(yīng)用完成可視化操作。

4.2 測試結(jié)果與分析

4.2.1 功能測試

如圖5、6所示。圖5左截圖為移動端應(yīng)用的訂閱參數(shù)界面，右截圖為勾選“星務(wù)采集母線電壓”工程參數(shù)界面。

圖5 移動端應(yīng)用界面

圖6所示為參數(shù)可視化界面的截圖，可視化界面采用曲線的方式進行顯示。

從上面的測試結(jié)果可以看出移動端應(yīng)用與系統(tǒng)的訂閱功能、推送功能、可視化功能良好。

4.2.2 性能測試

表1與表2所示的數(shù)據(jù)為測試文件由測試系統(tǒng)回放完后，通過統(tǒng)計工程數(shù)據(jù)適配器的日志信息得來的數(shù)據(jù)。

性能測試共3個測試項目，分別是1分鐘回放完數(shù)據(jù)、5分鐘回放完數(shù)據(jù)、與采用未優(yōu)化主題名時1分鐘回放完數(shù)據(jù)。

圖6 參數(shù)可視化界面

表1 接收測試統(tǒng)計表

從表1中可以看出，長約10分鐘的數(shù)據(jù)源文件，1分鐘回放完數(shù)據(jù)與用約5分鐘回放完數(shù)據(jù)，兩次推送的剩余字節(jié)數(shù)一致。從兩次的對比可以看出，工程數(shù)據(jù)適配器沒有產(chǎn)生丟包。

表2 優(yōu)化測試統(tǒng)計表

從表2中的前兩個測試可看出采用優(yōu)化主題名的推送的剩余字節(jié)數(shù)為3 650 390字節(jié)。第三個測試直接采用主題名與工程參數(shù)名一致的方式進行推送的剩余字節(jié)數(shù)為23 808 212字節(jié)。對比可以看出主題名的優(yōu)化帶來6倍以上的流量優(yōu)化。因為用戶一般不會訂閱所有主題，因此這無法代表用戶通過移動端應(yīng)用訂閱感興趣主題時節(jié)省的流量，但可以反應(yīng)出平均的優(yōu)化效果。

5 結(jié)束語

本文的衛(wèi)星工程數(shù)據(jù)低流量推送系統(tǒng)，實現(xiàn)了適用于任務(wù)支持系統(tǒng)向移動端推送的低流量方案。通過采用主題名優(yōu)化的方式對MQTT協(xié)議中的“發(fā)布”報文進行空間壓縮，以達到進一步節(jié)省流量的目的。本論文的中的MQTT服務(wù)器部署、與工程數(shù)據(jù)適配器并不完善，沒有在安全性方面考慮，在以后的工作中將會側(cè)重這方面的工作。

參考文獻：

[1]楊鵬.基于MQTT協(xié)議的信息推送平臺系統(tǒng)的設(shè)計與實現(xiàn)[D].成都：電子科技大學，2015.

[2]顧正敏.一種面向Android平臺的輕量級推送技術(shù)研究與應(yīng)用[D].北京：北京大學，2013.

[3]崔東歡，郭立君，張榮，等.基于MQTT協(xié)議的移動IM系統(tǒng)設(shè)計與實現(xiàn)[J].移動通信，2016（16）:80-85.

[4]關(guān)慶余，李鴻彬，于波.MQTT協(xié)議在Android平臺上的研究與應(yīng)用[J].計算機系統(tǒng)應(yīng)用，2014（4）:196-200.

[5]陳樸.基于Web的企業(yè)統(tǒng)一通信終端開發(fā)套件的設(shè)計與實現(xiàn)[D].沈陽：中國科學院研究生院（沈陽計算技術(shù)研究所），2016.

[6]任亨.基于MQTT協(xié)議的消息推送集群系統(tǒng)的設(shè)計與實現(xiàn)[D].沈陽：中國科學院研究生院（沈陽計算技術(shù)研究所），2014.

[7]陳濤，李娟.基于MQTT協(xié)議的推送技術(shù)研究[J].軟件導刊，2016（3）:18-21.

[8]劉峰，陳樸，賈軍營.WebSocket與MQTT在Web即時通信系統(tǒng)中的應(yīng)用[J].計算機系統(tǒng)應(yīng)用，2016（5）:28-33.

[9]周樂欽，燕彩蓉，蘇厚勤.基于Web-Socket協(xié)議的推送數(shù)據(jù)技術(shù)在監(jiān)控系統(tǒng)中的應(yīng)用研究[J].計算機應(yīng)用與軟件，2013（5）:229-232.

[10]賈軍營，王月鵬，王少華.基于MQTT協(xié)議IM的研究和實現(xiàn)[J].計算機系統(tǒng)應(yīng)用，2015（7）:9-14.

[11]馬躍，孫翱，賈軍營，等.MQTT協(xié)議在移動互聯(lián)網(wǎng)即時通信中的應(yīng)用[J].計算機系統(tǒng)應(yīng)用，2016（3）:170-176.

[12]許金喜，張新有.Android平臺基于MQTT協(xié)議的推送機制[J].計算機系統(tǒng)應(yīng)用，2015（1）:185-190.

[13]王月鵬.面向企業(yè)的統(tǒng)一通信客戶端的設(shè)計與實現(xiàn)[D].沈陽：中國科學院研究生院（沈陽計算技術(shù)研究所），2015.

[14]許金喜，張新有.Android平臺基于MQTT協(xié)議的推送機制[J].計算機系統(tǒng)應(yīng)用，2015（1）:185-190.

[15]蓋榮麗，錢玉磊，李鴻彬，等.基于MQTT的企業(yè)消息推送系統(tǒng)[J].計算機系統(tǒng)應(yīng)用，2015（11）:69-75.

[16]張愷.基于UDP的可靠文件傳輸協(xié)議的設(shè)計與實現(xiàn)[D].西安：西安電子科技大學，2014.