OPC UA 已经有一段时间了，开始只知道它将是工业4.0 中一个重要的通信协议（IEC 62541）。出于好奇，就了解一下。我看的主要内容包括：Open62541 库和uaExpert，uamodeler等工具软件。同时也阅读了OPC UA 的标准文本和网络上的许多文章。但是总觉得云里雾里，神龙见首不见尾。

俗话说”不识庐山真面目，只缘身在此山中”。在学习电脑新技术时，我们往往会被劈头盖脑的各种术语，数据结构，函数，协议，模型带到沟里去了。而忘却了思考它是什么？它解决上什么问题？为什么这样做？这些根本的问题。有时真的搞不懂，这么复杂的东西是这么想出来的？是大公司用来故弄玄虚的么？

有一个早上，我突然顿悟，OPC UA 就是在分布式系统中实现对象的描述，什么Node呀，variable呀，reference呀，无非是想描述一个对象！OPC UA 在工业4.0 中的重要性就是通过面向对象的技术，将物理设备，传感器，电机描述成一个个对象，形成数字化模型。让不同的软件可以像调用对象那样来控制设备。

于是，我放慢心情，顺着面向对象的思路，来探究OPC UA 的本质。

面向对象程序设计

软件设计的重要一环就是将物理世界的物体抽象成数字化模型。其中最重要的技术就是面向对象的程序设计技术。例如，对于一个马达，我们可以抽象成下面的类。

class motor {
float speed；
int direction；
float current；
float voltage；
float temperature；
void start()；
void stop();
}

这个类描述了电机的基本特性，它们包括速度，转动方向，工作的电流，电压和温度。其中方法包括了启动和停止。

在程序中，我们可以将motor 类实例化，并且对实例的参数参数和控制。例如：

motor motor1，motor2；
motor1.speed=1200；
motor.direction=CCW；
motor.start();
delay(10)
motor.stop();

面向对象程序设计是最流行的程序设计方法，流行的OOP 语言是C++。面向对象程序设计的最大好处是突出了接口，屏蔽了细节。提高了软件的模块化和重用性。

分布式对象

类的应用和定义是在一个程序中的。如果将面向对象的概念扩展到程序之间，或者是网络中的不同程序之间会怎么样呢？人们的确是这么做了。

分布式计算环境下，程序之间的相互调用最早采用RPC(远程过程调用) 方式。但是对于更加复杂的情况下，更好的方式是采用分布式对象技术。计算机程序可以调用网络中的任何一个对象。这也符合实际应用的需要，比如自动控制SCADA程序启动注塑机上的主电机（motorA），就演变成为调用注塑机控制器中的对象motorA的start 函数。所以将面向对象程序设计中的对象概念衍生到分布式系统中，就产生了分布式对象的概念。

常见的分布式对象技术包括了

微软的COM/DCOM （Distributed Component Object Model）
国家组织OMG的CORBA（Common Object Request Broker Architecture）

OPC 协议

在了解OPC UA 的之前，我们首先了解一些它的前身OPC 协议。这样更有利于了解OPC UA 的本质和由来。

OPC 是基于微软的DCOM 技术，用于设备和软件之间交换数据。这也意味着OPC 只能在window 系统上运行.在运行OPC 之前需要配置Window 的COM/DCOM.在运行命名行键入”DCOMCNFG”可以看见window的服务组件的配置(细节我并不了解).不过有一点可以确实,就是OPC 是在运行windows的工业PC 和上位机上方可运行.这在window 一统天下的年代的不二选择.一台PLC 如果要和OPC 上位机软件通信,必需通过Windows 工业电脑来完成。

重新认识OPC UA

现在,我们来重新来认识OPC UA 的本质吧! OPC UA 是OPC 的后继标准，只是后面增加了UA ,意指”统一架构”(Unified Architecture).它的主要目的是摆脱windows! 实现与平台无关的OPC.

从OPC 演进到OPC UA,它的目的并没有改变,依然是为了实现分布式控制系统中的分布式对象技术.但是它的方式变成了与平台无关.面向了开放系统.这也就意味着我们可以在一个Arm /linux平台上实现OPC 的server,或者在云端linux平台上实现Client 程序.

