手机版
你好,游客 登录 注册
背景:
阅读新闻

OPC向UNIX的演进(OPC evolution toward UNIX)

[日期:2011-09-13] 来源:Linux社区  作者:guxch [字体: ]

一、摘要

面向过程控制的OLE(OPC)是一个工业应用领域内的中间件。它通常用来连接设备和更高端的控制系统(例如SCADA),自它1996年提出后,就被工业界所广泛接受。现在,它已成为过程监控事实上的标准。许多设备制造商都为他们的设备提供了OPC服务,这些“即插即用”的服务将设备信息整合到了整个监控系统中。

在极大简化系统整合者的工作的同时,一直以来OPC只能工作于MS windows工作平台之上,由于1.DCOM标准的开放性;2.XML OPC的引入;3.OPC UA的引入,上面的情况并不完全如此。本文将讨论各个解决方案-它的优点和缺点。最后,我们总结这些解决方案的测试数据。

二、与DCS的通讯

下图是DCS系统的数据流示意图。


通常,SCADA系统从各种不同的设备中获取数据,监控这些设备,并将综合信息传递给其它系统。光束状态信息(Beam status)来自与加速器(Accelerator),安全系统(Safety systems)和通用服务系统(general services)之间需要传递信息。另外,远程站点也要访问DCS,这些节点的信息交换是通过一种或多种通讯协议完成。开发、调试、维护这些通讯协议需要耗费大量的精力。

当需要与硬件设备通讯时,这个问题特别突出,这时,不同的通讯协议可能发生在1.不同制造商提供的设备之间;2.同一设备商的不同模块之间;3.同一设备不同的通讯协议版本之间。

因此,一种理想的解决方式是能用商业化的标准协议,来掩盖不同设备之间的差异。一种方案是使用中间件,它能提供一种通用的可以联系各软件(通常分布于各设备)的接口。CORBA,JavaRMI,DCOM就是现有的一些中间件解决方案。然而,它们要成为一种通用的解决方案,必须经过不同程度的进一步开发,才能用来获得设备的数据。这些开发可能以不同的方式进行,但是,在进一步引入协议之前,需要一个能处理这种协议的客户端。

已经进行了一些工作来使中间件标准化。2005年,OMG(Object Management Group)引入了一种将CORBA更专业化的标准来获取数据。但是,在这之前9年,OPC基金会引入了一系列面向过程控制的基于OLE的标准。

1、OPC的方案

OPC基金会成立于1995年5月,目的是创建一种适合于工厂应用的中间件解决方案。1996年8月,OPC基金会推出OPC数据获取标准1.0版,它采用MS的接口定义语言(IDL)描述了一系列用来获取和管理设备数据的接口,更进一步,它详细描述了一种数据模型,模型不但包括了设备数据,还包括诸如最大/最小值、数据描述、工程单位、时间戳等数据属性,这样,OPC用户就可以很容易理解他们接收到的数据。最好,这个标准提供了客户/服务和出版/订阅通讯模型。应用这些标准,开发着可以写出OPC-DA客户端和服务器端程序。

OPC-DA也有几个弱点,如只支持简单的数据类型,不支持命令;没有显式的安全支持等。经过近几年的发展,OPC基金会已经扩展了DA标准,并引入了额外的标准来弥补这些缺点。

OPC已经成为一个事实上的工业通讯标准,现在已经很难找到一个不包含OPC客户端的SCADA系统,购买一个通过OPC服务器来通讯的硬件设备是很平常的事。

2、对传感控制器的意义

在DCS中,购买一个采用标准方式控制的软件和硬件是一个很好的事情,它减少了为大量的不同设备开发和维护中间件的成本,但是,要注意,它不是万能药。

OPC依赖于DCOM的安全机制有配置问题-DCOM的安全机制难于理解,因此用户倾向于不使用或少使用安全机制。DCOM依赖的Windows注册表,被证明是脆弱的和易于崩溃的。Windows升级包(尤其是SP2)也增加了维护OPC服务器运行的复杂性。再者,OPC服务器越来越要承担在有限的时间内提供成千上万点的数据,OPC服务器的效率就成为最重要的事情。最后,可能更显著,控制系统天生就是不同的,通常,机器运行基于X86架构的Windows或Linux系统,但是,混用这些系统是存在的,由于使用了非Windows机器,就要求OPC服务器能在基于UNIX系统上运行。标准上的给出的答案是这种情况不可以,虽然事实上并非严格如此...

