1、OPC UA的信息模型与统一架构
有一些朋友常常会说OPCUA之所以能够如此普及是因为它能跨平台。远程I/O模块觉得这不是一个充分条件。我个人认为OPCUA之所以能够很广泛的普及是因为它的统一架构与信息模型做的太完善了。OPCUA的信息模型来源于面向对象编程(OOP)的思想，这也是最契合实际需求的。
假设在工业现场有若干台空调需要监控，首先我们需要监视它的温度，湿度，运行状态；其次我们需要对它进行启停操作；然后我们需要接受它的非停事故报警信息；最后我们常常需要分析某一时段的运行参数来判断空调的状态。运用面向对象编程的思想，我们创建一个类—空调，在这个类中分别定义相应的属性，方法和事件，其中属性即可以是简单的数据，也可以是复杂的结构体。这个类即可理解成OPC UA的信息模型。OPC UA将现场的这些实时数据(DA)，历史数据(HDA)还有事故报警数据(A&E)，在同一平台进行管理，即为统一架构。
用这种模式来通讯，效果怎么样呢？下面我们做一个简单的演示。在unified automation公司出品的demo server中，已经定义了若干个空调，我们通过该公司出品的客户端UA Expert进行监视。在菜单栏的左侧，列出了该空调的属性，方法和事件；在右侧中，这里只是监视空调的温度，湿度和运行状态。这时，空调是停止(OFF)状态。如果需要将空调启动，并将运行目标温度设定为比较舒服的25℃，只需要调用StartWithSetpoint方法，并在对话框中输入目标值即可。
监控事件与报警信息时，创建事件试图并订阅该空调的事件。空调的启停状态发生会触发一个事件，空调处于停止状态则会触发一个报警，同时在客户端也可以确认报警。
最后，如果在服务器端，将空调某个属性历史存储功能打开，经过一段时间的存储后，在客户端就可以读取历史数据了。
这就是信息模型与统一架构的魅力，让一个通讯软件有了HMI的感觉。
当然，OPC UA的这个信息模型其实也不是在工控界独领风骚的，在PTC的物联网平台Thingworx中的物模型(thing model)，罗克韦尔的CIP协议也都是类似的面向对象的模型。所以说好的设计都是相似的，不好的设计各有各的磕碜。
2、OPC UA的安全性
工业通讯协议初期是以速率和稳定性优先的，那时候为了控制系统安全，很多网络都是与外网隔离的，因为已经被物理隔离，所以协议就没有做任何的安全设计。而且以前处理的芯片处理能力有限，如果要做加密解密运算的话，会消耗很多的资源，所以只能为了时效性而牺牲安全性。想想Modbus协议，如果你能连接到网络里，用ModScan是不是可以随意的修改Modbus从站的数据，无需用户认证，权限控制；你也可以用一些类似Wireshark之类的抓包软件很轻松的解析这些明文传递的数据包。可以说系统完全是在裸奔的情况下运行的。
不过因为系统与外界是隔离的，如果想攻击它，你需要骗过厂门口的保安，躲过大狼狗，然后跑到车间，撬开控制柜，接入网络，然后才能用黑客技术攻击它。不过如果你已经这么厉害了，是不是直接给控制器上泼一盆水，用这种物理攻击更高效一些。
但是现在这种情况发生了变化，因为工业网络希望能够插上互联网的翅膀，去做OT与IT的融合，去做工业物联网(IIOT)。所以，在这种需求下安全成为了最大的需求。就像王坚院士讲：安全是互联网公司的生命。在通讯的过程中面临着众多的外部安全威胁，例如：信息泄露，篡改指令，越权操作，伪造重发，泛滥攻击等。面对这些威胁，OPC UA则使用加密，签名，用户认证，权限访问控制，会话管理等方式一层一层完成深度防御。
OPC UA的安全也是得到业内认可的，不过世界上也没有绝对安全的协议。Synopsys公司在对一些工业通讯协议进行测试的时候还是发现了一些问题的。所以，OPCUA的安全还是有些工作要去做的。欲戴王冠，必承其重。
3、OPC UA与物联网(IoT)
物联网是一个很热的话题，也实实在在的影响和改变着我们的生活。从上面OPC UA对一个空调的监控的例子中，不难发现OPC UA协议对物的监视与控制是很简洁流畅的。同时又有了强大的安全性为它保驾护航，因此，在面对物联网这个风口，OPC UA也希望将自己打造成一款IoT主流协议。OPC UA能够很好的支持HTTPS，在与HTTPS配合时，可以发送XML或者JSON格式的数据。
现在很多的物联网平台也已经支持OPC UA了，比如国外的Azure，国内的阿里云等物联网平台。
不过OPC UA最初的client与server之间的查询与响应的一对一模式最适合通讯节点较少，通讯信息量大且稳定持续的场景。在物联网的应用场景中，往往通讯节点比较多，但是节点间的通讯量不大，有时还需要一对多、多对一通讯。如果还用一对一的模式去拥抱物联网，容易扑个空。这时OPC UA引入了pub/sub机制，融合了一些MQTT协议，就能比较好的支持物联网的场景了。相关的白皮书已于2018年发布，感兴趣的朋友可以去官网下载，看看细节。
4、OPC UA常用调试工具
无论是开发OPCUA的产品，还是在现场调试，常常需要一些调试工具。这些工具包括客户端和一些模拟服务器，Matrikon, IntegrationObjects, unified-automation这些厂家都有出品，可以去官网免费下载的，使用也很简单。这里推荐unified-automation出品的调试神器UA Expert和UA server。
在调试通讯产品时，通过抓包，分析报文是很有效的手段。对于OPC UA协议，非常推荐使用抓包神器Wireshark来完成这项工作。Wireshark对OPCUA的支持也是很完善的，已经将OPCUA加入所支持的协议列表里，缺省的端口为4840。
打开Wireshark,然后在OPC UA做些操作，比如browse节点。这时候在Wireshark中就能看到这个browse请求的细节，对照白皮书第四篇，瞬间秒懂各个细节。所以，只要左手Wireshark，右手OPC UA白皮书，两天即可轻松实现从入门到精通。(其实学习任何网络协议都可以这样，左手协议解析器，右手白皮书。)
5、OPC UA开源库
除了上面提到的调试工具之外，现在网上也涌现出很多的OPC UA开源库，开发的语言也是琳琅满目。这也可以看出OPC UA的生态圈是非常好的。巧妙的使用这些库可以很好的提高我们开发和测试产品的效率，比如完成一些功能测试，回归测试，性能测试，模糊测试等等。
这里介绍两款开源库：
◆python-opcua：源代码网址为：
优点：它最大的特点就是简单，用pip install opcua安装即可，经过几年更新以后，对OPCUA协议的支持也越来越充分，既支持服务器，又支持客户端。下面是官网给出的实例，用不到30行代码就能创建一个包含一个动态点的服务器。
缺点：这个库的性能差一些；有部分OPC UA协议标准中定义的服务还没有支持。最后，在使用的过程中发现存在一些bug。
◆UA-.NETStandard：源代网址为：
优点：这个库是OPC基金会官方出品的库，包含服务器，客户端，可以在windows，linux运行，也可以在iOS和Android运行。它的性能很好，拿到了OPCUA实验室的官方认证，对OPC UA协议标准支持的全面程度自然没得说了。
缺点：从工控人的角度看，需要一些C#的编程技能，上手稍微慢一点，没有Python那个库容易学习。Git上同样有一些实例工程，可以在它们的基础上根据自己的开发和测试需求做修改。
6、小结
可以说OPC UA的统一架构真的是包罗万象，既能做实时数据，又能做历史数据，既能上云，又能嵌入到控制器，甚至可能被封装到PLC中的功能码，将触角深入到工控通讯行业的各个角落。真所谓：可上九天揽月，可下五洋捉鳖。这从它超过14卷的白皮书就能看出它的野心。而且还是一款成长中的协议，还有很多的功能在拓展，比如：OPC UA还在与TSN技术融合，要在数据链路层搞点事情。
作为吃瓜群众，我有时候觉得OPC UA不只是想要统一架构，更是想一统江湖。可是世界上没有完美的东西，这样一个大而全的架构，它的缺点是什么？OPC UA又会用什么样的方式完善呢？欢迎你也来聊聊你的想法！
相关阅读
PCS 7通过OpenPCS 7站组件实现OPC UA通讯
通过OPC UA标准实现Kepware与SCADA软件的数据交换
