OPC标准技术分析.docx

OPC标准技术分析.docx

《OPC标准技术分析.docx》由会员分享，可在线阅读，更多相关《OPC标准技术分析.docx（10页珍藏版）》请在冰豆网上搜索。

OPC标准技术分析

OPC标准技术分析

（一）

OPC全称OLEforProcessControl（用于过程控制的OLE），是在微软的合作下，由OPC基金会组织倡导，全世界范围内自动化领域中处于领导地位的厂商协作制定的软件接口标准。

它是基于微软的OLE（现称为ActiveX）、COM（ComponentObjectMode）和DCOM（DistributedComponentObjectMode）技术，由一系列用于过程控制的自动化领域标准接口、属性以及方法组成。

OPC提供了一种单一、一致的工业标准接口。

它允许软件供应商将更多的精力集中到增加软件的功能上，而不是开发一系列专有的硬件设备驱动程序。

OPC提供了一个环境，鼓励设备制造商投资开发他们自己的OPC服务器，而且同样的服务器能被支持OPC客户端的HMI、SCADA、DCS或其他软件系统所访问。

这激励了设备制造商把他们开发工业网络方面所获得的知识转向OPC服务器的开发上，从而保证了设备的性能能够达到最优。

OPC的目标是开发出一个开放的、灵活的、即插即用的工业标准，使最终用户对解决方案拥有很大的选择余地，同时大大减少硬件和软件供应商的开发和维护费用。

OPC结构采用客户机/服务器模式。

利用OPC技术，异构计算环境中的系统集成变得很简单。

图1-1OPC技术的异构计算环境

从图1-1可以看出，在这种异构网络中，OPC数据服务器负责对设备的访问，客户通过标准的接口访问其中的数据。

OPC数据服务器向下与设备相连，向上通过Intranet或Internet与客户端相连。

OPC技术基础

OPC规范在短短的几年里发展如此之快，得益于OPC技术内涵。

它基于Microsoft的OLE/COM和DCOM技术，包括了一整套自动化应用中使用的接口、属性和方法的标准。

Microsoft是OPC基金组织的发起成员之一，它把自己的COM/DCOM等新技术带给了OPC基金组织。

这些技术为工业控制领域里最重要的数据交换环节提供了技术保证。

1COM/DCOM

组件对象模型（ComponentObjectModel，简称COM），是一种以组件为发布单元的对象模型，这种模型使各软件组件可以用一种统一的方式进行交互。

COM既提供了组件之间进行交互的规范，也提供了实现交互的环境。

组件对象之间交互的规范不依赖于任何特定的语言，所以COM也可以是用不同语言协作开发的一种标准。

组件模型为COM对象提供了活动的空间，COM对象以接口的方式提供服务，图1-2表明了COM组件、COM对象和COM接口三者之间的关系。

图1-2COM组件结构图

一个组件程序可以包含多个COM对象，而且每个COM对象可以实现多个接口。

当另外的组件或普通程序（即组件的客户程序）调用组件的功能时，它首先创建一个COM对象或者通过该对象所实现的COM接口调用它所提供的服务。

当所有的服务结束后，如果客户程序不再需要该COM对象，那么应该释放掉对象所占有的资源，包括对象自身。

COM标准包括规范和实现两大部分，规范部分定义了组件和组件之间通信的机制，这些规范不依赖于任何特定的语言和操作系统，只要按照该规范，任何语言都可以使用。

COM主要是由对象和接口两部分组成。

对象是某个类（class）的一个实例；而类则是一组相关的数据和功能组合在一起的一个定义。

使用对象的应用（或另一个对象）称为客户，有时也称为对象的客户。

接口是一组公用功能定义，是一组逻辑上相关的函数集合，其函数称为接口成员函数。

按照习惯，接口名称常以"I"为前缀，例如"IUNKNOWN".对象通过接口和成员函数为客户提供各种形式的服务。

在国际上有很多先进的工业自动化软件都采用了COM技术。

Intellution公司的FIX软件就是一个典型的例子。

FIX软件是由多个组件构成的，核心组件是一个实时数据库，并可根据需要装上其它的功能组件。

这样就很容易地、可靠地把别的组件加载进来，或者更换己有的组件，使之具有新的功能。

Microsoft的分布式COM（DCOM）扩展了组件对象模型技术（COM）,使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通讯。

使用DCOM，应用程序就可以分布到网络不同的位置，从而满足客户和系统的需求。

在现在的操作系统中，各个进程之间是相互屏蔽的。

