如何使用OPC 数据访问规范 (DA)
何时使用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)
|
可以用OPC DA传输历史数据吗？
不能。任何OPC DA都是专用于传输当前数据的。一旦当前数据已经被读, 下一数据的读取就会开始, OPC DA没有为OPC DA客户端提供历史数据的接口。如果要传输历史数据, 需要使用同样基于
OPC客户端-服务器结构 的OPC历史数据存取规范（OPC HDA）。
同一供应商生产的OPC DA客户端程序可与不同供应商的OPC服务器搭配工作吗？
一般情况下是可以的, 在OPC DA客户端与服务器都支持同样版本的OPC DA规范（见上文）或者至少其中一个能够反向兼容的条件下。
|