OPC规范简介
OPC规范
传统的实时监控系统存在的问题
传统的实时监控系统作为支撑现代工业生产和社会生活的基础设施，得到了广泛的应用和发展。但过去，动用了当时最好的技术和最好的人才，可以开发出好的实时监控系统，但由于系统不具备开放性，各个部分的联系过于紧密，使系统过于复杂。这样系统的更新、扩展、升级变得非常困难。修改什么地方，怎样修改往往无从下手。同时当参与开发的技术人员可能因为其它原因而各奔东西，更加造成了系统得维护困难。而这种复杂得关系造成文档的难以形成。
传统的实时监控系统开发中出现的另一个主要问题是软件的重复开发，软件不能够重用，资源不能共享，造成大量人力与物力资源的浪费。随着计算机软件的发展，这种情况有所改观，高级语言中库函数的采用，实现了一定程度上资源的共享，尤其是面向对象的方法的应用，使得我们可以利用面向对象的继承等方法大量重用源代码。但这些重用只是对源代码级的重用而不是对可执行文件级的重用，对每一类库都要重新编译，所以并没有真正实现资源共享，并且对某个某个模块中某个类库的修改将“触一发而动全身”，引起所有引用该类库的模块的修改，因此非常难以实现某个模块的升级。同时，为一种语言开发的类库以及函数库都不能够为其他语言所用，也大大限制了软件的重用。
一般实时监控系统为分布式的结构，实现了人机接口、通信、数据处理等功能在网络上的分布，同时将一个系统划分为各个子系统，降低了系统的复杂程度，改善了系统性能，便于整个系统的开发，减少了开发周期与维护费用。但由于系统各个计算机的通信协议依赖于某个厂家，没有形成统一的标准，不同厂家之间的软件与硬件的集成难于实现。因此也没有真正实现不同厂家的软件共享。
OPC规范简介
为此，由OPC Task Force制定的OPC(OLE for Process Control)规范于1996年8月正式诞生了，随着1997年2月Microsoft公司推出Windows95支持的DCOM技术，1997年9月新成立的OPC Foundation对OPC规范进行修改，增加了数据访问等一些标准，OPC规范得到了进一步的完善。
“OPC 基于Microsoft公司的 Distributed interNet Application (DNA) 构架和 Component Object Model (COM) 技术的，根据易于扩展性而设计的。OPC 规范定义了一个工业标准接口，这个标准使得COM技术适用于过程控制和制造自动化等应用领域。”OPC 基础委员会主席Dave Rehbein是这样描述的
OPC是以OLE/COM机制作为应用程序的通讯标准。OLE/COM是一种客户/服务器模式，具有语言无关性、代码重用性、易于集成性等优点。OPC规范了接口函数，不管现场设备以何种形式存在，客户都以统一的方式去访问，从而保证软件对客户的透明性，使得用户完全从低层的开发中脱离出来。
基于OPC的软件结构如图。
由图可见，应用程序与OPC服务器之间必须有OPC接口，OPC规范提供了两套标准接口：Custom标准接口，OLE自动化标准接口。通常在系统设计中采用OLE自动化标准接口。
OLE自动化标准接口，及采用OLE自动化技术进行调用，其技术为上节所述的OLE自动化技术。OLE自动化标准接口定义了以下三层接口，依次呈包含关系。
OPC Server：OPC启动服务器，获得其他对象和服务的起始类，并用于返回OPC Group类对象；
OPC Group：存储由若干OPC Item组成的Group信息，并用于返回OPC Item 类对象。
OPC Item：存储具体Item 的定义、数据值、状态值等信息。
由于OPC规范基于OLE/COM技术，同时OLE/COM的扩展远程OLE自动化与DCOM技术支持TCP/IP等多种网络协议，因此可以将OPC客户、服务器在物理上分开，分布于网络不同节点上。
OPC规范可以应用在许多应用程序中，如它们可以应用于从SCADA 或者DCS 系统的物理设备中获取原始数据的最低层，它们同样可以应用于从SCADA 或者DCS系统中获取数据到应用程序中。实际上，OPC设计的目的就是从网络上某节点获取数据。图4.2.2OPC的客户/服务器关系图同样描述了OPC在SCADA系统的应用。
采用OPC规范设计系统的好处
在进行新型微机远动系统的研制中，各个计算机以及各个模块的数据交换应该按照OPC规范进行。这样做有以下好处：
1、OPC规范以OLE/DCOM为技术基础，而OLE/DCOM支持TCP/IP等网络协议，因此可以将各个子系统从物理上分开，分布于网络的不同节点上。
2、OPC按照面向对象的原则，将一个应用程序（OPC服务器）作为一个对象封装起来，只将接口方法暴露在外面，客户以统一的方式去调用这个方法，从而保证软件对客户的透明性，使得用户完全从低层的开发中脱离出来。
3、OPC实现了远程调用，使得应用程序的分布与系统硬件的分布无关，便于系统硬件配置以及，使得系统的应用范围更广。
4、采用OPC规范，便于系统的组态化，将系统复杂性大大简化，可以大大缩短软件开发周期，提高软件运行的可靠性和稳定性，便于系统的升级与维护。
5、OPC规范了接口函数，不管现场设备以何种形式存在，客户都以统一的方式去访问，从而实现系统的开放性，易于实现与其它系统的接口。
简介：
2000年6月20日，美国马萨诸塞州NORWOOD、德国Walldorf，全球工业自动化解决方案的领导者Intellution公司和当今企业内部软件解决方案的供应商SAP AG公司宣布，他们将合作共同开发并销售一个过程控制OLE (OPC)的接口，它使得厂级数据能够与https://www.doczj.com/doc/9510149510.html,共享。SAP ODA(SAP的数据访问连接器)将能够在https://www.doczj.com/doc/9510149510.html,和任一与OPC 兼容的服务器之间传递数据，而无需用户编程或其他应用软件，这就加快了在使用多家产品进行电子商务时的操作速度。
SAP的过程制造部的产品经理Oswald Wieser说，"为了充分发挥https://www.doczj.com/doc/9510149510.html,为制造业所提供的灵活性和快速性，企业必须成为供应链上的一个灵敏部件。我们意识到需要一种简单的集成连接器来与https://www.doczj.com/doc/9510149510.html,对接，而且我们非常高兴能够与Intellution合作开发SAP ODA连接器，因为他们擅长于厂级信息。通过https://www.doczj.com/doc/9510149510.html,，我们的用户可以将我们的过程指令数据与自动化过程相结合，并立即从中受益"。
"我们与SAP的合作，非常清晰地说明了厂级生产与商务系统进行无缝连接，以求优化供应渠道和有效完成电子制造策略的必要性"，Intellution的首席执行官Steve Rubin说，"另外，这种合作，也是诸如OPC和用于制造业的Microsoft Windows DNA等工业标准的功能的一个有力例证"。
Intellution的首席技术负责人、OPC基金会技术主席Al Chisholm说，"OPC是一个理想的方式，它为制造商在其企业中集成多个分散的应用提供了一个便捷而节省的方案。用户不用被迫对多个应用接口进行投资，只要简单地通过标准的OPC兼容组件，与https://www.doczj.com/doc/9510149510.html, 解决方案并轨(SNAP)即可"。
OPC包含一套标准的接口、属性和方法，用于过程控制和自动化制造，在多个过程控制设备之间进行通讯，而无需控制软件。OPC基于Microsoft OLE(现在为Active X)、COM (组件对象模型Component Object Model)和DCOM (分散的组件对象模型Distributed Component Object Model)等技术。OPC标准由OPC基金会建立和维护，该基金会是一个独立的非盈利性团体，有200多个成员，包括Intellution。SAP ODA连接器将于今年第四季度发布。
文章：
OPC通用接口与OPC服务器注册
戚玉松
1 引言
工业控制软件缺乏统一的工业标准，不同厂家的软件之间进行通讯是非常麻烦的一件事。各个厂家的软件对控制系统硬件操作的设备驱动程序接口也各不相同，为了对市场上不同厂家的设备都能管理，控制软件厂家必须针对市场上几百种常用的设备开发设备驱动程序，而且当硬件设备升级或者修改时，驱动程序也必须做相应修改，这样做下来成本是相当高的。此外，一个系统中如果同时运行不同的工业控制软件，由于不同的应用程序不可能同时访问同一设备，当他们通过各自的设备驱动程序同时对一个硬件设备操作时，往往会由于相互之间的不协调、不兼容造成系统的崩溃，影响到整个系统的运行情况。如果设备驱动程序由硬件设备制造厂开发，那么他们也必须为市场上所有的工业控制软件都开发相应驱动程序，成本同样是非常高的。
针对上述问题，OPC基金会制定了一套标准的OPC规范。OPC规范是基于微软的COM技术，它规范了过程控制和生产自动化软件与用OPC服务器实现的硬件驱动程序之间的接口，并且提供基于工业自动化应用的统一数据传输平台。本文从通用OPC接口定义的描述出发，给出OPC 服务器的安装与注册中的一般方法以及相应的IDL描述。文中所提到的相关组件和源文件可以从OPC基金会的Web站点上获得。
2 OPC概述
OPC是OLE for Process Control的缩写，意思是把OLE技术应用于工业控制领域。OLE原意是对象链接与嵌入，随着OLE2 0的发布，其范围已远远超出了这个概念。现在的OLE包容了许多新的特征，如统一数据传输、结构化存储和自动化，已经成为独立于计算机语言、操作系统甚至硬件平台的一种规范，是面向对象程序设计概念的进一步延伸。OPC建立在OLE规范之上，它为工业控制领域提供了一种标准的数据访问机制。
OPC服务器实现了一套标准的COM接口，即OPC接口，任何一个OPC客户都可以连接到由一个或多个供应商提供的OPC服务器上。只要工业自动化软件符合OPC规范，它不需要做任何修
改就能一致地访问所有的OPC服务器实现的硬件驱动程序。而且OPC客户可以透明地与网络计算机商的OPC服务器进行通讯，对软件实现网络化极其方便。OPC技术规范以Microsoft的OLE/COM 设计为基础，它所定义的是一组接口规范，包括OPC自动化接口(Automation Interface)和客户化接口(Custom Interface)两个部分，在硬件供应商和软件自动化接口(Automation In terface)和客户化接口(Custom Interface)两个部分，其实质是在硬件供应商和软件开发商之间建立了一套完整的接口规则，只要遵循这套规则，数据交换对两者来说都是透明的，硬件供应商无需考虑应用程序的多种需求和传输协议，软件开发商也无需了解硬件的实质和操作过程。值得注意的是，OPC技术规范定义的是OPC服务器程序和客户机程序进行接口或通讯的一种规则，它不规定如何具体来实现这种接口。
3 OPC的通用接口
这一部分是对OPC通用接口的描述，也包括一些OPC的基本概念的罗列，它们对所有OPC
服务器/客户应用程序中接口的描述都是适用的。
(1)客户接口与自动化接口
OPC规范包含了两套接口：客户化接口和自动化接口。如果只定义单一的接口(如自动化接口 )，既要实现高效的操作，又要实现方便、快捷的自动化接口的功能(如Excel)，从设计的角度出发，是很难实现的。
通常情况下，OPC服务器应实现客户化接口(用C++语言实现)，有时为了简捷与方便，也可以实现自动化接口(VBA方式)，为此，OPC基金会提供一套标准的自动化接口包装器(Wrapper D LL)，如图3所示。
(2)必选接口与可选接口定义
OPC服务器的开发人员必须实现必选接口的全部功能(最小实现)。一个OPC客户通过调用OPC 必选接口的函数与OPC服务器进行通讯。当然，OPC服务器开发人员也可以实现可选接口的功能。可选接口并不一定要在每一个OPC服务器里实现。当一个OPC服务器支持可选接口时，此接口内部的各个功能函数都能够被调用，甚至此函数返回E NOTIMPL。试图使用可选接口函数的OPC 客户应对OPC服务器发出Query请求，对可选接口进行查询。
(3)内存维护
在每一个COM规范中，客户都必须释放所有与“out”或“in/out”参数相关的内存，也包括由结构体内部变量所指向的内存。这一点对于客户应用程序的开发者非常重要，因为对内存维护的忽略可能会导致难以发现的内存泄漏，必要时应参考IDL文件。对于客户应用程序的开发，推荐的办法是创建一个子程序，可以用来成功地释放各种类型变量所指向的内存。不论成功与否，服务器必须能够返回预先定义好的值，作为“out”参数。
(4)空串(NULL Strings)与空指针(NULL Pointers)
空串与空指针这两个术语在OPC的开发中都会遇到，但它们并不代表同样的含义。一个NUL L指针是一个无效的指针(0)，如果使用的话，有可能导致异常(Exception)。一个NULL串是一
个有效的指针(非0)，指向只有一个字符的队列，此字符为NULL(比如0)。假如一个NULL串作为一个out参数从method返回，它必须被释放，否则包含此NULL串的内存将会丢失。同时，由于COM规则的严格限制，一个NULL指针不能作为［in,string］参数被传递。
(5)错误与返回代码
OPC规范描述了OPC服务器应该实现的功能和OPC客户应用程序依赖的接口以及相应的行为，在每一个相应的规范里都包含了错误列表和返回代码，对于每一种所描述的Method，所有可能的OPC错误以及最常见的OLE错误代码都包括在内。当然，在开发和使用过程中，用户还会遇到另外的错误代码，比如安全性问题。
4 OPC服务器的注册
(1)组件目录的注册
随着计算机系统内部可用组件(Component)的大量增加，对它们的管理程序也变得越来越复杂，在特定的场合，OPC客户需要列举可以使用的OPC服务器。在早先的版本里，OPC规范规定了用OPC Sub Key来标识OPC在注册表里的入口。客户必须按这个Sub key进行浏览。这种方法效率较低，因为它要求浏览所有的CLSID条目。
对所有版本超过Data Access 1 0的OPC服务器规范，OPC使用了组件目录(Component Categ ories)，按照(服务器)所实现的功能对OPC服务器进行分类。客户可以使用新的接口I OPC Server List得到一个包含所需要功能的服务器的列表。每一个版本的OPC接口规范都有一个组件目录，每一个目录都由全局标识符(GUID)CATID所标识，CATID位于每一个规范的注册区域。
服务器应首先创建将要使用的目录并为此服务器进行注册，值得注意的是已注册服务器的注销也将导致目录的删除。一个服务器可以属于多个目录，也就是说，它可以支持Data Acces s 1 0A和2 0以及Alarm&Event Handling等。在注册的过程中，每一个OPC服务器必须将自身注册到组件目录管理器(Components Categories Manager)，这是微软提供的系统级的COM 对象。OPC客户可以对组件目录管理器进行查询，以获取所有注册的OPC服务器的CLSID。
为了在组件目录管理器中进行注册，服务器应首先调用ICat Register::Regi ster Categories函数对CATID和组件进行描述并注册，然后利用ICat Register::Register Class Impl Categories()函数注册其自身的CLSID作为CATID的实现。
为了得到指向ICat Register的指针，调用Co Creat Instance()，例如
# include
Co Creat Instance (CLSIDstd Component Categories Mgr,NULL,CLSTXINP ROCSERVER,
IIDICat Register,(void**)&pcr;
以OPC Alarm & Events服务器为例，其中调用了CATHELP CPP中的ICat Register函数。
#include “cathelp.h”
#include “opcae.h”
#include “opcaedef.h”
void Register Server()
{
//register component categories
HRESULT hr;
//IIDOPC Event Server CATID is the Category ID(a GUID) defined in opc ae.idl.
//OPCEVENTSERVERCATDESC is the category description defined in opcaedef.h
//All servers should register the categogy this way
hr=Create Component Category (IIDOPC Event Server CATID,OPCEV ENTSERVERCATDESC);
//CLSIDOPC Event Server is the CLSID for this sample server.Each server
//will need to register its own unique CLSID here with the component manager.
hr=Register CLSID In Category(CLSIDOPC Event Server,IIDOPC Event S erver CATID);
}
void unregister Server()
{
Un Register CLSID In Category(CLSIDOPC Event Server,IIDOPC Even Se rver CATID);
}
客户可以使用接口IOPC Server List来获得本地或远程主机上服务器的一个列表。这个接口提供了组件目录管理器的基本的功能。值得注意的是它并不支持对组件目录管理器的远程访问。
(2)Proxy/Stub DLL的注册路径
Proxy/Stub用来对本地或远程服务器进行接口调度。它直接由IDL代码产生，对每一个OPC 服务器都是一样的。一般来说，Proxy/Stub可以实现自身注册(在实现时定义REGISTERPROXYDLL)。因为这一部分自动完成并且对上层透明，所以在这里就不做进一步讨论了。
尽管供应商可以在OPC对象上增加他们自己的接口(如同COM对象一样)，但是试图通过修改标准的OPC IDL文件或者Proxy/Stub DLL文件来包含这类接口是不可取的。这类接口应该被定义在一个独立的IDL文件中，由供应商提供的独立的Proxy/Stub DLL来调度。
(3)创建注册路径
COM定义了一种叫做“self-registration”机制，使得我们可以将注册过程封装在DLL或EXE 中，客户和服务器都可用这种非常容易的方法将给定模块准确无误地注册。此时，服务器必须是所有支持它的组件包括类型库创建注册的入口。此外，COM还包含一种名为“unregistr ation”的机制，当DLL或者EXE从文件系统中删除时服务器也会删除其自身的注册路径，依靠这种方式保持服务器的清洁、有序和可管理。
对于DLL服务器来说，这些行为是通过调用输出函数Dll Register Server和Dll Unregister Server来实现的。这两个函数都不带参数，返回一个HRESULT显示结果。两个可能返回的错误代码是SELFREGECLASS和SELFREGETYPELIB，分别表示CLSID和类型库信息的注册或删除的失败(这两个代码定义在OLECTL H头文件中)。
如果服务器以EXE模块的形式出现，对服务器进行注册就要使用命令行参数/Reg Server或-R eg Server(区分大小写)。如果要注销服务器，必须带命令行参数/Unreg Server或-Unreg S erver运行EXE模块。自注册EXE模块检测到命令行参数后，引发相当于DLL服务器的Dll Regi ster Server和Dll Unregister Server函数的行为，相应地，应在Local Server32路径下对模块进行注册而不是在inproc Server32或inproc Handler32下。
服务器不应对proxy/stub接口进行注册，它们是由proxy/stubDLL注册的。Proxy接口的服务器不应对proxy/stub接口进行注册，它们是由Proxy/Stub DLL注册的。Proxy接口的注册路径是在编译Proxy DLL时产生的。只需在编译时定义REGISTERPROXYDLL ，链接路径表示，支持Data Access 1 0接口的服务器必须按如下的注册路径：
HKEYCLASSESROOT＼My Vendor.Server Name.1＼OPC HKEYCLASSESROOT＼My Vendor.Server Name.1＼OPC＼Vendor=My V endor Name
(4)安装OPC库
为了能够使用供应商提供的组件，必须安装OPC基金会所提供的相应组件(Proxy/Stub DLLs 、自动化包装器等)，而且必须正确无误的遵守以下安装规则：
(1)所有的OPC基金会提供的库必须安装并注册在System目录下，这个路径由Win32函数Get S ystem Directory返回。如果欲安装的文件版本较新，则会覆盖此目录下已有的旧文件，这可以通过调用函数Geg File Time、Get File Version Info和Get File Information By Hn dle来实现。 (2)所有OPC基金会所提供的库的安装和删除应根据参考计数(Reference Counting)而进行。当拷贝一个文件后，注册表中此文件的使用数将会增1，相应地，当删除时，参考计数将减1。当其为0时，用户要么注销，要么删除此文件。文件的参考计数注册关键字为：
＼HKEYLOCALMACHINE＼SOFTWARE＼Microsoft ＼Windows＼Curr ent Version＼Shared DLLs个参考计数为5的OPC Proxy.dll和一个参考计数为3的OPC Enum. exe的信息如下：
＼HKEYLOCALMACHINE＼SOFTWARE＼Microsoft＼Windows＼Current Vers ion＼Shared DLLs C：＼WINNT＼System32＼OPCPROXY.DLL=5
C：＼WINNT＼System32＼OPCENUM.EXE=3