当一个客户进程需要和另一个进程中的组件通讯时，它不能直接调用该进程，而需要遵循操作系统对进程间通讯所做的规定。

COM使得这种通讯能够以一种完全透明的方式进行：

它截取从客户进程而来的调用并将其传送给另一进程中的组件。

当客户进程和组件位于不同的机器时，DCOM仅仅只是用网络协议来代替本地进程之间的通讯。

无论是客户还是组件都不会知道连接它们的线路比以前长了许多。

DCOM的整体结构是：

COM运行库向客户和组件提供了面向对象的服务，并且使用RPC和安全机制产生符合DCOM线路协议标准的网络包。

DCOM使得组件的位置对你来说完全透明，无论它是位于客户的同一进程中或是在地球的另一端。

在任何情况下，客户连接组件和调用组件的方式都是一样的。

DCOM不仅无需改变源码，而且无需重新编译程序。

一个简单的再配置动作就改变了组件之间相互连接的方式。

DCOM的位置独立性极大地简化了将应用组件分布化的任务，使其能够达到最合适的执行效果。

在设计和实现分布式应用系统时，一个普遍的问题就是为开发一个特定的组件而选择语言以及工具的问题。

作为COM的扩展，DCOM具有语言独立性。

任何语言都可以用来创建COM组件，并且这些组件可以使用更多的语言和工具，例如Java，VisualC++，VisualBasic，Delphi和PowerBuilder都能够使用DCOM组件进行开发。

DCOM通过给每个组件保持一个索引计数来管理对组件的连接问题，这些组件有可能是只连接一个客户上，也可能被多个客户所共享。

当一个客户和一个组件建立连接时，DCOM就增加此组件的索引计数。

同理，当客户释放连接时，DCOM就减少此组件的索引计数。

如果索引计数为零，组件就可以被释放了。

2COM+技术及WindowsDNA

COM+综合了COM、DCOM和MicrosoftTransactionServer（MTS）这些技术要素，它把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统，因此，COM+与操作系统的结合更加紧密。

COM+的系统服务包括事务、队列、对象池、内存数据库、安全模型以及管理特性等结合MTS的多方面内容。

通过这些服务，我们可以很容易开发出多层结构的应用系统。

COM+以系统服务的形式为应用提供了许多新特性，客户或者组件程序可以直接利用这些系统服务，避免了底层的细节处理，减少了开发成本，同时也减小了犯错误的可能性；同时，有一些系统服务包装了较复杂的逻辑甚至是底层的系统资源管理，这简化了应用层的访问；另外，使用系统服务可以增强应用程序的可靠性。

与COM相比，COM+与操作系统结合得更为紧密；与MTS相比较，COM+简化了分布式应用的开发。

COM+已经成为基于微软平台分布式应用的重要技术基础。

COM+具有如下几个主要的特性：

高性能、可伸缩。

COM+提供了负载平衡、对象池、可管理、易于配置等特性较大地提高了分布式应用的性能和伸缩性。

松散的客户机/服务器连接。

COM+底层提供了队列组件服务，这使客户和组件有可能在不同的时间点上协同工作，COM+应用无须增加代码就可以获得这样的特性。

事件通知机制。

新的事件机制使事件源和事件接收方实现事件功能更加灵活，利用系统服务简化了事件模型。

避免了COM可连接对象机制的琐碎细节。

事务处理功能。

继承并发展了MTS的特性。

从COM到MTS是一个概念上的飞跃，COM+则完成并实现了事务处理功能。

易于开发。

COM组件的开发一直是Wndows平台上应用开发的难点。

COM+开发模型大大简化了以前的COM组件开发模式。

COM+标志着微软的组件技术达到了一个新的高度。

COM+与多层应用架构及Windows操作系统平台的结合为企业应用提供了一套完整的解决方案。

WindowsDistributedinterNetApplicationsArchitecture（WindowsDNA）是微软多年积累下来的技术精华集合起来而形成的一个完整的、多层结构的企业应用总体方案，它定义了十几种不同的Microsoft产品和技术如何协调在一起的整体框架，使Windows真正成为企业应用平台。

WndowsDNA的核心是集成Web和客户机/服务器计算模型。

WindowsDNA描述了企业级应用如何利用分布式应用程序服务、分布式基础服务和Windows平台的公共界面，以及如何利用其它有用的Web技术。

3组件技术在工业监控中的应用

计算机技术的不断发展为用户带来了日益复杂的应用程序。

