[發(fā)明專利]一種基于MQTT協(xié)議的設備監(jiān)控方法與裝置

有效

• 申請?zhí)枺?/td>: 202010545901.4
• 申請日: 2020-06-16
• 公開（公告）號: CN111818129B
• 公開（公告）日: 2023-04-28
• 發(fā)明（設計）人: 王平;王學斌;吳文波;金翔;楊友蘭;馬毅華
• 申請（專利權(quán)）人: 上海申鐵信息工程有限公司
• 主分類號: H04L67/125
• 分類號: H04L67/125;H04L67/02;H04L69/163
• 代理公司: 上海科盛知識產(chǎn)權(quán)代理有限公司 31225
• 代理人: 宣慧蘭

本發(fā)明涉及一種基于MQTT協(xié)議的設備監(jiān)控方法，執(zhí)行MQTT協(xié)議的模塊包括設備側(cè)客戶端、中介服務器和軟件側(cè)客戶端，具體包括以下步驟：步驟S1：設備側(cè)和軟件側(cè)分別向中介服務器訂閱閉環(huán)下行消息與閉環(huán)上行消息；步驟S2：軟件側(cè)向中介服務器發(fā)布閉環(huán)下行消息，并發(fā)送至設備側(cè)；步驟S3：設備側(cè)對接收到的閉環(huán)下行消息進行處理，向中介服務器發(fā)布閉環(huán)上行消息，并發(fā)送至軟件側(cè)；步驟S4：軟件側(cè)接收閉環(huán)上行消息，記錄發(fā)送閉環(huán)下行消息與接收閉環(huán)上行消息之間的閉環(huán)時間間隔，若大于門限值，或者差值大于門限值，則產(chǎn)生相應告警信息，并上報。與現(xiàn)有技術相比，本發(fā)明具有提高設備監(jiān)控的判定結(jié)果的穩(wěn)定性與準確性、擴大設備監(jiān)控的適用范圍等優(yōu)點。

技術領域

本發(fā)明涉及物聯(lián)網(wǎng)技術領域，尤其是涉及一種基于MQTT協(xié)議的設備監(jiān)控方法與裝置。

背景技術

在物聯(lián)網(wǎng)IoT的設備層與軟件層接口上，HTTP與MQTT是兩大主流接口協(xié)議。HTTP是網(wǎng)頁的事實標準，但是軟件與機器之間的接口往往并不適用請求/回答模式，而是需要采用基于發(fā)布/訂閱模式的MQTT協(xié)議。

MQTT是基于二進制消息的發(fā)布/訂閱編程模式的消息協(xié)議，與HTTP、CoAP、XMPP等協(xié)議相比，MQTT協(xié)議在物聯(lián)網(wǎng)應用中具有以下優(yōu)勢：

一、MQTT基于TCP，相比CoAP基于UDP，對設備的下行控制更可靠；

二、MQTT基于異步Pub/Sub實現(xiàn)，相比HTTP、CoAP的同步模式，通信時延更小；

三、MQTT擁有針對物聯(lián)網(wǎng)的QoS機制與Will機制。

但是，與HTTP協(xié)議一樣，MQTT仍只是物聯(lián)網(wǎng)的設備層與軟件層的接口協(xié)議，并不是一種能從軟件監(jiān)控到設備傳感與執(zhí)行層的端到端協(xié)議。因此，在MQTT的基礎上，需要一種基于MQTT協(xié)議的設備監(jiān)控方法與裝置，支持軟件層對設備傳感與執(zhí)行層進行端到端監(jiān)控。

現(xiàn)有技術中公開了一種基于端-邊-云架構(gòu)的社區(qū)火災監(jiān)測系統(tǒng)，在數(shù)據(jù)上行中將所述社區(qū)火災監(jiān)測數(shù)據(jù)轉(zhuǎn)換為MQTT協(xié)議數(shù)據(jù)格式后匯聚到云網(wǎng)關，在數(shù)據(jù)下行中由云網(wǎng)關中的閾值預警模塊判斷是否出現(xiàn)異常。但僅根據(jù)火災監(jiān)測數(shù)據(jù)的數(shù)值大小來對異常情況進行判斷，數(shù)據(jù)來源較為單一，判斷結(jié)果容易出現(xiàn)較大誤差，同時該方法不是對設備傳感與執(zhí)行層進行端到端通信質(zhì)量監(jiān)控的通用性方法。

發(fā)明內(nèi)容

本發(fā)明的目的就是為了克服上述現(xiàn)有技術存在的缺少端到端協(xié)議、缺乏通用性的缺陷而提供一種基于MQTT協(xié)議的設備監(jiān)控方法與裝置。

本發(fā)明的目的可以通過以下技術方案來實現(xiàn)：

一種基于MQTT協(xié)議的設備監(jiān)控方法，執(zhí)行所述MQTT協(xié)議的模塊包括設備側(cè)客戶端、中介服務器和軟件側(cè)客戶端，所述設備監(jiān)控方法具體包括以下步驟：

步驟S1：設備側(cè)客戶端向中介服務器訂閱協(xié)議閉環(huán)下行消息與控制閉環(huán)下行消息，軟件側(cè)客戶端向中介服務器訂閱協(xié)議閉環(huán)上行消息與控制閉環(huán)上行消息；

步驟S2：軟件側(cè)客戶端向中介服務器發(fā)布所述協(xié)議閉環(huán)下行消息與控制閉環(huán)下行消息，所述中介服務器將協(xié)議閉環(huán)下行消息與控制閉環(huán)下行消息發(fā)送至設備側(cè)客戶端；

步驟S3：設備側(cè)客戶端對接收到的所述協(xié)議閉環(huán)下行消息與控制閉環(huán)下行消息進行處理，向中介服務器發(fā)布協(xié)議閉環(huán)上行消息和控制閉環(huán)上行消息，所述中介服務器將協(xié)議閉環(huán)上行消息和控制閉環(huán)上行消息發(fā)送至軟件側(cè)客戶端；

步驟S4：軟件側(cè)客戶端接收所述協(xié)議閉環(huán)上行消息與控制閉環(huán)上行消息，記錄發(fā)送協(xié)議閉環(huán)下行消息與接收協(xié)議閉環(huán)上行消息之間的協(xié)議閉環(huán)時間間隔，以及發(fā)送控制閉環(huán)下行消息與接收控制閉環(huán)上行消息之間的控制閉環(huán)時間間隔，若協(xié)議閉環(huán)時間間隔大于第一門限，或者控制閉環(huán)時間間隔大于第二門限，或者協(xié)議閉環(huán)時間間隔和控制閉環(huán)時間間隔的差值大于第三門限，則軟件側(cè)客戶端產(chǎn)生相應告警信息，并上報應用層軟件。