耿向征,袁逸萍,毛 軍,吳正春
(1.新疆大學(xué)機(jī)械工程學(xué)院,新疆 烏魯木齊 830047;2.卓郎新疆智能機(jī)械有限公司,新疆 烏魯木齊 830000)
近年來,隨著數(shù)據(jù)采集技術(shù)和信息傳輸技術(shù)的迅猛發(fā)展,離散制造車間中獲取的制造數(shù)據(jù)呈爆炸式增長,這使得制造業(yè)大數(shù)據(jù)成為制造行業(yè)的研究熱點(diǎn)之一。
在此環(huán)境下,傳統(tǒng)的單機(jī)計算速度已無法滿足實時性要求,為實現(xiàn)對車間中多類制造資源的實時定位、追蹤、監(jiān)控,急需將車間定位技術(shù)與大數(shù)據(jù)技術(shù)結(jié)合。
在車間定位技術(shù)方面,紫蜂(Zigbee)、超寬帶技術(shù)(Ultra Wide Band,UWB)、無線射頻識別技術(shù)(Radio Frequency Identification,RFID)等技術(shù)常被用于車間定位[1]。文獻(xiàn)[2]通過對車間生產(chǎn)過程中生產(chǎn)要素定位需求和射頻識別技術(shù)的研究,開發(fā)出一套基于RFID的應(yīng)用系統(tǒng),滿足了對批量化零件的自動化監(jiān)控和對人員實時定位與管理的需求;文獻(xiàn)[3]將UWB定位技術(shù)集成到數(shù)據(jù)系統(tǒng)中,對倉庫內(nèi)的叉車和其他移動實體進(jìn)行定位和跟蹤,提高了倉庫的安全性和操作效率;文獻(xiàn)[4]提出了一種RFID和無線保真技術(shù)相融合的實時定位平臺,通過對物料進(jìn)行監(jiān)控,實現(xiàn)了倉庫的自動化、數(shù)字化和智能化。
在大數(shù)據(jù)技術(shù)應(yīng)用方面,文獻(xiàn)[5]為了實現(xiàn)實時網(wǎng)絡(luò)中異常流量的快速分析和識別,設(shè)計了融合Spark流和Kafka的分布式實時網(wǎng)絡(luò)異常流量檢測系統(tǒng)(DRNATDS),并提出了一種基于相對密度和距離的K-means算法,有效地分析網(wǎng)絡(luò)異常流量,檢測實時數(shù)據(jù)流下的各種網(wǎng)絡(luò)攻擊;為解決在視頻檢索過程中由于視頻數(shù)據(jù)的海量性、復(fù)雜性、冗余性所導(dǎo)致的計算能力和資源需求過高問題,文獻(xiàn)[6]提出利用Hadoop、Hbase、Spark 和Opencv 實現(xiàn)了基于內(nèi)容的視頻檢索系統(tǒng);文獻(xiàn)[7]提出一種利用Spark Streaming和改進(jìn)的網(wǎng)格索引技術(shù)對車輛位置和交通事件進(jìn)行快速處理的方法,使與應(yīng)用了WEVING服務(wù)的司機(jī)實時共享周圍車輛信息、行人信息和交通事件信息更方便。
在離散制造車間中包含眾多的生產(chǎn)要素,能夠?qū)崟r準(zhǔn)確的獲取生產(chǎn)要素位置信息和狀態(tài)信息將降低車間的管理難度和提升生產(chǎn)效率。在實際生產(chǎn)過程中,傳統(tǒng)的數(shù)據(jù)收集技術(shù)和單機(jī)計算模式難以保證數(shù)據(jù)的實時性、價值性。上述研究提供了基礎(chǔ)的研究理論與方法,通過借鑒傳統(tǒng)大數(shù)據(jù)技術(shù)對現(xiàn)有問題進(jìn)行解決。選擇UWB定位系統(tǒng)作為生產(chǎn)要素位置信息的獲取手段,設(shè)計一種利用大數(shù)據(jù)技術(shù)對生產(chǎn)要素定位數(shù)據(jù)進(jìn)行實時地采集、處理、存儲,利用Demo 3D 軟件進(jìn)行可視化的平臺,并采用基于Spark Streaming 框架的多線程卡爾曼濾波器解決單機(jī)進(jìn)行卡爾曼濾波時間過長和軌跡平滑度問題。最后,以新疆某農(nóng)機(jī)制造車間為實踐對象、相應(yīng)設(shè)備及軟件為基礎(chǔ),對定位要素的位置數(shù)據(jù)進(jìn)行實時可視化顯示。
大數(shù)據(jù)環(huán)境下離散制造車間實時定位數(shù)據(jù)可視化平臺整體架構(gòu),如圖1所示。其中UWB定位系統(tǒng)是數(shù)據(jù)采集層,負(fù)責(zé)對生產(chǎn)要素的位置信息進(jìn)行實時采集;Kafka是數(shù)據(jù)接收層,負(fù)責(zé)對采集到位置數(shù)據(jù)流進(jìn)行接收并傳遞;Spark Streaming作為數(shù)據(jù)預(yù)處理層,負(fù)責(zé)對Kafka傳遞的數(shù)據(jù)進(jìn)行實時處理,并將處理后的數(shù)據(jù)存入HBase 數(shù)據(jù)存儲系統(tǒng)中。Demo 3D 是數(shù)據(jù)應(yīng)用層,利用HBase提供的API接口和TCP協(xié)議,將數(shù)據(jù)傳遞給Demo 3D進(jìn)行生產(chǎn)要素的定位信息顯示。
圖1 平臺結(jié)構(gòu)Fig.1 Structure of Platform
選用Ubisense UWB 定位設(shè)備對位置信息進(jìn)行采集。在實際工作中,通過定位傳感器與定位標(biāo)簽之間的脈沖信號傳輸來測定AOA、TDOA信息,再使用定位引擎對測定的信息進(jìn)行解析,獲得定位標(biāo)簽的精確位置信息,如圖2所示。定位傳感器選擇Series 7000系列傳感器,定位標(biāo)簽選擇Ubitag(緊湊型)。
圖2 UWB定位系統(tǒng)硬件Fig.2 Hardwares of UWB Positioning System
在多種傳感器并存、通信感知技術(shù)廣泛應(yīng)用的情況下,一方面要保證數(shù)據(jù)的實時性,另一方面又要減少數(shù)據(jù)的丟失,這些都給工業(yè)數(shù)據(jù)的收集帶來了巨大挑戰(zhàn)。
Kafka是一種分布式發(fā)布訂閱消息傳遞系統(tǒng)[8],在流式計算中被廣泛應(yīng)用。Kafka中可以包含一個或多個代理的服務(wù)器,它們收集并存儲信息,然后發(fā)布相關(guān)的Topic。Apache Zookeeper被用于跟蹤Kafka中集群節(jié)點(diǎn)的狀態(tài)。生產(chǎn)者將消息發(fā)送給代理,代理保存消息,確保消費(fèi)者可以接受完整的消息。Kafka架構(gòu),如圖3所示。
圖3 Kafka架構(gòu)Fig.3 Architecture of Kafka
Apache Spark 是一個開放源碼的、分布式的、快速的、集群的、用于處理大數(shù)據(jù)的計算框架。其速度比Hadoop更快[9]。
Spark Streaming是Spark中基于內(nèi)存的流處理計算框架??梢暂p松處理實時數(shù)據(jù),其處理結(jié)果能夠滿足實時的要求。此外,它可以接收多個數(shù)據(jù)源的數(shù)據(jù),如Apache Kafka、Apache Flume、Amazon Kinesis等。
Spark Streaming在處理數(shù)據(jù)時,首先Spark接收流式數(shù)據(jù),并將數(shù)據(jù)先按指定的批處理間隔分割為大量的批數(shù)據(jù)。然后通過Spark引擎對每個批進(jìn)行處理,最后將各個批的結(jié)果進(jìn)行匯總,得到最終結(jié)果。處理過程,如圖4所示。
圖4 Spark Streaming處理過程Fig.4 Processing of Spark Streaming
Apache HBase 是一種基于Hadoop 存儲系統(tǒng)的分布式數(shù)據(jù)庫,HBase 利用HDFS 作為底層文件系統(tǒng)和分布式編程框架mapreduce作為實現(xiàn)框架[10]。
HBase數(shù)據(jù)表的基本單元是列族,它由一個或多個列組成。兩個列族,即Column Family 和Column,分別包括列X、Y和列V_x、V_y,如圖5所示。
圖5 HBase存儲模型Fig.5 HBase Storage Model
HBase 能夠提供實時性的查詢需求。Client 通過內(nèi)部緩存的信息定位到與客戶查詢請求相對應(yīng)的Region,首先會根據(jù)查詢需求在Region 的Memstore(內(nèi)存緩沖區(qū))內(nèi)查找,如果查詢到結(jié)果,則將結(jié)果傳出;如果沒有查詢到結(jié)果,將在已持久化的Store-File中繼續(xù)查找。在這種數(shù)據(jù)查詢機(jī)制下,實時的位置數(shù)據(jù)被存放在Region的Memstore中,保證了數(shù)據(jù)查詢的實時性。
Demo 3D是一款能夠?qū)⒛承┱鎸嵨锢硖匦匀诤系缴a(chǎn)仿真中的仿真軟件,相比于國內(nèi)常用的Tecnomatix Plant Simulation、witness等仿真軟件具有更好的視覺效果[11]。畫面在經(jīng)過高清渲染過后,可以生成高質(zhì)量的影像,使動態(tài)仿真模型更加逼真。
Demo 3D提供了大量的設(shè)備模塊的同時也支持導(dǎo)入多種格式的三維模型,并且用戶可以使用面向?qū)ο蟮恼Z言C#、Jscript進(jìn)行開發(fā),這使得編程難度降低、仿真模型的搭建效率大大提升。
卡爾曼濾波器是一種對系統(tǒng)中的未知狀態(tài)進(jìn)行最優(yōu)估計的遞推算法。
預(yù)測階段:
圖6 卡爾曼濾波器工作流程Fig.6 Workflow of Kalman Filter
傳統(tǒng)的卡爾曼濾波器無法直接在Spark Streaming集群中運(yùn)行。本小節(jié)將對卡爾曼濾波器實現(xiàn)基于Spark Streaming集群的多線程設(shè)計。在kafka消息傳輸過程中,kafka的Producer根據(jù)數(shù)據(jù)中標(biāo)簽ID 的不同,將數(shù)據(jù)推送到同一Topic 中相應(yīng)的Parition中。Spark Streaming 作為kafka 中數(shù)據(jù)的消費(fèi)者,通過多線程技術(shù)對同一Topic中不同的parition數(shù)據(jù)進(jìn)行消費(fèi)。每個線程單獨(dú)創(chuàng)建一個KafkaConsumer且只消費(fèi)Kafka中一個Partition隊列中的數(shù)據(jù),如圖7所示。在這種模式下,多個線程被分發(fā)給集群的各個節(jié)點(diǎn)進(jìn)行計算,提高了計算速度。
圖7 消費(fèi)數(shù)據(jù)過程Fig.7 The Process of Consuming Data
線程中的算法步驟如下:
(1)在Kafka 中一個partition 消息隊列中創(chuàng)建一個間隔為1秒的Dstream(key,value)。
(2)調(diào)用轉(zhuǎn)換接口,將Dstream 的格式重寫,形成新的rddqueue。在使用Kafka傳輸數(shù)據(jù)時,數(shù)據(jù)以時間為序列的K-V對形式存在,在本平臺中k為標(biāo)簽ID拼接上系統(tǒng)獲取數(shù)據(jù)的時間,V為x坐標(biāo)與y坐標(biāo)的拼接。例如:Dstream((ID0_time0),”x0#y0”)轉(zhuǎn)化為rddqueue((“ID0_time0”),DenseVector(x0,y0))。
(3)將rddqueue放入到Spark Streaming的流序列中,并對生成的對象運(yùn)用updataStateBykey算子對每條數(shù)據(jù)進(jìn)行計算并將狀態(tài)更新。
(4)創(chuàng)建put對象,將計算結(jié)果放入到HBase數(shù)據(jù)表中。
(5)重復(fù)步驟(1)~步驟(4)。
主要代碼如下:
object KFUpdateFunction{
val updateFunc=(values:Seq[KalmanFilterData],
state:Option[KalmanFilterState])=>{
if(values.length==0){
state
}else{
val x:DenseVector[Double]=values(0).actualState
val z:DenseVector[Double]=values(0).observedState
val prevState=state.getOrElse(new KalmanFilterState())
val NC:Long=prevState.count+values.size
val F:DenseMatrix[Double]=KalmanFilterConstants.F
val GA:DenseVector[Double]=KalmanFilterConstants.GA
val H:DenseMatrix[Double]=KalmanFilterConstants.H
val I=DenseMatrix.eye[Double](4)
val xe= F*prevState.xe+GA
val p=F*prevState.p*F.t+KalmanFilterConstants.Q
val s=H*p*H.t+KalmanFilterConstants.r
val k=p*H.t*inv(s)
val y=z-(H*xe)
val NewXe=xe+(k*y)
val NewP=(I-(k*H))*p
Some(new KalmanFilterState(NC,x,NewXe,NewP))
}
}
}
實驗選自新疆某農(nóng)機(jī)制造企業(yè)的綜合一機(jī)加工車間,長170m、寬72.5m、高11m,實驗環(huán)境為室溫,高干擾噪聲。
通過對車間分析,擬采用5個定位單元,其中包括30個定位節(jié)點(diǎn)和60個標(biāo)簽,在車間進(jìn)行部署。
根據(jù)Ubisense提供的資料,每個標(biāo)簽的位置刷新頻率在(1~40)Hz之間,在實驗車間定位系統(tǒng)中設(shè)置最高的位置刷新頻率并對標(biāo)簽產(chǎn)生的位置數(shù)據(jù)量進(jìn)行統(tǒng)計,如表1所示。
表1 實驗車間的數(shù)據(jù)量統(tǒng)計Tab.1 Data Volume Statistics of the Experimental Workshop
每個標(biāo)簽每秒約產(chǎn)生39 條數(shù)據(jù),60 個標(biāo)簽每分鐘約產(chǎn)生140400條定位數(shù)據(jù),如表1所示。在定位系統(tǒng)中,通過對每個標(biāo)簽與不同實體綁定來獲取實體的位置數(shù)據(jù),由于每個標(biāo)簽是獨(dú)立的,所以獲取的位置數(shù)據(jù)也是獨(dú)立。單機(jī)程序在處理這種多數(shù)據(jù)源且海量數(shù)據(jù)時難以保證數(shù)據(jù)的實時性要求。
在單機(jī)數(shù)據(jù)處理模式下,Java程序?qū)γ總€標(biāo)簽的數(shù)據(jù)流分配一個線程并提交到線程池中,線程池控制工作線程并發(fā)地對不同標(biāo)簽的數(shù)據(jù)進(jìn)行卡爾曼濾波處理。由于單CUP環(huán)境下多線程屬于并發(fā)模式,CPU在不同線程間切換執(zhí)行,并且不同線程需要進(jìn)行大量的數(shù)據(jù)交換和卡爾曼濾波的迭代計算,在標(biāo)簽數(shù)量增加時無法保證數(shù)據(jù)的實時性處理。
由4.1節(jié)可知,每個標(biāo)簽每秒產(chǎn)生39條數(shù)據(jù),人工生成60個標(biāo)簽5分鐘的數(shù)據(jù),每個標(biāo)簽11700條數(shù)據(jù),分別命名為id1、id2...id60。多線程數(shù)據(jù)處理基于Intel(R)Pentium(R)G3260,雙核心雙線程,4G 內(nèi)存。Spark Streaming 基于CPU 為Intel(R)Pentium(R)G3260 三臺機(jī)器搭建的集群。多線程處理方式與Spark Streaming的耗時對比,如圖8所示。
圖8 兩種方案耗時對比Fig.8 Comparison of Time-Consumption Between the Two Schemes
根據(jù)圖8可以看出,隨著標(biāo)簽數(shù)量的增加,耗費(fèi)的時間也增加,當(dāng)標(biāo)簽數(shù)量超過34個時,由于單機(jī)計算機(jī)性能的約束,傳統(tǒng)的多線程方式不能滿足數(shù)據(jù)的實時性。Spark Streaming 通過分布式并行的計算方式,耗費(fèi)的時間遠(yuǎn)小于單機(jī)多線程計算方式。當(dāng)標(biāo)簽數(shù)量達(dá)到60個時,耗時比單機(jī)多線程方式少218.2s。
以不同標(biāo)簽數(shù)量為基礎(chǔ),通過改變集群節(jié)點(diǎn)的數(shù)量分析集群的運(yùn)行時間,如圖9所示。當(dāng)集群中的節(jié)點(diǎn)數(shù)量增加時,不同數(shù)量標(biāo)簽的耗時均有所下降。這說明,當(dāng)標(biāo)簽數(shù)量不斷增加,使當(dāng)前集群的計算性能無法滿足系統(tǒng)的實時性要求時,可以增加集群的節(jié)點(diǎn)數(shù)量。
圖9 集群節(jié)點(diǎn)數(shù)量對數(shù)據(jù)處理效率的影響Fig.9 Effect of Number of Cluster Nodes on Data Processing Efficiency
選擇VMware Workstation Pro 虛擬機(jī)搭建三臺以Centos6.9系統(tǒng)為運(yùn)行環(huán)境的集群,需安裝的組件及版本如下:Hadoop-2.7.7、Zookeeper-3.4.14、Hbase-2.1.7、spark-2.1.1、Kafka、JDK1.8,并以YARN模式運(yùn)行。另在DELL 15-7572筆記本上安裝遠(yuǎn)程控制軟件—SecureCRT和Demo 3D。
平臺搭建過程如下:
(1)根據(jù)車間實際情況和對要素的定位需求布置UWB定位基站位置,節(jié)點(diǎn)布置,如圖10所示。
圖10 實驗路線及節(jié)點(diǎn)布置Fig.10 Experiment Route and Nodes Arrangement
(2)按圖中的位置坐標(biāo),將定位基站安裝在3m高的高腳支架上,傾斜向下。
(3)將標(biāo)簽固定在叉車頂端,減小噪聲對測量的干擾。
(4)使用定位軟件對基站進(jìn)行調(diào)試,并使用AOA、TDOA算法獲取叉車位置信息。
(5)啟動大數(shù)據(jù)集群,對獲取的位置數(shù)據(jù)進(jìn)行實時收集、處理、存儲。
(6)啟動Demo3D仿真軟件,對叉車軌跡進(jìn)行顯示。
在離散制造車間中,由于地面約束的存在,叉車只在二維空間中運(yùn)動,所以本實驗只研究二維的位置坐標(biāo)。在車間中選擇一條叉車頻繁通過的路徑勻速運(yùn)動,如圖10所示。在此條件下將X=[px,py,vx,vy]T作為系統(tǒng)的狀態(tài)變量,其中px、py—叉車的x、y坐標(biāo),vx、vy—x、y軸的速度分量。
狀態(tài)轉(zhuǎn)移矩陣:
式中:Δt—兩次定位的間隔時間。
由于UWB定位系統(tǒng)只能測得標(biāo)簽的位置坐標(biāo),而不能測得標(biāo)簽的運(yùn)動速度,所以,觀測矩陣:
因為卡爾曼濾波器可以不斷的對誤差協(xié)方差矩陣和預(yù)測值進(jìn)行修正,所以對初始值的要求比較寬泛。在這里中,將px0、py0設(shè)置成叉車的初始位置,vx0,vy0為0,誤差協(xié)方差矩陣的初始值:
為叉車行駛時的軌跡對比結(jié)果,如圖11所示。
圖11 結(jié)果對比Fig.11 Comparison of Results
在干擾噪聲較大的離散制造車間,僅使用UWB定位系統(tǒng)獲取的位置點(diǎn)稀疏不均,位置跳動現(xiàn)象嚴(yán)重。再經(jīng)過卡爾曼濾波器處理過之后使得誤差整體降低,整體的軌跡平滑度明顯提升,具有更好的展示效果,如圖11和表2所示。
表2 誤差統(tǒng)計對比Tab.2 Statistical Comparison of Error
利用HBase提供的API接口和TCP技術(shù),將HBase中存儲的位置數(shù)據(jù)傳輸?shù)紻emo 3D 中。Demo 3D 使用C#語言進(jìn)行開發(fā),首先,搭建比例尺為1:1的車間物理模型,保證虛擬車間布局與實際車間相同。
其次,在叉車模型中編寫移動方法。最后,運(yùn)行整體模型,Demo 3D將從HBase中讀取數(shù)據(jù)驅(qū)動叉車模型運(yùn)動;將模型映射在網(wǎng)頁上,當(dāng)鼠標(biāo)點(diǎn)擊叉車時,彈出窗獲得數(shù)據(jù)信息并進(jìn)行可視化展示,如圖12所示。
圖12 叉車定位信息可視化Fig.12 Visualization of Forklift Location Information
(1)這里將車間定位技術(shù)與大數(shù)據(jù)流式計算技術(shù)相結(jié)合,搭建了大數(shù)據(jù)情況下車間位置數(shù)據(jù)收集、處理、存儲系統(tǒng),其可視化效果達(dá)到了預(yù)期。
(2)設(shè)計了基于Spark Streaming的卡爾曼濾波器。在定位標(biāo)簽數(shù)量為60個時,比單機(jī)多線程卡爾曼濾波器耗時少218.2s,其定位精度和軌跡的平滑度均有明顯提高,展示效果更好。
(3)雖然整體大數(shù)據(jù)處理系統(tǒng)能夠達(dá)到預(yù)想要求,但是對性能的優(yōu)化方面尚有不足,沒能發(fā)揮大數(shù)據(jù)技術(shù)的最大潛能。在可視化界面上,交互性能和界面美化較差,是今后改進(jìn)的重點(diǎn)。