[發明專利]一種基于MQTT消息協議的集中器應用進程看護設計方法

在審

• 申請號: 202310177598.0
• 申請日: 2023-02-28
• 公開（公告）號: CN116126597A
• 公開（公告）日: 2023-05-16
• 發明（設計）人: 葛玉磊;孫彥鵬;沈海洋;李玉寧;趙璽
• 申請（專利權）人: 青島鼎信通訊股份有限公司;青島鼎信通訊科技有限公司
• 主分類號: G06F11/14
• 分類號: G06F11/14;G06F11/34
• 代理公司: 暫無信息
• 代理人: 暫無信息

本發明公開了一種一種基于MQTT消息協議的集中器應用進程看護設計方法，其技術方案包括以下步驟。步驟1：基于MQTT的消息框架，啟動一個MQTT?broker。看護程序app1與各集中器主要業務app作為客戶端連接至該broker；步驟2：由app1定時向主要的業務app發送消息，各業務app通過訂閱收到消息后進行確認信息的回復，根據回復信息對app運行狀態進行預測；步驟3：若業務app未及時響應確認信息，app1仍繼續按照周期進行消息發送，并自動開啟報文監控，將交互報文儲存在儲存單元；步驟4：連續超過給定周期后，則認為該app出現異常，需要嘗試重啟該app，主動發起對該app的復位動作。步驟5：重啟后的app與MQTT?broker建立新的連接；本發明實現了集中器對于異常app的主動復位，節省了人工現場復位所產生的時間人力成本。

技術領域

本發明涉及集中器進程看護技術領域，尤其涉及一種基于MQTT消息協議的集中器應用進程看護設計方法。

背景技術

現行終端長期在現場運行，存在程序邏輯異常導致的軟件崩潰現象，而傳統的設備缺乏牢靠的看護機制，程序異常退出時無法及時感知并嘗試重新拉起，進一步造成個別臺區的采集成功率下降甚至為0的情況。且由于業務app退出后，設備已從采集主站離線，無法響應主站的復位等操作，必須由人工前往現場進行設備的恢復動作，時間及人力成本大大提高。

當前電網公司無法及時發現集中程序異常問題，在發現問題后派遣人工前往無法確定問題發生時的時間及狀況，不僅缺少時效性，更無法為后續的問題研究提供現場資料，導致后續問題處理困難，可能存在再次出現的風險，造成一定的經濟損失。

發明內容

本發明針對現有技術存在的不足和缺陷，提供了一種基于MQTT消息協議的集中器應用進程看護設計方法，在設備中增加看護app，基于MQTT(Message?Queuing?TelemetryTransport,消息隊列遙測傳輸)消息架構通過安裝mosquitto應用，啟動一個mqtt?broker，app1和各業務app都作為客戶端連接至該broker，進行信息交互。實現了看護app高效穩定地對集中器內各業務app監管，利用markkov鏈模型對集中器當前進程狀態進行預測，能有效預防故障的發生，同時針對軟件崩潰現象能主動恢復，節省了現場處理的時間及人力成本。

本發明的目的可以通過以下技術方案來實現：

一種于MQTT消息協議的集中器應用進程看護設計方法，包括以下步驟：

步驟1：基于MQTT的消息框架，啟動一個MQTT?broker。看護程序app1與各集中器主要業務app作為客戶端連接至該broker，創建一個MQTT保活線程用來監測各app與MQTTbroker的連接情況；

步驟2：由看護程序app1定時向主要的業務app發送消息，各業務app通過訂閱收到消息后進行確認信息的回復，心跳消息中攜帶app的信息及系統時間；

步驟3：根據各業務app回復消息中攜帶的app信息構建Markov鏈模型，對業務app未來運行狀況進行預測，對于可能出現異常的狀況及時向主站發出告警信息；

步驟4：若業務app未在規定時間內向MQTT?broker發送回復包，此時看護程序app1仍繼續按照周期向MQTT?broker發布相應主題的消息信息并自動開啟報文監控，將交互的MQTT消息報文日志儲存在集中器的儲存單元；

步驟5：如果連續超過給定周期后該業務app仍未進行消息回復，則認為該app出現異常，需要嘗試重啟該app，由看護程序app1執行異常應用異常后的拉起操作；

步驟6：重啟后的app向服務端發起重連，則Broker會啟動客戶端接管機制：關閉舊的半連接，然后與該業務app建立新的連接；