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 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，因此是芯片等级可以使用的通信架构[2]。

OPC UA支持两种通信协定[3]，这两种通信协定的差异只有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部份感兴趣[4]。

UA应用程序在服务器端或是客户端，其架构上都有分层的结构。

有些部份和以往的COM Proxy/Stubs相等，由OPC协会提供。可移植性级别（portability level）是新的，简化了引入UA ANSI C通信协定栈的进程，也简化了移植到其他平台的的难度。OPC协会也提供了针对Window及Linux的port layer。

UA安全性包括了认证、授权、加密以及通过签名实现的数据集成性。针对Web服务会使用WS-SecureConversation，可以和.NET和其他以SOAP实现的软件兼容。若是二进制的版本，也会依循WS-SecureConversation的算法，转换为二进制的版本，称为 UA Secure Conversation。

有另外一个混合的版本，程序是二进制的，而其传输层是用SOAP。这是在二进制的效率以及对防火墙友善的传输之间的妥协。因为是二进制的程序，会需要使用UA Secure Conversation。 其认证只使用X.509认证，是靠程序开发者决定UA应用程序要使用哪一个证书保存区。例如，也可能使用Active Directory中的公开密钥基础建设（PKI）。

在许多编程语言中都有UA的API。在C、C++、Java及.NET中有商业的SDK。而至少在C、C++、Java、Javascript(node)及Python中有其开源的通信协定栈。

• 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版本的实现在底层用ANSI C，其余部份使用.NET。因此只有网络端点的处理以及消息分块的取得是从ANSI C的通信栈处理的。反串行化直接在.NET中进行，会直接转换为.NET的结构及对象。因此其性能会比先反串行化成C语言结构，再复制到.NET结构的效率要好。

有许多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。

FreeOpcUa（页面存档备份，存于）项目提供了以Python编程语言实现的OPC UA（和Python 2, 3 及pypy兼容），也提供了OPC-UA客户及服务器的高层次抽象化，可以用在客户的应用中，或是渐渐延伸到客户的应用。

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