现代软件应用程序复杂，开发耗时，维护困难而且代价高昂，扩展其功能将冒很大风险。

应用程序不能对外开放，程序的数据和功能都不易为其它程序所共享。

然而遵守COM架构的软件可以较好地解决这些问题。

基于组件编程模型的主要目的之一是发挥互操作性。

在组件软件的环境中，互操作性是组件协同工作的一种能力。

如果工程软件是不自然地强行集成在一起，那么该应用程序就应该分成多个组件。

微软在COM的基础上提出了WindowsDNA三层软件体系结构，把一个软件体系分为表示层、商业层和数据访问层。

微软与工业领域代表性公司一直有很好的合作关系，如Intellution、Wonderware、Honeywell、GE、Siemens等，并积极地将包括分布式组件在内的一系列微软技术推向工业领域。

对于分布式组件技术，微软结合其DNA应用体系，提出了如图1-3所示的工业自动化行业应用框架。

可以看出，COM分布式组件技术在这个框架中占据核心的位置。

图1-3OPC工业自动化行业应用框架

  如前所述，采用分布式组件技术设计的软件体系都是分布式的。

但是分布对象技术应用起来比较复杂，因为这种软件通常都比较庞大，涉及到网络、面向对象、并发控制等多项技术，系统开发难度很大。

通过基于组件的软件方法进行开发和集成，分布式系统的开发就不再困难。

目前，国外利用分布对象技术开发的大型应用系统也不是很多，但发展较快。

在技术的应用方面，国内与国外有较大的差距，这种差距是全面的，包括标准、支撑平台和成功的应用。

一般来说，分布式应用发展的趋势是C/S两层结构、B/S三层结构、分布对象模式。

目前国外基本上已经从B/S三层结构向第三代分布对象模式过度。

OPC标准技术分析

（二）

OPC接口标准关键在于提供了一种开放、高效的通信机制，它所关心的是现场数据的存取方式而不是实际的数据类型，它给工业监控软件提供了一种一致的存取现场设备数据的方法。

1OPC对象与接口

OPC规范描述了OPC服务器需要实现的COM对象及其接口,它定义了定制接口（CustomInterface）和自动化接口（AutomationInterface）。

每种OPC规范又分定制接口规范和自动化接口规范二部分,以方便开发者设计和实现OPC服务器程序或客户程序。

图1自动化接口和定制接口

两种接口分别为不同的编程语言环境提供访问机制。

自动化接口提供了一个自动配置和存取过程数据的接口，它是为基于描述性编程语言而定义的标准接口，可以为VB程序、Excel及其他可以使用OLE自动化服务器接口的应用程序使用。

而定制接口描述了OPC组件和对象的接口及其中的方法，适用于期望获得最佳运行性能的客户应用程序，是专门为C++等高级编程语言而制定的标准接口。

实际上，OPC设计的目的就是使用标准接口实现网络上任意支持该标准的节点获取数据，而不需要考虑底层的变化。

在有些情况下,OPC基金会提供了标准的自动化接口封装器（wrapper.dll）,以方便自动化接口和定制接口之间的转换，使采用自动化接口的客户程序也可以访问只实现了定制接口的服务器[10]。

OPC规范定义了COM接口,规定了服务器程序和客户程序通过接口交互的标准,但并没有说明具体实现的方法。

OPC服务器供应商必须根据各自硬件特性实现这些接口的成员函数。

不论定制接口还是自动化接口都可分为必选接口和可选接口。

必选接口包括了客户程序与服务器进行交互的基本功能,因此必须实现;可选接口则规定了一些额外的高级功能,可根据需要有选择地实现。

客户程序应通过查询接口的方式来判断服务器程序是否实现了可选接口的功能。

2OPC标准的组成

图2OPC标准地发展历史

自从1995年OPC标准化组织成立以来，OPC基金会已经发布多个OPC规范，其中包括：

OPCDataAccess数据存取规范，OPCDataeXchange数据交换规范、OPCHistoricalDataAccess历史数据存取规范和OPCAlarmsandEvents报警和事件规范、OPCBatch批处理规范、OPCSecurity安全规范、OPCXML数据存取规范。

规范的组成结构如下图所示：

图3OPC标准规范组成结构图

3OPC标准规范组成结构图

OPC标准技术分析（三）

OPC数据存取规范

OPC数据存取（DataAccess）规范定义了OPC服务器中一组COM对象及其接口，并规定了客户程序对服务器程序进行数据存取时需要遵循的标准。

