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

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

　　2. COM 的局限

　　上世纪90年代，随着视窗计算机的普及，微软COM/DCOM技术引入的一组特性，得到了家庭计算机用户和工业自动化用户的高度欣赏。这些特性包括了拷贝与粘贴，拖拽与投放，链接与嵌入。DCOM还提供了完整的通信基础架构，并带有必要的安全机制，诸如授权、鉴权和加密。DCOM安全机制能够实现计算机对数据和程序的远程访问。但DCOM安全机制同时也对安装工程师、系统集成商和开发者管理项目提出了挑战，其中包括了跨越PC的OPC通信。正确地设置DCOM安全功能是非常困难的任务，需要很多专业的知识。作为结果，安装工程师和系统集成商会例行公事地选择快速流程，在所有连网的OPC计算机采取宽松的访问授权，造成大多数保护不起作用且允许非授权远程访问。这种做法与信息技术(IT)安全的要求相违背。在长期运行时，可能会有粗心大意者或者蓄意破坏的人造成损害的危险。DCOM安全设置常常需要一种特别才能，而配置OPC通信功能则非常容易。

　　3. OPC 通信穿过防火墙

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

　　4. 在非视窗平台使用OPC

　　在工业应用中，几乎“无所不在”的微软平台，把DCOM 作为操作系统的一个组件是传统OPC能被快速接受的一个重要因素。但是同时，OPC的集成概念在使用其他操作系统时就不灵光了，因为他们不支持DCOM。比如在IT行业，常常使用Unix或者Linux系统就是这种情况。

　　自动化也是这样，有的应用领域明确拒绝使用视窗操作系统。嵌入式设备领域是另一个视窗很难(除了视窗CE或者嵌入XP)涉及的领域。这里，复杂的应用直接嵌入到现场设备、PLC、操作屏和其他设备之中。他们运行VxWorks、QNX、嵌入式Linux、RTOS或者其他嵌入式操作系统而没有DCOM。在这些领域里使用OPC 的集成概念注定要失败，因为OPC需要DCOM作为技术基础，而这个基础在嵌入式系统中正好缺失。

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

　　随着在2003年OPC XML-DA规范的发布，OPC基金会第一次展示了一种独立于视窗平台的方式和克服DCOM限制的方法。今天，很多OPC XML-DA产品演示了基于Web服务的OPC技术。但是XML-DA 通信的数据吞吐量还是比不上DCOM，通信速度要慢5到7倍。这个速度对于很多自动化的要求而言是太慢了。基于Web服务的OPC通信功能还是有用的，因为实现了跨越操作系统的能力，但还要进一步提高数据传输性能。

　　6. 统一数据模型

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