船舶數(shù)字化儀控系統(tǒng)的OPC技術(shù)應(yīng)用研究＊

陽世榮 夏 偉 寧 鷗

（中國艦船研究與設(shè)計中心 武漢 430064）

1 引言

隨著計算機技術(shù)、自動控制技術(shù)及信息技術(shù)的高速發(fā)展，儀控系統(tǒng)已經(jīng)從傳統(tǒng)的單機分散監(jiān)控階段、模擬式集中監(jiān)控階段跨進了數(shù)字化網(wǎng)絡(luò)化時代[1～2]?，F(xiàn)代高性能船舶的數(shù)字化儀控系統(tǒng)廣泛應(yīng)用網(wǎng)絡(luò)通信技術(shù)[3～4]，通過雙冗余工業(yè)以太網(wǎng)將各現(xiàn)場控制設(shè)備與控制室內(nèi)的綜合顯控臺連接起來，由通信程序軟件來實現(xiàn)信息交互，大大減少了現(xiàn)場控制設(shè)備到控制室的連接電纜，簡化儀控系統(tǒng)的架構(gòu)體系，提高了系統(tǒng)集成度，更有利于提升儀控系統(tǒng)綜合自動化水平，也便于進行系統(tǒng)維護和升級擴展。

船舶數(shù)字化儀控系統(tǒng)內(nèi)部包含了大量的現(xiàn)場控制設(shè)備，這些設(shè)備大都通過網(wǎng)絡(luò)接口與儀控系統(tǒng)通信網(wǎng)絡(luò)連接。由于現(xiàn)場控制設(shè)備往往是由不同的廠商供貨，種類品牌各異，為了實現(xiàn)在同一網(wǎng)絡(luò)平臺上的集成通信，傳統(tǒng)的做法是，硬件供應(yīng)商提供控制設(shè)備的通信驅(qū)動程序，由儀控系統(tǒng)的綜合顯控臺調(diào)用各控制設(shè)備的通信驅(qū)動程序?qū)崿F(xiàn)網(wǎng)絡(luò)通信，其通信架構(gòu)如圖1所示。

在這種情況下，儀控系統(tǒng)軟件設(shè)計的大量工作都集中在通信驅(qū)動程序應(yīng)用開發(fā)方面；即使現(xiàn)場控制設(shè)備的硬件有了一點小小的變動，通信驅(qū)動程序就可能需要重寫，相應(yīng)的綜合顯控臺通信軟件也需要修改；不同控制設(shè)備都對應(yīng)不同的通信驅(qū)動程序，隨著儀控系統(tǒng)規(guī)模的增大，通信軟件的版本控制及管理也日益繁瑣；如果要進行系統(tǒng)升級和功能擴展，所帶來的軟硬件開發(fā)工作量則更大。因此，這種傳統(tǒng)的通信技術(shù)方案仍然無法消除數(shù)字化儀控系統(tǒng)內(nèi)部不同廠商硬件設(shè)備之間的通信壁壘，在某種程度上甚至阻礙了數(shù)字化儀控系統(tǒng)的技術(shù)發(fā)展。鑒于上述現(xiàn)狀，本文介紹了一種基于OPC（OLE for Process Control）技術(shù)的通信解決方案，通過制定統(tǒng)一的接口規(guī)范，能夠較好地解決數(shù)字化儀控系統(tǒng)面臨的通信壁壘問題。

圖1 傳統(tǒng)的通信架構(gòu)

2 OPC技術(shù)的基本原理

OPC（OLE for Process Control）是一套工業(yè)標準，為基于Windows平臺的應(yīng)用程序與現(xiàn)場控制設(shè)備之間建立了溝通橋梁[5]。OPC以 OLE／COM／DCOM 技術(shù)為基礎(chǔ)，采用客戶端／服務(wù)器模式[6]，能夠為上位機應(yīng)用軟件提供統(tǒng)一通用的接口，實現(xiàn)與各種不同類型控制設(shè)備之間的通信，而不必考慮各個通信節(jié)點的具體硬件信息[7]。因此，應(yīng)用OPC技術(shù)后，數(shù)字化工業(yè)控制系統(tǒng)的軟件開發(fā)者可以免除繁重的通信驅(qū)動程序開發(fā)工作，而把更多的精力投入到系統(tǒng)邏輯核心軟件開發(fā)上。如此一來，不但可以避免開發(fā)工作的重復(fù)性，也提高了系統(tǒng)的開發(fā)性和可互操作性，特別適合于大規(guī)模的數(shù)字化工業(yè)控制系統(tǒng)。

