胥 軍，孟新委，翁啟孟，李剛炎

(武漢理工大學(xué) 機(jī)電工程學(xué)院，湖北 武漢 430070)

由于近年來的不斷開采，天然彩砂資源瀕臨枯竭；另一方面，各種天然彩砂品質(zhì)不一、批次色差大，且品種逐年減少，無法滿足目前建筑市場的需求[1-2]。因此，以礦物顆粒為原料，混合無機(jī)顏料，經(jīng)高溫?zé)Y(jié)而成的人工燒結(jié)彩砂得到了有力發(fā)展，逐漸成為滿足市場需求的主流產(chǎn)品[3-4]。

面對具有巨大潛力的國內(nèi)彩砂市場，不少企業(yè)開始增大人工燒結(jié)彩砂的生產(chǎn)規(guī)模，而彩砂生產(chǎn)控制與管理水平逐漸成為制約彩砂大規(guī)模生產(chǎn)的主要因素。國內(nèi)對于彩砂生產(chǎn)的研究主要集中在生產(chǎn)工藝方面，而對于彩砂生產(chǎn)實施過程中設(shè)備監(jiān)控與管理方面的研究極少。目前，建材制造業(yè)傳統(tǒng)的監(jiān)控系統(tǒng)大多以二維平面為主[5-6]，管理人員在生產(chǎn)過程中難以直觀地定位監(jiān)測點。同時，在連續(xù)大批量生產(chǎn)過程中，若生產(chǎn)設(shè)備無法得到有效管理、故障未能及時偵測并排除，將會導(dǎo)致產(chǎn)線停產(chǎn)，甚至引發(fā)重大安全事故。

筆者面向人工燒結(jié)彩砂生產(chǎn)制造過程，基于實時數(shù)據(jù)采集、傳輸與處理以及WebGL(web graphics library)三維可視化技術(shù)，設(shè)計開發(fā)了彩砂生產(chǎn)線三維可視化監(jiān)控系統(tǒng)，其能實時動態(tài)監(jiān)控彩砂生產(chǎn)線運行情況，提升彩砂生產(chǎn)線管理效率。使設(shè)備的維護(hù)和管理從人工被動看守向計算機(jī)集中管控的模式轉(zhuǎn)變，解決上層管理與底層控制脫節(jié)的問題，實現(xiàn)管理、控制、決策一體化操作。

1 可視化監(jiān)控系統(tǒng)功能需求

某廠彩砂生產(chǎn)線布局如圖1所示，生產(chǎn)線總長達(dá)125 m，各工藝段設(shè)備相距較遠(yuǎn)，涉及的設(shè)備種類和數(shù)量繁多。彩砂的制備過程主要包括原砂與色漿混合、烘干、煅燒和冷卻等工序。彩砂生產(chǎn)線產(chǎn)能要求不低于10 t/h，同時需要根據(jù)生產(chǎn)批量大小與工藝要求靈活地調(diào)整彩砂生產(chǎn)速度。

圖1 彩砂生產(chǎn)線布局圖

1.1 設(shè)備控制需求分析

彩砂生產(chǎn)線跨度大，生產(chǎn)線各個設(shè)備分布較為分散，系統(tǒng)采用本地控制模式會增加線材損耗，過長的線路不僅會給控制系統(tǒng)帶來隱患，還會使后期設(shè)備和線路檢修難度加大。因此，需要合理設(shè)計控制方案，對生產(chǎn)線實現(xiàn)有效控制的同時減少線材損耗。此外，生產(chǎn)不同型號的彩砂前需重新手動調(diào)整多臺設(shè)備的控制參數(shù)，不利于實現(xiàn)快速轉(zhuǎn)產(chǎn)，需要合理設(shè)計控制模式對生產(chǎn)線設(shè)備能夠集中控制，實現(xiàn)彩砂生產(chǎn)線的快速轉(zhuǎn)產(chǎn)。

1.2 監(jiān)控對象分析

