OPC协议解析-关于OPC协议的几个问题

1    什么是OPC协议？

为了便于自动化行业不一样厂家的设备和应用程序能相互交换数据，定义了一个统一的接口函数，就是OPC协议规范。有了OPC就可使用统一的方式去访问不一样设备厂商的产品数据。

OPC基金会前先后后规定了不一样的接口定义，以下：

• OPC DA (Data Access, exchange of real-time values)

• OPC A&E (Alarms & Events, exchange of alarms and events)

• OPC HDA (Historical Data Access, exchange of historical values)

• OPC XML DA (XML-based exchange of real-time values)

2      OPC DA是什么？

OPC DA指代的是 OPC数据访问规范。它是由OPC基金会定义的其中一种通讯规范, 定义了实时数据如何在数据源和数据接收体（好比PLC, HMI）之间, 在不知道彼此特定通讯协议的状况下仍然进行交换、传输。

2.1     为何OPC DA如此受欢迎？它和过去的通讯协议有什么不一样?

OPC DA客户端/服务器结构服务器结构是OPC基金会界定的首个结构。在OPC DA 以前, 供应商的产品（设备、PLCs、HMIs）要求与这些产品相链接的任何设备或应用程序要自带“特制驱动”, 以在第三方通讯和所涉及的供应商产品之间进行数据传译。像这样基于“特制驱动”的通信存在许多问题, 其中最多见的有：成本高、将用户限制在某一特定供应商、因为每个特制驱动都有其独有的处理方式而形成配置和维护的困难、因为新设备和应用程序的层出不穷而形成难于更新。相比之下,OPC DA却能够与任何实时数据源相链接, 也不须要为数据源或数据接收端特制任何驱动程序。 所以, 数据接收器不须要了解数据源的本地协议或内部数据结构就能够进行读和写。

2.2     OPC DA规范是只有一种吗？

很难说是或不是。由于OPC DA规范由OPC基金会来维护, 它们已经通过屡次修订。主要版本包括:

年份     版本     备注

1996    1.0       初始规范。

1997    DA 1.0a      数据访问（DA）, 该名称用于区分与其并行开发的其它规范。

1998    DA 2.0 - DA 2.05a   多处规范澄清和修改。

2003    DA 3.0 进一步补充和修改。

考虑到有不一样版本的OPC 数据访问（OPC DA）规范, 关键问题是：这些版本反向兼容吗? 例如：OPC DA 1.0a 客户端是否能够与OPC DA 3.0 OPC服务器通信？答案是：这取决于具体状况。

2.3     数据访问OPC客户端及OPC服务器反向兼容性

开发商编写反向兼容的OPC客户端及OPC服务器是值得推荐的, 同时这也是能够实现的。然而, 由于反向兼容性是可选功能, 而不是强制功能, 这意味着会有许多开发商选择（而且会继续）开发仅仅遵循一种或两种规范的OPC DA服务器, 而不是遵循全部规范。这样的话, 那些非反向兼容的OPC服务器及OPC客户端仍然向用户提供OPC所带来的些许优点, 但仅仅局限于特定版本的规范。好消息是MatirkonOPC不只开发彻底反向兼容的OPC服务器, 也提供OPC数据管理产品（如： OPC Data Manager及OPC Security Gateway）。这些产品在非向后兼容的OPC客户端及服务器之间, 经过及时地在 OPC DA不一样规范之间转换实现彼此通信。

3      如何使用OPC 数据访问规范 (DA)

3.1     什么时候使用OPC DA？

简单的回答就是：用于须要传输实时数据的任什么时候刻。对于须要考虑的多种情形, 下表介绍了最多见的几种类型, 简述了一些难点, 并给出了利用标准OPC组件加以解决的相关建议。

