基于MQTT協(xié)議族的AMI通信支撐平臺(tái)設(shè)計(jì)

梁　捷

(廣西電網(wǎng)有限責(zé)任公司電力科學(xué)研究院，廣西 南寧 530023)

0　引言

傳統(tǒng)的人工抄表方式自動(dòng)化程度低，漏抄、錯(cuò)抄等情況時(shí)有發(fā)生。隨著智能電網(wǎng)的建設(shè)，以遠(yuǎn)程電能數(shù)據(jù)自動(dòng)靈活采集技術(shù)為特征之一的高級(jí)計(jì)量架構(gòu)(advanced metrology institution，AMI)出現(xiàn)，并得到發(fā)展。AMI通信支撐平臺(tái)建設(shè)時(shí)，需解決實(shí)際應(yīng)用中常見(jiàn)的通信網(wǎng)存在多種通信方式并存[1]，電力用戶基數(shù)龐大，采集的數(shù)據(jù)項(xiàng)多，工作網(wǎng)絡(luò)的低速和不穩(wěn)定性[2]等問(wèn)題。

消息隊(duì)列遙測(cè)傳輸協(xié)議（Message Queue Telemetry Transport，MQTT）協(xié)議族是針對(duì)低速、低質(zhì)量的網(wǎng)絡(luò)開(kāi)發(fā)的一種輕量級(jí)基于代理的發(fā)布/訂閱消息傳輸協(xié)議族。它包含多種支持不同通信信道的子協(xié)議，可通過(guò)鏈路層子域劃分滿足混合通信網(wǎng)的需求，報(bào)文格式簡(jiǎn)單，有利于提高AMI信息平臺(tái)的網(wǎng)絡(luò)通訊速度，改善不同通信協(xié)議的兼容環(huán)境[3]。

本文介紹了MQTT協(xié)議族在電能數(shù)據(jù)采集系統(tǒng)中的應(yīng)用，給出了該系統(tǒng)的物理和邏輯框架，說(shuō)明了關(guān)鍵的組網(wǎng)技術(shù)，并對(duì)不同通信質(zhì)量服務(wù)等級(jí)下的CPU資源使用狀況和消息吞吐能力進(jìn)行測(cè)試和分析。

1　MQTT協(xié)議族簡(jiǎn)介

MQTT協(xié)議族包括MQ、MQTT、MQTT-P等協(xié)議[3]。MQTT(Message Queue Telemetry Transport，MQTT)，即消息序列傳送規(guī)約，是一種規(guī)則簡(jiǎn)約的支持觀察者模式的傳送規(guī)約，旨在改善使用TCP/IP建立的不可靠并且低帶寬的小型設(shè)備之間的連接質(zhì)量。

MQTT的報(bào)文起始部分由兩個(gè)字節(jié)的固定起始符和多達(dá)12個(gè)字節(jié)的附加可變起始符組成。該協(xié)議使用可變起始符來(lái)進(jìn)行預(yù)訂和連接，對(duì)于大多數(shù)發(fā)布則使用只有兩個(gè)字節(jié)的固定起始符。由于規(guī)約起始符和消息字節(jié)數(shù)組的有效內(nèi)容長(zhǎng)度均較短，故使得消息整體較小，有利于降低網(wǎng)絡(luò)流量。

表1　不同消息傳輸協(xié)議的特點(diǎn)比較

由表1可見(jiàn)，在兼容性方面，由于MQTT支持C、Java、Python、JS等多種開(kāi)發(fā)語(yǔ)言，且支持同步、異步多種傳輸模式，故在程序設(shè)計(jì)上更為靈活。在功能方面，提供三種服務(wù)質(zhì)量級(jí)別，具備雙向連接通訊的實(shí)時(shí)推送；在開(kāi)銷方面，為了降低網(wǎng)絡(luò)流量，客戶端協(xié)議棧盡量最小化，其中基于C語(yǔ)言的MQTT的Class庫(kù)只有30Kb，不僅可以有效節(jié)省設(shè)備空間，而且能在最低為8 bit的CPU上運(yùn)行[6]。

MQTT-P是在MQTT協(xié)議基礎(chǔ)上研究設(shè)計(jì)出的適用于RS232/485以及載波通信情況下的通信傳輸協(xié)議，設(shè)計(jì)實(shí)現(xiàn)上考慮了AMI抄表的業(yè)務(wù)特點(diǎn)和通信環(huán)境，可與MQTT協(xié)議搭配使用，可嵌入智能電表和集中器中。MQTT-P協(xié)議是一個(gè)高效的非IP網(wǎng)絡(luò)下的通信協(xié)議，區(qū)別于電網(wǎng)中的傳統(tǒng)通信協(xié)議，引入了訂閱與發(fā)布機(jī)制，使得后臺(tái)應(yīng)用服務(wù)器與前端設(shè)備解耦，保持各自的獨(dú)立性，便于局部更新和分區(qū)管理。