一個OPC數(shù)據(jù)服務(wù)器由三類對象組成，即：服 務(wù) 器 （Server）、組（Group）、數(shù)據(jù)項（Item），其基本原理如圖2所示。其中，OPC數(shù)據(jù)項是OPC服務(wù)器端定義的對象，對應(yīng)于現(xiàn)場控制設(shè)備（比如PLC控制器）的一個寄存器單元[8]。OPC客戶端對現(xiàn)場控制設(shè)備寄存器的讀寫操作正是通過OPC服務(wù)器的數(shù)據(jù)項來完成的。但是，OPC數(shù)據(jù)項并不提供對外接口，OPC客戶端不能直接對數(shù)據(jù)項進行操作，所有操作都必須通過服務(wù)器對象、組對象進行。

如圖3、圖4所示，一個OPC客戶端可以連接一個或多個OPC服務(wù)器，而多個OPC客戶端也可以同時連接一個OPC服務(wù)器，各個OPC客戶端通過OPC標準接口對各個OPC服務(wù)器對應(yīng)的現(xiàn)場控制設(shè)備進行操作，而不需關(guān)心服務(wù)器的實現(xiàn)細節(jié)以及控制設(shè)備內(nèi)部的具體細節(jié)。

因此，相對于傳統(tǒng)的通信連接方式（如圖1所示），基于OPC的通信連接方式（如圖3、圖4所示）結(jié)構(gòu)更加簡單，大大提升了系統(tǒng)的開放性和可互操作性。

圖2 OPC基本原理圖

圖3 基于專用OPCServer的通信連接方式

圖4 基于通用OPCServer的通信連接方式

3 數(shù)字化儀控系統(tǒng)架構(gòu)

數(shù)字化儀控系統(tǒng)在邏輯上從下至上劃分為三個層次，即為設(shè)備層、控制層和管理層。下層的設(shè)備為上層提供服務(wù)，同時接受來自上層設(shè)備的控制與管理。但是，各層之間又相對獨立、各司其職，當上一層設(shè)備或網(wǎng)絡(luò)故障時，下一層的設(shè)備可相對獨立地并行工作，確保儀控系統(tǒng)的可靠性。其基本的系統(tǒng)架構(gòu)圖如圖5所示。

圖5中，控制室內(nèi)的綜合顯控臺是管理層的核心，承擔著全系統(tǒng)綜合監(jiān)控及運行管理的重任?？刂茖拥目刂乒駥崿F(xiàn)設(shè)備層眾多傳感器、執(zhí)行器的集成連接。由于儀控系統(tǒng)設(shè)備層的傳感器、執(zhí)行器數(shù)量眾多，技術(shù)水平也參差不齊，因此控制柜提供了硬接線直連和現(xiàn)場總線連接兩種方式。對于非智能傳感器、執(zhí)行器集中的區(qū)域，由該區(qū)域的控制柜通過硬接線直接連接；對于非智能傳感器、執(zhí)行器分布相對分散的區(qū)域，則通過現(xiàn)場總線和分布式IO接口箱，實現(xiàn)設(shè)備層與控制層的連接；對于具備現(xiàn)場總線接口的智能型傳感器、執(zhí)行器，可通過現(xiàn)場總線直接與控制柜連接。

圖5 數(shù)字化儀控系統(tǒng)架構(gòu)圖

控制柜收集的來自設(shè)備層的現(xiàn)場信息，獨立完成自身的邏輯控制，并通過以太網(wǎng)將信息傳送給管理層的綜合顯控臺；綜合顯控臺從以太網(wǎng)絡(luò)收集儀控系統(tǒng)的全部信息，實現(xiàn)綜合監(jiān)視及報警，并將控制指令發(fā)送給控制柜，由控制柜驅(qū)動執(zhí)行器動作輸出，從而實現(xiàn)綜合控制及運行管理。需要說明的是，為確?？煽啃?，對數(shù)字化儀控系統(tǒng)內(nèi)部的少數(shù)可靠性要求極高的涉及安全性的設(shè)備，仍通過硬接線與綜合顯控臺面板的按鈕、開關(guān)直接連接，當出現(xiàn)緊急狀況時，由硬接線通道實施可靠控制，確保系統(tǒng)安全性。

4 OPC技術(shù)應(yīng)用方案

4.1 基于專用OPCServer的應(yīng)用方案