監(jiān)控對象主要有原料、設(shè)備、產(chǎn)品、檢修計劃等。原料監(jiān)控包括原料庫存狀態(tài)、原料消耗速率等。設(shè)備監(jiān)控包括設(shè)備運行實時狀態(tài)和異常狀態(tài)等。產(chǎn)品監(jiān)控內(nèi)容包括彩砂產(chǎn)量等。檢修計劃監(jiān)控包括檢修任務(wù)完成情況、異常狀態(tài)處理情況等。

1.3 數(shù)據(jù)處理需求分析

生產(chǎn)數(shù)據(jù)的實時采集與處理是實現(xiàn)彩砂生產(chǎn)線可視化監(jiān)控的基礎(chǔ)。傳統(tǒng)彩砂生產(chǎn)線的不同設(shè)備之間存在“信息孤島”，數(shù)據(jù)利用率低，對生產(chǎn)線管理難以起到實時有效的指導(dǎo)作用。因此，彩砂三維可視化監(jiān)控系統(tǒng)需要實現(xiàn)對所有設(shè)備的生產(chǎn)數(shù)據(jù)進(jìn)行實時采集并集中統(tǒng)一處理。

1.4 可視化監(jiān)控需求分析

傳統(tǒng)彩砂生產(chǎn)線的管理人員難以實時全面掌握各個設(shè)備的運行狀態(tài)；設(shè)備技術(shù)資料管理不規(guī)范，不利于設(shè)備維護(hù)與管理；設(shè)備巡檢工作量較大，且設(shè)備巡檢周期各不相同，容易出現(xiàn)漏檢；設(shè)備出現(xiàn)故障時維修人員無法及時定位故障源，導(dǎo)致應(yīng)急處理滯后。因此，可視化監(jiān)控不僅需要對彩砂生產(chǎn)線生產(chǎn)數(shù)據(jù)進(jìn)行高效處理以便于對生產(chǎn)線的生產(chǎn)進(jìn)行管理，還要對各個設(shè)備運行狀態(tài)進(jìn)行監(jiān)控以及反饋以便于維修人員對設(shè)備的維護(hù)。

2 可視化監(jiān)控系統(tǒng)技術(shù)框架

基于以上對彩砂生產(chǎn)線三維可視化監(jiān)控系統(tǒng)的功能需求分析，需合理設(shè)計實現(xiàn)該系統(tǒng)的技術(shù)框架。

2.1 生產(chǎn)線設(shè)備分布式控制方案

基于現(xiàn)場總線的控制方式能兼容不同類型設(shè)備，且具有控制結(jié)構(gòu)分散、通信數(shù)字化等特點，適用于彩砂生產(chǎn)線設(shè)備多且分散的狀況，同時又能滿足各工段間生產(chǎn)工藝相互關(guān)聯(lián)的需求。通過本地控制與遠(yuǎn)程I/O模塊控制結(jié)合的方式，在CC-Link現(xiàn)場總線的基礎(chǔ)上搭建主從分布式實時通信網(wǎng)絡(luò)，互聯(lián)各站點設(shè)備，實現(xiàn)對彩砂生產(chǎn)線的分布式控制[7]，彩砂生產(chǎn)線分布式控制方式如圖2所示。

圖2 彩砂生產(chǎn)線分布式控制

集中控制柜中主站負(fù)責(zé)對采集的數(shù)據(jù)進(jìn)行運算處理和邏輯判斷，并發(fā)出控制指令；控制柜1、控制柜2、控制柜3、控制柜4中各從站分別對彩砂生產(chǎn)線4個工作段內(nèi)的設(shè)備進(jìn)行控制，并采集設(shè)備運行數(shù)據(jù)，實現(xiàn)設(shè)備分組分站控制與數(shù)據(jù)分布式采集。

2.2 可視化監(jiān)控系統(tǒng)總體技術(shù)框架

