OPC解决I/O驱动问题

在工厂自动化中，有许多不同的设备、协议和工业网络标准。因此，每个软件供应商都负责从自动化应用程序连接到其他供应商的硬件产品。另一个复杂的问题是，这些设备和协议一直在发展。

通过Al Chisholm, OPC基金会一九九八年五月一日

关键字

控制软件
先进控制
嵌入式控制
过程控制系统

栏:
条款

在工厂自动化中，有许多不同的设备、协议和工业网络标准。因此，每个软件供应商都负责从自动化应用程序连接到其他供应商的硬件产品。另一个复杂的问题是，这些设备和协议一直在发展。这些持续的更新需要频繁地维护软件。

用户利益

为了解决这个问题，最初的OPC(过程控制OLE)基金会的工作组制定了OPC数据访问规范。该规范定义了工业自动化的标准接口，允许软件和硬件设备驱动程序简单地“即插即用”。

开发OPC数据访问规范标准的过程始于OPC工作组中的少数几家公司。OPC基金会包括大约140家国际公司的成员，这些公司目前正在解决最初的OPC工作组所提到的I/O驱动程序问题。缺乏已定义的标准接口会消耗工程资源，从而影响供应商，也会使系统中设备和软件组件的混合和匹配变得更加困难，从而影响最终用户。

创建一个行业标准是具有挑战性的。在制造业中有一个很大的安装基础，供应商不愿意让它过时。然而，OPC工作组相信，解决这个I/O驱动程序问题将使供应商和用户受益，而不会减少供应商的竞争。

为什么COM ?

OPC基金会的第一个决定是定义技术基础。它应该是平台(操作系统)中立和/或语言中立吗?大多数企业已经基于微软的Windows操作系统，因此基于微软标准的OPC基金会是有意义的。鉴于此，微软的组件对象模型(COM)似乎是唯一合乎逻辑的选择。COM是:

已经建立的技术;分布式组件对象模型(DCOM)正在开发中。看来COM/DCOM将为OPC工作提供良好的技术基础。使用COM作为管道将最大限度地减少OPC工作组和使用OPC标准的供应商需要重新发明和重新设计的软件基础设施的数量。
在性能上有吸引力。由于之前与DDE(动态数据交换)和OLE 1.0相关的性能问题，经常会问及OPC的性能问题。首先，底层技术COM从根本上不同于DDE或OLE 1.0，而且效率高得多。每个协议都包含一定程度的高而不可避免的开销。然而，COM允许在客户机和服务器之间创建连接，其中开销基本上为零。在最近的测试中，每秒有100万个正值在进程中OPC服务器和客户端之间移动。
容易扩展。使用COM，供应商可以很容易地在不影响已定义的OPC接口的情况下添加功能。通过定义附加的特定于供应商的接口，可以简单地添加功能。因此，供应商可能会增加独特的功能和价值，或者只是解决安全等问题，同时保持与其他OPC产品的兼容性。

OPC对象模型如何工作

OPC基金会开发了一个基于COM的对象模型。解决方案类似于NETBIOS、WINSOCK或DDE。创建了一组api(应用程序接口)，以通用的方式移动数据，而不指定底层监视或控制系统提供的功能细节。

接下来，基金会定义了公开数据的性质以及应用程序如何引用这些数据。最灵活的方法是定义一个非常擅长公开“命名数据项”的接口，如PLC42:R40001或FIC101.PV。最简单、最通用的方法是允许用户最初以字符串形式传递项目的名称，其中字符串的格式完全是特定于供应商的(也就是说，对客户端来说是“不透明的”)。在初始注册之后，这个名称被解析为一个“句柄”，以实现更有效的读写。

接下来，工作组确定向客户端返回数据的二进制格式。工作组选择了一种名为Variant的数据类型。虽然此数据类型非常适合返回单个值，但如果将来定义了这些值，它也可以用于返回数组和结构。使用当前的规范，变体还可以用于在供应商的服务器和客户端之间移动特定于供应商的数据。

在解决了命名和数据类型之后，剩下的问题是如何组织COM/OPC对象来输入名称和检索值。为了做出这个决定，研究了典型应用程序的需求，如人机界面(HMI)、报告、历史和趋势应用程序。

定义标准接口的一个目标是使接口非常有效且易于集成，从而使供应商希望将其用作主要接口，而不是像DDE那样将其作为附加组件来支持，从而使性能最大化。因此，这需要主要关注c++用户。

然而，工作组还希望允许用Visual Basic编写快速而简单的应用程序。经过大量的实验和争论，该部队指定了一个自定义c++接口作为主要数据路径，并指定了一个更简单的自动化接口供Visual Basic使用。VB接口将被创建为c++接口的“包装器”，就像微软的RDO(远程数据对象)是OLE/ODBC(开放数据库兼容)接口的包装器一样。

OPC，不断发展的接口

在开发已定义的标准接口时，OPC需要处理多个客户端以多种方式访问数据。这些客户端可能包括多个操作员显示窗口、报告和趋势组，它们在不同的时间以不同的速率需要不同的数据。这种需求导致了OPC组的发明。客户端可以根据每分钟或每天的需要动态地创建、使用和删除这些组。它们类似于OLEDB等接口所使用的行集。

最初OPC主要关注过程I/O设备、监控和数据采集(SCADA)或分布式控制系统(dccs)之间的连接，如前面提到的相关“I/O驱动程序问题”。优先考虑的是使这个接口尽可能灵活和高效。因此，指定的接口可以在SCADA、DCS引擎和高级应用程序之间工作。DCOM的发展使得在网络上使用OPC接口成为可能，部分原因是COM的工作方式。

在撰写本文时，OPC数据访问2.0规范工作已接近完成。这项工作涉及到对原始OPC规范的微小更新。更改的目的是在不改变范围或有效性的情况下向原始工作添加功能。

由于OPC基金会成员多次要求扩大OPC的工作范围并取得成功，在历史数据访问(由Fisher-Rosemount的Dave Rehbein领导)、警报和事件消息传递(由Al Chisholm领导)、安全控制(由Fisher-Rosemount的Neil Peterson领导)和批量数据访问(由Joe Bangs领导)等领域也活跃着其他工作组。

OPC标准的结果是，供应商将花更少的时间在设备接口的微利重新设计上。这种情况将通过来自不同供应商的OPC工具包的可用性得到进一步改善。

例如，使用OPC工具包就像在CD上获得熟练的劳动力。OPC工具包的设计是为了显著减少开发时间。独立的现场试验表明，驱动程序的开发时间大幅缩短至两天。