衛星工程數據低流量推送系統的設計與實現

盧 山 ，胡 鈦 ，李 虎

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

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

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

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

1 移動端平臺的推送機制現狀

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

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

2 MQTT協議介紹

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

圖1 MQTT控制報文格式

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

3 系統設計與實現

考慮到兼容性，在不影響現有任務支持系統基礎上，本文設計的MQTT協議的科學衛星工程數據推送系統分為三部分，分別為MQTT服務端、工程數據適配器端和移動端應用，并在MQTT協議的可變報頭位置進行了主題名優化處理。具體架構方案如圖2所示。

圖2 MQTT協議的科學衛星工程數據推送總體架構圖

3.1 系統需求功能描述

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

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

3.2 服務端器部署

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

3.3 工程數據適配器設計實現

3.3.1 工程數據適配器設計

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

1）UDP組播格式說明：

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

圖3 組播數據包格式說明

2）工程參數配置文件說明：

任務支持系統將經預處理得到的工程數據后，先進行解包操作得到各工程參數數據，然后按照工程參數配置文件進行打包轉發到工程參數數據輸出端。配置文件有兩種形式，一種是記錄式文本配置文件，另一種為XML格式配置文件。本文涉及系統選用XML格式作為配置文件，其結構如圖4所示。

圖4 XML格式配置文件

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

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

3）MQTT主題名優化策略：

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

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

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

3.3.2 工程數據適配器實現

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

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

3.4 移動端應用

本文的移動端應用基于Android MVC框架模式[4，15]。控制層通過主要完成封裝MQTT協議與發送、接收MQTT報文，并操作模型層。模型層根據可視化層中數據的類型的需要，通過單例模式實現模型層。視圖層主要是通過依賴基于Java Canvas控件開發的開源框架實時完成曲線的繪制。

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

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

4 系統測試及結果分析

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

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

4.1 測試方法

本地保存的UDP數據為連續的UDP數據包流，為了模擬任務支持系統發送的組播UDP包，需要根據任務支持系統內的約定格式進行發送，即一個UDP數據包為一個邏輯數據包并包括其下所有參數。實際每個組播UDP數據包的結構進行拆包后再發送。

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

4.2 測試結果與分析

4.2.1 功能測試

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

圖5 移動端應用界面

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

從上面的測試結果可以看出移動端應用與系統的訂閱功能、推送功能、可視化功能良好。

4.2.2 性能測試

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

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

圖6 參數可視化界面

表1 接收測試統計表

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

表2 優化測試統計表

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

5 結束語

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

參考文獻：

[1]楊鵬.基于MQTT協議的信息推送平臺系統的設計與實現[D].成都：電子科技大學，2015.

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

[3]崔東歡，郭立君，張榮，等.基于MQTT協議的移動IM系統設計與實現[J].移動通信，2016（16）:80-85.

[4]關慶余，李鴻彬，于波.MQTT協議在Android平臺上的研究與應用[J].計算機系統應用，2014（4）:196-200.

[5]陳樸.基于Web的企業統一通信終端開發套件的設計與實現[D].沈陽：中國科學院研究生院（沈陽計算技術研究所），2016.

[6]任亨.基于MQTT協議的消息推送集群系統的設計與實現[D].沈陽：中國科學院研究生院（沈陽計算技術研究所），2014.

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

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

[9]周樂欽，燕彩蓉，蘇厚勤.基于Web-Socket協議的推送數據技術在監控系統中的應用研究[J].計算機應用與軟件，2013（5）:229-232.

[10]賈軍營，王月鵬，王少華.基于MQTT協議IM的研究和實現[J].計算機系統應用，2015（7）:9-14.

[11]馬躍，孫翱，賈軍營，等.MQTT協議在移動互聯網即時通信中的應用[J].計算機系統應用，2016（3）:170-176.

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

[13]王月鵬.面向企業的統一通信客戶端的設計與實現[D].沈陽：中國科學院研究生院（沈陽計算技術研究所），2015.

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

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

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