彩砂生產(chǎn)線可視化監(jiān)控系統(tǒng)，包括物理層、數(shù)據(jù)服務(wù)層與設(shè)備管理層，其總體技術(shù)框架如圖3所示。

圖3 系統(tǒng)總體技術(shù)框架

(1)物理層是彩砂生產(chǎn)線的制造資源層，包括生產(chǎn)線的生產(chǎn)設(shè)備、傳感器以及數(shù)據(jù)采集總線等，是完成設(shè)備控制、生產(chǎn)數(shù)據(jù)采集、彩砂生產(chǎn)的基礎(chǔ)。

(2)數(shù)據(jù)服務(wù)層主要對生產(chǎn)數(shù)據(jù)進(jìn)行存儲、處理分析，同時實現(xiàn)具體的業(yè)務(wù)邏輯。系統(tǒng)采用MySQL數(shù)據(jù)庫存儲歷史數(shù)據(jù)，采用Redis數(shù)據(jù)庫對實時數(shù)據(jù)進(jìn)行處理，數(shù)據(jù)經(jīng)處理后將為設(shè)備可視化管理功能提供數(shù)據(jù)支撐。

(3)設(shè)備管理層面向生產(chǎn)管理人員，使用Three.js框架完成對三維場景的渲染，通過可視化圖表動態(tài)顯示生產(chǎn)數(shù)據(jù)。管理人員可對設(shè)備進(jìn)行基礎(chǔ)信息管理及狀態(tài)監(jiān)控，同時也可進(jìn)行設(shè)備異常狀態(tài)管理。

3 生產(chǎn)數(shù)據(jù)的采集、處理與傳輸

3.1 基于Modbus/TCP的數(shù)據(jù)采集

在現(xiàn)場控制層中，通過讀取PLC(programmable logic controller)中的數(shù)據(jù)信息，能快速獲取彩砂生產(chǎn)線設(shè)備的運行數(shù)據(jù)。生產(chǎn)線采用三菱Q系列PLC作為主控制器，其源地址屬于物理層地址，無法直接被上層網(wǎng)絡(luò)識別，利用Modbus映射規(guī)則將PLC內(nèi)部元件的源地址轉(zhuǎn)為Modbus地址[8]。

為監(jiān)控彩砂生產(chǎn)線設(shè)備運行狀態(tài)，需要采集輸出線圈、離散輸入和數(shù)據(jù)寄存器中的數(shù)據(jù)，采用Java編程語言，通過Modbus-Master-TCP類庫設(shè)計Modbus/TCP客戶端，通過定時輪詢方式周期性獲取PLC運行數(shù)據(jù)。采用多線程的方式對生產(chǎn)數(shù)據(jù)進(jìn)行獲取與處理，主線程創(chuàng)建輪詢線程、解析線程和控制線程3個子線程。

3.2 生產(chǎn)數(shù)據(jù)的傳輸與處理

靜態(tài)數(shù)據(jù)由人工手動錄入系統(tǒng)數(shù)據(jù)庫中進(jìn)行集中管理，而對于生產(chǎn)實時數(shù)據(jù)，需進(jìn)行及時處理，防止數(shù)據(jù)可視化出現(xiàn)明顯滯后。系統(tǒng)選擇內(nèi)存數(shù)據(jù)庫Redis對實時數(shù)據(jù)進(jìn)行處理，可以在極短時間內(nèi)完成數(shù)據(jù)集成和轉(zhuǎn)換[9]，通過發(fā)布訂閱推送機(jī)制向客戶端提供實時數(shù)據(jù)。由于內(nèi)存限制，Redis數(shù)據(jù)庫中的數(shù)據(jù)不能永久地在內(nèi)存中保留，需要將超出時限的數(shù)據(jù)移入歷史數(shù)據(jù)庫。實時數(shù)據(jù)對象D包含有3個分量，可表示為：

D=d(value,time,period)

(1)

式中：value為實時數(shù)據(jù)的值；time為數(shù)據(jù)采樣時間；period為數(shù)據(jù)有效期。

