基于物聯(lián)網(wǎng)的大型電機遠程監(jiān)測系統(tǒng)的移動端設計

徐志祥，牛小剛，李春秋，曹冰冰

（大連理工大學 機械工程學院，遼寧 大連 116024）

0 引 言

大型電機是船舶、能源、軍工等行業(yè)重要裝備的關鍵動力裝置。大型電機在運行過程中突然發(fā)生故障，將帶來不可估量的損失，確保其安全、穩(wěn)定、高效運行事關重大。如何對大型電機進行遠程監(jiān)測受到廣泛關注。隨著物聯(lián)網(wǎng)技術的快速發(fā)展和智能手機的廣泛應用，使得通過移動端實現(xiàn)大型電機的遠程監(jiān)測變?yōu)榭赡堋?/p>

鑒于此，本文以物聯(lián)網(wǎng)三層架構為基礎研究基于Android平臺的大型電機遠程監(jiān)測技術，將電機的運行狀態(tài)通過物聯(lián)網(wǎng)呈現(xiàn)在智能手機上，幫助用戶隨時隨地掌握電機的運行狀態(tài)，實現(xiàn)對大型電機的遠程監(jiān)測，并為大型電機的故障診斷打下基礎。

1 移動端功能設計

基于物聯(lián)網(wǎng)的大型電機遠程監(jiān)測系統(tǒng)由感知層、網(wǎng)絡層和應用層組成，系統(tǒng)框架如圖1所示。其中，感知層負責數(shù)據(jù)的采集，網(wǎng)絡層負責數(shù)據(jù)的計算和數(shù)據(jù)存儲，應用層負責數(shù)據(jù)的顯示和人機交互。不同的用戶通過應用層對不同的大型電機進行遠程監(jiān)測，以及時發(fā)現(xiàn)并消除大型電機的故障，避免造成嚴重的后果。

圖1 基于物聯(lián)網(wǎng)的大型電機遠程監(jiān)測系統(tǒng)框圖

移動端為了能夠反映大型電機的實時運行狀態(tài)和歷史運行狀態(tài)，需要實現(xiàn)實時參數(shù)監(jiān)測功能和參數(shù)監(jiān)測歷史查詢功能；為了能夠及時通知用戶處理大型電機的故障，需要實現(xiàn)故障報警功能；為了能夠反映大型電機的故障歷史，需要實現(xiàn)故障報警歷史查詢功能。

（1）登錄功能

移動端根據(jù)登錄用戶的不同加載不同的電機數(shù)據(jù)。

（2）實時參數(shù)監(jiān)測功能

移動端根據(jù)用戶選擇的電機和參數(shù)，以折線圖的方式顯示某個電機的實時數(shù)據(jù)。

（3）參數(shù)監(jiān)測歷史查詢功能

移動端根據(jù)用戶選擇的電機、參數(shù)和時間，以折線圖的方式顯示某個電機參數(shù)的歷史數(shù)據(jù)，并根據(jù)用戶的操作對折線圖進行縮放和平移。

（4）故障報警功能

當某個電機運行狀態(tài)異常時，移動端將產(chǎn)生故障的電機、產(chǎn)生故障的時間、產(chǎn)生故障的參數(shù)等以通知的方式告知用戶，以及時處理故障，避免造成更嚴重的后果。

（5）故障報警設置功能

移動端根據(jù)用戶的操作判斷是否允許接收故障報警以及在允許接收故障報警時是否開啟聲音和振動。

（6）故障報警歷史查詢功能

移動端根據(jù)用戶選擇的電機，以二級列表的方式顯示某個電機的故障報警歷史。

（7）故障報警歷史清除功能

移動端根據(jù)用戶的操作判斷是否清除緩存的故障報警歷史。

2 移動端架構設計

目前，移動端架構模式主要有MVC（Model-View-Controller）、MVP（Model-View-Presenter）、MVVM（Model-View-View Model）三種。與其他兩種架構模式相比，MVP架構模式不僅實現(xiàn)了Model層與View層的分離，而且具有較高的代碼復用性。因此，移動端采用MVP架構模式，其中，Model層負責移動端的數(shù)據(jù)處理，View層負責移動端的數(shù)據(jù)顯示，Presenter層負責Model層與View層的數(shù)據(jù)通信。MVP架構模式框架如圖2所示。

圖2 MVP架構模式

3 移動端數(shù)據(jù)存儲

目前，移動端的數(shù)據(jù)存儲方式主要有文件存儲、SharedPreferences文件存儲以及SQLite數(shù)據(jù)庫存儲。其中，文件存儲適合存儲無格式的數(shù)據(jù)，SharedPreferences文件存儲適合存儲格式簡單、批量較小的數(shù)據(jù)，SQLite數(shù)據(jù)庫存儲適合存儲格式復雜、批量較大的數(shù)據(jù)。

