Advosol 为开发适用于所有 OPC 规范的 OPC 服务器提供工具包。
- Classic OPC DA, AE
- OPC UA
服务器由处理 OPC 客户端接口的通用部分和处理设备的应用程序特定部分组成。
应用程序特定的服务器部分可以使用 C# 或 Visual Basic .Net 开发为 .Net 程序集。 相同的自定义 .NET 插件程序集可用于 Classic OPC (DCOM) 或 OPC UA 的不同工具包。
相同的定制插件程序集可用于在 32 位或 64 位模式下运行的服务器。
XML DA 和 UA OPC 规范自 2003 年以来就已经存在,但大多数已安装和新开发的 OPC 应用程序仍使用基于 DCOM 的 Classic OPC,主要是 OPC DA(当前数据),较少的 Alarm&Events (AE) 和历史数据访问 (HDA)。 DCOM 有通信限制,但对于大多数应用程序来说已经足够了。 对于本地连接(同一台机器上的服务器和客户端),DCOM 提供最佳性能,隧道和桥接产品可用于 DCOM 无法处理或配置过于复杂的情况。
基于 Web 服务的 OPC 规范没有 DCOM 的通信限制,但可能需要转换器服务器,因为大多数已安装的 OPC 应用程序都是经典 OPC。
通常可以根据个人喜好选择 OPC 规范,但有些情况需要特定的 OPC 规范或排除一些不可用的规范。
-
通过 Internet 或特殊通信链接进行远程访问
在这样的环境中,经典 OPC 只能与以下设备结合使用:
- 使通信供应商特定的隧道解决方案
- 转换为 XML DA。 XML DA 转换器 易于配置,但提供有限的安全选项并且仅支持 OPC DA。
- 转换为 UPC UA。 UA 转换器可以针对更广泛的通信要求进行配置,但配置需要了解通信安全功能。
-
需要多平台能力。
OPC UA 专为多平台使用而设计。 经典 OPC 依赖于仅在 Windows 中受支持的 DCOM。 基于 Web 服务的 OPC 规范可以在不同平台上实现,但通信功能仅限于两个平台支持的功能集。
无论为应用程序选择何种 OPC 规范,都可能需要转换器服务器,因为在不同规范上实现的应用程序需要进行通信。
转换器服务器产品适用于大多数组合。
实施 OPC 规范以最大限度地减少对转换器的需求是一种很好的做法。 由于涉及两种不同的通信类型,转换器往往会使设置和配置复杂化。