三、非Windows上的OPC

有几个方案解决OPC服务器在非Windows上运行的问题,我们现在依次来看看。

1. DCOM

MS于1996年11月公开了他们的DCOM标准,这导致出现了一系列在Solaris、VXworks和Linux等上面DCOM的实现方法,这些方法都以库的方式安装在目标平台上,开发者采用这些DCOM库,就可能提供运行于UNIX平台上OPC服务器。

我们关注这些实现方式,特别是它们在Linux下的性能和稳定性。为了测试,我们采用OPC基金会OPC DA2.05样例方法和AG公司的EntireX DCOM库,在Linux上实现OPC服务器,我们要对比在Windows XP下的同样的服务器,测试的方式是采用OPC-DA IOPCSyncIO读方法(这个方法允许客户端同时读取多个OPC点)读取1000个OPC点(浮点类型),取其平均值。下图给出了XP和Linux平台下,随着OPC点增加,读取时间的平均值。


我们能看到Linux实现要慢于Windows实现,有意思的是,Linux实现中,端到端的传输浮点数的流量,似乎最好为2.3Mbps(要说明的是,其它数据如时间戳、数据质量也要传输),尽管显得比较慢,每秒钟可以传送超过76000个点的数据。

我们的Linux实现有一些稳定性问题:1.DCOM库中转换多字节为“宽字节”的方法有问题;2.“Windows注册表"容易丢失存到里面的数据;3.DCOM依赖的DEC-RPC服务会突然失效(尽管它还在运行)-只有重新安装DCOM库才能解决这个问题。在Linux上OPC DA服务器实用之前,这些问题需要解决,而且是可以解决的。另一种在Linux上实现DCOM的方式是采用Open Groups的FreeDCE,与在Windows上的实现方式相同。

2. XML DA

2003年6月,OPC基金会发布了OPC XML DA标准,它非常类似于DOPC DA 3.0版,但它与之前的OPC标准不同的是,它不再使用DCOM作为传输层,而是采用基于HTML和SOAP的Web服务。采用这种实现方式,一个XML DA服务器可以嵌入Web服务器(如 Apache, IIS)中或独立运行。

由于HTML是一个普遍的协议,那么,实现XML DA标准的OPC服务器就有可能在任何支持HTML的平台上存在。XML DA将所有的数据采用XML字符串表达,对这种方式的效率就有一些忧虑。为了研究这个问题,我们采用了和上面DCOM比较测试中相同的方法,这一次,采用Read()方法(OPC XML DA 1.1中定义)获取数据。我们分别采用TechnoSoftware AG公司的Windows评估版OPC XML Server C++ Framework和OPC Client Framework.net。下图对比了我们采用XML读的结果和采用DCOM IOPCSyncIO读的结果。


我们可以看出OPC XML DA和OPC DA的性能有很大不同。采用其它更加有效率的编码方式(如base64或十六进制编码)可以提高XML DA的性能,但没有被XML DA标准所采纳。

另一个效率上的考虑是缺少一个真的“发布/订阅者”通讯模型。这被一个叫“轮询更新(polled refresh)”的方式所取代,它需要客户端每隔一段时间查询服务器来获得所订阅的OPC点的信息。OPC服务器可能保存客户端所关心的变化了的OPC点的信息,以至于在客户端轮询的间隔期,不丢失数据。如果客户端查询的周期慢于预设的周期,服务器就有可能释放那个客户端的所有资源。

在建造XML DA服务器时,我们发现用来解析WSDL文件(Web Service定义语言,描述了OPC Web服务)的工具不能总是产生正确的代码。Web服务依赖于XML、XML schema、SOAP和WSDL,这些都是复杂的标准,任何对这些标准的解析错误都能导致服务器端和客户端的不一致。这个问题不仅仅在OPC XML中存在,检验是否符合标准的测试也确实做过,但即使如此,依然有兼容性问题。

3. OPC UA