圖1　MQTT及MQTT-P協(xié)議棧的結(jié)構(gòu)

如圖1，MQTT/MQTT-P屬于應(yīng)用層規(guī)約，對(duì)上層業(yè)務(wù)應(yīng)用層提供底層數(shù)據(jù)通訊功能支撐。其中，MQTT-P在下行網(wǎng)絡(luò)，如PLC窄帶載波上，由于沒(méi)有網(wǎng)絡(luò)層和傳輸層的控制，所以在設(shè)計(jì)規(guī)約的過(guò)程中復(fù)用了鏈路層HDLC很多設(shè)計(jì)，對(duì)上層提供類似于MQTT的應(yīng)用層接口。MQTT在網(wǎng)絡(luò)層上和HTTP的規(guī)約類似，它構(gòu)建在TCP/IP網(wǎng)絡(luò)應(yīng)用層規(guī)約基礎(chǔ)上，只需對(duì)上層提供簡(jiǎn)單的通道連接、數(shù)據(jù)發(fā)送和接收接口。

2　系統(tǒng)模型

2.1　系統(tǒng)通用架構(gòu)

如圖2，電能遠(yuǎn)程數(shù)據(jù)采集系統(tǒng)通常采用主站-集中器-電表三層結(jié)構(gòu)，用戶電量數(shù)據(jù)由電表采集后通過(guò)集中器傳輸?shù)街髡綶7]。

圖2　系統(tǒng)通用部署架構(gòu)

由于用戶基數(shù)龐大(千萬(wàn)級(jí))，新一代智能電表需要采集的數(shù)據(jù)項(xiàng)越來(lái)越多，數(shù)據(jù)采集的時(shí)間間隔越來(lái)越小，導(dǎo)致單位時(shí)間內(nèi)需上傳的數(shù)據(jù)量越來(lái)越龐大。傳統(tǒng)的電力信息采集和通信網(wǎng)絡(luò)一般包括GPRS、以太網(wǎng)、RS232/485、無(wú)線Zigbee、PLC等，屬于復(fù)雜的混合通信網(wǎng)，存在信道頻段復(fù)用度高、信息傳送速率低、信道易受干擾等問(wèn)題，且缺乏統(tǒng)一的服務(wù)保障機(jī)制。

對(duì)此，在選擇圖2系統(tǒng)的通訊協(xié)議時(shí)，應(yīng)考慮通信終端數(shù)據(jù)分析和處理能力、協(xié)議棧支持的平臺(tái)、開(kāi)發(fā)語(yǔ)言、協(xié)議棧的大小以及它對(duì)設(shè)備空間和資源的占用等問(wèn)題。

2.2　系統(tǒng)邏輯框架

基于MQTT協(xié)議族的AMI通信支撐系統(tǒng)邏輯框架如圖3所示，下行鏈路，管理人員利用后臺(tái)主站服務(wù)器通過(guò)MQ通信協(xié)議發(fā)布話題到前置機(jī)上，再通過(guò)MQTT協(xié)議由前置機(jī)路由命令到集中器上，集中器收到命令并解析，再視情況對(duì)接收MQTT-P協(xié)議命令分發(fā)的所轄表計(jì)數(shù)量進(jìn)行調(diào)整。對(duì)于上行鏈路，依次走相反的協(xié)議處理過(guò)程，表計(jì)收到命令后，采集數(shù)據(jù)，組合成相應(yīng)的報(bào)文返回到集中器，集中器再將組合的信息發(fā)布到相應(yīng)的話題上，最終在主站服務(wù)器上顯示結(jié)果。

圖3　本文AMI系統(tǒng)邏輯框架

2.3　組網(wǎng)技術(shù)支撐

為滿足現(xiàn)場(chǎng)對(duì)通信準(zhǔn)確性的不同需要，MQTT-P協(xié)議支持QOS0，QOS1，QOS2三種消息發(fā)布服務(wù)質(zhì)量等級(jí)(Quality of Service，簡(jiǎn)稱QOS)[8]：

QOS0：接收單元“最多一次”接收發(fā)送單元發(fā)來(lái)的通信幀，會(huì)發(fā)生消息丟失或重復(fù)。從服務(wù)等級(jí)上看，服務(wù)質(zhì)量是不太可靠，但其傳輸效率較高。

QOS1：接收單元“至少一次”接收發(fā)送單元發(fā)來(lái)的通信幀。從服務(wù)質(zhì)量上來(lái)講，基本能保證消息到達(dá)，其通信質(zhì)量可靠，但是其傳輸效率居中。但是接收單元有可能會(huì)多次收到發(fā)送單元發(fā)來(lái)的報(bào)文，從而帶來(lái)應(yīng)用層處理的混亂。