移動端需要存儲用戶信息和電機信息。由于用戶信息格式簡單、批量較小，所以采用SharedPreferences文件存儲，用戶信息的存儲格式見表1所列；由于電機信息格式復雜、批量較大，所以采用SQLite數(shù)據(jù)庫存儲，電機信息的存儲格式見表2所列。

表1 用戶信息的存儲格式

表2 電機信息的存儲格式

對于故障報警設置功能，移動端需要存儲用戶設置。與用戶信息相比，用戶設置具有相同的特點，所以采用SharedPreferences文件存儲，用戶設置的存儲格式見表3所列。

表3 用戶設置的存儲格式

對于故障報警歷史查詢功能，移動端需要存儲故障報警歷史信息。與電機信息相比，故障報警歷史數(shù)據(jù)與其具有相同的特點，所以采用SQLite數(shù)據(jù)庫存儲，故障報警歷史信息的存儲格式見表4所列。

表4 故障報警歷史信息的存儲格式

4 移動端數(shù)據(jù)處理

移動端主要通過Activity組件、Fragment控件及Service組件實現(xiàn)相關功能。以下主要介紹登錄功能、實時參數(shù)監(jiān)測功能、參數(shù)監(jiān)測歷史查詢功能、故障報警功能與故障報警歷史查詢功能的數(shù)據(jù)處理。

4.1 登錄功能

移動端登錄功能的數(shù)據(jù)處理流程如圖3所示。在用戶登錄時，應用程序會判斷SharedPreferences文件中是否存在用戶的賬號和密碼。如果存在用戶的賬號和密碼，則從SQLite數(shù)據(jù)庫中的電機信息表加載電機數(shù)據(jù)；如果不存在用戶的賬號和密碼，則顯示登錄頁面。用戶通過登錄的方式使移動端從服務端獲取電機數(shù)據(jù)。如果登錄成功，應用程序會首先將用戶的賬號和密碼寫入SharedPreferences文件，并將電機數(shù)據(jù)寫入SQLite數(shù)據(jù)庫中的電機信息表，然后從SQLite數(shù)據(jù)庫中的電機信息表加載電機數(shù)據(jù)并顯示主頁面；登錄失敗時，顯示登錄頁面并通過Toast通知用戶登錄失敗。

圖3 登錄功能的數(shù)據(jù)處理流程

4.2 實時參數(shù)監(jiān)測功能

控制器將采集的參數(shù)實時數(shù)據(jù)通過網(wǎng)絡發(fā)送給服務端，服務端將其解析后寫入數(shù)據(jù)庫并在移動端請求，從數(shù)據(jù)庫讀出發(fā)送給移動端，移動端將其解析后以折線圖的方式向用戶展示。

移動端實時參數(shù)監(jiān)測功能的數(shù)據(jù)處理流程如圖4所示。應用程序根據(jù)用戶選擇的電機和參數(shù)，以1 s為時間間隔，不斷向服務端發(fā)送獲取該電機參數(shù)實時數(shù)據(jù)的請求。如果從服務端獲取數(shù)據(jù)成功，以折線圖的方式向用戶展示；如果從服務端獲取數(shù)據(jù)失敗，應用程序會根據(jù)用戶的操作判斷是否重新向服務端發(fā)送獲取該電機該參數(shù)實時數(shù)據(jù)的請求。如果不重新向服務端發(fā)送獲取該電機參數(shù)實時數(shù)據(jù)的請求，顯示操作失敗頁面。

圖4 實時參數(shù)監(jiān)測功能的數(shù)據(jù)處理流程

4.3 參數(shù)監(jiān)測歷史查詢功能

除實時參數(shù)監(jiān)測功能外，移動端允許用戶查詢?nèi)我怆姍C任意時刻的歷史數(shù)據(jù)。移動端參數(shù)監(jiān)測歷史查詢功能的數(shù)據(jù)處理流程如圖5所示。應用程序根據(jù)用戶選擇的電機、參數(shù)和時間，向服務端發(fā)送獲取該電機該參數(shù)該時刻歷史數(shù)據(jù)的請求。如果從服務端獲取數(shù)據(jù)成功，則以折線圖的方式向用戶展示，并允許用戶根據(jù)需要對折線圖進行縮放和平移；如果從服務端獲取數(shù)據(jù)失敗，則應用程序會根據(jù)用戶的操作判斷是否重新向服務端發(fā)送獲取該電機該參數(shù)該時刻歷史數(shù)據(jù)的請求。如果不重新向服務端發(fā)送獲取該電機該參數(shù)該時刻歷史數(shù)據(jù)的請求，顯示操作失敗頁面。

圖5 參數(shù)監(jiān)測歷史查詢功能的數(shù)據(jù)處理流程

4.4 故障報警功能