基于專用OPCServer的應(yīng)用方案通信架構(gòu)如圖3所示。由于OPC技術(shù)已經(jīng)成為一項工業(yè)標準，因此世界上主流的硬件廠商都針對各自的產(chǎn)品開發(fā)了專用的OPCServer，如 Siemens PLC 的 SimaticNet、AB PLC 的 RSLinx、Schneider PLC的OFS等。數(shù)字化儀控系統(tǒng)的控制柜、DCS集控柜大都采用PLC控制器作為邏輯控制核心，通過OPCServer，綜合顯控臺人機界面程序的OPC客戶端就能夠方便地實現(xiàn)到控制器的數(shù)據(jù)訪問，而不必過多關(guān)注控制器內(nèi)部的硬件細節(jié)，從而實現(xiàn)了數(shù)字化儀控系統(tǒng)的通信集成。即使儀控系統(tǒng)的控制層設(shè)備增加，只要其控制器能夠提供OPCServer，那么綜合顯控臺的OPC客戶端只需要進行簡單的配置，即可實現(xiàn)人機界面程序與新增控制器的數(shù)據(jù)通信，消除了長期存在的通信壁壘。

但是，該技術(shù)方案仍然存在不足之處。由于不同廠商的控制器采用的是各自專用的OPCServer，那么隨著儀控系統(tǒng)規(guī)模的擴大，控制層設(shè)備采用的控制器種類可能越來越多，相應(yīng)地在OPCServer的種類也越來越多，一方面導(dǎo)致軟件采購經(jīng)費增加，同時OPCServer運行時的硬件開銷增加也會導(dǎo)致計算機服務(wù)器的費用增加；另一方面，隨著OPCServer種類增加，針對OPCServer的日常軟件維護以及版本控制工作量也會大大增加，實際上在某種程度上抵消了OPC技術(shù)所帶來的好處。

4.2 基于通用OPCServer的應(yīng)用方案

基于通用OPCServer的應(yīng)用方案能夠很好地解決專用OPCServer所存在的不足。通用OPCServer幾乎集成了世界上所有主流廠商PLC控制器的硬件訪問功能，應(yīng)用通用的OPCServer，數(shù)字化儀控系統(tǒng)的通信集成方案就可以擺脫控制層設(shè)備控制器種類、品牌的限制，使得通信架構(gòu)更加簡化，如圖4所示。

美國的Kepware公司提供的KEPServer EX就是一款功能強大、專業(yè)高效的通用OPCServer，在工業(yè)控制領(lǐng)域已經(jīng)得到了廣泛應(yīng)用。KEPServer EX采用了業(yè)界領(lǐng)先的驅(qū)動程序插件式結(jié)構(gòu)，嵌入了100多種通信協(xié)議，涵蓋了當今世界上所有主流控制器型號。不僅如此，它還能通過下載新的驅(qū)動程序插件進行功能擴展，從而適應(yīng)不斷推陳出新的技術(shù)發(fā)展需求[10～11]。

將KEPServer應(yīng)用到數(shù)字化儀控系統(tǒng)中，能夠很好地解決當前存在的通信壁壘問題。根據(jù)數(shù)字化儀控系統(tǒng)控制層設(shè)備控制器的型號，在KEPServer中進行相應(yīng)型號的驅(qū)動程序參數(shù)配置，無需購買更多的OPCServer軟件，即可完成通信集成。KEPServer可以安裝在控制層設(shè)備自身配置的計算機中，也可安裝于儀控系統(tǒng)的通信服務(wù)器中，作為單獨的通信節(jié)點存在。應(yīng)用KEPServer的數(shù)字化儀控系統(tǒng)通信架構(gòu)如圖6所示。

圖6 基于KEPServer的通信架構(gòu)圖

由圖6可見，控制層設(shè)備控制器的型號包括Siemens、Schneider、AB、GE、Omron等，如果采用常規(guī)的方法，每個型號的控制器只能通過對應(yīng)的OPCSerever與顯控臺客戶端通信，那么儀控系統(tǒng)通信平臺需要配置五種不同的OPCServer。而KEPServer能夠同時與上述五種控制器實現(xiàn)通信集成，從而大大簡化了儀控系統(tǒng)通信平臺的設(shè)計與后續(xù)維護。以Siemens PLC為例，在KEPServer的通道配置中選擇Siemens PLC的型號及通信接口類型，并配置變量名一一對應(yīng)Siemens PLC的寄存器地址即可實現(xiàn)KEPServer與Siemens PLC的聯(lián)通，顯控臺的OPC客戶端只需訪問KEPServer中的變量名即可實現(xiàn)對Siemens PLC相應(yīng)寄存器的讀寫。其它類型的控制器均能通過類似的簡便方法實現(xiàn)通信集成。因此，KEPServer很好地消除了不同類型控制器在數(shù)字化儀控系統(tǒng)中的通信壁壘。

