基于OPC技術的輪轂裝配線監控系統①

湯亞玲,郭 健,張學鋒,儲岳中

(安徽工業大學 計算機科學與技術學院,馬鞍山 243032)

OPC 通信技術一經問世,就在自動化生產等相關行業掀起了浪潮,其獨特的機制屏蔽了不同種硬件設備之間的差異,全部使用一個標準,使得軟件開發商不再拘泥于各種紛繁雜亂的驅動軟件開發工作,節省了許多開發時間,不同廠商的設備也可以實現互連互訪[1].目前OPC 技術在編程語言開發的軟件中實現方式有很多種,文獻[2]使用Qt 開發OPC 服務器,并利用Matlab 建立Simulink 工程進行仿真模擬,驗證了其可行性.文獻[3]基于C#語言實現了OPC客戶端,詳細地闡述了客戶端的編寫過程,并有具體的代碼實現,為OPC 自動化接口的實現提供了借鑒.如文獻[2,3]等研究基本涵蓋了當下常用的開發環境,對OPC 組件的開發具有一定的指導意義,但主要集中在OPC 服務器或客戶端研究,缺乏對整體過程構建的探討,難以在實際生產中指導上位機程序的編寫.在此情況下,本文提出了一種基于“Qt+KEPServerEX”的OPC 開發方式,以KEPServerEX 作為OPC 服務器,簡化了服務器的開發過程,并使用Qt 將客戶端嵌套進上位機監測系統中,加之一些上位機常用功能模塊,構成一個完整的生產線監測系統,并在一條實際的裝配線中投入使用.

1 技術概述

1.1 OPC 技術簡介

用于過程控制的OLE (OLE for Process Control,OPC)是一種基于Windows 系統的工業自動化標準.它采用C/S 模式[4],簡化了軟、硬件間的通信流程,為應用程序和現場硬件生產設備等架起了橋梁.該技術以微軟的OLE 技術為基礎,跨過TCP 協議層次,在應用層中直接進行數據通訊,客戶程序只需簡單配置客戶端程序,即可訪問OPC 接口中的Server 程序[5],實現與設備之間的交互.

1.2 KEPServerEX 簡介

KEPServerEX是一款服務器軟件,內部已集成OPC標準接口.客戶端程序按照OPC 標準編寫,并和服務器做對應的配置,即可連接KEPServerEX 所建立的服務器.

1.3 PLC 簡介

可編程邏輯控制器(PLC)是一種工業控制微型計算機,其穩定性好、操作靈活,可通過內部預設的各種運算指令等來控制各種類型的設備及生產過程,并進行相關的計算[6].

2 通信過程的構建

2.1 OPC 通信接口選擇

OPC 服務器有兩種接口,如圖1所示.一種是自動化接口,這種自動化接口主要用于VB、C#等編程語言,為這一類可使用自動化對象的程序服務[7].另一種定制接口則為C++等語言服務,定制接口是服務商必須提供的,具有一定的靈活性.Wincc 之類的軟件可以直接通過其內部的OPC Server 接口實現與PLC的通信[8],但是組態軟件價格昂貴,對于一個項目而言是一筆很大的開支.一般項目為了節省成本,采用C++等高級編程語言來實現OPC 通信接口.而在Qt 等C++環境中應用OPC 通信技術,必須引入OPC 基金會提供的文件[9].

圖1 OPC 通信結構圖

系統的核心部分為與PLC的交互部分,數據接收與處理需嚴密及準確,而定制接口可以根據現場需要來定制開發,所以綜合考慮,決定采用定制接口來構建OPC 客戶端.

2.2 數據訪問方式

OPC的數據讀取方式有同步、異步、訂閱式3 種訪問方式.

(1)同步訪問可進行讀、寫操作,其特點是在和OPC 服務器發生數據交互的期間,會阻塞系統線程,直到OPC 數據標簽的讀取或寫入完成后才可繼續執行.適用于標簽數據較少的情況.

(2)異步訪問是把數據交互過程放在服務器端執行,執行期間客戶端程序可以去進行其他工作.當數據交互完成后,服務器會主動觸發客戶端的異步訪問完成事件.該方式在數據標簽量較多和網絡擁堵的情況下執行效率很高.

