徐志祥,牛小剛,李春秋,曹冰冰
(大連理工大學(xué) 機(jī)械工程學(xué)院,遼寧 大連 116024)
大型電機(jī)是船舶、能源、軍工等行業(yè)重要裝備的關(guān)鍵動(dòng)力裝置。大型電機(jī)在運(yùn)行過(guò)程中突然發(fā)生故障,將帶來(lái)不可估量的損失,確保其安全、穩(wěn)定、高效運(yùn)行事關(guān)重大。如何對(duì)大型電機(jī)進(jìn)行遠(yuǎn)程監(jiān)測(cè)受到廣泛關(guān)注。隨著物聯(lián)網(wǎng)技術(shù)的快速發(fā)展和智能手機(jī)的廣泛應(yīng)用,使得通過(guò)移動(dòng)端實(shí)現(xiàn)大型電機(jī)的遠(yuǎn)程監(jiān)測(cè)變?yōu)榭赡堋?/p>
鑒于此,本文以物聯(lián)網(wǎng)三層架構(gòu)為基礎(chǔ)研究基于Android平臺(tái)的大型電機(jī)遠(yuǎn)程監(jiān)測(cè)技術(shù),將電機(jī)的運(yùn)行狀態(tài)通過(guò)物聯(lián)網(wǎng)呈現(xiàn)在智能手機(jī)上,幫助用戶隨時(shí)隨地掌握電機(jī)的運(yùn)行狀態(tài),實(shí)現(xiàn)對(duì)大型電機(jī)的遠(yuǎn)程監(jiān)測(cè),并為大型電機(jī)的故障診斷打下基礎(chǔ)。
基于物聯(lián)網(wǎng)的大型電機(jī)遠(yuǎn)程監(jiān)測(cè)系統(tǒng)由感知層、網(wǎng)絡(luò)層和應(yīng)用層組成,系統(tǒng)框架如圖1所示。其中,感知層負(fù)責(zé)數(shù)據(jù)的采集,網(wǎng)絡(luò)層負(fù)責(zé)數(shù)據(jù)的計(jì)算和數(shù)據(jù)存儲(chǔ),應(yīng)用層負(fù)責(zé)數(shù)據(jù)的顯示和人機(jī)交互。不同的用戶通過(guò)應(yīng)用層對(duì)不同的大型電機(jī)進(jìn)行遠(yuǎn)程監(jiān)測(cè),以及時(shí)發(fā)現(xiàn)并消除大型電機(jī)的故障,避免造成嚴(yán)重的后果。
圖1 基于物聯(lián)網(wǎng)的大型電機(jī)遠(yuǎn)程監(jiān)測(cè)系統(tǒng)框圖
移動(dòng)端為了能夠反映大型電機(jī)的實(shí)時(shí)運(yùn)行狀態(tài)和歷史運(yùn)行狀態(tài),需要實(shí)現(xiàn)實(shí)時(shí)參數(shù)監(jiān)測(cè)功能和參數(shù)監(jiān)測(cè)歷史查詢功能;為了能夠及時(shí)通知用戶處理大型電機(jī)的故障,需要實(shí)現(xiàn)故障報(bào)警功能;為了能夠反映大型電機(jī)的故障歷史,需要實(shí)現(xiàn)故障報(bào)警歷史查詢功能。
移動(dòng)端根據(jù)登錄用戶的不同加載不同的電機(jī)數(shù)據(jù)。
移動(dòng)端根據(jù)用戶選擇的電機(jī)和參數(shù),以折線圖的方式顯示某個(gè)電機(jī)的實(shí)時(shí)數(shù)據(jù)。
移動(dòng)端根據(jù)用戶選擇的電機(jī)、參數(shù)和時(shí)間,以折線圖的方式顯示某個(gè)電機(jī)參數(shù)的歷史數(shù)據(jù),并根據(jù)用戶的操作對(duì)折線圖進(jìn)行縮放和平移。
當(dāng)某個(gè)電機(jī)運(yùn)行狀態(tài)異常時(shí),移動(dòng)端將產(chǎn)生故障的電機(jī)、產(chǎn)生故障的時(shí)間、產(chǎn)生故障的參數(shù)等以通知的方式告知用戶,以及時(shí)處理故障,避免造成更嚴(yán)重的后果。
移動(dòng)端根據(jù)用戶的操作判斷是否允許接收故障報(bào)警以及在允許接收故障報(bào)警時(shí)是否開(kāi)啟聲音和振動(dòng)。
移動(dòng)端根據(jù)用戶選擇的電機(jī),以二級(jí)列表的方式顯示某個(gè)電機(jī)的故障報(bào)警歷史。
移動(dòng)端根據(jù)用戶的操作判斷是否清除緩存的故障報(bào)警歷史。
目前,移動(dòng)端架構(gòu)模式主要有MVC(Model-View-Controller)、MVP(Model-View-Presenter)、MVVM(Model-View-View Model)三種。與其他兩種架構(gòu)模式相比,MVP架構(gòu)模式不僅實(shí)現(xiàn)了Model層與View層的分離,而且具有較高的代碼復(fù)用性。因此,移動(dòng)端采用MVP架構(gòu)模式,其中,Model層負(fù)責(zé)移動(dòng)端的數(shù)據(jù)處理,View層負(fù)責(zé)移動(dòng)端的數(shù)據(jù)顯示,Presenter層負(fù)責(zé)Model層與View層的數(shù)據(jù)通信。MVP架構(gòu)模式框架如圖2所示。
圖2 MVP架構(gòu)模式
目前,移動(dòng)端的數(shù)據(jù)存儲(chǔ)方式主要有文件存儲(chǔ)、SharedPreferences文件存儲(chǔ)以及SQLite數(shù)據(jù)庫(kù)存儲(chǔ)。其中,文件存儲(chǔ)適合存儲(chǔ)無(wú)格式的數(shù)據(jù),SharedPreferences文件存儲(chǔ)適合存儲(chǔ)格式簡(jiǎn)單、批量較小的數(shù)據(jù),SQLite數(shù)據(jù)庫(kù)存儲(chǔ)適合存儲(chǔ)格式復(fù)雜、批量較大的數(shù)據(jù)。
移動(dòng)端需要存儲(chǔ)用戶信息和電機(jī)信息。由于用戶信息格式簡(jiǎn)單、批量較小,所以采用SharedPreferences文件存儲(chǔ),用戶信息的存儲(chǔ)格式見(jiàn)表1所列;由于電機(jī)信息格式復(fù)雜、批量較大,所以采用SQLite數(shù)據(jù)庫(kù)存儲(chǔ),電機(jī)信息的存儲(chǔ)格式見(jiàn)表2所列。
表1 用戶信息的存儲(chǔ)格式
表2 電機(jī)信息的存儲(chǔ)格式
對(duì)于故障報(bào)警設(shè)置功能,移動(dòng)端需要存儲(chǔ)用戶設(shè)置。與用戶信息相比,用戶設(shè)置具有相同的特點(diǎn),所以采用SharedPreferences文件存儲(chǔ),用戶設(shè)置的存儲(chǔ)格式見(jiàn)表3所列。
表3 用戶設(shè)置的存儲(chǔ)格式
對(duì)于故障報(bào)警歷史查詢功能,移動(dòng)端需要存儲(chǔ)故障報(bào)警歷史信息。與電機(jī)信息相比,故障報(bào)警歷史數(shù)據(jù)與其具有相同的特點(diǎn),所以采用SQLite數(shù)據(jù)庫(kù)存儲(chǔ),故障報(bào)警歷史信息的存儲(chǔ)格式見(jiàn)表4所列。
表4 故障報(bào)警歷史信息的存儲(chǔ)格式
移動(dòng)端主要通過(guò)Activity組件、Fragment控件及Service組件實(shí)現(xiàn)相關(guān)功能。以下主要介紹登錄功能、實(shí)時(shí)參數(shù)監(jiān)測(cè)功能、參數(shù)監(jiān)測(cè)歷史查詢功能、故障報(bào)警功能與故障報(bào)警歷史查詢功能的數(shù)據(jù)處理。
移動(dòng)端登錄功能的數(shù)據(jù)處理流程如圖3所示。在用戶登錄時(shí),應(yīng)用程序會(huì)判斷SharedPreferences文件中是否存在用戶的賬號(hào)和密碼。如果存在用戶的賬號(hào)和密碼,則從SQLite數(shù)據(jù)庫(kù)中的電機(jī)信息表加載電機(jī)數(shù)據(jù);如果不存在用戶的賬號(hào)和密碼,則顯示登錄頁(yè)面。用戶通過(guò)登錄的方式使移動(dòng)端從服務(wù)端獲取電機(jī)數(shù)據(jù)。如果登錄成功,應(yīng)用程序會(huì)首先將用戶的賬號(hào)和密碼寫(xiě)入SharedPreferences文件,并將電機(jī)數(shù)據(jù)寫(xiě)入SQLite數(shù)據(jù)庫(kù)中的電機(jī)信息表,然后從SQLite數(shù)據(jù)庫(kù)中的電機(jī)信息表加載電機(jī)數(shù)據(jù)并顯示主頁(yè)面;登錄失敗時(shí),顯示登錄頁(yè)面并通過(guò)Toast通知用戶登錄失敗。
圖3 登錄功能的數(shù)據(jù)處理流程
控制器將采集的參數(shù)實(shí)時(shí)數(shù)據(jù)通過(guò)網(wǎng)絡(luò)發(fā)送給服務(wù)端,服務(wù)端將其解析后寫(xiě)入數(shù)據(jù)庫(kù)并在移動(dòng)端請(qǐng)求,從數(shù)據(jù)庫(kù)讀出發(fā)送給移動(dòng)端,移動(dòng)端將其解析后以折線圖的方式向用戶展示。
移動(dòng)端實(shí)時(shí)參數(shù)監(jiān)測(cè)功能的數(shù)據(jù)處理流程如圖4所示。應(yīng)用程序根據(jù)用戶選擇的電機(jī)和參數(shù),以1 s為時(shí)間間隔,不斷向服務(wù)端發(fā)送獲取該電機(jī)參數(shù)實(shí)時(shí)數(shù)據(jù)的請(qǐng)求。如果從服務(wù)端獲取數(shù)據(jù)成功,以折線圖的方式向用戶展示;如果從服務(wù)端獲取數(shù)據(jù)失敗,應(yīng)用程序會(huì)根據(jù)用戶的操作判斷是否重新向服務(wù)端發(fā)送獲取該電機(jī)該參數(shù)實(shí)時(shí)數(shù)據(jù)的請(qǐng)求。如果不重新向服務(wù)端發(fā)送獲取該電機(jī)參數(shù)實(shí)時(shí)數(shù)據(jù)的請(qǐng)求,顯示操作失敗頁(yè)面。
圖4 實(shí)時(shí)參數(shù)監(jiān)測(cè)功能的數(shù)據(jù)處理流程
除實(shí)時(shí)參數(shù)監(jiān)測(cè)功能外,移動(dòng)端允許用戶查詢?nèi)我怆姍C(jī)任意時(shí)刻的歷史數(shù)據(jù)。移動(dòng)端參數(shù)監(jiān)測(cè)歷史查詢功能的數(shù)據(jù)處理流程如圖5所示。應(yīng)用程序根據(jù)用戶選擇的電機(jī)、參數(shù)和時(shí)間,向服務(wù)端發(fā)送獲取該電機(jī)該參數(shù)該時(shí)刻歷史數(shù)據(jù)的請(qǐng)求。如果從服務(wù)端獲取數(shù)據(jù)成功,則以折線圖的方式向用戶展示,并允許用戶根據(jù)需要對(duì)折線圖進(jìn)行縮放和平移;如果從服務(wù)端獲取數(shù)據(jù)失敗,則應(yīng)用程序會(huì)根據(jù)用戶的操作判斷是否重新向服務(wù)端發(fā)送獲取該電機(jī)該參數(shù)該時(shí)刻歷史數(shù)據(jù)的請(qǐng)求。如果不重新向服務(wù)端發(fā)送獲取該電機(jī)該參數(shù)該時(shí)刻歷史數(shù)據(jù)的請(qǐng)求,顯示操作失敗頁(yè)面。
圖5 參數(shù)監(jiān)測(cè)歷史查詢功能的數(shù)據(jù)處理流程
控制器采集參數(shù)數(shù)據(jù)時(shí)會(huì)根據(jù)設(shè)置的參數(shù)數(shù)據(jù)閾值判斷電機(jī)的運(yùn)行狀態(tài),一旦發(fā)現(xiàn)電機(jī)運(yùn)行狀態(tài)異常,就立即向服務(wù)端發(fā)送故障報(bào)警信息;服務(wù)端接收到故障報(bào)警信息后會(huì)立即將其發(fā)送給移動(dòng)端;移動(dòng)端通知用戶及時(shí)處理故障,以避免造成更嚴(yán)重的后果。由于Android系統(tǒng)的限制,移動(dòng)端接收服務(wù)端發(fā)送的故障報(bào)警信息情況分為在應(yīng)用程序運(yùn)行時(shí)接收和在應(yīng)用程序未運(yùn)行時(shí)接收兩種情況。
在應(yīng)用程序運(yùn)行時(shí),移動(dòng)端通過(guò)消息中間件的方式接收故障報(bào)警信息。目前主流的消息中間件有RabbitMQ、ActiveMQ和Kafka等,其中RabbitMQ因具有擴(kuò)展性高、可靠性好等優(yōu)點(diǎn)被廣泛應(yīng)用于實(shí)際項(xiàng)目中。RabbitMQ的工作原理如圖6所示,消息生產(chǎn)者將消息通過(guò)交換器傳遞到與交換器綁定的消息隊(duì)列中存儲(chǔ),消息消費(fèi)者與服務(wù)端建立連接后從消息隊(duì)列中取出消息進(jìn)行處理。
圖6 RabbitMQ的工作原理
移動(dòng)端故障報(bào)警功能的數(shù)據(jù)處理流程如圖7所示,應(yīng)用程序啟動(dòng)時(shí),啟動(dòng)故障報(bào)警服務(wù)。故障報(bào)警服務(wù)會(huì)創(chuàng)建消費(fèi)者并與服務(wù)端連接,一旦監(jiān)聽(tīng)的消息隊(duì)列不為空,應(yīng)用程序根據(jù)Shared Preferences文件中的通知效果發(fā)送通知,通知用戶發(fā)生故障的時(shí)間、發(fā)生故障的電機(jī)、發(fā)生故障的參數(shù)、發(fā)生故障的參數(shù)的值。
圖7 故障報(bào)警功能的數(shù)據(jù)處理流程
因?yàn)锳ndroid系統(tǒng)在運(yùn)行內(nèi)存不夠時(shí)會(huì)殺死故障報(bào)警服務(wù),所以為了保證應(yīng)用程序在運(yùn)行時(shí)能夠接收故障報(bào)警信息,應(yīng)用程序啟動(dòng)時(shí),會(huì)注冊(cè)廣播接收器。一旦故障報(bào)警服務(wù)終止,就發(fā)送廣播;廣播接收器接收到廣播后會(huì)重新啟動(dòng)故障報(bào)警服務(wù)。在應(yīng)用程序未運(yùn)行時(shí),移動(dòng)端通過(guò)短信或郵件的方式接收故障報(bào)警信息。
由于故障報(bào)警歷史數(shù)據(jù)規(guī)模較小,移動(dòng)端采用在SQLite數(shù)據(jù)庫(kù)的故障報(bào)警歷史信息表緩存故障報(bào)警歷史數(shù)據(jù)的方式,以提高應(yīng)用的響應(yīng)速度。
移動(dòng)端故障報(bào)警歷史查詢功能的數(shù)據(jù)處理流程如圖8所示,應(yīng)用程序根據(jù)用戶選擇的電機(jī),向服務(wù)端發(fā)送獲取該電機(jī)未獲取過(guò)的故障報(bào)警歷史數(shù)據(jù)的請(qǐng)求。如果從服務(wù)端獲取數(shù)據(jù)成功,應(yīng)用程序會(huì)首先將該電機(jī)未獲取過(guò)的故障報(bào)警歷史數(shù)據(jù)寫(xiě)入SQLite數(shù)據(jù)庫(kù)中的故障報(bào)警歷史信息表,然后從SQLite數(shù)據(jù)庫(kù)中的故障報(bào)警歷史信息表加載該電機(jī)的故障報(bào)警歷史數(shù)據(jù),并以二級(jí)列表的方式向用戶展示;如果從服務(wù)端獲取數(shù)據(jù)失敗,應(yīng)用程序會(huì)直接從SQLite數(shù)據(jù)庫(kù)中的故障報(bào)警歷史信息表加載該電機(jī)的故障報(bào)警歷史數(shù)據(jù),并以二級(jí)列表的方式向用戶展示并通過(guò)Toast通知用戶操作失敗。
圖8 故障報(bào)警歷史查詢功能的數(shù)據(jù)處理流程
為測(cè)試移動(dòng)端能否正常運(yùn)行,我們?cè)诨贏ndroid10的HuaWei nova5Pro設(shè)備上進(jìn)行測(cè)試。
實(shí)時(shí)參數(shù)監(jiān)測(cè)功能的測(cè)試結(jié)果如圖9所示,移動(dòng)端能夠正常顯示用戶選擇的電機(jī)和參數(shù)的實(shí)時(shí)數(shù)據(jù)。
圖9 實(shí)時(shí)參數(shù)監(jiān)測(cè)功能
參數(shù)監(jiān)測(cè)歷史查詢功能的測(cè)試結(jié)果如圖10所示,移動(dòng)端能夠正常顯示用戶選擇的電機(jī)、參數(shù)和時(shí)間的歷史數(shù)據(jù)。
圖10 參數(shù)監(jiān)測(cè)歷史查詢功能
故障報(bào)警功能的測(cè)試結(jié)果如圖11所示,移動(dòng)端能夠正常顯示產(chǎn)生故障的電機(jī)、產(chǎn)生故障的時(shí)間、產(chǎn)生故障的參數(shù)以及產(chǎn)生故障的參數(shù)的值。
圖11 故障報(bào)警功能
故障報(bào)警歷史查詢功能的測(cè)試結(jié)果如圖12所示,移動(dòng)端能夠正常顯示用戶選擇的電機(jī)的故障報(bào)警歷史數(shù)據(jù)。
圖12 故障報(bào)警歷史查詢功能
本文基于Android平臺(tái)設(shè)計(jì)的大型電機(jī)遠(yuǎn)程監(jiān)測(cè)系統(tǒng)的移動(dòng)端,實(shí)現(xiàn)了實(shí)時(shí)參數(shù)監(jiān)測(cè)功能、參數(shù)監(jiān)測(cè)歷史查詢功能、故障報(bào)警功能以及故障報(bào)警歷史查詢功能等,具有不受時(shí)空限制的優(yōu)點(diǎn),能夠幫助用戶及時(shí)發(fā)現(xiàn)并消除大型電機(jī)的故障,避免造成嚴(yán)重的后果。