OPC向UNIX的演进（OPC evolution toward UNIX）

原文由Beharrell, Mark (CERN) ; Barillère, Renaud (CERN)发表于23 Sep 2005，标题为“OPC evolution toward UNIX (from Windows to world-wide domination?)”（http://cdsweb.cern.ch/record/922755）

一、摘要

面向过程控制的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.