服务热线:
您当前的位置:首页 > 知识库 > OPC 技术

基于OPC和OPC-XML的企业综合自动化的应用研究

2011/9/8 15:13:47

 

[摘 要]


    OPC和XML的结合,实现从工厂底层的监控和控制系统到较高级别的企业应用程序整个工业信息系统的纵向信息集成,同时也使OPC由基于单一的Windows操作系统向跨平台的应用迈出了一步。在OPC和XML的基础上,研究了基于OPC和OPC XML的系统模型,简化了工业信息系统不同层之间数据共享和交换的方法,为今后企业的更高层次的系统集成提供了基础,促进了企业综合自动化的实现。

    企业在实现综合自动化时,采用OPC技术,但是,在企业上层以及在企业间网络实现自动化信息集成存在不足之处。随着XML及其相关技术和应用的发展,XML不仅成为了应用间交换数据的一种标准,也是万维网重要的信息交换标准和表示的技术之一,OPC—XML正是利用XML的特点实现企业上层的信息集成。如何结合二者优势来实现整个企业的综合自动化,是本文的研究重点。

1 相关技术

1.1 OPC技术的研究
    OPC技术由于其标准性、开放性和灵活性而逐渐成为过程控制领域的软硬件接口标准,OPC在工业控制底层的局域网范围内提供了不同硬、软件供应商的硬件和软件间以及企业应用程序间的接口标准,解决了控制系统与各种现场设备间的互操作性问题,实现了自动化数据的高性能交换,是解决开放性企业信息集成的重要途径。目前,Internet的蓬勃发展为工业控制带来了巨大的契机。企业信息化的范围也随之从企业内部扩展到企业供应链甚至全球范围。但是OPC规范是基于COM/DCOM的,它的局限性大大限制了OPC进一步的发展及其在集成领域中的高层应用,主要具体问题为:
    1)缺少跨平台通用性。COM/DCOM技术作为微软的基于对象RPC机制,实现微软Windows环境中的跨组件、跨过程和跨机器的通信。
    2)较难与Interrier应用程序集成。端口80是为HTTP网络通信保留的,但是DCOM不使用端口80,这样导致了基于DCOM传输的数据会被防火墙阻塞。
    3)较难与企业应用程序连接。因为DCOM要求服务客户端与系统提供的服务本身之间必须进行紧密耦合,即要求一个同类基本结构。

1.2 OPC—XML规范的研究
    XML是Web数据使用的通用语言,它具有高度结构化、规范化、简洁化和可扩展性、便于网络传输等优势。XML能够让软件开发人员将来自于各种应用程序的结构化数据传送给操作员站桌面,以便在本地或远程计算机上进行计算和显示。XML允许为特殊应用程序创独特的数据格式。同时,它也是结构化数据从服务器到服务器传输的理想格式。XML是分布式自动化控制系统之间实现多种数据传输的一种手段。
    企业发展对数据的进一步的需求迫切要求将XML和OPC两者结合起来,优势互补,为企业数据集成提供新的解决途径。OPC基金会于2003年7月12日发布了一种新标准——OPCXML-DA Specification Version 1.0PC XML定义一组通过互联网访问工厂现场数据的工业标准接口,并提供即插即用的可连接性和多个厂商产品的互操作性等功能,降低了企业信息与互联网应用集成的难度,同时也使OPC由基于单一的Win-dows操作系统向跨平台的应用迈出了一步。它采用XML和SOAP来暴露工厂底层数据的接口规范。这些数据内容与基于COM的OPC DA表示的数据内容一样。与DCOM不同的是,XML是一种万维网组织的规范,它基于Internet协议,并具有平台无关性。XMl简化了应用程序间的互操作性,并允许在更高层次上共享和交换数据。由于XML和SOAP是Web Services的基本组成部分,OPC XML DA实际上描述了一个XML WebService。
    XML DA是实现与Internet应用程宇集成和跨平台的数据交换的最佳方式,如图1所示。
由于OPC XML DA规范是基于XML的,XML的特点解决了COM/DCOM所不能解决的问题。同时,为了保证OPC的互操作性,在定义XML schemas的基础上,还采用了SOAP和WSDL两个标准协议图1 OPC XML DA的体系结构来保证多家厂商的通用性。首先SOAP(简单对象协议)建立在XML的层之上,接着WSDL(WEB服务描述语言)是建立在SCAP层之上。这些定义建立了真正的互用性。

 


    OPC XML DA在具体应用上还有以下几点不足之处:
    1)OPC DA客户端需要有较高的速度去访问设备,但是XML表示数据的复杂性,使得数据在传输过程中无法满足实时性的需要,同时,网络延时,又进一步影响客户端的高速访问;
    2)现有的OPC商家大多提供了0PC COM服务器,如果放弃现有的DA服务器而设计XML DA以得到一个统一的系统,将要花费很大的代价。
   
2 基于OPC和OPC—XML的系统模型
    根据OPC XML—DA和OPC DA各自的特点,将两种规范结合起来,OPC DA在局域网内提供高性能的现场数据交换,XML DA解决远程访问问题和跨平台访问问题。XML DA标准允许对现有的OPC COM服务器进行包装集成,两种标准都描述了相同的数据集合的接口,这为我们解决问题提供了可能性。在两种标准之间需要一个中间件服务器(或称为包装器),将OPC DA服务器包装(Wrapper)成XML DA服务器,在整个系统模型中,OPC DA服务器仍作为OPC DA服务器在LAN内供OPC DA客户访问,OPC XML DA服务器供远程的或跨平台的XML客户访问(图2所示)。在整个企业集成系统中OPC和XML实现了系统各个层次间的通信和工厂底层到企业高层应用程序间数据的无缝集成。
    系统模型中,低层的OPC DA Server和顶层的OPC XMLCIient实现起来比较简单,本文的重点是如何实现二者的转换,它主要分为:OPC DA Client层,OPC DA映射层,XML DAServer层。同时,为了对现场系统的多个OPC服务器进行统一管理和对各种数据的统一表示,还需要将各种各样的数据格式转换成统一的数据结构,用固定的结构层次来表示。在统一数据后,再把数据以XML消息的方式提供给远程应用或各种操作系统平台上的应用程序。

 

