胡清鐘



摘 要:針對稀土萃取生產過程中所出現的故障現象、安全隱患,文中從物聯網應用角度,使用Java語言,采用多線程、MVC開發模式開發了稀土萃取傳動裝置故障監測系統。采用“自下而上”“功能分層”“模塊劃分”的設計思路,從底層硬件組成、硬件工作原理、通信原理、網絡拓撲結構、軟件架構設計入手,提出了整體解決方案并成功實現,滿足了工廠的實際需求。
關鍵詞:物聯網;萃取;傳動裝置;故障監測;模塊劃分;多線程;MVC
中圖分類號:TP393文獻標識碼:A文章編號:2095-1302(2020)02-00-05
0 引 言
在稀土萃取生產過程中,通常由電機通過皮帶傳動驅動萃取槽內的攪拌器轉動,實現稀土氧化物的提煉。當出現電機停止轉動、皮帶打滑或者斷裂等故障時,攪拌器將停止攪拌槽內溶液,這將大大影響產品質量。同時由于從萃取槽兩端不斷進入的有機相和水相,導致溶液溢出萃取槽,引發事故進而嚴重影響整條生產線的正常作業。傳統的檢測方法是采用員工巡查來檢測攪拌器運轉情況,該方式存在兩個問題:一是當皮帶有輕微打滑時,巡查人員很難察覺;二是由于設備數量較多,當攪拌機發生故障時,巡查人員無法及時發現。這種檢測攪拌器運轉的方法嚴重影響了工作效率,所以對傳動裝置進行故障監測尤為重要[1]。
本文從硬件組成、網絡拓撲結構、分機和主機工作原理、通信原理與通信協議、數據庫設計、應用程序設計等方面提供了整體設計方案并予以實現。
1 總體方案設計
系統按照功能分為四個層次,從下到上依次分為數據采集層(分機)、數據匯聚層(主機)、數據存儲層(上位機和服務器)和數據表現層,框架如圖1所示。
系統的工作過程如下:
(1)分機負責皮帶傳動裝置信息的采集,通過433無線通信協議把數據傳送給主機;
(2)主機接收到數據后,對數據進行循環冗余CRC校驗,把校驗正確的數據通過CAN總線協議傳輸給上位機(本系統是一臺工控機)[2];
(3)上位機收到數據后,按照接收幀格式提取數據,可選擇將數據直接存儲到MySQL數據庫,以方便后期處理,如果企業對實時性要求較高,則可選擇先處理數據,將結果在上位機或監控室大屏顯示,然后再將數據存儲到數據庫;
(4)所有車間的PC機都運行有基于Java多線程與MVC設計模式[3]的客戶端應用軟件,通過局域網從MySQL數據庫獲取數據,從而實現同步監控本車間各槽位傳感器狀態信息的功能。
2 各分層結構設計說明
2.1 數據采集層
本層采用星型拓撲結構,在433無線通信協議中,把中心網絡節點稱為主機,其他節點稱為分機。分機包含的主要硬件有CC1310無線通信芯片、霍爾傳感器(Si7201)、外接天線、段碼液晶屏、紅外接收管、紅外遙控器、干簧管,結構示意如圖2所示。
由于分機是電池供電設備,所以要求降低功耗來延長電池壽命。分機采用定時(具體時間根據工廠需求設定)喚醒機制,當喚醒時刻到來時打開霍爾傳感器,檢測是否有磁場切割,同時設定一個時間段,只要在該時間段內檢測到脈沖信號,則說明皮帶傳動裝置工作正常,此時立刻關閉霍爾傳感器,以減少電量消耗。如果未檢測到脈沖,則連續檢測3次,若均未檢測到脈沖,則此時立即發送報警數據給主機,然后關閉霍爾傳感器。分機處理流程如圖3所示。
除此之外,分機還可以顯示本身的MAC(物理)地址,當磁鐵靠近干簧管時,段碼屏亮起,分機MAC地址將高亮顯示,如果無操作,幾秒鐘之后段碼屏會自動變暗(或一段時間后自動隱藏)以節省電量。分機可以通過紅外遙控器設置信道和發射功率以適應復雜的環境。
2.2 數據匯聚層
數據匯聚層的主要功能是收集并緩存工作在同一信道的分機發送來的數據,本系統設定每個主機最多可以管轄100個
分機。主機和分機采用星型拓撲結構,每個主機工作的信道不相同,所有主機通過CAN(控制器局域網)串行通信協議鏈接在一條總線上,主機和上位機自定義數據鏈路層幀交換數據。主機的結構比較簡單,主要硬件包括STM32芯片[4]、CC1310無線通信芯片、外接天線和電源模塊(交流供電),結構如圖4所示。
2.3 數據處理層
這一層主要由上位機和MySQL數據庫服務器組成。上位機通過數據鏈路層幀與主機進行數據通信。本系統自定義了2種幀格式,分別為發送幀和接收幀。發送幀總長7 B,各字段涵義見表1所列。
2.4 數據表現層
本層的主要作用是對數據進行可視化處理,結果在總監控室大屏和各車間顯示屏展示。系統使用Java語言,MVC(Model,數據模型;View,用戶界面;Control,控制器)開發模式設計構建。MVC是當今最流行的軟件設計模式之一,可以極大地提高軟件開發效率和代碼重用率。使用MVC的目的是將M和V實現代碼分離,從而使同一個程序可以使用不同的表現形式。
Model層主要包括的實體類有Gdrfs,Sensor,Slot和SlotCurrentState。
Control層主要實現程序的邏輯控制,比如基于數據庫的增、刪、改、查操作,用戶需求相關功能實現等,都以接口(API函數)形式提供給View層。例如本系統最重要的一個接口getSensorsStateByDepartId(String departId),形參departId是一個指向某車間Id的字符串值,接口的功能是從數據庫讀取車間值為departId的所有傳感器的當前狀態值,返回一個Map
View層通過調用API函數完成每個槽位報警狀態的動態顯示。某車間所有槽位狀態顯示程序流程如圖9所示。
3 關鍵技術實現
3.1 接收幀粘包和斷幀
粘包指接收端接收幀時,原本發送端發送兩幀數據被接收端當成一幀數據接收。相反,如若發送端只發送了一幀數據,而接收端卻誤認為是多個幀,這種現象被稱為斷幀。造成粘包的主要原因是接收端定時時間過長,而造成斷幀的原因在于接收端定時時間過短。如果采用固定幀長,就可以很好地解決接收端時長難以確定的問題,比如本系統設定的接收幀固定長度為1 024 B,如果主機發給上位機的幀長度不足,則虛擬不存在的節點(物理地址為全0)將其他字段全部填充0,上位機在接收到此類MAC地址時需要過濾這些填充的0。分析幀的結構,發現每幀都是由數據頭、長度、數據內容、CRC校驗碼組成,通過數據長度字段來讀取每一幀數據也能夠得到一個完整的數據幀。亦可采用CRC校驗碼過濾偽特征碼數據(數據是以0xA55A開頭的幀)。
3.2 上位機負荷過重
本項目實施企業共安裝了780個分機,12個主機,上位機每隔200 ms對主機進行一次輪詢,一個周期的時間為
2 400 ms,由此可算出每小時理論數據量為1 123 200條數據。但實際卻比理論計算值少,因為分機使用電池供電,為了省電,只有在兩種情況下分機才會發送數據,一是當分機檢測到皮帶傳動裝置異常,二是定時喚醒時刻,否則大部分時間都處于休眠狀態。通過查看數據庫,實際每小時數據量約為15 000條。但考慮到本項目中上位機使用的是一臺普通的工控機,配置為酷睿Core i5處理器,內存8 GB,當數據量達到500萬條以上時,CPU利用率幾乎達到100%,嚴重影響數據表示層的時效性。因此采用如下方法解決上述問題:
(1)優化SQL查詢語句,對經常查詢的字段建立索引;
(2)將上位機與數據庫服務器分離。
4 結 語
本系統從軟硬件方面結合企業實際需求研究和設計了稀土生產線萃取傳動裝置故障監測方案,并予以實現。本系統具有很好的開放性、時效性、易維護性和易擴充性,符合企業需求,達到了預期目標,具有較高的實用價值和一定的推廣示范性。
參 考 文 獻
[1]胡振光,陳松嶺.基于粗糙集和BP神經網絡的稀土萃取傳動裝置故障監測及診斷方法[J].礦冶,2016,25(5):63-66.
[2]張光河.物聯網概論[M].北京:人民郵電出版社,2014:5-50.
[3]趙晨時,馬琪,竺紅衛.一種基于多特征量的直流電弧故障檢測方法[J].物聯網技術,2018,8(2):27-29.
[4]王嘉俊.基于STM32的智能小車控制系統設計[J].電子制作, 2018(17):21-22.
[5]孟凡榮,閆秋艷.數據庫原理與應用(MySQL版)[M].北京:清華大學出版社,2019.
[6]賈召喜.基于工業物聯網的生產線遠程監控系統研究[D].天津:河北工業大學,2015.
[7]白文榮,王曉燕.Java核心技術[M].北京:清華大學出版社,2018.
[8]陳恒,樓偶俊,鞏慶志,等.Spring MVC開發技術指南[M].北京:清華大學出版社,2017.
[9]戶晨飛.面向工業物聯網的生產線遠程數據傳輸系統研究[D].上海:東華大學,2018.
[10]林道志.萃取技術在稀土分離科學中的應用及前景[J].化工進展,1994(5):6-11.