OPC－全開放控制系統的中間件技術

一 OPC結構概述

    眾所周知，從計算機技術介入到工業（控制）應用領域開始，伴生的“信息孤島”問題就一直困繞著業界?！靶畔⒐聧u”相當嚴重地限制了信息交換繼而約束了應用領域的拓展?！靶畔⒐聧u”問題概括體現在用戶（應用）程序對數據的訪問，一是從信息源獲取什么樣品格數據（包括類型—信息類型與數據類型，品位—好、壞、不定，以及時標等），二是如何把這些數據信息從源（地址）送達目的地。期間，為解決“信息孤島”問題也曾作過多種嘗試。例如ISO就數據交換（通信）制定了OSI（開放系統互連）的7層模型，來描述、表達數據傳輸及表示的屬性與要求。但是，它不是一種標準或規范。就7層模型的下面4層一物理層、鏈路層（網絡層及傳輸層）而言，據此進行數據傳輸的通信協議的現場總線控制系統FCS就多達8種[1]，使人們莫衷一是[2]。至于7層OSI中的表示層與會話層，在DCS及PLC中基本上不予采用。但據筆者理解，正是OPC基金會將這兩層的功能作為基金會的規范予以確定，為用戶提供了一個統一的系統平臺。

圖1 客戶應用程序與多個OPC服務器（程序）聯同工作

    如圖1所示，OPC服務器程序A、B、C分別代表譬如FF的設備供應商提供的服務器(程序)，PROFIBUS的服務器與CONTROLNET的服務器，其與應用程序X、Y交換數據的品格符合OPC規范；同樣，應用程序（客戶端）需讀、寫的數據品格也符合OPC規范。這就相當于III型儀表中的記錄儀、變送器、調節器等均按4~20mA或1~5V的標準制作，這樣不但不受其制造廠商約束而任意組合配置，而且還可即插即用。對客戶而言，它只需按規范規定的數據品格與服務器交換數據，而勿須關注其數據來往的細節（例如硬件設備與通信規約）。至此，對客戶端而言，其系統平臺是統一的。對設備制造商而言，它所制造的設備的信息用戶有了規范可依，也就勿須逐一制訂適合不同應用的驅動軟件，相形之下也就事半功倍而何樂不為呢？正因為如此，OPC規范深得用戶與制造商的歡迎。就用戶而言，無須對目前FCS的多維局面而杞人憂天!

圖2 典型的OPC結構圖

    典型的OPC結構如圖2所示。當作為客戶端的應用程序需訪問在不同數據庫的數據時就借助OPC服務器予以進行。這種OPC服務器是由提供所使用設備的制造商作為一攬子產品予以提供的。誠然，該服務器在同客戶端應用連接之前，不但需提供客戶同步或異步讀、寫數據要求的能力，而且還需逐一詢問所訪問數據的目的地址(例如站號、設備或參數工位號及標識號等)、數據品格(品格指數據的類型、尺寸、質量、時標等)、訪問速率、是同步讀寫還是異步讀寫、訪問群組(group)及每一群組內的參數數據等組態或配置數據。OPC服務器據此按每一群group安排線程，每一個group內所包含的參數數據由服務器分解為一系列Item，如圖3所示。例如，一個記錄型數據(Recode)包括一個Status(Un8)及Value (Float，4byte)，則Status與Value就各構成一個Item，即Recode或ARRAY有多少子項，則每一個子項都構成一個Item。至于每一數據或Item的含義則一概不予過問。據此，一個服務器就是按多線程調度實施的智能開關，按要求接通數據的源與目的地址，至于是同步讀寫還是異步讀寫，則由客戶應用確定。例如，進行批處理或配方處理時常要求異步讀寫。圖1中在X、Y中的OPC Interface等同于圖2中的OPC Automation Interface及/或OPC Custom Interface。它的功能可大致理解為遠程通信打包、拆包。服務器對于傳輸的數據含義一概不知，然而在這種Interface中就需賦以含義了，這就是筆者把OSI中7層模型中的表示層與會話層折同于此的依據。其中，OPC Automation Interface可由OPC基金會一個標準的自動接口搭扣(wrapper)實施平常的接口轉換，而OPC Custom Interface則在需刷新或更改接口功能時予以使用。

圖3 群組Group/Item關系圖

    綜上所述，按OPC基金會的規范，各設備制造廠商連同實際設備與相應的OPC服務器(程序)成套供應，與客戶應用(程序)打交道的，只是規范了的數據，這就是OPC為客戶應用端提供全開放的統一系統平臺的基本思路! 無疑，為爭取市場，各制造廠商會致力于相應OPC服務器的開發實施。據悉，National Instruments(NI)公司已有適合FF規范的OPC服務器問世。順便提及，OPC規范尚有待進一步完善升級，當應用需求的數據品格不在現有規范之列時，可以Byte ARRAY的數據格式代之，而用OPC Custom Interface予以賦義解釋。

原文轉自：http://www.anti-gravitydesign.com