Open62541 是著名的OPC UA 开源项目,网络上有许多的介绍,对学习OPC UA 信息模型非常有帮助。但是介绍在实际产品中应用并不多。该项目中的一些例子也只是一些简单的演示。
本博文探讨如何使用Open62541 开源代码开发一台OPC UA 网关产品的软件。它的主要功能是将PLC 内部的存储器变量映射到OPC UA 的信息模型中,网关与PLC 之间采用modbus 协议。
OPC UA 组织为各种行业制定了各种规范。并且提供了Nodeets ,它们是预先制定的信息模型。这些规范可以在下列地址中找到
https://github.com/OPCFoundation/UA-Nodeset
对应于PLC 有DI和PLCopen 两组NodeSet 可供采纳。它们通过Nodeset Compiler预先编译好。用户的OPC UA 模型是建立在这些模型之上的。我们希望直接构建用户的信息模型模型。
要实现一个通用的OPC UA 服务器,至少要解决两个问题:
upc ua 建模的方式通常是使用建模工具建模(比如uaModeler),直接输出C,C++,C# 源代码,然后与OPC UA 服务器的代码一起编译。Open62541 也是如此。它提供了一个python 编写的nodeset_compiler工具。将nodeset.XML 编译成为myNS.c和.h文件。然后结合到server 的代码中。
如果是开发一个特定的产品,它的opc ua 信息模型是预先确定的。那么这样做还能容忍,毕竟这是由程序员做的工作。但是在实际应用中,如果开发的产品是一个通用产品,比如PLC,网关或者边缘控制器。要根据具体的应用来构建OPC UA 的信息模型。如果需要OT 工程师来编译和下载软件。那么对于OT 工程师就太麻烦了。他们也不擅长这样的工作。
我尝试的方法是。开发一个简单的组态软件,应用工程师使用该组态程序构建OPC UA 的信息模型,完成后导出opc ua 模型的configuration.xml 文档。
在服务器端根据Configuration.XML 文档由服务器端的程序完成模型的添加。
我主要的关注点是在设备中实现OPC UA 服务器。信息模型需要与硬件融合在一起。所有在建模的同时需要额外的配置,例如变量与物理地址的映射关系等(下面我们会进一步的探讨)
想必这一的软件比较容易实现,可以使用树形结构和填表的方法来实现。这里就不展开讨论了。我们首先是手动的方式编写了一个Configuration.xml文档。
目前的第一版本主要实现一个OPC UA 的子集,满足嵌入式系统OPC UA 的需求。
嵌入式OPC UA 模型包括的主要组件
与硬件的关联并不是OPC UA 模型中的内容,但是在嵌入式系统中是必须实现的。具体的方式有两种:
1 通过OPC UA 来构建一个HardwareVariable 对象,它包括了 变量,物理地址等参数。
2 通过内部的表实现变量与物理地址对应起来。
为了简单其间,目前采用第二种方式。
OPC UA 信息模型中的方法是对内部程序的封装。也就是说,每个方法都将对应服务器内部的一个程序,它们可以是一个子程序,一个功能块,或者是其他形式的程序。OPC UA 并没有提供描述这些程序的方式。只能依靠预先实现各种方法库,或者通过动态链接库的方法下载到设备中。
事件类似于计算机硬件中断。当设备内部发生某个事件的时候,服务器产生一个事件。客户端能够接收到该事件。
事件可以来自于服务器的内部状态的变化,也可以来于硬件的某一个Boolean变量。在我的实验项目中,这种方法。
条件是事件的继承类型。我们采用与硬件变量关联的方式实现。
许多事情看起来都比较简单,一旦深入细节就发现其中的困难。在实现过程中发现。使用Open62541 来开发具体的产品难度还是比较大的。一方面是OPC UA 信息模型非常复杂,另一方面Open62541 的文档不多,网络上的例子大多数是项目中的Example 。自己需要编写的代码还是比较多的。下一步要将modbus 协议与OPC UA Server 代码相结合。
还有一个问题是新版本的uaExpert 在ubuntu 上老是出毛病。不知道是什么毛病。