OPC UA 的全名是 OPC Unified Architecture（OPC 統一架構）。是 OPC 基金會應用在自動化技術的機器對機器網絡傳輸協議。有以下的特點：


* 著重在資料收集以及控制為目的的通訊，用在工業設備以及系統中

* 開源標準：標準可以免費取得，實作設備不需授權費，也沒有其他限制

* 跨平台：不限制作業系統或是程式語言

* 面向服務的架構（SOA）

* 強健的信息安全特性

* 整合的信息模型，是資訊整合中，基礎設施的基礎，製造商以及組織可以將其複雜的資料在 OPC UA 命名空間上建模，利用 OPC UA 面向服務的架構的優點。



歷史

OPC UA 和其前身開放平台通信（OPC）是由同一個組織所開發，但兩者有顯著不同。基金會開發 OPC UA 的目的是發展比原來 OPC 通訊架構（只使用 Microsoft Windows 的進程交換 COM/DCOM）更理想的架構，也更符合正在發展中的工業自動化

OPC UA 的規格開發了三年，之後花了一年實現通訊協定，OPC UA 的第一個版本在 2006 年問世。

到 2015 年 10 月 10 日為止，OPC UA 最近的版本是 1.03。除了 client/server 通訊協定外，新版的 OPC UA 也加入了 publish/subscribe 的機制。



創新

開放平台通信（OPC）和 COM/DCOM 的結合雖讓開放平台通信可以順利推展，但有以下的缺點：


* 頻繁配置 DCOM 的問題

* 沒有可以規劃的逾時機能

* 只適用於 Microsoft Windows

* 資料安全性較低

* 沒有針對 DCOM 的控管（COM/DCOM 類似黑盒子，開發者無法取得源代碼，因此需要處理一些相關的問題或是未充份實現的問題）

因為這些缺點以及許多其他的考慮因素，使得 OPC 基金會決定開發一個針對全新而且獨立的 OPC UA 通訊協定棧來取代 COM/DCOM。其優點有：


* 多平台實現，包括可攜式的 ANSI C、Java 及.NET 框架。

* 可擴展性，從智能傳感器、智能致動器一直到大型計算機。

* 支援多線程，也有單線程 / 單任務的模式，以便將此通訊協定棧放在嵌入式系統中。

* 基於新標準的資料安全性

* 每個設備都有可以規劃的逾時機能

* 大容量資料報文的組塊

通訊協定棧反映了架構創新的基礎，OPC UA 架構是服務導向架構（SOA），以許多不同邏輯層級為其基礎。

OPC 基礎服務是抽象形別的敘述，和通訊協定無關，是 OPC UA 機能的基礎。傳輸層將方法轉換為通訊協定，將資料序列化（或反序列化），再傳送到網路上。
為了上述目的，定義了兩種通訊協定，其中一個是以效率進行過最佳化的二進制 TCP 訊定，另一個則是 Web 服務導向的協定。

OPC 資訊模型是所謂的全網狀網絡（Full Mesh Network），以節點為基礎。節點類似物件導向程式設計（OOP）中的物件，可以包括各種的元資料。節點可以有屬性讓其他設備讀取（DA、HDA），有方法可以呼叫（Commands），也有可以啟動傳輸的觸發事件（AE、DataAccess、DataChange）。節點包括過程資料，也包括其他種類的元資料。OPC 命名空間中包括了形態模型。

客戶端軟體可以確認伺服器支援哪些行規（profile），有需要獲得這些資訊，知道伺服器是否只支援 DA，或是還支援 AE 和 HDA。而且可以得到伺服器是否支援特定行規的訊息。OPC UA 還有以下重要的新機能：


* 支援冗餘（Redundancy）

* 雙方向連結的心跳報文（Heartbeat）（確定另外一端是否「活著」），這表示客戶端和伺服器都可以識別中斷。

* 傳輸資料及 acknowledgement 的緩衝（Buffering），連結遺失不會造成資料遺失，可以重新獲取之前遺失的資料報文。

OPC UA 是在 2006 年 10 月在慕尼黑舉行的 OPC UA DevCon 中首次公開其協定，在 Beckhoff 的 PLC 上已有許多的 UA 伺服器，在 Euros 嵌入式測試電路板中也有 UA 伺服器。Beckhoff PLC 的底層是 Windows XP 嵌入式系統，而嵌入式控制器執行的作業系統是實時作業系統 Euros。Embedded Labs Ltd 公司在他們執行在單晶片 ARM 控制器（64kb RAM） C++ UA Stack 上展示了 OPC-UA。2012 年 10 月時德國的 Fraunhofer-Application Center IOSB-INA 以及工業信息技術研究所（Institute for industrial Information Technologies, inIT）證實了 OPC-UA 伺服器可以只使用 15 kB RAM 以及 10 kB ROM，因此是晶片等級可以使用的通訊架構。



通訊協定

OPC UA 支援兩種通訊協定，這兩種通訊協定的差異只有 URL 的不同，二進位通訊協定是 opc.tcp://Server，而 Web 服務的通訊協定是 http://Server，其他情形下，OPC UA 對應用程式接口的作業完全透明，其他作業不受 OPC UA 的影響。

二進位通訊協定的效率最高，其 overhead 也最少，讓需要的資源最小化（不需要 XML 解析器、SOAP 及 HTTP，對嵌入式系統格外重要），提供最佳的互操控性（在實現時，二進位通訊協定提供較少的自由度），使用任意選取的 TCP 通道，可以較容易的進行隧道協議，也可以從透過防火牆開啟。