OPC统一架构(OPC UA)是OPC基金会最新的产品,它在2005年4月提出,细节仍制定中,它的目标包括:

  • 能够将企业级别的结构化的工厂端数据和internet整合在一起
  • 安全、可靠和高效的服务
  • 平台和协议无关性

它表达了使方案跨平台和整合到企业级别或更高级别的一种努力,这个架构将现存的OPC标准融合到一个前后连贯的标准中。各种对象(变量、属性、命令)通过服务完成。服务器提供服务并且相关的服务组成服务集(这种服务集的例子如数据获取服务集和订阅服务集)。

UA的目标是让DCOM“退休",而采用基于SOAP的方法替代DCOM,这个替代方法用WSDL定义接口并绑定HTML或TCP/IP。为解决XML DA的效率问题,UA将采用二进制编码。但最初,采用base64来编码SOAP envelope中的数据,当UA最终版时,base64被Message Transmission Optimization Mechanism(MTOM)所取代。

OPC UA的性能有待测试,但是,如果UA实现了它的目标,并且解决了XML DA发现的解析工具问题,对控制系统领域内或之外的通讯方法的使用,都是一件令人感兴趣的事情。


四、总结

1. 端到端的性能

关于在UNIX系统上实现OPC服务器的的问题,我们研究了Linux上DCOM以及XML DA的性能,但是,OPC协议的性能只是我们需要考虑的一个方面。

根据我们经验,”慢“OPC服务器不仅是由于OPC协议本身,而且还包括OPC服务器读取现场设备数据的方式-特别那些基于网络(以太网或现场总线)的设备。在这种情况下,有两个典型的方式:1.一个OPC服务器读取各个设备;2.通过网络帧读取多个值。下面两个因素就可能提高性能:

  • 在网络能力允许时,服务器可以并行向多个设备发出请求,而不是在得到回应之前等待。
  • OPC服务器可以根据网络帧成组读取设备,这样,OPC服务器就���需要每次为每个点发送帧,而是发送一次,更新相关所有的OPC点的信息。

2. 是否有用?

从上面我们可以看出,从技术上讲,UNIX类平台上都有可能实现XML和基于DCOM的OPC服务器,虽然它们都慢于Windows平台上的DCOM实现,但还是能满足多数DCS的数据速率要求。OPC的一个优势是设备制造商的支持,即如果买了一个设备,那么设备的OPC服务器是"白给"的,但这个OPC服务器要运行于Windows。虽然在Linux上有OPC服务器和客户端的开发工具,支持DCOM和XML ,但它们还没有被设备制造商和最终用户所接受,他们仍倾向于Windows平台上被证明能很好工作的DCOM方案,这样的结果就是,如果我们想要Linux上的OPC服务器,我们就需要定制开发。开发Linux上的基于DCOM的OPC服务器,主要基于两点:1.性能;2.SCADA系统中存在大量的OPC客户端,采用DCOM方式读取服务器。XML DA有可能是一种唯一的用来封装存在的基于DCOM的OPC服务器的方法,使OPC服务器能从Internet上访问。

本文中未涉及但值得研究的是Linux上的OPC DA客户端。它不应该太困难并使基于Linux的SCADA可以读取现在大量的OPC DA服务器。

五、结论

在不远的将来,我们继续会看到基于Window的OPC DA大量用于工业界,XML DA用在服务器需要被远程访问的场合,而不是主流的设备读取场合。XML DA有可以能被OPC UA所替代,因为UA承诺是一个更加安全、健壮、灵活和高效的,并且可以用于监控通讯各方面的方案。用户的接受程度将最终决定OPC UA是否替代OPC DA,成为一个新的多平台的事实上的标准。现在,如果我们需要Linux上的OPC服务器,我们可能需要自己开发。


参考文献

[1] Object Management Group, Inc., http://www.omg.org.
[2] http://java.sun.com/products/jdk/rmi/
[3] http://www.microsoft.com/com/default.mspx
[4] “Data Acquisition from Industrial Systems Specification – Version 1.1”, Object Management Group, Inc., June 2005
[5] “Data Access Custom Interface Standard”, currently v 3.0, OPC foundation, March 2003.
[6] “Congestion Control in IP/TCP Internetworks”, RFC 896, Network Working Group, John Nadle, 6 January 1984.

linux
相关资讯       UNIX  OPC 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款