用向量V表示在數(shù)據(jù)有效期內(nèi)采集到的數(shù)據(jù)，Di表示標(biāo)識為i的某個采集數(shù)據(jù)，將在時刻j采集到的數(shù)據(jù)表示為：

(2)

式中:period[p,q]為開始時刻p到結(jié)束時刻q之間的數(shù)據(jù)有效期時間段區(qū)間。

在period[p,q]的時間區(qū)間內(nèi)系統(tǒng)實時數(shù)據(jù)處理的能力Cas可表示為：

(3)

式中：q為當(dāng)前時刻；Cas為具體某個某檢測信號的實時數(shù)據(jù)范圍，將在此范圍內(nèi)采集到的數(shù)據(jù)標(biāo)定為實時數(shù)據(jù)，超過此范圍的數(shù)據(jù)標(biāo)定為歷史數(shù)據(jù)，分別存入對應(yīng)數(shù)據(jù)庫中。

系統(tǒng)采用Websocket協(xié)議傳輸彩砂生產(chǎn)線實時數(shù)據(jù)，在減小系統(tǒng)資源消耗的同時降低了數(shù)據(jù)傳輸時延。相比于Ajax長輪詢、Comet等通信技術(shù)，Websocket支持服務(wù)端主動推送實時數(shù)據(jù)，能有效提高數(shù)據(jù)傳輸?shù)膶崟r性[10-11]。

數(shù)據(jù)訪問與傳輸方式如圖4所示。客戶端能主動發(fā)起HTTP(hyper text transfer protocol)請求，從服務(wù)器數(shù)據(jù)庫獲取不經(jīng)常變動的“冷數(shù)據(jù)”；對于實時數(shù)據(jù)的傳輸，可從訪問請求中獲取所要監(jiān)測設(shè)備數(shù)據(jù)發(fā)布的通道，并訂閱該通道，從而和服務(wù)器之間建立起數(shù)據(jù)推送，當(dāng)檢測到數(shù)據(jù)變化時可以實時主動推送至客戶端，對監(jiān)控頁面的數(shù)據(jù)進(jìn)行局部的刷新。

圖4 服務(wù)器數(shù)據(jù)訪問方式

4 可視化監(jiān)控系統(tǒng)實現(xiàn)及驗證

4.1 生產(chǎn)線三維模型構(gòu)建

WebGL作為主流的Web端3D繪圖技術(shù)，通過提供硬件3D加速渲染，實現(xiàn)了三維交互場景模型在Web端的流暢展示[9]。Three.js是基于JavaScript的第三方庫，對WebGL的原生API(application program interface)進(jìn)行了很好的封裝，只需少量易讀的JavaScript腳本即可在Web端構(gòu)建彩砂生產(chǎn)線的三維場景。

采用SolidWorks與3D Max協(xié)同的方法搭建彩砂生產(chǎn)線三維模型，然后將其轉(zhuǎn)換成Three.js框架支持的文件格式，并以文本形式存放于服務(wù)器中。用戶通過瀏覽器下載后由對應(yīng)函數(shù)解析模型文件，生成模型對象及其材質(zhì)信息，同時添加到構(gòu)建完成后的場景中。Three.js場景創(chuàng)建流程如圖5所示，通過調(diào)整模型位置、相機(jī)和光源的參數(shù)，使得彩砂生產(chǎn)線三維模型在Web端進(jìn)行可視化展示。

圖5 Three.js場景創(chuàng)建流程

4.2 生產(chǎn)線三維模型輕量化及渲染優(yōu)化

瀏覽器加載彩砂生產(chǎn)線三維模型時的平均阻塞時長為18 s。模型渲染性能較低，模型實時渲染性能過低會出現(xiàn)掉幀、卡頓等現(xiàn)象，不僅會影響可視化管理系統(tǒng)運行的流暢度，有時甚至?xí)绊懴到y(tǒng)的正常運作。因此需對模型數(shù)據(jù)傳輸及渲染過程進(jìn)行優(yōu)化。

