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服务器为您解决了控制器之间的通信, 因为各产品均采用各自厂商的通信协议, 不同于控制器与应用软件间的通信。 |
- 数据源端、数据接收端的控制器X和Y分别需使用OPC DA服务器
for X和OPC DA 服务器for Y。 |
|
控制器/设备 |
关系数据库 |
关系数据库利用“结构化查询语言”（SQL）通过“开放数据库互联”（ODBC）协议进行通信；而控制器和控制设备则利用各自的自定义协议。找到一个贯穿两者的数据桥并非易事, 通常需要一定的技术经验才能建立起来。 |
- 利用 OPC
DA Client for ODBC 从OPC服务器中获取实时OPC数据, 通过SQL/ODBC将其准确地传输到数据库。 |
|
控制器/设备 |
过程历时数据库（Historian） |
过程历史数据库采集的是实时数据, 它们通常有自己的通信协议和自定义驱动来收集各种设备或应用程序的数据。这里的难点是找到一个历史数据库不仅支持现有设备还要支持将来可能出现的数据源。 |
历史数据库有其自己的标准协议, 且几乎所有的historian都有内置OPC DA客户端。 OPC Desktop Historian 就是这种有内在OPC接口历史数据库的其中一个。 - 对于数据源：用一个用于数据源X的 OPC DA服务器即可。 |
|
冗余的设备 |
控制器/应用程序 |
按照传统的方式, 如果控制器或应用程序不支持设备级冗余, 为保证设备的冗余性, 额外的硬件是需要的。 |
- 对控制器：需要用于控制器X的OPC服务器。 |
|
远程设备（数据采集与监视控制系统）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数据访问规范。