The Challenge--挑戰                                                    作者：劉珍坤 先生

由於早期網路的不發達，所有的控制點必須拉線到主控制器來做控制，如果點數很多時，控制盤內就會有非常多的控制線，也相對增加配線人員接錯點的機率，維護或查線起來也會非常困難。

分散式控制系統則採用將控制器分散在各區域做獨立控制，且控制器間以網路連接可作連鎖控制，另外還有一種方式是用Remote I/O的方式將各區的控制點各自集中，再透過網路將訊號傳到主控制器，主控制器就可將這些遠端的控制點當成自己近端的點來做控制。

由於監控系統的規模愈來愈大，不同廠家所生產的現場設備的種類也在不斷地增加，而不同廠家所提供的現場設備的通訊機制也並不盡相同，所以電腦監控系統軟體需要開發的硬體設備通信驅動程式也就越來越多，造成了硬體設備通信驅動程式需要不斷開發的現象。以硬體設備通信驅動程式開發商來說，同一種硬體設備的通訊協定，也必須因不同的電腦監控系統軟體而需修改程式以供其使用。

OPC技術標準

基於COM/DCOM技術的OPC技術，提供了一個統一的通訊標準，不同廠商只要遵循OPC技術標準就可以實現軟硬體的互操作性。OPC（OLE for Process Control）是為過程控制專門設計的OLE技術，由一些世界上技術佔領先地位的自動化系統和軟、硬體公司與微軟（Microsoft）緊密合作而建立的，並且成立了專門的OPC協會來管理，OPC協會負責OPC規範的制定和發佈。OPC提出了一套統一的標準，採用典型的Client/Server模式，針對硬體設備的驅動程式，由硬體廠商或驅動程式開發商完成，提供具有統一OPC接口介面標準的SERVER程序，軟件廠商只需按照OPC標準編寫CLIENT程式來讀/寫SERVER程式，即可實現與硬體設備的通信。

OPC Server 的優勢與部署

與傳統的通訊開發方式相比較，OPC Server 的優勢是：

n       硬體廠商熟悉自己的硬體設備，因而設備驅動程序性能更可靠、效率更高。

n       軟體廠商可以減少複雜的設備驅動程式的開發週期，只需開發一套遵循OPC標準的程序，就可以實現與硬體設備的通信，因此可以把人力、物力資源投入到系統功能的完善之中。

n        可以實現軟硬體的互操作性。OPC把軟、硬體廠商區分開來，使得雙方的工作效率有了很大的提高。

傳統架構與OPC架構圖：

一個OPC Client可以連接一個或多個OPC Server，而多個OPC Client也可以同時連接同一個OPC Server，如下圖所示。

OPC的技術本質是採用了Microsoft的COM/DCOM技術，COM 是一種發展軟體元件的方法，所謂的軟體元件，是指一個可以提供應用程式、作業系統、以及其他元件服務的二進位可執行程式。事實上，發展自訂的 COM 物件就好像是在建構一套可以動態執行的物件導向 API 一般。你可以在應用程式執行的時期隨意拼上或移除所需要的元件。依據 COM 這樣的概念，發展應用程式就像是堆積木一樣，每一個 COM 元件就是一塊積木，你可以利用各式各樣不同的積木，拼湊出你所需要的應用程式。，DCOM是COM技術在分散式領域的擴展，使COM可以在區域網路、廣域網路甚至Internet上不同電腦上的對象之間的通訊。

Diagnostics—結論

雖然COM技術本質上具有語言無關性，可以用各種語言開發，但由於最適合COM開發的語言仍然是C++，因此一般都選擇採用Visual C++進行開發。

目前用Visual C++開發COM組件主要有三種方式：使用COM SDK直接開發COM物件；通過MFC提供的COM支持實現COM物件；通過ATL來實現COM物件。

OPC Server 提供了許多的介面，Client 端透過這些介面，可以取得與 OPC Server 相連的硬體裝置的資訊，而無須瞭解這些硬體裝置的細節資訊。也就是說，程式設計者可以使用相同的程式碼，操作不同的硬體裝置，充分達成 software reuse 的理想。同時，由於 COM/DCOM 已實作了網路部分的細節，也使得 Client 對 OPC Server 進行遠端存取非常容易，使程式設計者很容易地達成遠端控制的目標。

參考資料:

1. OPC Data Access Custom Interface Specification Version 3.0

2. DAQBench 論壇: OPC Server概述

3. 工控幫文摘: OPC概述