组件对象模型(COM)/分布式组件对象模型(DCOM)的终止

传统OPC应用之间的数据交换是基于微软的组件对象模型(COM)技术。因为视窗(Windows)操作系统在世界范围内得到了广泛的应用，同时也促进了视窗计算机在自动化中的使用，所以COM技术也为OPC技术的广泛使用创造了条件。在2002年初，微软发布了新的.NET框架并且宣布COM技术的停止研发。虽然这不意味着将来的视窗操作系统不支持COM，但作为停止的结果，传统OPC开放通讯协议（OPC）的基础技术已经不再发展，或早或晚要被淘汰，所以要寻求新的替换方案。

COM的局限

上世纪90年代，随着视窗计算机的普及，微软COM/DCOM技术引入的一组特性，得到了家庭计算机用户和工业自动化用户高度欣赏。这些特性包括了拷贝与粘贴、拖拽与投放、链接与嵌入。DCOM还提供了一套完整通信基础设施，并带有必要安全机制，如授权、鉴权和加密。但DCOM安全机制同时也对安装工程师、系统集成商和开发者管理项目提出了挑战，其中包括跨越PC远程访问数据和程序正确设置DCOM安全功能非常困难需要专业知识。

OPC通信穿过防火墙

在自动化行业很早就认识到OPC通信需要跨越计算机边界，这是另一个限制传统OPC通信的地方。DCOM需要多个端口，如鉴权传输数据以及一系列服务建立连接所以，在防火墙中不得不打开很多端口才能让DCOM通信穿过他。在防火墙上每打开一个端口都是一个潜在安全隐患，为黑客攻击提供一种可能性。而OCUA中的隧道技术是一种被广泛接受策略解决了传统OPC产品中DCOM限制的问题。

在非视窗平台使用OPC

在工业应用中几乎“无所不在”的微软平台把DCOM作为操作系统的一个组件是传统OCP能被快速接受的一个重要因素。但是在IT行业常用Unix或者Linux系统就是这种情况。

通过Web服务实现跨平台 OPC 通信

随着2003年发布 的 OPCCXML-DA 规范， OPC 基金会第一次展示了一种独立于 Windows 平台而克服 DCOM 限制方式今天许多 OPCCXML-DA 产品演示基于 Web 服务 的 OPC 技术但是 XML-DA 通信速度比 DCOM 慢大约5至7倍这个速度对于许多自动化要求来说太慢了

统一数据模型

迄今为止 traditionals' s OP C 技术已有3种不同的 OP C服务器 - 数据访问服务器 报警 与事件服务器 和历史数据访问服务器 如果用户想要获取一个温度传感器当前值一个温度超过限定值事件以及温度历史平均值 那么他必须发送三个请求 访问三个服务器 用户访问过程数据事件及历史数据用不同的方法花费大量时间 所以 统一 这些 对象 模型 可以使这样事情变得简单 不仅对 OCP 产品供应商 有利 也对 系统 集成 商 及 用户 有利

支持复杂结构

O PC 的主要 应用 是 对串行 通信 或者 现场 总线 联网 设备 的配置 监控 以 配置 设备 O CP 客户 需要写入 数据类型 经过 OCP 服务器 到达 设备 包括 数据结构 元素 意义

8 保证 无丢失

最 早 定义 的 数据 访问 能够 让 客户 应用 程序 周期 获得 过程 数据 当前 状态 如果 在 OCP 客户 端 和 远程 O CP 服 务 器 之间 物理 通信 连接 发生 了 故障 数据 通信 会 受损 当 通信 丢失 时 转移 到 O CP 客 户 端 数 据 将 发 生 改变 而 或 丢失

9 增加保护

随着 自动化 行业 基于 以太 网 工作不断增长 自动化 和 办公室 网络 已经纠缠 在 一起 同时 垂直 集成 想法 引发 了 新 需求 这 种 类型 集成 也 带 来 了 新 安全 风险

10 支持 命令 调用

很多 应 用 中 不仅 只 要 阅读 写数 值 非常 重 要 还 有 执行 命令 非常 重 要 如 启 动 停止 一 台 驱动器 下载 文件 到 设备 中 OCUP命令规范定义执行这些命令方法但只能用于OCUA不能用于传统OCP