(3)訂閱式數據采集屬于異步訪問的一種特殊類型.服務器在固定周期內檢查過程數據,如果發現數據變化超過一定范圍,就立刻通知客戶端來接收數據.這種方式可有效降低客戶程序對服務器的重復訪問次數.缺點是不能對服務器進行寫入操作.

一般生產線數據總體產生量較大,并且在運行過程中,經常需要由客戶端向PLC 發送一些數據指令,以完成一些特殊的控制操作,客戶端對服務器的讀寫功能是必要的.綜上所述,異步讀取的方式更加適合本系統.

2.3 KEPServerEX 構建服務器

利用KEPServerEX 搭建OPC 服務器,其核心思想與一般構建服務器的思路基本一致,關鍵點在于創建OPC 服務器的服務器對象(Server)、組對象(Group)、項對象(Item).一個服務器對象可以包含多個組,一個組對象可以包含多個項[10].項是整個通信過程的基本單位,其作用是維護OPC 服務器中與數據有關的信息.組則作為設備的基本單位,提供包容和組織OPC 項對象的機制[11],在實際的生產過程中對應由一臺PLC 上測量產生的所有數據的集合.服務器對象則作為OPC組對象的包容器,通過列舉本地設備上的所有可連接的服務器,對其進行初始化后獲取服務器名稱和唯一標識符.KEPServerEX 在本系統中充當服務器的角色.在KEPServerEX 中,先需要指定設備對應的模型,該模型為設備所使用的PLC 型號,設備驅動選擇當前PLC 以太網網卡驅動,隨后指定一個固定網段(根據交換機劃分)作為設備的唯一ID.LinkType 表示要選擇上位機的類型,有OP、PG、PC 三種類型,其中PG是針對生產線上的工控機使用的連接類型.構建過程如圖2所示.

Tag 作為一個設備的基本單位,對應需要采集的數據信息,由PLC 產生其通訊地址,一個數據變量產生一個地址.如地址“DB14,REAL2”,DB是PLC 數據塊的簡寫,DB14 代表編號為14的PLC 數據塊,而REAL 則是該數據的類型,2 代表則是在該段連續的表示通道結果的地址上的偏移量,隨后依次為通道2、通道3 等.根據PLC 數據塊中產生的變量信息,組合產生數據地址.隨后在KEPServerEX 對應的設備中輸入地址,即可形成與PLC 間的數據通道.數據地址一般由PLC 內部程序的編寫人員以文檔的形式提供,上位機開發人員只需將數據地址與標簽數據對應起來,無需考慮PLC 內部如何設定變量地址.

圖2 KEPServerEX 構建服務器流程圖

2.4 構建OPC 客戶端

OPC 客戶端構建工作主要集中在連接服務器、響應接收、關閉連接3 個部分,具體過程如下:

(1)自定義ConnectedOPC 函數,包含OPCClient.h頭文件,創建了一個客戶端對象,調用成員函數Connect函數進行連接,該函數原型為:HRESULT Connect(QString s).連接成功后,使用HRESULT AddGroup(QString n,DWORD update_rate,int async=1)創建組信息,n為組信息,包含標簽tags,組名的格式一般為“服務器名+組名+數據項”,一個工位的數據為一組.update_rate為數據刷新率,其設置時要保證小于服務器的接收速率.async為訪問方式設定,其值為0 時表示同步方式,值為1 時表示異步方式,缺省值為1,讀寫函數會根據該值來區分調用.之后自定義AddItemwin函數,將所有數據項預先裝入列表中,通過AddItems將數據項添加進服務器,與服務器中添加的tags 對應起來,形成一個與服務器之間進行數據交互的通道,建立連接.

