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產品的供應商有利，也對系統集成商和用戶有利。