在数据存取规范中，一个OPC的数据存取服务器中包括几类对象：

服务器（OPCServer）、组（OPCGroup）和项（OPCItem）[11]。

OPC服务器对象维护有关服务器的信息并作为OPC组对象的包容器。

OPC服务器对象主要实现IUnknown和IOPCServer接口，OPC客户通过OPC服务器的接口与OPC对象进行通信，对数据源进行存取。

数据源可以是现场的I/O设备，也可以是其他应用程序。

服务器内部封装了与I/O控制设备通讯及操作的具体实现过程。

OPC组对象维护有关其自身的信息，提供包容OPC项的机制，并管理OPC项。

它提供了一种客户程序组织数据的手段。

例如，一个组中可以包括一个设备中所有的数据项，客户程序和数据项之间可以建立基于“订阅”的连接。

有两种类型的组，公共组（PublicGroup）和局域组（LocalGroup）。

公共组可以被多个客户共享，而局域组只能被一个客户使用。

每个组中都可以定义一个或多个OPC项。

 图2-4OPCDA中的对象

OPC项代表了与服务器中的数据连接。

从定制接口（CustomInterface）的角度看，OPC项不能被OPC客户作为一个对象直接进行操作。

因此，没有为OPC项定义的外部接口。

所有对OPC项的操作都是通过包含此项的OPC组对象进行的。

每个项都有数值（Value）、品质（Quality）和时间戳（TimeStamp）三个属性，值的类型为Variant，品质的类型是Short。

数值代表数据项的值，品质代表数值的可信度，时间戳代表数据的存取时间。

OPC的数据传输机制主要分为同步读写和异步读写两种。

同步数据传输是指，客户直接调用OPC服务器的IOPCSyncIO接口的同步读写函数，在发出数据请求后一直等待，直到数据返回。

这种方法虽然简单可靠，但当OPC服务器采集现场数据的时间很长时，客户等待的时间就会很长，这就降低了客户程序的效率。

异步数据传输是指，客户在发出数据请求后，可立即返回进行其它处理，OPC服务器在得到数据请求后，访问设备，读写数据后主动把采集的结果通知客户端。

这种传输机制的优点是：

可以避免空等待，提高了客户程序的效率。

OPC的异步数据传输又分为两种方式：

异步读写和订阅。

在订阅方式下，客户提出一次订阅请求，服务器将周期性采集数据，传给客户，直到客户取消订阅为止[3]。

如果客户程序想一直监视某些变量，则使用订阅方式较好。

在异步读写方式下，客户提出一次请求，服务器相应进行一次数据读写，然后通知客户，这次操作结束。

对于异步读写操作，服务器只是对要读写的组和项作一下标记，调用后就返回。

当服务器读写完成后，主动把数据通知客户端。

该过程需要调用服务器端IOPCAsyncIO（），IDataObject（）接口和OPC客户端的IAdviseSink（）接口。

OPC标准规定了Server和Group两种对象应该支持的接口。

下面是OPCDA2.03标准中的接口定义。

[12]

图2-5标准的OPCServer对象和Group对象

IUnknown：

COM标准接口定义，包括AddRef，Release和QueryInterface。

IOPCCommon：

处理错误字符串和本地化语言。

IOPCServer：

创建、获得和删除组，生成组的状态信息和错误信息。

IConnectionPointContainer：

支持连接点，客户可在Server关闭时获得通知。

IOPCBroweServerAddressSpace：

使客户获得Server包含的所有项的名字。

OPCGroup对象有七个接口，其中六个是必须的。

当客户创建组时，获得组的接口。

由于任何一个接口都可以从同一对象上的其它任意接口上查询，所以客户可以获得七个接口中任意一个并保持接口。

IUnknown：

所有COM对象都支持的接口

IOPCGroupStateMgt：

获取并设置组参数，例如名字、刷新频率、活动状态。

IOPCItemMgt：

负责添加、删除和设置参数，可通过ItemAttributEnumerator来列举项。

IOPCSyncIO：

同步读写。

IOPCAysncIO2：

异步读写，当操作完成后通知客户IOPCDataCallback接口。

IDataObject：

使用OPC数据流格式，在C/S间建立Advise连接。

自动化客户通过使用包装“wrapper”，访问OPCDA服务器。

wrapper在客户端进程内调用，将服务器提供的定制接口与客户端要求的自动化接口进行协议转换[13]。

DA3.0标准增加了IOPCBrowse等多个接口，并对以前版本中的部分接口做出一些修改[14]。