本页使用了标题或全文手工转换

OPC UA

维基百科,自由的百科全书
跳到导航 跳到搜索

OPC UA的全名是OPC Unified Architecture(OPC統一架構)。是OPC基金會英语OPC Foundation應用在自动化技术機器對機器网络传输协议。有以下的特點:

  • 著重在資料收集以及控制為目的的通訊,用在工業設備以及系統中
  • 开源标准:標準可以免費取得,實作設備不需授權費,也沒有其他限制
  • 跨平台:不限制作業系統或是程式語言
  • 面向服务的架构(SOA)
  • 強健的信息安全特性
  • 整合的信息模型,是資訊整合中,基础设施的基礎,制造商以及組織可以將其複雜的資料在OPC UA命名空間上建模,利用OPC UA面向服务的架构的優點。

歷史[编辑]

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

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 CJava.NET框架
  • 可扩展性,從智能傳感器英语Smart transducer、智能致動器一直到大型计算机。
  • 支援多線程,也有單線程/單任務的模式,以便將此通訊協定棧放在嵌入式系統中。
  • 基於新標準的資料安全性
  • 每個設備都有可以規劃的逾時機能
  • 大容量資料報文的組塊

通訊協定棧反映了架構創新的基礎,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英语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,因此是晶片等級可以使用的通訊架構[2]

通訊協定[编辑]

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

二進位通訊協定的效率最高,其overhead也最少,讓需要的資源最小化(不需要XML解析器、SOAPHTTP,對嵌入式系統格外重要),提供最佳的互操控性(在實現時,二進位通訊協定提供較少的自由度),使用任意選取的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部份感興趣[4]

UA通訊協定棧[编辑]

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

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

UA安全性[编辑]

UA安全性包括了認證、授權、加密以及透過簽名實現的資料整合性。針對Web服务會使用WS-SecureConversation英语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,目前只有基本機能)[5]
  • 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客戶及伺服器規範[6]

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

Python下的OPC UA[编辑]

FreeOpcUa專案提供了以Python程式語言實現的OPC UA(和Python 2, 3 及pypy相容),也提供了OPC-UA客戶及伺服器的高層次抽象化,可以用在客戶的應用中,或是漸漸延伸到客戶的應用。

IEC 62541[编辑]

IEC 62541是OPC UA的標準

IEC 62541簡介
ID 發布日期 標題
IEC/TR 62541-1 02/2010 OPC Unified Architecture - Part 1: Overview and Concepts
IEC/TR 62541-2 02/2010 OPC Unified Architecture - Part 2: Security Model
IEC 62541-3 07/2010 OPC Unified Architecture - Part 3: Address Space Model
IEC 62541-4 10/2011 OPC Unified Architecture - Part 4: Services
IEC 62541-5 10/2011 OPC Unified Architecture - Part 5: Information Model
IEC 62541-6 10/2011 OPC Unified Architecture - Part 6: Mappings
IEC 62541-7 07/2012 OPC Unified Architecture - Part 7: Profiles
IEC 62541-8 10/2011 OPC Unified Architecture - Part 8: Data Access
IEC 62541-9 07/2012 OPC Unified Architecture - Part 9: Alarms and Conditions
IEC 62541-10 07/2012 OPC Unified Architecture - Part 10: Programs

相關條目[编辑]

腳註[编辑]

參考資料[编辑]

  • 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