QOS2：接收單元“有且僅有一次”接收發(fā)送單元發(fā)來(lái)的通信幀，要求設(shè)備上具有持久存儲(chǔ)器，用來(lái)保持協(xié)議狀態(tài)和臨時(shí)存儲(chǔ)通信幀，直至確定接收單元接收到此消息才清除相關(guān)緩存。從服務(wù)質(zhì)量上來(lái)講，通信質(zhì)量是可靠，接收方不會(huì)收到多次發(fā)送方發(fā)來(lái)的報(bào)文，應(yīng)用層處理起來(lái)也比較方便，缺點(diǎn)是傳輸效率不高。

可見(jiàn)，MQTT-P協(xié)議為應(yīng)用層提供了完備的服務(wù)質(zhì)量等級(jí)，應(yīng)用層程序可以綜合考慮通信等待時(shí)間與可靠性，視應(yīng)用的需要進(jìn)行靈活選擇。例如：對(duì)于關(guān)鍵業(yè)務(wù)數(shù)據(jù)，電能指標(biāo)等，可以采用QOS2的服務(wù)等級(jí)，以保證傳輸可靠性。而對(duì)一些不太關(guān)鍵的數(shù)據(jù)應(yīng)用可使用QOS0的服務(wù)等級(jí)，以降低整個(gè)PLC系統(tǒng)的通信消耗。

在MQTT-P協(xié)議的設(shè)計(jì)和實(shí)現(xiàn)中，引入組播機(jī)制以解決拆鏈?zhǔn)д`帶來(lái)的問(wèn)題。圖2所示集中器和所屬表計(jì)的所在低壓電力通信網(wǎng)區(qū)在物理介質(zhì)上可視作一個(gè)廣播系統(tǒng)。有一對(duì)一和一對(duì)多兩種廣播模式。一對(duì)一模式中，由于集中器是逐個(gè)依次與表計(jì)建鏈，采集數(shù)據(jù)完成后再拆除鏈路，此時(shí)，有可能存在操作失誤，沒(méi)有完全拆除鏈路就轉(zhuǎn)去采集下一個(gè)表計(jì)，造成有些鏈路仍連通的問(wèn)題。這種現(xiàn)象在一臺(tái)集中器控制幾百個(gè)電表的情況下尤其突出。

一對(duì)多的廣播模式即組播，應(yīng)用層程序可以利用組播來(lái)進(jìn)行同步拆鏈或校時(shí)等操作。若存在上次拆鏈?zhǔn)д`的表計(jì)，它仍處在傳輸狀態(tài)中，此時(shí)若發(fā)起通信，通信兩端的狀態(tài)不同步，通信的一方為了確認(rèn)對(duì)方的狀態(tài)會(huì)陷入超時(shí)等待過(guò)程。此時(shí)若引入組播拆鏈的過(guò)程，定時(shí)用組播方式進(jìn)行全體表計(jì)拆鏈，可為網(wǎng)絡(luò)終端多提供一次拆鏈機(jī)會(huì)，可減少該問(wèn)題的發(fā)生。

3　系統(tǒng)測(cè)試及分析

測(cè)試平臺(tái)邏輯架構(gòu)參考圖2，包括10只智能電表和1個(gè)集中器，通信方式：表計(jì)到集中器為電力線載波，集中器到前置機(jī)為GPRS，前置機(jī)到主站服務(wù)器為TCP/IP。

3.1　不同服務(wù)質(zhì)量下的CPU資源使用狀況測(cè)試

本測(cè)試通過(guò)多路服務(wù)器和soapUI模擬軟件模擬1～10萬(wàn)個(gè)集中器客戶端接入主站服務(wù)器，測(cè)試結(jié)果見(jiàn)圖4，可見(jiàn)，并發(fā)連接數(shù)由1萬(wàn)放大10倍后，各QOS下CPU資源消耗增加不超過(guò)30%，從曲線變化趨勢(shì)看，CPU資源隨連接數(shù)的放大幾乎成線性的增長(zhǎng)，并沒(méi)有對(duì)服務(wù)器造成大的性能壓力，這是由于基于C的MQTT的Class庫(kù)占用空間小，只有30Kb，對(duì)服務(wù)器處理資源需求較低。

圖4　不同QOS下的CPU資源使用狀況

