摘 要:為了實現(xiàn)設備群報警信息的可配置和對指定用戶訪問權(quán)限的管理,在不修改原系統(tǒng)程序的基礎上提出了一種基于MQTT的可配置設備群遠程報警系統(tǒng)的設計與實現(xiàn)。組態(tài)王與10余臺真空處理設備的PLC及傳感器進行通信,實時采集運行數(shù)據(jù)和報警信息。采用Qt開發(fā)的數(shù)據(jù)傳輸軟件Data Bridge通過OPC DA協(xié)議獲取組態(tài)王中的設備數(shù)據(jù),并通過MQTT協(xié)議發(fā)布到云平臺服務器。當用戶登錄APP時,系統(tǒng)根據(jù)預先配置好的設備訪問權(quán)限自動訂閱授權(quán)設備的報警信息和關(guān)鍵數(shù)據(jù),解決了分布式設備管理環(huán)境下操作人員和維修人員往往由于設備分布較遠無法及時獲取和處理指定設備報警信息的問題。
關(guān)鍵詞:可配置設備群;Qt;MQTT;遠程報警系統(tǒng);OPC DA;云平臺
中圖分類號:TP277 文獻標識碼:A 文章編號:2095-1302(2025)01-0-05
0 引 言
隨著人力成本的不斷增加,不少企業(yè)要求操作人員同時操作和管理多臺設備。這些設備往往分布在廠區(qū)的不同位置,距離較遠,導致操作人員和維修人員無法及時了解設備信息,尤其是運行狀態(tài)和報警信息。越來越多的企業(yè)希望在不更改原有控制系統(tǒng)的基礎上對現(xiàn)有的設備群進行升級,使操作人員和維修人員能夠通過遠程的方式及時掌握所授權(quán)的多臺設備的狀態(tài)和報警信息。
針對遠程報警系統(tǒng)方面,國內(nèi)外學者和技術(shù)人員進行了深入的研究。文獻[1]應用GSM網(wǎng)絡模塊TC35i,實現(xiàn)了將煙霧報警傳感器的報警信息以短信的形式發(fā)送到指定手機中。文獻[2]設計了一個基于物聯(lián)網(wǎng)和云的遠程醫(yī)療系統(tǒng),將病人信息通過短信和電子郵件發(fā)送給醫(yī)生。文獻[3]設計了基于云平臺技術(shù)和Modbus RTU協(xié)議的電鍋爐設備,實現(xiàn)鍋爐的運行控制、狀態(tài)監(jiān)測以及故障報警,并將故障信息推送至微信和郵箱。文獻[4]對倍捻設備群進行了改造,基于以太網(wǎng)實現(xiàn)了設備群運行狀態(tài)網(wǎng)絡化在線監(jiān)測,重點監(jiān)測倍捻設備群斷紗和停機故障。文獻[5]研發(fā)了一套運架設備群遠程安全監(jiān)控系統(tǒng),采用VPN技術(shù)組網(wǎng),實現(xiàn)管理調(diào)度并在中心大屏幕上實時顯示各現(xiàn)場施工設備的各種安全數(shù)據(jù)。文獻[6]設計了一種基于云平臺的綜采設備群遠程故障診斷系統(tǒng),可以將報警信息推送到手機APP。
綜上所述,近年來隨著物聯(lián)網(wǎng)(IoT)技術(shù)的不斷發(fā)展,遠程報警狀態(tài)的獲取方式已經(jīng)從原來的GSM網(wǎng)絡短信形式轉(zhuǎn)向了物聯(lián)網(wǎng)和云平臺。同時,設備數(shù)據(jù)采集的方式也發(fā)生了變化,從單一設備的數(shù)據(jù)采集逐漸轉(zhuǎn)向了設備群的數(shù)據(jù)采集模式。然而,目前這些設備群的所有信息往往只集中定向到中控室、Web端或APP端,并未對設備和用戶群體進行區(qū)分,缺乏靈活性。對于集成了云平臺功能的可配置型設備群遠程報警系統(tǒng),即能夠?qū)⒉煌O備的報警信息配置給不同用戶的系統(tǒng),目前鮮見報道。
針對電工領(lǐng)域真空處理設備群,提出了一種基于Qt和MQTT的可配置設備群遠程報警系統(tǒng),在不更改原有系統(tǒng)程序的基礎上進行升級,采用Qt開發(fā)的數(shù)據(jù)傳輸軟件Data Bridge通過OPC DA協(xié)議獲取各設備組態(tài)王中的數(shù)據(jù),并通過消息隊列遙測傳輸(Message Queuing Telemetry Transport, MQTT)協(xié)議發(fā)布到云平臺服務器。用戶登錄APP時,系統(tǒng)根據(jù)預先配置好的設備訪問權(quán)限自動訂閱授權(quán)設備的報警信息和關(guān)鍵數(shù)據(jù),實現(xiàn)了設備群報警信息的可配置和對指定用戶訪問權(quán)限的管理。
1 系統(tǒng)的設計
1.1 系統(tǒng)架構(gòu)設計
系統(tǒng)架構(gòu)如圖1所示。本系統(tǒng)由設備層、通信層、服務層和應用層組成。設備層由10 kV線圈烘箱、10 kV器身干燥爐、35 kV器身干燥爐和注油設備等10余臺設備組成。設備層是整個系統(tǒng)的基礎,每臺設備都有各種傳感器、PLC和工控機,負責感知和采集關(guān)鍵數(shù)據(jù)及報警信息,并通過MQTT協(xié)議發(fā)送到服務器。通信層負責連接設備和云服務器,包括路由器和互聯(lián)網(wǎng)連接。服務層由云服務器構(gòu)成,主要負責接收、處理和存儲來自設備的數(shù)據(jù)。其中,MQTT Server負責消息的轉(zhuǎn)發(fā);Access Manager負責權(quán)限管理及數(shù)據(jù)訪問控制;MySQL負責保存設備數(shù)據(jù)和權(quán)限信息。應用層由多個客戶端APP組成,通過與服務層進行通信,實現(xiàn)對設備的遠程訪問、數(shù)據(jù)查詢和控制等功能。設備層用于數(shù)據(jù)傳輸?shù)腗QTT Bridge、服務層的Access Manager和應用層的APP三者之間的通信均采用MQTT協(xié)議,經(jīng)MQTT Server轉(zhuǎn)發(fā)實現(xiàn),通過發(fā)布和訂閱主題的方式進行交互。
設備層的數(shù)據(jù)采集結(jié)構(gòu)如圖2所示。原工控機上裝有組態(tài)王軟件,系統(tǒng)升級時并不修改原有組態(tài)程序,只增加了Qt編寫的Data Bridge模塊、OPC Bridge模塊和MQTT Bridge模塊。OPC Bridge模塊主要用于組態(tài)王的數(shù)據(jù)采集,通過OPC DA協(xié)議與組態(tài)王進行通信,獲取報警信息和關(guān)鍵數(shù)據(jù)。而MQTT Bridge模塊用于將這些采集到的數(shù)據(jù)通過MQTT協(xié)議發(fā)送到云端,再由服務器發(fā)送給訂閱信息的手機APP。
1.2 關(guān)鍵技術(shù)選擇
電工領(lǐng)域的真空處理裝備中,舊系統(tǒng)下位機多種多樣,包括不同品牌的PLC和RS 485遠程模塊。舊系統(tǒng)的數(shù)據(jù)接口通常不完善,原廠家可能已經(jīng)倒閉或報價過高,都會影響到設備升級。在不修改原系統(tǒng)程序的基礎上進行報警系統(tǒng)升級是問題的關(guān)鍵。該行業(yè)大部分系統(tǒng)使用組態(tài)王作為上位監(jiān)控軟件,鑒于組態(tài)王本身是OPC Server,可以通過OPC Client軟件快速找到系統(tǒng)報警變量,因此選擇OPC DA作為數(shù)據(jù)采集技術(shù),并通過OPC Bridge模塊實現(xiàn)設備數(shù)據(jù)的采集。
為了滿足設備群報警信息可配置給指定用戶的需求,經(jīng)過對比分析,選擇MQTT作為數(shù)據(jù)傳輸技術(shù)。相較于HTTP、WebSocket、CoAP等通信連接技術(shù),MQTT是需要安全通信環(huán)境并同時向多個訂閱者發(fā)送消息的物聯(lián)網(wǎng)應用程序的首選[7]。MQTT是一種輕量級通信協(xié)議,采用發(fā)布-訂閱模式,工作原理如圖3所示。消息發(fā)布者(Publisher)通過消息代理(Broker)將消息發(fā)布到特定主題(Topic),訂閱者(Subscriber)通過訂閱主題接收消息。它的推送機制效率高,功耗低,可以穩(wěn)定用于Android平臺上的應用[8]。同時,它具備高可靠性和穩(wěn)定性,通過消息持久化和QoS等級確保數(shù)據(jù)傳輸?shù)目煽啃?。重要的是,MQTT具有良好的可擴展性,支持訂閱和發(fā)布機制,方便管理多個客戶端和設備之間的通信。它為設備群報警信息的靈活配置和即時傳輸提供了優(yōu)秀的解決方案。
為了實現(xiàn)MQTT的功能,選擇Mosquitto作為消息轉(zhuǎn)發(fā)服務器軟件。Mosquitto是一個開源的MQTT代理服務器,它提供了非常理想的輕量級數(shù)據(jù)交換的解決方案[9]。MQTT Bridge模塊與Mosquitto進行集成,實現(xiàn)實時報警消息和關(guān)鍵數(shù)據(jù)的傳遞。
1.3 數(shù)據(jù)流設計
數(shù)據(jù)流轉(zhuǎn)圖如圖4所示。首先,APP登錄后獲取登錄用戶的設備權(quán)限;然后,根據(jù)擁有的設備權(quán)限向MQTT Server訂閱所需的設備數(shù)據(jù)信息;最后,MQTT Server將收到的設備信息轉(zhuǎn)發(fā)給擁有權(quán)限的APP。具體過程如下:APP1將登錄的用戶名和輸入的密碼(A)以發(fā)布方式發(fā)給MQTT Server,MQTT Server轉(zhuǎn)發(fā)(A')給已訂閱用戶信息的Access Manager。然后,Access Manager讀取MySQL數(shù)據(jù)庫進行密碼比對,將驗證信息和設備訪問權(quán)限(B,可訪問設備2和設備3)經(jīng)MQTT Server轉(zhuǎn)發(fā)(B')給APP1。APP1獲得權(quán)限列表后,發(fā)布信息(C和D)分別訂閱設備2和設備3的運行數(shù)據(jù)和報警信息。設備2的數(shù)據(jù)(F)和設備3的數(shù)據(jù)(G)定時發(fā)布到MQTT Server,并由服務器轉(zhuǎn)發(fā)(F'和G')給APP1。由于APP1沒有設備1的訪問權(quán)限,所以APP1無法接收到設備1發(fā)送的消息(E)。這樣便實現(xiàn)了指定設備報警信息配置給特定用戶的功能,可滿足不同用戶對報警系統(tǒng)的個性化需求。
2 系統(tǒng)的實現(xiàn)
2.1 數(shù)據(jù)采集模塊的實現(xiàn)
開發(fā)OPC DA客戶端有兩種常用方式:基于COM技術(shù)和利用第三方動態(tài)鏈接庫或工具包[10]。前者需要掌握DCOM技術(shù)和復雜的COM設置,可以通過調(diào)用OPC基金會提供的API[11]或使用MFC的COM庫函數(shù)[12]進行開發(fā)。后者則具有開發(fā)難度低、效率高的優(yōu)勢,但往往需要付費使用第三方OPC動態(tài)鏈接庫[13],如Matrikon和Kepware所提供的開發(fā)工具包。組態(tài)王提供了免費的Kingvewcliend.dll動態(tài)鏈接庫,用于與組態(tài)王OPC服務器進行連接和交互[14]。為此,本文采用Qt框架基于DLL實現(xiàn)了實時報警信息和關(guān)鍵數(shù)據(jù)的獲取,主要包括以下步驟:
(1)定義函數(shù)指針,顯式加載動態(tài)鏈接庫
定義函數(shù)指針startCliend、addTag、readTag、writeTag和stopCliend,分別指向DLL的相應函數(shù),實現(xiàn)連接組態(tài)王OPC服務器、添加變量、讀取變量、寫入變量和斷開組態(tài)王OPC服務器連接等功能。通過QLibrary myLib (\"kingvewcliend.dll\")加載DLL。
(2)連接OPC服務器
通過startCliend(\"127.0.0.1\")指令連接組態(tài)王OPC服務器。
(3)添加采集變量
首先,使用亞控公司提供的OPC客戶端軟件OPC Client.exe查找原系統(tǒng)中的變量名稱。然后,通過循環(huán)方式使用addTag(qstr2bstr(tagNames[i]), nTagIDs[i], nTagTypes[i])函數(shù)添加到采集列表,tagNames、nTagIDs和nTagTypes分別存放要采集的變量名稱、id和類型。需要注意的是,第一個參數(shù)需要將變量名稱從QString轉(zhuǎn)換為BSTR類型。
(4)定時采集數(shù)據(jù)并發(fā)送到MQTT Bridge
通過readTag(nTagIDs[i], bVal, lVal, fVal, sVal)函數(shù)實現(xiàn)數(shù)據(jù)讀取,并存放到相應的變量 bVal/lVal/fVal/sVal 中,具體存放到哪個寄存器取決于 nTagTypes[i] 的值。數(shù)據(jù)采集完成后,將采集的變量和數(shù)值放入 tagAndValueMap鍵值對變量中,并通過信號發(fā)送給MQTT Bridge:emit sendDataToMqtt(tagAndValueMap)。
(5)通過槽的方式接收和處理MQTT Bridge發(fā)來的控制指令
使用writeValue(QString tagName, QString sv)函數(shù)將指令寫入組態(tài)王,執(zhí)行設備的啟動或停止動作,實現(xiàn)設備的遠程控制。
2.2 數(shù)據(jù)上傳和下載模塊的實現(xiàn)
通過Data Bridge模塊中的MQTT Bridge模塊與MQTT Server交互,實現(xiàn)采集數(shù)據(jù)的發(fā)布和定閱。Qt官方封裝的MQTT庫(5.13.2)非常方便,具體實現(xiàn)步驟如下:
(1)在Qt官網(wǎng)下載MQTT庫源碼,進行編譯,并將Qt MQTT庫部署到項目中。
(2)創(chuàng)建MQTT客戶端。代碼如下:
QMqttClient *m_client = new QMqttClient();
(3)連接MQTT服務器。設置主機名、訪問密碼、端口和客戶端id,通過m_client-gt;connectToHost()連接服務器。
(4)將OPC Bridge發(fā)來的數(shù)據(jù)發(fā)布到MQTT服務器。OPC Bridge模塊將組態(tài)王中采集的數(shù)據(jù)(tagAndValueMap)通過信號方式發(fā)送給MQTT Bridge模塊。MQTT Bridge模塊接收到這個鍵值對變量后,需要將其轉(zhuǎn)換為JSON格式,加密后再通過MQTT協(xié)議發(fā)布到MQTT Server[15]。代碼如下:
QString msg=mapToJson(map);
bool isRetain=true;
int QoS=1;
QString topic=\"Values\";
m_client-gt;publish(topic, msg.toUtf8(), QoS,isRetain);
(5)接收并處理MQTT服務器信息。使用“m_client-gt;subscribe(static_castlt;QStringgt;(\"Control Command\"), 1)”訂閱控制命令主題,其中第一個參數(shù)為訂閱的主題,第二個參數(shù)為QoS(Quality of Service)。QoS=0表示最多發(fā)送一次,QoS=1表示最少發(fā)送一次,QoS=2表示只發(fā)送一次。通過修改指令中的主題名即可訂閱其他主題。若接收到“ControlCommand”主題,則將信號發(fā)送給OPC Bridge模塊進行處理。關(guān)鍵代碼如下:
connect(m_client, amp;QMqttClient::messageReceived, this, [this,myClientID](const QByteArray amp;message, const QMqttTopicName amp;topic) {if(topic.name() == \"ControlCommand\"){emit sendDataToOpc (message);}});
2.3 云服務器的搭建
本系統(tǒng)將Mosquitto、MySQL和Access Manager統(tǒng)一部署到阿里云ECS云服務器上,這樣可以簡化部署和管理工作,提高性能和可靠性,并降低成本,為系統(tǒng)提供高效穩(wěn)定的服務。
Mosquitto是一個MQTT代理服務器,負責接收和轉(zhuǎn)發(fā)MQTT消息給訂閱者。Access Manager軟件既作為MQTT客戶端與Mosquitto進行通信,又作為權(quán)限管理和數(shù)據(jù)管理者通過開源的關(guān)系型數(shù)據(jù)庫MySQL實現(xiàn)數(shù)據(jù)的CRUD操作。
確保Mosquitto和Access Manager之間正常通信的關(guān)鍵是配置正確的主機和端口信息,并確保云服務器的網(wǎng)絡設置允許MQTT流量通過。這包括入站和出站規(guī)則、網(wǎng)絡安全組以及防火墻等設置。如果使用了防火墻或網(wǎng)絡安全組,需要打開相關(guān)的MQTT端口。這樣,系統(tǒng)才能順利地進行MQTT消息傳遞和數(shù)據(jù)管理操作。
2.4 權(quán)限管理和數(shù)據(jù)存儲模塊的實現(xiàn)
權(quán)限管理和數(shù)據(jù)存儲模塊Access Manager采用Qt開發(fā),使用MQTT協(xié)議與MQTT Server進行交互,通過發(fā)布和訂閱主題實現(xiàn)。該模塊主要完成3大功能:用戶驗證和返回設備權(quán)限列表、將設備信息保存到MySQL數(shù)據(jù)庫、根據(jù)APP指令查詢數(shù)據(jù)庫中指定時間范圍的報警信息或歷史數(shù)據(jù)。這3個功能都需要使用MQTT協(xié)議與MQTT Server進行交互,并設置好Topic和Payload(消息內(nèi)容)的內(nèi)容。在Qt中,可以使用QJsonDocument和QJsonObject來處理JSON字符串中的鍵值對。當Payload中包含多個數(shù)據(jù)鍵值對時,可以使用迭代器來遍歷JSON字符串并獲取相關(guān)數(shù)據(jù)。主要的Topic信息見表1。
2.5 Android APP的實現(xiàn)
2.5.1 頁面布局
手機客戶端采用Android Studio原生開發(fā),包括登錄頁面、主控頁面和設備分控頁面。登錄頁面用于驗證用戶身份,普通用戶可修改密碼、注銷和進入主控界面,系統(tǒng)管理員還能進行用戶管理,如創(chuàng)建用戶、重置密碼和設備權(quán)限設置。主控頁面如圖5所示,展示了實時報警信息,包含設備名稱、報警器件、報警描述、類型、代號、報警時間及幫助信息。同時,提供已授權(quán)設備群的訪問按鈕,點擊后即可跳轉(zhuǎn)至相應設備的分控頁面。設備分控頁面如圖6所示,在該頁面可以選擇顯示真空系統(tǒng)、加熱系統(tǒng)、輔助系統(tǒng)、產(chǎn)品信息、關(guān)鍵參數(shù)和報警信息等實時狀態(tài)和信息,并提供報警確認、遠程暫停和啟動功能。此外,設備分控頁面還設有報警日報表、月報表和年報表的訪問按鈕。
2.5.2 APP獲取設備數(shù)據(jù)的實現(xiàn)
APP獲取設備數(shù)據(jù)流程如圖7所示,用戶在APP登錄頁面輸入用戶名和密碼,經(jīng)加密后向MQTT服務器發(fā)布登錄請求主題。MQTT服務器將請求信息傳遞給訂閱了該主題的Access Manager模塊。Access Manager在MySQL數(shù)據(jù)庫中驗證用戶名和密碼,驗證通過后,查詢用戶的設備訪問權(quán)限,加密后發(fā)布到MQTT服務器。該主題的信息以JSON格式[16]表示,包括AppID、用戶名、管理員權(quán)限、可訪問設備數(shù)量以及可訪問設備列表。例如:{\"AppID\":\"App3\",\"UserName\":\"劉明宇\",\"isAdmin\":\"0\",\"DeviceCount\":\"2\",\"Device1\":\"35 kV器身干燥爐\",\"Device2:\"35 kV真空脫氣罐\"}。APP訂閱該消息并解密后,讀取設備列表中的設備名稱,并逐個訂閱設備的數(shù)據(jù)信息。當接收到訂閱設備的信息后,將報警信息顯示在報警信息匯總表中。
2.5.3 可配置設備群的實現(xiàn)
系統(tǒng)管理員可以在登錄頁面點擊“用戶配置”按鈕,對用戶和可訪問設備進行配置,配置頁面如圖8所示;可在“人員”頁面配置人員的信息,如姓名、類別、電話等。也可在“設備”頁面完成允許訪問人員的配置。管理員首先選擇設備名稱,然后選擇人員,點擊“添加”按鈕,該人員自動添加到允許訪問人員列表中。為了保證數(shù)據(jù)的安全性,APP會對用戶權(quán)限信息進行加密,并以JSON格式發(fā)布到MQTT Server。MQTT Server會將加密后的信息轉(zhuǎn)發(fā)給Access Manager。Access Manager在接收到數(shù)據(jù)后將其解密,并將權(quán)限信息寫入MySQL數(shù)據(jù)庫中。當該用戶登錄后,系統(tǒng)會自動將允許訪問的設備信息發(fā)送到該APP,用戶可以通過APP查看自己被授權(quán)訪問的設備信息。
3 結(jié) 語
基于MQTT的可配置設備群遠程報警系統(tǒng),在不修改原控制系統(tǒng)程序的基礎上實現(xiàn)了設備群報警信息的采集、配置、上傳以及特定用戶訪問指定設備的功能。系統(tǒng)的可配置性和靈活性使得設備報警信息能夠針對不同用戶進行個性化配置,滿足了不同用戶的需求。系統(tǒng)應用效果良好,操作人員和維修人員能夠及時了解設備的運行狀態(tài)和報警信息,提高了設備的管理效率和故障處理速度。
參考文獻
[1]江杰,宋宏龍.基于GSM短信的煙霧傳感報警系統(tǒng)[J].測控技術(shù),2014,33(1):1-3.
[2]AMIN M T, PEU J S. IoT cloud-based remote patient health monitoring and alarm system [J]. International journal of scientific and engineering research, 2021, 12(4): 221-228.
[3]許景波,秦聰,趙博亮,等.基于云平臺的蓄熱式電鍋爐遠程測控系統(tǒng)設計[J].自動化儀表,2023,44(3):60-63.
[4]蔡志端,王培良,顧玉祥,等.網(wǎng)絡化倍捻設備群運行狀態(tài)在線監(jiān)測[J].毛紡科技,2012,40(6):61-64.
[5]袁明.運架設備群遠程安全監(jiān)控系統(tǒng)的研發(fā)與應用[J].鐵道工程學報,2015,32(5):54-58.
[6]李旭,吳雪菲,田野,等.基于云平臺的綜采設備群遠程故障診斷系統(tǒng)[J].工礦自動化,2021,47(7):57-62.
[7] BAYILMIS C, EBLEME M, CAVUSOGLU U, et al. A survey on communication protocols and performance evaluations for Internet of Things[J]. Digital communications and networks, 2022, 8(6): 1094-1104.
[8]許金喜,張新有. Android平臺基于MQTT協(xié)議的推送機制[J].計算機系統(tǒng)應用,2015,24(1):185-190.
[9] LEE S, KIM H, HONG D K, et al. Correlation analysis of MQTT loss and delay according to QoS level [C]// 2013 International Conference on Information Networking (ICOIN). [S.l.]: IEEE Computer Society, 2013.
[10]鄒云濤,吳重光. OPC DA客戶端的三種實現(xiàn)方式[J].自動化博覽,2004,21(1):51-53.
[11]蘇磊,李茜,湯偉. OPC數(shù)據(jù)訪問客戶端的研究與實現(xiàn)[J].計算機工程,2010,36(11):80-82.
[12]魏森聲,田慕琴. VC6.0編程客戶端訪問組態(tài)王OPC服務器的方法[J].工礦自動化,2012,38(8):127-130.
[13]黎邦騰,梁薇,馬平.基于Qt平臺的OPC服務器的開發(fā)及仿真應用[J].計算機測量與控制,2017,25(11):154-158.
[14]尹靜濤,劉利平. OPC技術(shù)在高爐生產(chǎn)測控系統(tǒng)中的應用[J].制造業(yè)自動化,2012,34(1):139-140.
[15]郭翠娟,暴寧,榮鋒.基于MQTT的物聯(lián)網(wǎng)平臺研究與設計[J].計算機工程與設計,2022,43(8):2378-2384.
[16]黃良沛,張逸夫,譚姚,等.輸送機工況數(shù)據(jù)APP遠程監(jiān)控系統(tǒng)設計[J].金屬礦山,2022(4):169-172.