控制器采集參數(shù)數(shù)據(jù)時會根據(jù)設置的參數(shù)數(shù)據(jù)閾值判斷電機的運行狀態(tài)，一旦發(fā)現(xiàn)電機運行狀態(tài)異常，就立即向服務端發(fā)送故障報警信息；服務端接收到故障報警信息后會立即將其發(fā)送給移動端；移動端通知用戶及時處理故障，以避免造成更嚴重的后果。由于Android系統(tǒng)的限制，移動端接收服務端發(fā)送的故障報警信息情況分為在應用程序運行時接收和在應用程序未運行時接收兩種情況。

在應用程序運行時，移動端通過消息中間件的方式接收故障報警信息。目前主流的消息中間件有RabbitMQ、ActiveMQ和Kafka等，其中RabbitMQ因具有擴展性高、可靠性好等優(yōu)點被廣泛應用于實際項目中。RabbitMQ的工作原理如圖6所示，消息生產(chǎn)者將消息通過交換器傳遞到與交換器綁定的消息隊列中存儲，消息消費者與服務端建立連接后從消息隊列中取出消息進行處理。

圖6 RabbitMQ的工作原理

移動端故障報警功能的數(shù)據(jù)處理流程如圖7所示，應用程序啟動時，啟動故障報警服務。故障報警服務會創(chuàng)建消費者并與服務端連接，一旦監(jiān)聽的消息隊列不為空，應用程序根據(jù)Shared Preferences文件中的通知效果發(fā)送通知，通知用戶發(fā)生故障的時間、發(fā)生故障的電機、發(fā)生故障的參數(shù)、發(fā)生故障的參數(shù)的值。

圖7 故障報警功能的數(shù)據(jù)處理流程

因為Android系統(tǒng)在運行內(nèi)存不夠時會殺死故障報警服務，所以為了保證應用程序在運行時能夠接收故障報警信息，應用程序啟動時，會注冊廣播接收器。一旦故障報警服務終止，就發(fā)送廣播；廣播接收器接收到廣播后會重新啟動故障報警服務。在應用程序未運行時，移動端通過短信或郵件的方式接收故障報警信息。

4.5 故障報警歷史查詢功能

由于故障報警歷史數(shù)據(jù)規(guī)模較小，移動端采用在SQLite數(shù)據(jù)庫的故障報警歷史信息表緩存故障報警歷史數(shù)據(jù)的方式，以提高應用的響應速度。

移動端故障報警歷史查詢功能的數(shù)據(jù)處理流程如圖8所示，應用程序根據(jù)用戶選擇的電機，向服務端發(fā)送獲取該電機未獲取過的故障報警歷史數(shù)據(jù)的請求。如果從服務端獲取數(shù)據(jù)成功，應用程序會首先將該電機未獲取過的故障報警歷史數(shù)據(jù)寫入SQLite數(shù)據(jù)庫中的故障報警歷史信息表，然后從SQLite數(shù)據(jù)庫中的故障報警歷史信息表加載該電機的故障報警歷史數(shù)據(jù)，并以二級列表的方式向用戶展示；如果從服務端獲取數(shù)據(jù)失敗，應用程序會直接從SQLite數(shù)據(jù)庫中的故障報警歷史信息表加載該電機的故障報警歷史數(shù)據(jù)，并以二級列表的方式向用戶展示并通過Toast通知用戶操作失敗。

圖8 故障報警歷史查詢功能的數(shù)據(jù)處理流程

5 移動端測試

為測試移動端能否正常運行，我們在基于Android10的HuaWei nova5Pro設備上進行測試。

實時參數(shù)監(jiān)測功能的測試結果如圖9所示，移動端能夠正常顯示用戶選擇的電機和參數(shù)的實時數(shù)據(jù)。

圖9 實時參數(shù)監(jiān)測功能

參數(shù)監(jiān)測歷史查詢功能的測試結果如圖10所示，移動端能夠正常顯示用戶選擇的電機、參數(shù)和時間的歷史數(shù)據(jù)。

圖10 參數(shù)監(jiān)測歷史查詢功能

故障報警功能的測試結果如圖11所示，移動端能夠正常顯示產(chǎn)生故障的電機、產(chǎn)生故障的時間、產(chǎn)生故障的參數(shù)以及產(chǎn)生故障的參數(shù)的值。

圖11 故障報警功能

故障報警歷史查詢功能的測試結果如圖12所示，移動端能夠正常顯示用戶選擇的電機的故障報警歷史數(shù)據(jù)。

圖12 故障報警歷史查詢功能

6 結 語

本文基于Android平臺設計的大型電機遠程監(jiān)測系統(tǒng)的移動端，實現(xiàn)了實時參數(shù)監(jiān)測功能、參數(shù)監(jiān)測歷史查詢功能、故障報警功能以及故障報警歷史查詢功能等，具有不受時空限制的優(yōu)點，能夠幫助用戶及時發(fā)現(xiàn)并消除大型電機的故障，避免造成嚴重的后果。