QOS級(jí)別的由高到低的順序?yàn)镼OS2＞QOS1＞QOS0，由圖4可見(jiàn)，CPU資源占用率是QOS0＞QOS2＞QOS1，此處不能認(rèn)為服務(wù)質(zhì)量級(jí)別越高可靠性越高，從而CPU資源使用率越高。這是由于在測(cè)試環(huán)境下CPU的使用率不是孤立的，需要和消息處理能力結(jié)合來(lái)分析。當(dāng)QOS0時(shí)，雖然在消息流交互上比QOS1，QOS2簡(jiǎn)單，但消息的處理能力最強(qiáng)，處理的消息數(shù)最多，所以在三種質(zhì)量服務(wù)下，QOS0的CPU消耗最高；雖然QOS1下的消息處理能力比QOS2強(qiáng)，但差距不大。而且由2.3節(jié)，QOS1下接收單元有可能會(huì)多次收到發(fā)送單元發(fā)來(lái)的報(bào)文，QOS1對(duì)這些重復(fù)數(shù)據(jù)不做進(jìn)一步處理而直接傳給上層應(yīng)用，QOS2則需要處理這些重復(fù)的消息，因此交互流程比QOS1復(fù)雜，所以會(huì)出現(xiàn)QOS2下的CPU使用率比QOS1高。

3.2　不同服務(wù)質(zhì)量下的消息吞吐能力測(cè)試

本測(cè)試模擬了一臺(tái)集中器控制104～105只電表。模擬方法是在一個(gè)采集周期(Tc=5min)內(nèi)，集中器對(duì)每只電表各進(jìn)行1000次正向有功總電量數(shù)據(jù)采集，則相當(dāng)于多個(gè)電表往前置機(jī)發(fā)布數(shù)據(jù)包，每個(gè)數(shù)據(jù)包大小為21個(gè)字節(jié)。

圖5　不同QOS下系統(tǒng)的消息吞吐能力

由圖5可見(jiàn)，隨著電表數(shù)的增加，服務(wù)器每個(gè)Tc發(fā)布的消息數(shù)減少，對(duì)消息的處理能力下降，但在105并發(fā)連接且在最嚴(yán)苛的質(zhì)量服務(wù)QOS2下仍能達(dá)到將近每秒1000條消息的處理能力，證明了該通信系統(tǒng)在大規(guī)模客戶端并發(fā)接入的情況下，仍能保持較好的消息處理能力。

4　結(jié)論

MQTT協(xié)議族是為低速、低質(zhì)量通信網(wǎng)絡(luò)和處理能力及內(nèi)存資源有限的服務(wù)器設(shè)計(jì)的標(biāo)準(zhǔn)輕量級(jí)消息傳輸協(xié)議。它的比特級(jí)消息頭和可變長(zhǎng)度域設(shè)計(jì)能有效降低網(wǎng)絡(luò)流量。它還并提供豐富的消息發(fā)布服務(wù)質(zhì)量等級(jí)和高效率的組播機(jī)制，適用于自動(dòng)電能數(shù)據(jù)采集系統(tǒng)的需要。

本文提出一種基于MQTT協(xié)議族的電能數(shù)據(jù)采集通信支撐平臺(tái)設(shè)計(jì)，通過(guò)MQTT實(shí)現(xiàn)計(jì)量自動(dòng)化終端與后臺(tái)主站的通信和數(shù)據(jù)采集，通過(guò)MQTT-P實(shí)現(xiàn)不同服務(wù)質(zhì)量下數(shù)據(jù)采集終端與集中器的通信。測(cè)試結(jié)果表明，本系統(tǒng)在含多種通信信道的復(fù)合網(wǎng)絡(luò)中運(yùn)行穩(wěn)定，信息處理能力強(qiáng)，服務(wù)器資源占用較少，展示出良好的應(yīng)用前景。

參考文獻(xiàn)(References):

[1]王立城.基于AMI測(cè)量參數(shù)的電力線通信組網(wǎng)技術(shù)[J].電測(cè)與儀表,2017.54(21):42-48

[2]紀(jì)杉.提高用電信息采集成功率的研究[D].沈陽(yáng)農(nóng)業(yè)大學(xué)碩士學(xué)位論文,2016.

[3]林滸,張家銘,楊海波.基于MQTT協(xié)議的即時(shí)消息業(yè)務(wù)設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2017.26(3):219-224

[4]滕陽(yáng)陽(yáng),胡棟.基于Netty的HTTP協(xié)議棧的擴(kuò)展設(shè)計(jì)與實(shí)現(xiàn)[J].無(wú)線通信技術(shù),2017.26(3):38-42

[5]張令芬.一種基于JMS的實(shí)時(shí)推送技術(shù)[J].電子設(shè)計(jì)工程,2015.23(23):60-62

[6]任亨,馬躍,楊海波等.基于MQTT協(xié)議的消息推送服務(wù)器[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2014.23(3):77-82

[7]岳帥.用電信息采集系統(tǒng)的工作原理及應(yīng)用[J].科技創(chuàng)新與應(yīng)用,2016.46(17):182-182

[8]何干志,劉茜萍.基于QoS綜合評(píng)價(jià)的服務(wù)選擇方法[J].計(jì)算機(jī)技術(shù)與發(fā)展,2017.27(8):164-170