這里主要討論的是OPC Data Access 2.0服務器的開發，在掌握了這個最常用的OPC服務器開發之后，對其它類型的OPC服務器，如A&E、HDA等就可以觸類旁通了。
一個OPC服務器的開發，主要包括兩大部分的工作：OPC接口的實現和設備驅動部分的開發。
OPC接口的實現，實質上就是按照OPC標准進行COM接口開發，對於大多數的OPC服務器開發者來說，我認為沒有必要涉足。目前市場上有很多OPC服務器開發工具，國內外都有，當然價格也不盡相同，調研一下的話應該會找到適合自己的。有必要進行OPC接口開發的大致有這幾種情況：1、有實力的大公司，OPC相關產品較多，需要對OPC技術進行深入了解；2、OPC服務器開發工具廠商；3、對OPC技術感興趣的個人、院校及研究機構。除此之外，一般沒有必要一頭扎進COM的泥沼，去和內存分配、線程管理等繁瑣的事務打交道。
所以，當決定為設備/程序開發OPC服務器時，首先要選擇一款OPC服務器開發工具。（目前流行的OPC DA 2.0服務器開發工具的結構大同小異，kevin所在的公司也有這類產品，為避免廣告之嫌，這里就不做詳細介紹了。）
為了更好地理解OPC服務器開發工具的結構並合理使用，最好先了解OPC服務器的結構模型，這里簡單說一下。OPC(DA 2.0)里主要定義了兩個對象：OPCServer 和 OPCGroup。OPCServer對象是OPC服務器的核心，它提供的接口函數主要包括對OPCGroup對象的管理、OPCItem屬性查詢、連接點管理、以及地址空間瀏覽(可選)等。OPCGroup 對象的主要作用是管理一組數據項(Item)，包括數據項的同步/異步訪問、添加刪除、屬性查詢等。從客戶程序角度看，訪問一個OPC服務器的過程大致是首先創建一個 OPCServer 對象，然后通過它創建一個 OPCGroup，在其中添加想要訪問的數據項，之后利用訂閱回調機制周期性獲取動態數據或通過讀寫接口直接訪問數據項。
在OPC服務器的實現中，組對象的管理是關鍵，不同客戶程序可能創建多個組對象，每個組對象包含的數據項、更新周期都由客戶程序決定，不盡相同，需分別處理。所幸的是大部分OPC服務器開發工具都已實現了這一部分，並進行了封裝。用戶開發OPC服務器時可把主要精力放在現場數據的讀寫上。目前大部分的OPC服務器開發工具都提供了一些類對象或API形式的函數，用戶只需調用這些函數即可完成從現場數據到OPC服務器(通常是內部緩沖區)的數據更新。
在開始開發一個OPC服務器之前，用戶還要確定服務器的運行形式。OPC服務器做為一個COM組件，運行方式主要包括進程內(DLL)、進程外(EXE)以及服務(Service)。這里的進程內/外是相對於客戶程序說的，當OPC服務器是進程內組件時，它運行在客戶程序的進程里（遠程連接時是宿主程序(host)的進程），而我們通常接觸到的OPC服務器一般都是進程外組件。選擇哪一種形式要看具體的應用需求，進程內形式適合輕量級的小型服務器，特別是當底層設備具有較高的性能，支持並發多連接訪問，OPC客戶及服務器程序處於同一計算機上時，可采用進程內形式。其它情況下進程外形式可能更適合一些。簡言之，當你不清楚到底那種更合適時，就選擇進程外方式。服務形式主要是和進程外形式比較的，它在后台運行，沒有用戶界面。當OPC服務器計算機可能在沒有用戶登錄，或者需要經常切換登錄用戶時，服務形式的OPC服務器是最合適的。無論那種形式，都與設備驅動開發的關系不大，大部分的OPC服務器開發工具都帶有每種形式的服務器例程，用戶可在開發時參考。
開發一個OPC服務器時，首先通常要確定地址空間結構。OPC DA 2.0規定了兩種地址空間的組織形式：Flat(平坦的) 和 Hierarchical(分等級的)。可以理解為我們通常所說的“列表型”和“樹狀型”。雖說OPC DA 2.0里把IOPCBrowseServerAddressSpace接口定義為Optional，即可選的，但目前大部分OPC服務器開發工具都實現了這個接口，樹狀地址空間有利於客戶程序瀏覽查詢，特別是當數據項總數較多時，Flat 形式不利於數據項的分類、管理。所以建議定義樹狀地址空間。具體的空間結構因底層設備的特性而異，OPC沒有嚴格要求。借用OPC標准里的例子，比如：
<ROOT>
PLC_STATION_1 (branch)
ANALOG_VALUES (branch)
40001 (leaf)
40002 (leaf)
...
DISCRETE_VALUES (branch)
...
設計好地址空間結構之后，就要實現最主要的數據讀寫功能了(以后繼續)。
BTW，有朋友曾在論壇里提到“通用”OPC服務器，我想可能是指Kepware之類的OPC服務器套件，支持當前很多主流的設備。但這也是包含了多家廠商設備驅動的結果。或者其它的針對某些通用、公開的協議，比如Modbus，開發的服務器，但顯然它不能適應所有的設備。可以說，只要有私有協議的存在，就沒有真正意義上的通用OPC服務器。OPC標准的根本目的是提供設備驅動程序（軟件）與客戶軟件之間的互操作性。
refrence：http://blog.gkong.com/more.asp?name=kking&id=30090