opc ua 的代码足够地小,事实上已经可以将OPC UA 的server 端直接集成到PLC ,传感器或者小型网关中.

一旦了解了事物的本质,就可以高屋建瓴地理解许多细节.现在我们在来看看OPC UA 的许多概念.

1 信息模型(Information model)

OPC UA 使用了对象（objects）作为过程系统表示数据和活动的基础。对象包含了变量，事件和方法，它们通过引用（reference）来互相连接。这个概念和面向对象程序设计方法非常相似。

OPC UA 信息模型是节点的网络（Network of Node,），或者称为结构化图（graph），由节点(node)和引用(References)组成，这种结构图称之为OPC UA 的地址空间。这种图形结构可以描述各种各样的结构化信息(对象)。

节点(nodes) : 共计有8种节点(对象,对象类型,变量,变量类型,视图,方法,引用,数据类型)

也许我们通过一些实例能够更加容易理解这种节点图描述对象的能力。

视图节点（view node）

假如我们要为一个设备建立opc ua 模型，这个设备具有一个模拟量输入，一个数字输出，两个方法，分别是readAnalog和ReadDigital。这个模型如果使用C++的类来描述，是下面的样子。

class sensor {
public :
double analog;
uint32_t digital
double readAnalog(int port)
uint32_t  readDigital(int port)
}

如果使用节点图来描述首先要区分不同的节点类型

相应的节点图是下面的样子

如果你熟悉C++面向对象程序设计，可以将C++的类与OPCUA 的节点图对应起来，这样比较容易理解OPC UA 信息模型是如何构建的。

opc ua model 的设计工具：
opc ua 的模型采用XML 文件描述，然后通过一个编译工具可以将XML 编译成C++语言的程序。

为了方便地建立 opc ua 的信息模型，需要使用模型编辑软件，它们会产生XML 的小型模型，然后编译成C语言程序。

使用OPC UA的几大原因

OPC技术发明的初衷就是为了让这些信息在不同的平台间实现畅通无阻的交换，让平台之间实现零成本零耗时的无缝对接。

1. 组件对象模型（COM）/分布式组件对象模型（DCOM）的终止

传统OPC应用之间的数据交换是基于微软的组件对象模型（COM）技术。因为视窗（Windows）操作系统在世界范围内得到了广泛的应用，同时也促进了视窗计算机在自动化中的使用，所以COM技术也为OPC技术的广泛使用创造了条件。在2002年初，微软发布了新的.NET框架并且宣布COM技术的停止研发。虽然这不意味着将来的视窗操作系统不支持COM，但作为停止的结果，传统OPC的基础技术已经不再发展，或早或晚要被淘汰，所以要寻求新的替换方案。

2. COM 的局限

上世纪90年代，随着视窗计算机的普及，微软COM/DCOM技术引入的一组特性，得到了家庭计算机用户和工业自动化用户的高度欣赏。这些特性包括了拷贝与粘贴，拖拽与投放，链接与嵌入。DCOM还提供了完整的通信基础架构，并带有必要的安全机制，诸如授权、鉴权和加密。DCOM安全机制能够实现计算机对数据和程序的远程访问。但DCOM安全机制同时也对安装工程师、系统集成商和开发者管理项目提出了挑战，其中包括了跨越PC的OPC通信。正确地设置DCOM安全功能是非常困难的任务，需要很多专业的知识。作为结果，安装工程师和系统集成商会例行公事地选择快速流程，在所有连网的OPC计算机采取宽松的访问授权，造成大多数保护不起作用且允许非授权远程访问。这种做法与信息技术（IT）安全的要求相违背。在长期运行时，可能会有粗心大意者或者蓄意破坏的人造成损害的危险。DCOM安全设置常常需要一种特别才能，而配置OPC通信功能则非常容易。

3. OPC 通信穿过防火墙

在自动化行业，很早就认识到OPC通信需要跨越计算机边界的必要性，这是另一个DCOM限制传统OPC通信的地方。DCOM需要多个端口，如鉴权、传输数据和一系列服务建立一个连接。所以，在防火墙中不得不打开很多端口，才能让DCOM通信穿过他。在防火墙上每打开一个端口都是一个安全隐患，为黑客攻击提供一种潜在可能。OPC UA中的隧道技术是一种被广泛接受的策略，解决了传统OPC产品中DCOM限制的问题。

