一 OPC结构概述
众所周知，从计算机技术介入到工业（控制）应用领域开始，伴生的“信息孤岛”问题就一直困绕着业界。“信息孤岛”相当严重地限制了信息交换继而约束了应用领域的拓展。“信息孤岛”问题概括体现在用户（应用）程序对数据的访问，一是从信息源获取什么样品格数据（包括类型—信息类型与数据类型，品位—好、坏、不定，以及时标等），二是如何把这些数据信息从源（地址）送达目的地。期间，为解决“信息孤岛”问题也曾作过多种尝试。例如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予以赋义解释。