Web 服務（SOAP）通訊協定可以支援許多不同的工具（包括 Java 環境或是.NET 環境的工具），使用標準 HTTP (S) 埠，可以和防火牆共同使用。

所有的實現方式都支援二進制通訊協定，但只有用.NET 實現的設備才支援 SOAP。



規範

OPC UA 規範屬於多部份的規範，包括了以下部份：

1. Concepts
2. Security Model
3. Address Space Model
4. Services
5. Information Model
6. Mappings
7. Profiles
8. Data Access
9. Alarms and Conditions
10. Programs
11. Historical Access
12. Discovery
13. Aggregates
14. PubSub

OPC UA 規範和其他以 COM 為基礎的規範不同，OPC UA 規範不是單純的應用規範。其中會描述典型的 UA 內部機制，這些會在通訊協定棧中處理，因此一般只有要將通訊協定棧導入特定硬體的人，或是要開發通訊協定棧的人才會對這些內容有興趣。

OPC UA 應用程式的開發者需要撰寫程式和 OPC UA API 溝通，因此主要只需要用到 API 的說明文件。不過應用程式開發者也可能會對其中的第 3、4、5 部份感興趣。



UA 通訊協定棧

UA 應用程式在伺服器端或是客戶端，其架構上都有分層的結構。

有些部份和以往的 COM Proxy/Stubs 相等，由 OPC 協會提供。可移植性級別（portability level）是新的，簡化了引入 UA ANSI C 通訊協定棧的程序，也簡化了移植到其他平台的的難度。OPC 協會也提供了針對 Window 及 Linux 的 port layer。



UA 安全性

UA 安全性包括了認證、授權、加密以及透過簽名實現的資料整合性。針對 Web 服務會使用 WS-SecureConversation，可以和.NET 和其他以 SOAP 實現的軟體相容。若是二進制的版本，也會依循 WS-SecureConversation 的演算法，轉換為二進制的版本，稱為
UA Secure Conversation。

有另外一個混合的版本，程式是二進制的，而其傳輸層是用 SOAP。這是在二進制的效率以及對防火牆友善的傳輸之間的妥協。因為是二進制的程式，會需要使用 UA Secure Conversation。
其認證只使用 X.509 認證，是靠程式開發者決定 UA 應用程式要使用哪一個證書存儲區。例如，也可能使用 Active Directory 中的公開金鑰基礎建設（PKI）。



OPC UA API

在許多程式語言中都有 UA 的 API。在 C、C++、Java 及.NET 中有商業的 SDK。而至少在 C、C++、Java、Javascript (node) 及 Python 中有其開源的通訊協定棧。



C++ 下的 OPC UA


* open62541（頁面存檔備份，存於網際網路檔案館）計劃是 OPC UA 伺服器端及客戶端的開源計劃，以 Mozilla 公共許可證開放授權，有 Linux 及 Windows 的版本，也支援 OS X、QNX 及其他的嵌入式系統。

* ASNeG 計劃是 C++ 開源（Apache License 2.0）OPC UA 應用層及 OPC UA 網頁伺服器（beta state，目前只有基本機能）

* FreeOpcUa（頁面存檔備份，存於網際網路檔案館）計劃提供開源（LGPL）的 C++ 伺服器端及客戶端實現。

* UAF（頁面存檔備份，存於網際網路檔案館）計劃提供開源（LGPL）) 的 C++/Python 實現。



.NET 下的 OPC UA

.NET 版本的實現在底層用 ANSI C，其餘部份使用.NET。因此只有網路端點的處理以及消息分塊的取得是從 ANSI C 的通訊棧處理的。反序列化直接在.NET 中進行，會直接轉換為.NET 的結構及物件。因此其效能會比先反序列化成 C 語言結構，再複制到.NET 結構的效率要好。



Java 下的 OPC UA

有許多 Java 語言的通訊棧，類似.NET，Java 語言的通訊棧分為三種：

1. 用 Java 本地接口封裝完整的 ANSI C 通訊棧，這樣不利於可攜性。雖然通訊棧可以移殖到不同的作業系統，但需要個別的編輯這些程式。而且資料也需要複製到 Java 本地接口的邊界，不過在反序列化時會有 C 語言的效能。
2. 直接撰寫網路層的代碼（類似目前.Net 的實現），用 Java 進行反序列化，省去了一次的資料複製，但仍會受到 C 堆疊的影響。
3. 撰寫原生的 Java OPC UA 通訊棧，這個是可攜性最好的，但是工程師需花費的心力也是最多的。Eclipse Milo 專案提供一個純 Java 開源 OPC UA 實現，是依照 UA 1.03 客戶及伺服器規範。

也有一些簡單的變體只支援 WebService 協定，此情形下，需要有可以支援 WS-Security 的 SOAP Toolkit。



Python 下的 OPC UA

FreeOpcUa（頁面存檔備份，存於網際網路檔案館）專案提供了以 Python 程式語言實現的 OPC UA（和 Python 2, 3 及 pypy 相容），也提供了 OPC-UA 客戶及伺服器的高層次抽象化，可以用在客戶的應用中，或是漸漸延伸到客戶的應用。



IEC 62541

IEC 62541 是 OPC UA 的標準



相關條目


* OPC 資料存取

* 開放平台通信（OLE for process control，簡稱 OPC）

* OPC 基金會



腳註



參考資料


* Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: _OPC Unified Architecture._ Springer Verlag 2009; ISBN 978-3-540-68898-3

* Lange, J., Iwanitz, F., Burke, T. OPC From Data Access to Unified Architecture 2010; ISBN 978-3-8007-3242-5