, ,
(華北電力大學(xué) 控制與計(jì)算機(jī)工程學(xué)院,河北 保定 071003)
基于Qt平臺(tái)的OPC服務(wù)器的開發(fā)及仿真應(yīng)用
黎邦騰,梁薇,馬平
(華北電力大學(xué)控制與計(jì)算機(jī)工程學(xué)院,河北保定071003)
OPC(OLE for Process Control)技術(shù)自1996年被提出,就迅速在自動(dòng)化領(lǐng)域得到了廣泛的應(yīng)用;它為工業(yè)控制軟件與硬件之間的交互定義了一個(gè)標(biāo)準(zhǔn)的接口,使得工業(yè)軟件及硬件之間的通訊變得非常便利;針對(duì)這個(gè)特點(diǎn),提出了一種將OPC服務(wù)器作為“中轉(zhuǎn)站”的仿真方案,即兩個(gè)或多個(gè)支持OPC客戶端功能的應(yīng)用程序?qū)PC服務(wù)器作為“中轉(zhuǎn)站”,實(shí)現(xiàn)程序間的相互訪問與控制;采用OPC開發(fā)工具包方式開發(fā)OPC服務(wù)器,并且在Qt平臺(tái)實(shí)現(xiàn);這摒棄了傳統(tǒng)的基于MFC平臺(tái)開發(fā)模式,充分利用了Qt在界面設(shè)計(jì)上的優(yōu)勢;最后利用Matlab建立了兩個(gè)Simulink工程作為OPC客戶端進(jìn)行仿真測試,實(shí)現(xiàn)了兩個(gè)客戶端之間通過“中轉(zhuǎn)站”完成信息交互;測試結(jié)果控制效果與預(yù)期一致,驗(yàn)證了本方案的可行性。
OPC服務(wù)器;OPC開發(fā)工具包;Qt平臺(tái);仿真測試;OPC客戶端
隨著計(jì)算機(jī)技術(shù)和自動(dòng)機(jī)技術(shù)的迅猛發(fā)展,越來越多的智能設(shè)備應(yīng)用到了工業(yè)現(xiàn)場中,給我們提供了更多的現(xiàn)場信息。但是,在這種需求下,一個(gè)控制系統(tǒng)可能包含幾十種或者更多的來自不同廠商的智能設(shè)備,這些設(shè)備遵循各自通訊規(guī)范,只能與特定的應(yīng)用軟件通訊,使得計(jì)算機(jī)內(nèi)部應(yīng)用程序與現(xiàn)場設(shè)備之間進(jìn)行信息溝通和傳遞變得非常困難[1-2]。正是在這種背景下,一個(gè)工業(yè)標(biāo)準(zhǔn) OPC技術(shù)規(guī)范被制定了出來[3]。OPC技術(shù)在應(yīng)用程序與設(shè)備之間建立起了一道橋梁,使得各工控軟件之間的信息交互非常方便,極大的提高了系統(tǒng)的互操作性和適應(yīng)性。本文提出了一種將OPC服務(wù)器作為“中轉(zhuǎn)站”的仿真方案,即通過OPC技術(shù)實(shí)現(xiàn)不同應(yīng)用程序之間的相互訪問與相互控制。因此,該文首先介紹了一種在OPC開發(fā)工具包WTOPCSvr.DLL的基礎(chǔ)上開發(fā)OPC服務(wù)器軟件的方法。
傳統(tǒng)上的OPC服務(wù)器或者客戶端主要基于MFC實(shí)現(xiàn)。MFC執(zhí)行代碼效率高,并且目前技術(shù)也比較成熟,但是它固有的架構(gòu)使得MFC去實(shí)現(xiàn)一個(gè)相對(duì)美觀靈活的用戶界面就會(huì)變得很繁瑣。因此,該軟件采用Qt實(shí)現(xiàn),摒棄了傳統(tǒng)的MFC平臺(tái)開發(fā)模式,充分的利用了Qt在界面開發(fā)上的優(yōu)勢。最后,利用matlab建立了兩個(gè)simulink工程作為OPC客戶端進(jìn)行仿真測試,驗(yàn)證了利用OPC服務(wù)器作為中轉(zhuǎn)站,實(shí)現(xiàn)不同應(yīng)用程序之間相互訪問和控制這個(gè)方案的可行性。
OPC是一個(gè)工業(yè)標(biāo)準(zhǔn),它采C/S模式,即OPC服務(wù)器與硬件通訊由廠商負(fù)責(zé),工業(yè)軟件通過OPC客戶端與OPC服務(wù)器建立連接,而不再與設(shè)備直接通訊,把軟、硬件開發(fā)徹底分開。這樣,一方面硬件開發(fā)商僅僅需要將硬件設(shè)備驅(qū)動(dòng)程序和通信程序封裝成獨(dú)立的OPC服務(wù)器,當(dāng)硬件升級(jí)時(shí)只需要更新對(duì)應(yīng)的驅(qū)動(dòng)程序,而不會(huì)對(duì)OPC接口產(chǎn)生任何影響。另一方面應(yīng)用程序軟件開發(fā)商不必關(guān)心設(shè)備與OPC服務(wù)器如何通信及通訊接口之間的兼容性問題,他們只需要遵循OPC數(shù)據(jù)協(xié)議,開發(fā)相應(yīng)OPC客戶端就能從OPC服務(wù)器獲取相應(yīng)的數(shù)據(jù)[4]。圖1所示為采用OPC技術(shù)之后工業(yè)控制軟件與硬件設(shè)備之間的通訊框架示意圖。
圖1 工業(yè)控制軟件與硬件設(shè)備之間的通訊框架
為了滿足多種系統(tǒng)和設(shè)備之間的通信需求,OPC定義了一系列規(guī)范,如OPC數(shù)據(jù)存取(data access)規(guī)范、OPC報(bào)警與事件(alarm and event)規(guī)范和OPC歷史數(shù)據(jù)存取(historical data access)規(guī)范等。不同類型的服務(wù)器和客戶端程序?qū)?yīng)不同的規(guī)范,本文主要介紹OPC數(shù)據(jù)存儲(chǔ)規(guī)范和數(shù)據(jù)存取服務(wù)器的開發(fā)[5]。
OPC數(shù)據(jù)存取規(guī)范是OPC基金會(huì)針對(duì)現(xiàn)場設(shè)備的在線數(shù)據(jù)存取制定的一個(gè)工業(yè)標(biāo)準(zhǔn),它主要定義了OPC DA Sever (數(shù)據(jù)存取服務(wù)器)。OPC DA Server主要由3個(gè)對(duì)象組成:服務(wù)器對(duì)象(server object)、組對(duì)象(group object)和項(xiàng)對(duì)象(item object)[6]。圖2所示為OPC DA Server的組成模型。
圖2 OPC DA Server的組成模型
如圖2所示,OPC服務(wù)器對(duì)象管理服務(wù)器的所有組信息,它是OPC組對(duì)象的包容器,能夠完成組對(duì)象的添加和釋放。在一個(gè)OPC服務(wù)器對(duì)象中,允許包含一個(gè)或者多個(gè)OPC組對(duì)象。OPC組對(duì)象管理本組的所有信息,并提供了組織和管理項(xiàng)的機(jī)制,從邏輯上實(shí)現(xiàn)對(duì)OPC 項(xiàng)對(duì)象的管理。OPC組包含Name(組的名字),Active(組的激活狀態(tài)標(biāo)志),Update Rate(刷新速率)和Percent Deadband (數(shù)據(jù)死區(qū))。客戶端程序可以設(shè)置組對(duì)象的死區(qū)、刷新頻率和需要組織的項(xiàng)。OPC項(xiàng)對(duì)象表示了OPC服務(wù)器到數(shù)據(jù)源的連接,它是讀寫數(shù)據(jù)的最小邏輯單位,它包括了值、品質(zhì)、時(shí)間戳3個(gè)基本屬性。其中,數(shù)據(jù)值以 Variant 形式表示,品質(zhì)代表了數(shù)值的可信度,時(shí)間戳則代表了數(shù)據(jù)的存取時(shí)間[2]。OPC項(xiàng)對(duì)象不能直接被訪問,所有對(duì)OPC項(xiàng)的操作都需要通過該項(xiàng)隸屬的組來完成。
目前,OPC服務(wù)器開發(fā)主要有通過MFC提供的COM支持開發(fā)OPC服務(wù)器、通過ATL開發(fā)OPC服務(wù)器和通過開發(fā)工具開發(fā)OPC服務(wù)器3種方式。
MFC采用面向?qū)ο蟮姆绞綄OM的基本功能封裝在若干的C++類中,能夠深入的掌握 COM 內(nèi)部技術(shù)細(xì)節(jié)等特點(diǎn)。但是要從底層開始編寫代碼,工作量大,工程也非常復(fù)雜。ATL 同樣需要對(duì) COM 機(jī)制有非常深入的理解。因此,不管MFC還是ATL,都會(huì)使得整個(gè)開發(fā)過程變得異常困難,不易實(shí)現(xiàn)。本文采用的是第三種方法,通過工具開發(fā)OPC服務(wù)器。它大大簡化了OPC服務(wù)器的開發(fā)過程,縮短開發(fā)周期,開發(fā)人員不用了解COM知識(shí)和OPC規(guī)范,僅僅需要調(diào)用相應(yīng)的API函數(shù)就能完成OPC服務(wù)器的開發(fā)[7]。
軟件基于VS2010+Qt平臺(tái)實(shí)現(xiàn),摒棄了傳統(tǒng)的MFC開發(fā)模式,充分發(fā)揮了Qt在界面設(shè)計(jì)上的優(yōu)勢。Qt是一個(gè)跨平臺(tái)C++圖形用戶界面應(yīng)用程序開發(fā)框架,建立了信號(hào)(SIGNAL)和槽(SLOT)機(jī)制。利用SIGNAL可以實(shí)現(xiàn)任意參數(shù)的傳遞,這與MFC中紛繁蕪雜的消息相比,Qt對(duì)事件的處理更加的自由靈活。在界面處理上,Qt完全從MFC的各種條條框框束縛解放出來,可以靈活地使用視圖和組織控件。
軟件是在WTOPCSvr.DLL工具包的基礎(chǔ)上完成的,WTOPCSvr.DLL是以DLL形式提供的一個(gè)OPC服務(wù)器快速開發(fā)工具。WTOPCSvr.DLL將COM和OPC處理的所有細(xì)節(jié)封裝起來,用戶不用去關(guān)心底層接口的實(shí)現(xiàn),僅僅通過調(diào)用幾個(gè)API函數(shù)就能快速地開發(fā)出自己的OPC服務(wù)器[8]?;谶@個(gè)平臺(tái),使得整個(gè)OPC開發(fā)過程就變得非常簡單。整個(gè)OPC服務(wù)器的系統(tǒng)框架如圖3所示。
圖3 OPC服務(wù)器開發(fā)系統(tǒng)框架
因?yàn)樵撥浖?cè)重點(diǎn)是建立一個(gè)“中轉(zhuǎn)站”,實(shí)現(xiàn)兩個(gè)OPC客戶端之間的通信。因此,并不需要考慮服務(wù)器對(duì)象接口與設(shè)備驅(qū)動(dòng)部分,所有數(shù)據(jù)的交換都是兩個(gè)客戶端之間發(fā)起的。當(dāng)OPC服務(wù)器起來完成初始化后,用戶就可以創(chuàng)建相應(yīng)的標(biāo)簽,不同的OPC客戶端通過訪問該服務(wù)器,就可以實(shí)現(xiàn)兩個(gè)客戶端之間的信息交互。
2.3.1 OPC服務(wù)器核心功能實(shí)現(xiàn)
OPC服務(wù)器的開發(fā)主要有以下主要步驟:
1) 調(diào)用UpdateRegistry注冊(cè)O(shè)PC服務(wù)器。
該函數(shù)的原型是:BOOL WINAPI UpdateRegistry (BYTE *pCLSID_Svr, LPCSTR Name, LPCSTR Descr, LPCSTR ExePath),其中參數(shù)pCLSID_Svr是服務(wù)器的類標(biāo)識(shí),這是唯一的。參數(shù)Name指定了服務(wù)器的名稱。參數(shù)Descr是對(duì)服務(wù)器的描述,而參數(shù)ExePath則定義了可執(zhí)行程序的完整路徑。
2)調(diào)用InitWTOPCsvr完成開發(fā)包初始化。
該函數(shù)原型:BOOL WINAPI InitWTOPCsvr (BYTE *pCLSID_Svr, UINT ServerRate),其中參數(shù)pCLSID_Svr含義同上,參數(shù)ServerRate定義了客戶的數(shù)據(jù)刷新速率,單位是毫秒。該函數(shù)實(shí)現(xiàn)了對(duì)DCOM的初始化和OPC服務(wù)器對(duì)象的創(chuàng)建。
3)注冊(cè)回調(diào)函數(shù)。
WTOPCSvr.DLL為用戶提供了很多回調(diào)函數(shù),方便服務(wù)器與客戶端之間的事件處理。當(dāng)特定的事件或者調(diào)解發(fā)生時(shí),服務(wù)器及時(shí)響應(yīng)客戶端的操作,這是非常方便的。以函數(shù)EnableWriteNotification為例。
該函數(shù)原型: BOOL WINAPI EnableWriteNotification (WRITENOTIFYPROC lpCallback, BOOL ConvertToNativeType)。這個(gè)函數(shù)定義了當(dāng)OPC客戶端些一個(gè)已定義的標(biāo)簽時(shí),函數(shù)會(huì)產(chǎn)生一個(gè)來自DLL的調(diào)用返回。展開類型WRITENOTIFYPROC的定義:typedef VOID (CALLBACK* WRITENOTIFYPROC)(HANDLE, VARIANT*, DWORD*)。它實(shí)際定義了一個(gè)函數(shù)指針,用戶調(diào)用EnableWriteNotification函數(shù)傳入對(duì)應(yīng)函數(shù)的指針,當(dāng)客戶端修改標(biāo)簽時(shí),會(huì)立即響應(yīng)該函數(shù),服務(wù)器可以對(duì)事件進(jìn)行處理。
4)創(chuàng)建標(biāo)簽和移除標(biāo)簽。
完成相應(yīng)的準(zhǔn)備工作后,就可以調(diào)用CreateTag函數(shù)創(chuàng)建標(biāo)簽了。
該函數(shù)原型:HANDLE WINAPI CreateTag (LPCSTR Name, VARIANT Value, WORD InitialQuality, BOOL IsWritable)。其中參數(shù)Name指定了創(chuàng)建的點(diǎn)名,它可以是任何文本字符串,也可以使用分層名字,中間用“.”分隔,如group.item。前者屬于扁平結(jié)構(gòu),后者屬于多層結(jié)構(gòu)。參數(shù)Value定義了標(biāo)簽的初始值,參數(shù)InitialQuality則定義了標(biāo)簽的屬性,參數(shù)IsWritable指定了標(biāo)簽是否可寫。標(biāo)簽一旦被創(chuàng)建,它就能夠在任何一個(gè)客戶端中參數(shù)列表中被檢索到。
與CreateTag相對(duì)應(yīng)的就有RemoveTag函數(shù),它用于標(biāo)簽的移除。其函數(shù)原型:BOOL WINAPI RemoveTag (HANDLE TagHandle),參數(shù)TagHandle是一個(gè)句柄,即調(diào)用CreateTag創(chuàng)建標(biāo)簽時(shí)返回的句柄。值得注意的是,標(biāo)簽被移除后,該標(biāo)簽就不能夠在客戶端的參數(shù)列表中檢索到了,但是已連接的這個(gè)標(biāo)簽仍然有效,只不過沒有新的數(shù)據(jù)來刷新該標(biāo)簽了。對(duì)于標(biāo)簽操作比較重要的API函數(shù)還有UpdateTag、UpdateTag-WithTimeStamp等,這里就不再一一介紹。
5)注銷及關(guān)閉服務(wù)器。
服務(wù)器注銷需要調(diào)用輔助函數(shù)NumbrClientConnections獲得當(dāng)前連接到服務(wù)器的客戶數(shù),在有客戶端連接的情況下,服務(wù)器應(yīng)該不允許被注銷。只有在服務(wù)器需要關(guān)閉時(shí),程序才會(huì)調(diào)用RequestDisconnect函數(shù)請(qǐng)求所有客戶端斷開連接。最終服務(wù)器調(diào)用函數(shù)UnregisterServer 完成注銷。該函數(shù)原型:BOOL WINAPI UnregisterServer (BYTE *pCLSID_Svr, LPCSTR Name),其中參數(shù)pCLSID_Svr、Name均與UpdateRegistry函數(shù)中的pCLSID_Svr、Name一致。在關(guān)閉服務(wù)器時(shí)還需要調(diào)用UninitWTOPCsvr函數(shù),完成資源的釋放。
2.3.2 OPC服務(wù)器界面實(shí)現(xiàn)
OPC服務(wù)器界采用Qt實(shí)現(xiàn)。Qt引入了模型/視圖框架完成數(shù)據(jù)與表現(xiàn)的分離,這來源與經(jīng)典的MVC三層結(jié)構(gòu)。M即模型(Model),表示數(shù)據(jù);V即視圖(View),表示用戶界面;C即控制(Controller),定義了用戶在界面上的操作。通過使用MVC模式,有效地分離了數(shù)據(jù)和用戶界面,使得設(shè)計(jì)更加的靈活。而在Qt中,應(yīng)該叫“MVD”模式了。在Qt中沒有Controller的說法,而是使用了代理(delegate)概念。通過使用代理,能夠自定義數(shù)據(jù)條目的顯示和編輯方式。其結(jié)構(gòu)如圖4所示[9]。
圖4 “MVD”模式結(jié)構(gòu)
這種模式使得用戶對(duì)數(shù)據(jù)的處理變得非常方便。用戶可以自己定義模型,對(duì)數(shù)據(jù)進(jìn)行靈活的處理,當(dāng)?shù)讓訑?shù)據(jù)源發(fā)生改變,只需要處理Model就可以了。
該軟件界面正是基于此種模式完成。用戶進(jìn)行添加、修改、刪除對(duì)應(yīng)標(biāo)簽后,程序通知Model數(shù)據(jù)發(fā)生變化,從而迅速更新內(nèi)部數(shù)據(jù)存儲(chǔ),然后發(fā)出信號(hào)通知View數(shù)據(jù)改變。在模型中的條目有不同的角色,這樣可以在不同的情況下提供不同的數(shù)據(jù)。該軟件中視圖中行顏色交替的變化正是修改了Qt::BackgroundRole角色。如圖5所示是該軟件的最終顯示界面。
圖5 軟件界面
圖6 PID控制組
圖7 控制對(duì)象組
程序首先使用QLocalSocket了保證在一臺(tái)機(jī)器上只允許運(yùn)行一個(gè)實(shí)例。然后啟動(dòng)定時(shí)器,實(shí)時(shí)刷新數(shù)據(jù)列表,更新當(dāng)前客戶端的連接狀態(tài)。最后通過API注冊(cè)了相應(yīng)的回調(diào)函數(shù),積極響應(yīng)客戶端的操作,及時(shí)更新服務(wù)器界面狀態(tài)。當(dāng)用戶操作或者客戶端的操作引起數(shù)據(jù)變化時(shí),Model會(huì)立即通知View更新視圖狀態(tài)。
基于此界面,用戶能夠?qū)崿F(xiàn)服務(wù)器注冊(cè)、服務(wù)器注銷、添加參數(shù)、修改參數(shù)和刪除參數(shù)等功能,非常便利。
為了驗(yàn)證本OPC服務(wù)器的功能,我們選取了某300 MW熱電機(jī)組主汽溫控制系統(tǒng)進(jìn)行測試[9]。系統(tǒng)導(dǎo)前氣溫控制對(duì)象為:
主汽溫控制對(duì)象為:
采用串級(jí)控制系統(tǒng),主、副控制器均使用PI控制。分別取δ1=1.51,Ti=202,δ2=0.55,Ti=48.6,利用simulink搭建仿真平臺(tái)如圖6、圖7所示。
其中圖6為PID控制組,圖7為控制對(duì)象組,PID控制器與控制對(duì)象的交互通過OPC服務(wù)器完成。整個(gè)測試步驟如下:
1)啟動(dòng)OPC服務(wù)器,分別添加浮點(diǎn)型標(biāo)簽Group0.e1,Group0.e2,Group0.u1和Group0.u2作為兩個(gè)PID控制器的輸入輸出。
2)在PID控制器組添加OPC讀寫模塊,并且分別設(shè)定PID控制器1的輸入讀取的是標(biāo)簽Group0.e1的值,輸出寫入到標(biāo)簽Group0.u1中;PID控制器2的輸入讀取的是標(biāo)簽Group0.e2的值,輸出寫入到標(biāo)簽Group0.u2中。同時(shí)設(shè)定兩個(gè)OPC讀取模塊的采樣時(shí)間和simulink仿真步距均為3 s,保證仿真的實(shí)時(shí)性。
3)同理,往控制對(duì)象組添加OPC讀寫模塊,并與對(duì)應(yīng)的標(biāo)簽綁定。
4)設(shè)定仿真時(shí)間為1 500 s,運(yùn)行仿真程序。
如圖8所示可以看到,當(dāng)前OPC服務(wù)器狀態(tài)欄顯示有2個(gè)客戶端連接,即PID控制器組和控制對(duì)象組,消息對(duì)話框準(zhǔn)確地打印我們的操作記錄。
圖8 服務(wù)器界面
等待1 500 s,程序運(yùn)行結(jié)束,最終仿真結(jié)果如圖9所示。
圖9 仿真結(jié)果
可以看到,在PID控制作用下,導(dǎo)前氣溫與主汽溫在1 100 s左右趨于穩(wěn)定,主汽溫達(dá)到了期望值。這與實(shí)際情形相符,驗(yàn)證了本方案的可行性。
OPC技術(shù)為設(shè)備集成提供了一個(gè)新的解決方案,它把硬件供應(yīng)商和應(yīng)用軟件開發(fā)者分離開了,大大簡化了設(shè)備之間的復(fù)雜通訊過程。本文簡單介紹了OPC技術(shù),詳細(xì)的分析了基于WTOPCSvr.DLL 工具包開發(fā)OPC服務(wù)器的過程,并結(jié)合Qt在界面設(shè)計(jì)上的優(yōu)勢,開發(fā)了一款用戶界面友好的OPC服務(wù)器,提出了一個(gè)將OPC服務(wù)器作為中轉(zhuǎn)站,實(shí)現(xiàn)OPC客戶端之間的通訊方案。本文最后給出了該OPC服務(wù)器在仿真上的應(yīng)用,驗(yàn)證了方案的可行性。同樣,在完成相應(yīng)的COM配置后,利用OPC的遠(yuǎn)程訪問功能,就可以實(shí)現(xiàn)兩臺(tái)計(jì)算機(jī)中任意支持OPC客戶端服務(wù)的應(yīng)用軟件之間的相互通訊。接下來,為OPC服務(wù)器完善更多的功能,如實(shí)現(xiàn)歷史數(shù)據(jù)查詢,歷史或?qū)崟r(shí)曲線查看及支持參數(shù)越限報(bào)警等諸多功能將是下一步研究的方向。相信隨著OPC 技術(shù)的推廣和應(yīng)用, OPC技術(shù)必將會(huì)被應(yīng)用到更加廣泛的領(lǐng)域。
[1] 朱耀春, 陸會(huì)明, 張永慶. OPC數(shù)據(jù)服務(wù)器的開發(fā)與測試[J]. 現(xiàn)代電力, 2003, 20(6): 63-66.
[2] 鄒云濤, 吳重光. OPC技術(shù)初探及國內(nèi)應(yīng)用現(xiàn)狀[J]. 石油化工自動(dòng)化, 2003(6): 1-5.
[3] 戚中奎, 林果園, 孫統(tǒng)風(fēng). OPC數(shù)據(jù)訪問服務(wù)器的研究與實(shí)現(xiàn)[J]. 計(jì)算機(jī)工程與設(shè)計(jì), 2011, 32(4): 1517-1520.
[4] 紀(jì)強(qiáng)君, 唐秀昆, 曹長修. 基于Visual C++的OPC客戶端實(shí)現(xiàn)[J]. 計(jì)算機(jī)應(yīng)用, 2007, 26(4): 70-73.
[5] 凌志浩, 陳偉彬, 馬 欣,等. 基于OPC數(shù)據(jù)存取規(guī)范的服務(wù)器研究與實(shí)現(xiàn)[J]. 華東理工大學(xué)學(xué)報(bào), 2004, 30(3): 318-321.
[6] 張慶軍. OPC及OPC服務(wù)器的設(shè)計(jì)與實(shí)現(xiàn)[A]. 智能檢測控制技術(shù)及儀表裝置發(fā)展研討會(huì)論文集[C]. 上海: 上海自動(dòng)化儀表股份有限公司技術(shù)中心, 2007.
[7] 王 平, 李大慶, 王 颋. OPC服務(wù)器開發(fā)工具包軟件的設(shè)計(jì)與實(shí)現(xiàn)[J]. 計(jì)算機(jī)工程, 2009, 35(22): 275-277.
[8] 陳丹丹, 錢 美, 夏 立, 等. OPC服務(wù)器開發(fā)的幾種方法[J]. 微計(jì)算機(jī)信息, 2006,22(6): 28-29.
[9] 蔡志明, 盧傳富, 李立夏,等. 精通Qt 4編程[M]. 北京:電子工業(yè)出版社, 2008.
[10] 韓 璞, 董 澤, 王東風(fēng),等.智能控制理論與應(yīng)用[M]. 北京:中國電力出版社, 2012.
[11] 劉暾東, 余齊齊, 柳小鵬. OPC服務(wù)器軟件開發(fā)及在DCS中的應(yīng)用[J]. 化工自動(dòng)化及儀表, 2007, 34(1): 46-48.
[12] 喬加新. OPC客戶端與OPC服務(wù)器的交互方式的研究[J]. 信息技術(shù), 2005(8): 122-124.
[13] 張 河, 魯五一. OPC客戶端與實(shí)時(shí)數(shù)據(jù)庫通信的實(shí)現(xiàn)[J]. 計(jì)算機(jī)工程與科學(xué), 2008, 30(5): 81-83.
[14] 王 杰, 高昆侖, 朱曉東. OPC通訊技術(shù)在可視化界面監(jiān)控系統(tǒng)中的應(yīng)用研究[J]. 計(jì)算機(jī)測量與控制, 2012, 20(1): 74-77.
[15] 李安伏, 崔亞量.基于OPC的Matlab與組態(tài)王的數(shù)據(jù)通信[J]. 電力自動(dòng)化設(shè)備, 2007, 27(7): 113-115.
[16] 胡開明, 傅志堅(jiān), 葛遠(yuǎn)香. 基于OPC與組態(tài)技術(shù)的自動(dòng)控制實(shí)驗(yàn)教學(xué)仿真平臺(tái)開發(fā)[J]. 實(shí)驗(yàn)技術(shù)與管理, 2013, 30(6): 50-53.
[17] 李二超, 李 煒, 李戰(zhàn)明,等. 基于OPC技術(shù)的網(wǎng)絡(luò)控制系統(tǒng)仿真平臺(tái)設(shè)計(jì)[J]. 實(shí)驗(yàn)技術(shù)與管理, 2012, 29(6): 90-93.
DevelopmentandSimulationApplicationofOPCServerBasedonQtPlatform
Li Bangteng, Liang Wei, Ma Ping
(School of Control and Computer Engineering, North China Electric Power University, Baoding 071003,China)
OPC(OLE for Process Control) technology has been widely used in the field of automation since it was put forward in 1996. It defines a standard interface for the interaction between industrial control software and hardware, which makes the communication very convenient. For this feature, a scheme of OPC server as “transfer station” is proposed, that is, two or more applications that support OPC client functionality consider the OPC server as a “transfer station” to implement mutual access and control between programs. The development of OPC server uses the way of OPC development toolkit, and it is implemented on Qt platform. It makes full use of the advantages of Qt in the interface design, abandoning the traditional MFC platform development mode. Finally, in order to demonstrate the function of two clients completing the information interaction through the “transfer station”, we use matlab to build a two simulink project as an OPC client for simulation testing. The test results are consistent with the expected results, which verify the feasibility of the program.
OPC servers; OPC development kit; Qt platform; simulation testing; OPC client
2017-04-18;
2017-05-23。
黎邦騰(1991-),男,湖南郴州人,碩士研究生,主要計(jì)算機(jī)應(yīng)用方向的研究。
馬 平(1961-),女,湖南長沙人,教授,碩士研究生導(dǎo)師,主要從事計(jì)算機(jī)原理及應(yīng)用方向的研究。
1671-4598(2017)11-0154-05
10.16526/j.cnki.11-4762/tp.2017.11.039
TP311
A