三維網(wǎng)格模型的基本構(gòu)成為點、線和面，模型簡化操作中最小的維度也分為對點、線和面的操作。QEM(quadic error metrics)簡化算法以邊折疊為基礎(chǔ)，有較高的模型簡化效率，同時能保留模型主要特征的優(yōu)點[12]。通過將模型頂點的二次誤差度作為簡化目標(biāo)的度量準(zhǔn)則，選取一條邊上的兩個頂點進(jìn)行合并處理，并更新網(wǎng)格頂點與法向量等信息。邊折疊算法原理如圖6所示。

圖6 邊折疊算法原理圖

以烘干機(jī)模型為例，將其簡化到原始模型頂點數(shù)的50%，簡化前后的網(wǎng)格模型對比如圖7(a)所示，簡化后模型大小減小了37.7%。簡化后模型能保留細(xì)節(jié)部分，但圓柱形滾筒會有較為明顯的分段感，采用Three.js提供的THREE.SmoothShading(平滑著色屬性)優(yōu)化模型顯示效果，如圖7(b)所示。

圖7 Three.js烘干機(jī)模型網(wǎng)格簡化及渲染優(yōu)化

采用Draco算法對三維場景模型進(jìn)行壓縮處理，Draco算法主要用于三角網(wǎng)格數(shù)據(jù)和點云數(shù)據(jù)的壓縮，在沒有犧牲渲染速度和質(zhì)量的前提下，可大幅提升模型文件壓縮率，減少模型數(shù)據(jù)傳輸對網(wǎng)絡(luò)帶寬的壓力[13]。經(jīng)壓縮后烘干機(jī)模型大小僅為簡化后模型大小的7.17%，說明Draco算法可以顯著減小三維模型文件體積，同時不與輕量化策略沖突。此外，使用Three.js實例化并克隆場景中的重復(fù)模型，有效降低數(shù)據(jù)傳輸負(fù)載及GPU(graphics processing unit)渲染負(fù)載。

彩砂生產(chǎn)線三維模型整體大小為591 Mb，經(jīng)簡化與壓縮處理后減小至12 Mb左右，優(yōu)化處理后模型實時渲染效果良好，系統(tǒng)持續(xù)運行時的幀率保持在60左右，確保了系統(tǒng)運行流暢度。

4.3 分布式控制方案的實現(xiàn)

根據(jù)所設(shè)計的分布式控制方案，完成集中控制柜以及4個分控制柜的接線及調(diào)試工作?？刂乒裢ㄟ^面板指示燈顯示關(guān)鍵設(shè)備啟停狀態(tài)，并提供控制按鈕對彩砂生產(chǎn)線中關(guān)鍵設(shè)備進(jìn)行控制，集中控制柜實物如圖8所示。

圖8 集中控制柜實物

控制柜提供關(guān)鍵設(shè)備的手/自動控制的切換功能，設(shè)備操作人員能通過控制柜面板獨立操作單個設(shè)備，進(jìn)行控制主和檢修，完成生產(chǎn)與設(shè)備日常維護(hù)工作。系統(tǒng)控制柜為獨立供電，在局部設(shè)備發(fā)生故障時不影響其余設(shè)備正常工作。

4.4 可視化管理平臺的實現(xiàn)

可視化管理平臺分為基礎(chǔ)信息管理、設(shè)備狀態(tài)監(jiān)控、設(shè)備異常狀態(tài)管理、檢修計劃管理等功能模塊?；A(chǔ)信息管理界面如圖9所示，點擊場景中對應(yīng)模型，可查看設(shè)備臺賬信息及歷史運行數(shù)據(jù)，點擊面板定位標(biāo)簽，三維場景視角將快速跳轉(zhuǎn)至模型所在位置。

圖9 實物基礎(chǔ)信息管理界面