(2)利用Qt 中信號與槽機制,設立信號sg_OnDataChange(OPCHANDLE,DWORD,OPCHANDLE*,VARIANT*,WORD*,FILETIME*,HRESULT*)與接收處理槽函數sl_OnDataChange(OPCHANDLE hGroup,DWORD dwCount,OPCHANDLE *phClientItems,VARIANT *pvValues,WORD *pwQualities,FILETIME*pftTimeStamps,HRESULT *pErrors),該機制中要求信號和槽的參數類型必須保持一致.以槽中參數為例,依次為組、標簽個數、數據項、數據內容、數據質量、時間戳、錯誤信息,其中數據質量代表著數據的可信度,時間戳代表著數據的存取時間,使用VariantString 函數來輸出項目值字符串,函數原型為QString VariantString(VARIANT &pValue),以pvValues[i](0

(3)當完成數據通信后,客戶端資源會隨著程序關閉而釋放.在工位類析構函數中調用Disconnect 函數,該函數會清除通信過程中所有的組、數據項等信息,釋放通信過程中的中間對象等,并置為初始狀態.當客戶端內部對象釋放之后,客戶端對象釋放.

3 上位機基本功能模塊

在接收到PLC的數據后,需先進行數據過濾,否則數據表中會混入一些無效數據.經過濾之后得到的數據一般有以下4 個流向.

3.1 數據存儲模塊

數據匯入數據轉儲模塊中,經過客戶端接收過濾后,直接存儲進MySQL 數據庫中.每個需要存儲數據的工位對應一個數據模型,各自獨立存儲,隨時等待數據到來.而工位類過濾完畢后,將一組數據打包,通過信號發送給對應的模型類.保存之后,在每天固定時間生成備份文件,并按月導出生成數據報表,以便后續查看.

3.2 界面反饋

該模塊主要包含實時數據顯示和CPK 計算兩個子部分.

(1)實時數據顯示:采集的數據需要實時反饋到界面上,方便現場人員的測試與觀察.顯示的內容一般還會包括工位的運行信息,如循環周期、日生產計數、累計生產計數,這些數據由各工位PLC 獨立統計,既可以作為觀測工位運行情況的重要參考,又可以和程序主界面中的時間模塊統計信息一起作為OEE的計算要素.OEE 又稱為設備綜合效率,是從運行情況中的各種時間角度來分析設備運行效率[12],不同的項目根據實際情況決定是否添加OEE 計算模塊.

(2)CPK 計算:CPK 又稱為過程能力指數,是現代企業用于表示制程能力的指標.CPK的標準分為A+至D 五個等級,如表1所示,根據其等級來指導生產線后續生產計劃.

表1 CPK 等級分布及對應原則

CPK 標準的計算公式為:

其中,Cp,Ca分別為制程精準度和制程精確度.取樣的數據至少在20 組以上,這樣計算的結果才具有代表性.計算過程如下:

以X1,…,Xn來表示n個樣本數據,則:

其中,Min函數意為取兩個參數中值較小的那一個作為結果.隨后將計算結果顯示在界面中,并依據結果對生產線進行改進.

3.3 圖表分析

圖表分析模塊可采用外部導入的QCustomPlot 完成.一般情況是對采集的數據進行均值極差圖(Xbar-R)和正態分布圖的繪制,均值極差圖可對采集的連續的數據進行分析,觀察生產情況是否處于控制限中.正態分布圖則可觀察一個階段生產的產品的概率分布,根據分布是否明顯來判斷生產過程的穩定性.

3.4 警報信息記錄及導出

每個工位采集的數據中有一部分是工位報警信息.在工位類中預設報警的內容,并與PLC 發送來的報警標簽進行對應.主界面中應設立相應的報警模塊,每當某個工位的某個預警項收到警告數據時,即顯示該工位為報警狀態,并將警告數據對應的報警信息顯示在該模塊中,統計已發送的警告信息的數量,每天導出文本文檔用作報警日志文件.

4 程序的部署

4.1 生產線結構及服務器部署

本系統部署在某輪轂裝配線的工控機上,同時監控上料、清洗、孔徑檢測、壓裝等11 臺工位,每一臺工位由一個PLC 控制,由兩臺交換機構成生產線網絡.由AGV 小車對輪轂進行運送,機械手臂進行輪轂的上料,完成一圈裝配檢測后,機械手臂將輪轂取下并區分放置,統計合格數與NG 數,發送至本系統用以記錄生產信息,并將質量情況和檢測結束時間導入另一張數據表.KEPServerEX的配置情況如圖3所示,系統的類結構如圖4所示.

圖3 服務器配置情況

圖4 系統類結構圖

PLC 采用SIMATIC S7-1200 型號.S7-1200 設計緊湊、功能強大,市場應用十分廣泛,并且逐漸取代S7-200 等產品[13],其通信能力極強,以太網接口可以實現與S7-200、Wincc,以及一些計算機或顯控面板的OPC 通信.

設備驅動設置為Siemens TCP/IP Ethemet,服務器名預設為“Kepware.KEPServerEX.V5”.系統整體結構如圖5所示.

圖5 系統結構圖

4.2 人機交互界面設計

依據現場提供的裝配線信息和布局情況,在程序中大致建立裝配線的二維模型,每個工位根據實際位置布局分布在模型的對應位置上,可操作區域用特殊顏色標記.整體界面如圖6所示.

圖6 人機交互界面示意圖

4.3 核心分析模塊

系統核心分析模塊主要是針對CPK 值、XBar-R圖、正態分布情況的分析,具體過程如下:

(1)CPK 分析:在系統中通過指定日期間隔來選擇計算區間的數據,從而進行CPK 計算.根據實際的生產情況,初始化孔徑、測筆(位移傳感器)、錐度的USL與LSL:USL(孔徑)=159.915,LSL(孔徑)=159.845,USL(測筆)=37.00,LSL(測筆)=36.85,USL(錐度)=0.1,LSL(錐度)=?0.1.這里主要是對OP103 進行計算,部分參與計算的數據如表2所示,這里總共計算7 個CPK值,由表3的計算結果可以看出,當前103 工位處于A 級,狀態良好.

(2)Xbar-R 圖及正態分布分析:Xbar-R 控制圖是取所有測量數據中心的部分數據來繪制,可以每小時連續取5 個數據,隨著數據的不斷增加,坐標軸會自動進行橫向擴展,動態地展示數據情況.這里圖表分析采用的是實時采集的數據,如圖7所示,可以看出當前測量的數據皆處于控制限中,分布于中心線(CL)兩側.

表2 OP103 部分實際測量數據表

表3 OP103的CPK 計算結果

圖7 OP103的Xbar-R 控制圖

正態分布則是基于公式:

其中,μ為期望值,σ為標準差,對于各個標簽數據進行正態分布分析,觀測其概率分布情況.取當前數據庫中保存的單個標簽的所有數據,代入公式,根據計算結果繪制正態分布圖.103 工位通道1～2(孔徑)正態分布圖如圖8、圖9所示,可以觀察出孔徑1、2 概率分布多數集中于[159.87,159.885]區間之中,生產情況穩定.

5 實驗結果

本系統在卡車輪轂裝配線中部署,成功地與生產線上的11 臺工位通信并交互,部分設備采集數據如圖10、圖11所示,測試過程中發現傳輸延時小于800 ms,可滿足一般生產線的需求.采集之后實時計算數據,并進行相應的分析,結果以文本和數據庫的方式保存下來,或導出為數據報表.該系統經過多次實驗測試、現場對接和修改后,最終形成了穩定版本.目前該系統已經在現場運行了10 個月,在此期間除一些界面設計的問題需要修改,系統主體和功能模塊均無問題.

圖8 孔徑1 正態分布圖

圖9 孔徑2 正態分布圖

圖10 OP103 部分采集數據

圖11 OP107 部分采集數據

6 結束語

本文針對當下OPC 技術在自動化生產線的運用,提出了一種構建完整OPC 通信機制的思路,簡化了通信機制的構建過程,在此基礎上又融合一些在實際生產過程中常用的數據轉儲、分析計算等功能,構成了一個能滿足一般生產線需求的上位機系統,并在實際過程中部署及使用,驗證了該系統通信延時低、穩定性高等特點,為今后上位機監控軟件的編寫提供了一定的借鑒與參考.

下一階段我們的工作主要是以下兩個方面:(1)對系統的性能等問題進行優化;(2)對現有功能模塊進行改進,使其更加方便直觀地反饋信息.