综述OPC技术，她提供了一种从广泛的工业设备和系统中获取数据的一种手段，并呈现给windows客户端应用程序。 KEPServerEX 为一种Server应用程序. 在很多软件学科和商业领域中我们经常听说"client/Server应用程序"，在工业控制领域，这意味着在更广泛的范围内，从HMI,MES到ERP共享制造和产品信息.

抛开商业因素, client/server应用程序有一个共同的特点： 都具备标准访问数据的方法。 在工业控制领域，在过去10年里，很多 client/server 技术已经被开发利用。 起初， 这种技术的一部分被人独自拥有， 在很多方面这种 client/server 结构的应用程序被广泛应用，但对第三方应用程序却不可访问。在早期的windows应用程序开发中，Microsoft提供了一通过DDE方式实现的 client/server 技术。DDE确实提供了一种可让很多应用程序共享的数据的基础结构,但是DDE有问题。 DDE 不是专为工业领域设计的。 可是,并没有阻止DDE 成为 client/server结构的领先地位，主要是因为在大部分windows应用程序里都能获得它。 很及时， 一些业界领导厂商开发出很多DDE扩展。 这些DDE扩展强调速度和可靠性,但另外一些人却主张在工业控制领域需要开发出一种更好的方法。

OPC (OLE for Process and Control)

在1994年，一些厂商为了给工业控制领域带来一线光明，他们成立了OPC基金会,OPC基金会的宗旨就是开发出一种单一的client/server ,它允许任何厂商都可开发自己的应用软件和应用程序，它可快速强劲的方式访问这种client/server.OPC基金会的第一个产品称Data Access Specification 1.0a,于1996年发行。在这种方式下，厂商能快速地开发出client/server 结构的软件。

OPC基金会的主要目标是消除厂商自己开发客户端应用程序对驱动程序的需求。对很多厂商来说，开发客户端应用程序的各种驱动程序花去他们很多精力。采用OPC技术, 厂商可以专心地开发他们自己的客户端应用程序。 Data Access specification 定义哪些应用程序接口需要由client 和Server端构造。 如果这些规则被完全遵照， 客户端开发商就知道任何已存在的OPC 服务器都能提供访问数据的连接性。产品进入市场的实效性和可靠性不再约束OPC应用程序。OPC给最终用户额外的益处，可以选择自己的软件开发工具去解决应用问题。过去，没有期望的驱动程序，或者驱动程序不能充分发挥性能，唯一的解决办法就是劝说应用程序开发商去开发期望的驱动程序或修改已有的驱动程序。 在这两种情况下所花费的时间都不算少。 有了 OPC, 最终用户不再受客户端应用程序供应商资源的限制。 最终用户现在能根据驱动程序的需要或性能补偿的需要，从众多的OPC服务器厂商自己挑选。 同样地,客户端软件开发商更能集中精力持续开发自己的核心产品。 Kepware的宗旨就是在OPC领域内做OPC等同的服务器组件领先的供应商，并且提供可靠易用的产品。

OPC Data Access 基础

这节介绍 OPC Data Access 和 覆盖OPC Data Access的话题.

OPC 纵览

这个规约描述OPC COM 实体对象和由OPC Servers实现的接口。OPC 客户端能联接一个或多个厂商提供的OPC服务器。

图: OPC Client

OPC Servers可由不同厂商提供。 厂商的软件代码决定了硬件设备和Servers访问的数据，数据的命名方式和servers访问物理数据的详细情况.特别地命名规则在下节解释。

图: OPC Client/Server 的关系

在更高的级别上, 一个OPC server 是由几个对象实体组成： 服务器server, 组 group, 和条目item。  OPC server 对象维护Server的信息并做为OPC Group对象的容器。  OPC group 对象维护自己的信息并提供容纳OPC Items和以有效的逻辑组织OPC Items的机制。OPC Groups为客户端组织数据提供方法。例如，组对象可能代表特定的操作显示和报告，数据可被读写。客户端和组内的items 额外的连接也能创建。并根据需要使之失效或有效。 一个OPC client客户端能配置OPC Server至OPC Client 数据变更刷新速率.有两种组类型,公有组和私有组。公有组提供不同客户端的数据共享，私有组提供本地客户端数据共享， 特别的目的，功能及更详细的信息请参考公共组节， 公共组也存在可选接口，在一个组内可定义一个或多个可选接口。

图: Group/Item 间关系

在服务器内OPC Items代表到数据源的连接。一个 OPC Item, 单从用户定制接口方面来看, 并不能成为被OPC Client存取的对象。 因而OPC Item没有定义外部接口。 所有对OPC Items的访问都是通过包含OPC Items的OPC Group对象，或简单的在OPC Item 被定义的地方访问.

与每个item相关的是数值Value,品质Quality 和时间戳Time Stamp。数值的类型为可变类型VARIANT, 品质Quality 类似场总线的Quality.

注意：items并非数据源,它们只是与数据源连接。例如,tags在DCS中的存在并不管OPC Client端是否存取它们。OPC Item 应简单地想象成只是数据的地址,并不代表实际数据源的物理地址。

OPC 适合在哪些方面?

虽然OPC主要是设计成能存取网络服务器的数据,在应用程序里OPC interfaces可用在很多地方。在最低层，它们存取物理设备的原生数据到SCADA 或DCS,或者从SCADA或DCS系统到应用程序.这种体系结构能构建一个OPC服务器, 使客户端应用程序通过单一的对象就能访问网络上不同节点的不同厂商的OPC服务器提供的数据。

图: OPC Client/Server 间关系

OPC通用结构和组成

OPC是两个接口组件的规约;OPC 定制接口Custom Interfaces和OPC自动化接口  OPC Automation interfaces. 修订的版本为符合OPC规约的自动化接口automation interface 2.0。 图示如下

图: OPC 接口

OPC规约指定 COM 接口 (什么是接口？), 不是这些接口的实现 (和怎样实现). 它规定使用接口的客户端应用程序的接口的行为.包含对该体系结构的描述和适合这种体系结构接口的描述. 象所有的 COM 实现一样, OPC 的体系结构就是一 client-server 模型,在这里 OPC Server组件提供到OPC对象的接口并管理这些接口. 在实现OPC Server 时，有几个地方需要单独考虑. 主要一点就是在一个至物理设备的非共享通讯通道上数据的传输频率. 因而,我们期望 OPC Server不管是本地的还是远程的都必须包含专门负责处理物理设备有效数据的代码。OPC 客户端应用程序通过OPC 用户定制接口或自动化接口完成与OPC 服务器的通讯。OPC servers必须实现 custom interface接口, 实现自动化接口 Automation interfaces可选。 inproc (OPC 句柄)被用来编组接口并额外提供OPC自动化接口Item级的功能. 参考下图： 典型的 OPC 结构。