設(shè)備監(jiān)控模塊結(jié)合三維模型動態(tài)顯示設(shè)備啟停狀態(tài)、實時運行數(shù)據(jù)等。管理人員可在工藝參數(shù)設(shè)置面板上預(yù)先設(shè)定參數(shù)，只需選擇彩砂品種便能完成生產(chǎn)參數(shù)設(shè)定，且能根據(jù)現(xiàn)場生產(chǎn)情況在線調(diào)整工藝參數(shù)，實現(xiàn)快速轉(zhuǎn)產(chǎn)。設(shè)備異常管理模塊可檢測異常電氣設(shè)備并高亮顯示對應(yīng)模型以便快速定位故障。檢修計劃管理模塊可結(jié)合三維模型，顯示設(shè)備檢修位置，查看設(shè)備檢修計劃進(jìn)度和檢修任務(wù)統(tǒng)計信息。

4.5 系統(tǒng)性能測試

在完成彩砂三維可視化系統(tǒng)開發(fā)后，需依照軟件測試要求對系統(tǒng)進(jìn)行性能測試。測試內(nèi)容主要包括三維場景渲染幀率、系統(tǒng)實時性和系統(tǒng)安全性測試等，系統(tǒng)測試環(huán)境如表1所示。

表1 系統(tǒng)測試環(huán)境配置

(1)三維場景渲染幀率測試。渲染幀率是三維可視化系統(tǒng)運行效果最直觀的評價指標(biāo)，當(dāng)幀率達(dá)到30 幀/s(frames per second)以上時，人眼不會明顯感受到卡頓。采用Three.js提供的性能監(jiān)視器Stats類對三維場景渲染幀率進(jìn)行測試，判斷系統(tǒng)在各個功能模塊下系統(tǒng)的渲染性能表現(xiàn)是否滿足使用要求，并隨機(jī)選取20次幀率平均值作為測試結(jié)果，如表2所示。結(jié)果顯示各功能模塊下幀率值均在60 幀/s附近波動，表明了系統(tǒng)整體的可視化呈現(xiàn)效果較好，能夠滿足應(yīng)用的需求。

表2 三維場景渲染幀率測試

(2)系統(tǒng)實時性測試。在相同的網(wǎng)絡(luò)環(huán)境下記錄系統(tǒng)取得單位數(shù)量監(jiān)測數(shù)據(jù)所消耗的時間，重復(fù)進(jìn)行10次測試，每次測試的樣本數(shù)為100，取測試結(jié)果的均值，結(jié)果如圖10所示。

圖10 系統(tǒng)實時性測試

由此可知，采用Websocket協(xié)議及Redis內(nèi)存數(shù)據(jù)庫發(fā)布訂閱推送機(jī)制，使系統(tǒng)具備較高實時性能，數(shù)據(jù)延時小于1 s，契合實際生產(chǎn)需求。

(3)系統(tǒng)安全性測試。彩砂生產(chǎn)線分布式控制與設(shè)備可視化管理系統(tǒng)對操作安全性有較高的要求，因此有必要對系統(tǒng)進(jìn)行安全測試，驗證系統(tǒng)的保護(hù)機(jī)制是否滿足實際使用要求，其中部分安全測試項如表3所示。結(jié)果顯示系統(tǒng)安全性能滿足彩砂生產(chǎn)使用需求。

表3 系統(tǒng)安全測試

5 結(jié)論

筆者針對目前彩砂生產(chǎn)線的實際需求，設(shè)計了彩砂生產(chǎn)線三維可視化監(jiān)控系統(tǒng)，完成了生產(chǎn)線實時數(shù)據(jù)的采集、傳輸及處理，利用WebGL技術(shù)和模型輕量化的關(guān)鍵技術(shù)完成了彩砂生產(chǎn)線的三維可視化，降低了設(shè)備檢修難度與維護(hù)成本，有助于提升彩砂生產(chǎn)線的綜合管理水平。