数据源	数据接收端（用户）	OPC解决问题	相关建议
控制器（外部PLC）	应用程序（HMI）	不一样厂商的控制器均使用各自的通讯协议。OPC省去了HMI 针对各控制器“定制驱动器”的须要。	- 控制器：使用 OPC 服务器 for 控制器 X - 应用程序：一般有内置的OPC客户端。若是没有, 则可以使用适用于该应用程序Y的OPC DA 客户端。
控制器/设备	控制器或控制设备	备 OPC服务器为您解决了控制器之间的通讯, 由于各产品均采用各自厂商的通讯协议, 不一样于控制器与应用软件间的通讯。	- 数据源端、数据接收端的控制器X和Y分别需使用OPC DA服务器 for X和OPC DA 服务器for Y。 - 使用 OPC Data Manager, 在两控制器间实现有关实时数据的智能化传输。
控制器/设备	关系数据库	关系数据库利用“结构化查询语言”（SQL）经过“开放数据库互联”（ODBC）协议进行通讯；而控制器和控制设备则利用各自的自定义协议。找到一个贯穿二者的数据桥并不是易事, 一般须要必定的技术经验才能创建起来。	- 利用 OPC DA Client for ODBC 从OPC服务器中获取实时OPC数据, 经过SQL/ODBC将其准确地传输到数据库。 - 利用 OPC DA 服务器 for 设备 X 公开数据。 - 注：OPC DA为双向式通讯, 所以在必要时, 也可将实时数据从数据库写入设备或控制器中, 或将应用程序的数据写入OPC客户端。
控制器/设备	过程历时数据库（Historian）	过程历史数据库采集的是实时数据, 它们一般有本身的通讯协议和自定义驱动来收集各类设备或应用程序的数据。这里的难点是找到一个历史数据库不只支持现有设备还要支持未来可能出现的数据源。	历史数据库有其本身的标准协议, 且几乎全部的historian都有内置OPC DA客户端。 OPC Desktop Historian 就是这种有内在OPC接口历史数据库的其中一个。 - 对于数据源：用一个用于数据源X的 OPC DA服务器便可。
冗余的设备	控制器/应用程序	按照传统的方式, 若是控制器或应用程序不支持设备级冗余, 为保证设备的冗余性, 额外的硬件是须要的。	- 对控制器：须要用于控制器X的OPC服务器。 - 不一样的设备可使用不一样的OPC服务器。 - 使用 OPC Redundancy Broker (ORB) 来实施冗余机制。 - 对应用程序（如：HMI或Historian）：能够用 OPC客户端用于应用程序X。
远程设备（数据采集与监视控制系统）SCADA:例如，远程终端控制系统RTU	应用程序/控制器	因为通信故障和低频带宽, 与远程设备和数据来源之间的通讯通常较为复杂, 同时也更昂贵。而自定义驱动程序的问题在于不一样通讯渠道的稳定性难以保障	远程设备应该选择SCADA类的OPC服务器。跟通常现场应用的OPC服务器不一样, 这类OPC服务器是专门为适应复杂的SCADA工做环境而设计的。（例如, MatrikonOPC Server for SCADA Modbus)

 

3.2     能够用OPC DA传输历史数据吗？

不能。任何OPC DA都是专用于传输当前数据的。一旦当前数据已经被读, 下一数据的读取就会开始, OPC DA没有为OPC DA客户端提供历史数据的接口。若是要传输历史数据, 须要使用一样基于 OPC客户端-服务器结构 的OPC历史数据存取规范（OPC HDA）。

3.3     同一供应商生产的OPC DA客户端程序可与不一样供应商的OPC服务器搭配工做吗？

通常状况下是能够的, 在OPC DA客户端与服务器都支持一样版本的OPC DA规范（见上文）或者至少其中一个可以反向兼容的条件下。

4      OPC客户端-服务器结构

OPC 通讯结构是指包含一个或多个OPC客户端与服务器相互通讯的集合。最简单的理解方式, 即是读懂以下这张数据流程图。它显示了数据由数据源从下至上到达数据接收体的过程。

 

OPC 服务器：在这个例子中, 若是数据源有一个内在的OPC客户端, 那么外在的OPC客户端就不是必须的了。

OPC 通讯：由于OPC基金组织定义了多种 OPC通讯规范 保证能够传送不一样形式的数据信息, 因此OPC开发商和用户必须理解OPC服务器和客户端的通讯有时候不局限于单一的数据访问形式。这个概念的理解之因此重要, 是由于同一种OPC服务器每每会支持多于一种的OPC数据访问规范。