4. 在非视窗平台使用OPC

在工业应用中，几乎"无所不在"的微软平台，把DCOM 作为操作系统的一个组件是传统OPC能被快速接受的一个重要因素。但是同时，OPC的集成概念在使用其他操作系统时就不灵光了，因为他们不支持DCOM。比如在IT行业，常常使用Unix或者Linux系统就是这种情况。

自动化也是这样，有的应用领域明确拒绝使用视窗操作系统。嵌入式设备领域是另一个视窗很难（除了视窗CE或者嵌入XP）涉及的领域。这里，复杂的应用直接嵌入到现场设备、PLC、操作屏和其他设备之中。他们运行VxWorks、QNX、嵌入式Linux、RTOS或者其他嵌入式操作系统而没有DCOM。在这些领域里使用OPC 的集成概念注定要失败，因为OPC需要DCOM作为技术基础，而这个基础在嵌入式系统中正好缺失。

5.通过Web服务实现跨平台的OPC通信

随着在2003年OPC XML-DA规范的发布，OPC基金会第一次展示了一种独立于视窗平台的方式和克服DCOM限制的方法。今天，很多OPC XML-DA产品演示了基于Web服务的OPC技术。但是XML-DA 通信的数据吞吐量还是比不上DCOM，通信速度要慢5到7倍。这个速度对于很多自动化的要求而言是太慢了。基于Web服务的OPC通信功能还是有用的，因为实现了跨越操作系统的能力，但还要进一步提高数据传输性能。

6. 统一数据模型

迄今为止，传统的OPC技术已有3种不同的OPC服务器 – 数据访问服务器、报警与事件服务器和历史数据访问服务器。如果用户需要获取一个温度传感器的当前值，一个温度超过限定值的事件和一个温度的历史平均值，那么他必须发送3个请求，访问3个服务器。用户访问过程数据、事件和历史数据用不同的方法要花费很多的时间。所以，统一这3种对象模型可以使这样的事情变得非常简单，不仅对OPC产品的供应商有利，也对系统集成商和用户有利。

7. 支持复杂数据结构

OPC的一个主要应用是对串行通信或者现场总线联网设备的操作和监视。为了配置设备，OPC客户机需要写入数据类型，通过OPC服务器到达设备，包括数据结构元件的意义。OPC基金会已经创建了描述复杂数据结构的方法，即复杂数据规范。然而，大多数今天市场上的传统OPC产品除了很少的例外，不能使用复杂数据规范。

8. 保证通信不丢失数据

最早定义的数据访问，可以让客户应用程序周期获得过程数据的当前状态。如果在OPC客户机和远程OPC服务器之间的物理通信连接发生了问题，数据通信会受到损坏。当通信损坏时，传输到OPC客户机数据会发生改变，甚至丢失。这种数据丢失在有些数据访问应用中不是关键的，诸如趋势记录、过程监视或者过程显示。但在有些场合的应用中是非常关键的。比如，OPC技术已经成为这些区域的基础，诸如化工或者石化工业，这些地方要求必须无缝地记录数据。为了达到这个目标，供应商需要实施特殊扩展的方法。他们使用基于连接的监视系统，确保对断开的通信快速检测，如果通信断开能够自动重新连接，在数据访问服务器中有数据缓存、冗余、存储和转发功能。这些扩展的方法很有用，但在传统的OPC规范中没有定义，会因供应商不同而不同。

9. 对非授权数据访问而增加的保护

随着自动化行业基于以太网的通信不断增长，自动化和办公室网络已经纠缠在一起。同时，垂直集成的想法产生了新的需求，这种类型的集成也带来了新的安全风险。OPC也增加了远程维护和远程控制概念的使用。这里再一次提到，对外围非授权的访问，必须满足更严格的信息安全要求。随着网络犯罪、间谍和破坏活动的增长，信息技术安全越来越显得重要 – 所以使用OPC也有了安全的要求。传统的OPC供应商没有开发专有的预防措施，所以不能满足这些安全要求。