另外，Kepware公司還提供了U－CON軟件，能夠支持用戶自定義通信協(xié)議，并提供OPCServer。當儀控系統(tǒng)的通信網(wǎng)絡(luò)中出現(xiàn)了非主流控制器或自定義開發(fā)的控制器時，利用U－CON的編輯、組態(tài)功能能夠快速地開發(fā)出該控制器的驅(qū)動程序，作為插件整體嵌入到KEPServer中，從而方便地集成到儀控系統(tǒng)通信網(wǎng)絡(luò)當中。

由上述可得，基于KEPServer的應(yīng)用方案只需一種OPCServer，即可實現(xiàn)多種主流控制器與儀控系統(tǒng)通信網(wǎng)絡(luò)的無縫集成，開發(fā)調(diào)試、運行維護工作量小，成本低。同時，該方案還支持用戶自定義的通信協(xié)議，大大提升了儀控系統(tǒng)的兼容性和可擴展性，既能適應(yīng)技術(shù)現(xiàn)狀又能兼顧技術(shù)發(fā)展要求。所以，基于KEPServer的應(yīng)用技術(shù)方案更適合作為數(shù)字化儀控系統(tǒng)的網(wǎng)絡(luò)通信解決方案。

5 結(jié)語

為解決船舶數(shù)字化儀控系統(tǒng)技術(shù)發(fā)展中面臨的網(wǎng)絡(luò)通信壁壘問題，本文提出了基于OPC技術(shù)的通信應(yīng)用方案，并在對專用OPCServer和通用OPCServer進行比較分析的基礎(chǔ)上，提出了基于KEPServer的通用OPCServer通信解決方案。研究結(jié)果表明，該方案很好地實現(xiàn)了數(shù)字化儀控系統(tǒng)各設(shè)備的信息集成、共享，減小了通信軟件開發(fā)調(diào)試、運行維護工作量，降低了成本，同時還提升了儀控系統(tǒng)兼容性和可擴展性。

儀控系統(tǒng)是典型的工業(yè)控制系統(tǒng)，隨著計算機技術(shù)、信息技術(shù)的發(fā)展，基于網(wǎng)絡(luò)通信的數(shù)字化工業(yè)控制系統(tǒng)在電力、冶金、化工、采礦等工業(yè)領(lǐng)域應(yīng)用日益廣泛，這些控制系統(tǒng)同樣也面臨著類似儀控系統(tǒng)的通信壁壘問題。因此，本文提出的通信解決方案也適應(yīng)于其他數(shù)字化工業(yè)控制系統(tǒng)，具有廣闊的應(yīng)用前景。

[1]王遠隆.核電廠數(shù)字化儀控系統(tǒng)結(jié)構(gòu)比較分析[J].中國核電，2011，4（3）：212－219.

[2]林建輝，陳松濤.基于工業(yè)以太網(wǎng)的船舶綜合平臺管理系統(tǒng)[J].江蘇船舶，2012，29（2）：31－35.

[3]郭遠星，施一明，葉瑩.船舶綜合控制系統(tǒng)研究與設(shè)計[J].中國造船，2010，51（3）：191－198.

[4]吳春秋，唐慧妍.艦船監(jiān)控系統(tǒng)的現(xiàn)狀及發(fā)展趨勢[J].船舶，2011，22（3）：8－10.

[5]馬耀名，馬鈴.基于OPC自動化接口的監(jiān)控系統(tǒng)的設(shè)計與開發(fā)[J].自動化技術(shù)與應(yīng)用，2007，26（3）：52－54.

[6]郁梅，邵惠鶴.OPC規(guī)范在工業(yè)以太網(wǎng)中的應(yīng)用[J].計算機工程，2003，29（22）：38－39.

[7]智少磊，夏繼強，張炯.基于OPC的服務(wù)機器人監(jiān)控系統(tǒng)設(shè)計[J].計算機工程，2012，38（14）：266－268.

[8]蘇磊，李茜，湯偉.OPC數(shù)據(jù)訪問客戶端的研究與實現(xiàn)[J].計算機工程，2010，36（11）：80－82.

[9]孫國萍，張新宇.OPC技術(shù)在數(shù)據(jù)報表中的應(yīng)用[J].計算機與數(shù)字工程，2009（12）.

[10]寧鷗，陽世榮，夏偉，等.OPC技術(shù)在艦船綜合平臺管理系統(tǒng)中的應(yīng)用研究[J].中國艦船研究，2011，6（4）：75－77.

[11]張國華，郭成花.基于OPC服務(wù)器的Modbus Plus與MPI通訊及集中控制的實現(xiàn)[J].工業(yè)控制計算機，2007，20（11）：19－20.