2.1组态功能模块
    由于各种现场系统的数据结构下同,因此,相应的OPC服务器给出的数据结构也不相同。比如,OPC基金会提供的两个OPC服务器的数据结构就有差别。OPCJ.DADemoServer.1的数据结构仅一个层次,如“SVl”,而OPCJ.SampleServer.1的数据结构是具有三个层次,如“BCH6.BCH63.BCH631”。

 

    为了对OPC Server的统一管理,必须把各种现场数据重新组织成统一的结构。MOX定义了自己的数据结构:“标签集+标签”构成的二级层次结构。其中标签对应着数据源,通过OPC服务器与实际数据源相连;标签集是具有联系的标签的集合。标签集的属性包括:名称、说明、区域号;标签的属性包括:名称、说明、数据类型、对应的服务器,ID,OPC数据项、采集周期、读写权限属性等。这些功能由一个SQL Server2000应用程序实现,即组态程序。所有有关标签集和标签的信息保存在SQL Serv—er2000数据库中。

2.2 OPC DA client模块
    各种现场系统提供了OPC服务器,这些OPC服务器提供了开放的标准OPC接口,OPC客户端与这些OPC服务器通信,实现对异构数据源(DCS、PLC、各种现场总线系统及设备仪表)的数据访问。现场的OPC服务器根据COM原理可以以三种形式存在:进程内OPC服务器、本地OPC服务器、远程OPC服务器,必须能够与各种情况下的OPC服务器进行通信。与底层OPC DA服务器的通信包括同步读/写、异步读/写、数据订阅以及获取服务器运行状信息等方面。

2.3 OPC DA映射器模块
    从功能上看,OPC DA映射器模块二重角色:作为OPC客户瑞与OPC DA服务器通信获得现场系统的数据;作为Web服务器与远程客户通信提供数据访问服务。远程客户与系统绑定后,应将客户端发出的SOPA请求和信息通过OPC DA映射器模块转换为对具体OPC Server的访问。OPC DA映射器在完成上述过程时:一方面,为了提高数据访问性能和降低网络负担,OPC XML—DA规范将原先的OPC DA规范的功能从60余种减少到8种,也就是用8种复杂的相对独立的功能代替60种简单的相互关联的功能,因此MOX在处理客户的某个方法调用时需要通过映射器将此方法映射为对底层OPC DA服务器的一系列相关功能的请求;另一方面,由于两个规范在一些数据类型的定义上还存在一定的差别,因此需要映射器进行数据类型的转换。OPC DA映射器相当于一个桥接的作用实现OPC DA的请求及信息与OPC XML DA的请求及信息的相互转换。

2.4 XML DA Server模块
    XML DA Server实际上是根据OPC XML DA规范设计的一个XML Web Service,提供标准的服务接口,并通过基于XML的SOAP协议与远程各种平台上的应用程序进行数据交换。

3 OPC和OPC—XML的企业综合自动化中的应用
    将上述系统模型应用于企业信息集成,实现企业综合自动化时,其系统结构示意图如图4所示。可以看出由现场总线、PLC和DCS构成了现场控制层,现场控制层位于整个企业信息系统的低层;与现场控制层相连的OPC服务器以及本地计算机构成过程控制层,它是通过OPC DA规范实现的;然后利用OPC XML DA规范实现企业信息集成的上层——生产管理层,以及通过Internet企业网间的访问,实现整个企业的综合自动化,下面对系统做了两个方面的测试。

 

3.1 GetStatus服务测试
    客户端是采用VB.NET创建的Windows应用程序,添加Web服务的代理类,在"Web References"形成“OPCXML”引用,并产生三个文件“References.map”、“servicel,diSCO’和“service1.wsdI”。GetStatus方法的部分代码为:
    在Localeld和ClientRequestrHandle对应的文本框中输入请求的参数,然后点击“GetStatus”,返回的结果将显示在相应的文本框中,返回的信息包括所连接的OPC DA服务器的厂商信息、版本信息和服务器的运行状态信息等重要现场信息,如图5所示。

 

3.2 Read服务测试
    Read功能的测试比GetStatus的测试要复杂得多,这主要是因为Read方法提供的功能比较全面,在一次调用中,客户的请求信息和系统的Read返回信息都比较多。这样实现Read方法主要是考虑到网络性能的问题。因为此时客户和系统所在服务器是互联网上的两个节点,如果多次的连接传输少量的信息无疑会增加网络负担,所以采用一次连接传输大量数据的策略。
    应用程序的创建和对系统服务的引用与GetStatus中介绍的基本一样,调用Read方法的部分代码:
    返回的信息包括所连接的OPC DA服务器的项所对应的数据源的数值信息、时间戳和品质等重要现场信息。
    通过对系统的Getstatus和Read两个服务的测试,验证了基于OPC DA和OPC XML DA系统模型,能够将现场系统各个OPC DA Server的运行状态信息和现场系统中的数据源的值供给企业高层应用程序,能够解决基于Internet的数据交换问题,并具有语言无关性。

 

 


企业邮箱  |  法律公告  |  隐私保护  |  联系我们  |