探讨OPCUA 与IEC61499融合

      

OPC UA 与IEC61499 的特点

        OPC UA 是通往数字化重要的标准，它不仅提供了一种独立的通信协议，同时提供了构建信息模型的方法。

            同样地，IEC61499 也称为是一种构建分布式控制系统模型的标准，最重要的概念是功能块和功能块网络。就这一点看，OPC UA 和IEC61499 同样都是一种建模标准。但是它们的侧重点是不同的，OPC UA 侧重于工业控制领域资产模型（asset model） ，并且基于面向对象的设计思想。OPCUA 信息模型更适合数字孪生，仿真，工业4.0 管理壳的建模，已经获得了工业届的广泛认可。IEC61499 侧重于分布式系统的控制流的建模，IEC61499 的事件流充分体现了控制流。当然，这两种标准也相互交叉，例如，OPC UA 在包含了状态机，方法等元素。而IEC61499 中提出了复合功能块嵌套，子应用等元素体现了面向对象的设计思想。但是，两种标准的侧重点的差异是存在的。各有千秋。

OpcUa 与IEC61499 相结合

            两种侧重点不同的标准相结合，将会涌现出更加强大的功能。IEC61499 分布式系统模型弥补了OPC UA 执行组件控制流建模的不足。IEC61499 事件功能块网络实现了OPCUA 的分布式系统模型控制流建模，OPC UA 的状态机和方法调用只能实现高层的控制流，而方法的算法仍然需要借助于其它程序设计语言来编写，例如IEC61131-3 的ST 语言。OPCUA与IEC61499 相结合，能够直接使用IEC61499 功能块网络来描述算法。

     OPCUA 与IEC61499 相结合的方法是使用OPCUA 信息模型来封装IEC61499 的功能块，功能块连接和功能块网络模型。原先的IEC61499 运行时通过调用OPCUA 的信息模型来存储和访问功能块数据，并且解释执行功能快网络的执行。通过OPCUA 的Pub/Sub和Client、Server 协议实现分布式设备中功能块之间的事件和数据通信。基于OPCUA/IEC61499 的分布式控制架构如下：

 IEC61499 模型融入OPCUA 带来的好处在于：

•    进一步规范了IEC61499 标准中通信协议的使用

         IEC61499 在通信协议方面的规范是相对宽泛的，不同厂商的设备之间协议并不互相兼容，例如4diac 中使用的是TCP/IP ,语义封装采用的是ASN.1协议，而其它厂商，例如施耐德公司的PAC 使用winsocket 协议，并且加了密，内部语义并没有公开。到目前为止 4diac 运行时与施耐德PAC 运行时是无法互联互通。因此，IEC61499 并不是完全开放的标准。 

        如果IEC61499 的分布式系统采用了OPCUA 协议，设备之间的协议和语义模型都是公开透明的，完全可以通过用户来定义，实现不同厂商之间设备兼容性。设备之间采用OPCUA Pub/Sub 协议。

        此外，OpcUA 协议中导入了加密和安全机制，要比其它的协议更加安全可靠。

无处不在的OPC UA 

• IEC61499 功能块，功能块网络和系统描述的标准化

        尽管IEC61499 功能块的图形化定义和结构是标准化的，但是xml 文本并没有详细规范。仅仅有一个IEC 61499 Compliance Profile做了一些规范。不同系统的xml 文本并不相同。使用opcua 作为IEC61499 功能块的建模语言避免了不兼容的问题。所有的IEC61499 模型最终转换成为OPCUA 的 Nodeset2 文本。能够导入到任何OpcUa Server 中，而且能够使用任何OPCUA Client 访问。完全是透明可见的。

• 降低了IEC61499 的学习负担

      OPCUA 封装IEC61499 模型避免了系统工程师额外学习IEC61499 技术的学习负担，有利于IEC61499 标准的推广。平心而论，IEC61499 已经突出十几年了，从事IEC61499 技术开发的人并不多，也很努力。但是IEC61499 更多地停留在学术研究阶段。直到近几年才有一些厂商推出了商业化产品。要让IEC61499 成为工业1自动化的主流技术，还需要寻找“发动机”。让IEC61499 寄生在OPCUA 信息模型中，也许是一条出路。

使用OPCUA 封装IEC61499 模型的缺点：

    在运行时实现中，所有的功能块都封装在OPCUA 信息模型中，运行时程序需要通过访问OPCUA 模型来获取功能块的信息。这要比内部构建数据结构的方法需要执行更多的程序代码。增加了CPU 的开销。当然也有一些技术能够提高程序的执行效率。比如增加一些内部队列。

应用场景

           大多数IEC61499 技术开发和研发者都试图用IEC61499 取代传统PLC 。笔者认为，这是一条困难的道路，也许无法实现。与IEC61131-3 相比，IEC61499 具有许多优点。但是它毕竟是一个后来者，而IEC61131-3 在自动化领域根深蒂固。笔者看来， 开发替代PLC 的IEC61499 设备是天真的想法。IEC61499 技术面向新的领域 。

            我们尝试的应用方向是使用IEC61499 技术实现现场设备组成的分布式控制系统。面向离散制造生产线，制造业的边缘技术设备，云服务，AI等新应用场景。

    

        另一方面，IEC61499 在设备协同操作，工业4.0 ，物联网，测量，仿真，数字孪生等应用中的程序编排中也具有广阔的应用前景，而且这是传统PLC 难以应对的地方，才是IEC61499 的用武之地。

      在研究IEC61499 的过程中，我们曾经也花费了许多事件来开发“类PLC”产品。现在PLC 已经成为标准化的产品，国产化PLC 和远程IO也基本成熟。我们放弃了“类PLC” 产品，直接购买合适的PLC 产品，作为OPCUA/IEC61499 设备的硬件扩展。OPCUA/IEC61499实现更强大的功能。

实验系统

         为了进一步地研究OPCUA 和IEC61499 相互融合的可能性和效果，我们研发了一个OPCUA/IEC61499 分布式控制系统的原型系统。称为 OpenDACS （Open Distributed Automation Control System）。它基于OPCUA 协议和通信协议，并且使用IEC61499 基于事件的功能块构建开放性分布式系统。OpenDACS 完美地将OPC UA 信息模型和IEC61499 分布式控制系统模型完美地结合在一起。

   目前我们的研究工作主要集中在Open DACS runtime 的研发。它具备如下特色：

•  使用4diac 作为IEC61499 的开发环境，将4diac 的输出文档制动转换称为OpcUA 的design Model 文档。在此基础上开发轻量级IEC61499 IDE。  
• 使用OpcUa 信息模型 封装IEC61499 功能块和功能块网络。
• 使用OpcUa Pub/Sub作为功能块之间的通信。
• 使用OpcUa 设计文件（xml) 作为模型描述语言，转换为NodeSet2 文档，动态导入运行时。

模型设计流程

            如上所述，我们保留使用4diac IEC开发61499 IDE。这样做的好处在于4diac 毕竟是一个著名的IEC61499 开源项目，学习和使用4diac 的IEC61499 爱好者比较多，使用4diac 避免了用于再去学习新的开发工具。

             另一方面，随着chaTGPT 等AI技术的成熟，未来的自动控制程序编排趋向多元化，不会采取图形化编程一种方式。更多的可能是基于文本的设计。因此，OpenDACS采取了基于文本的设计流程。

 使用4diac设计的IEC61499 应用文档，通过下列流程进行处理： 

•  4daic 输出的文档通过我们自行编写的转换软件Converter 转换成 ModelDesign 文档
•  OPCUA Fundation 提供的开源工具UA_ModelCompiler 工具将ModelDesign文本转换成为Opcua 的NodeSet2 文本。
• 使用uaModeler 或者西门子的SiOME 工具设计设备的OpcUA 信息模型，直接导出NodeSet2 文本
• 将IEC61499 应用的NodeSet2和uaModeler 导出的NodeSet2 文档一起导入到ODACS 运行时。

模型及功能块程序库

设备的模型有两部分组成：

• 信息模型（information model)
• 功能块模型（function block model)

      功能块模型是可执行模型，它基于IEC61499 功能块，IEC61499 功能块模型主要包括：

• 功能块
• 功能块网络

     在IEC61499 的观点下，一个分布式控制系统能够使用基于事件的功能块网络来描述。

                IEC61499 功能块是运行时内部的实现，不仅需要模型文档，还需要功能块库。它由C++ 编写。与运行时一起编译，另外也支持用户编写功能块，生成C语言的动态库（so），由运行时动态导入。这一功能非常有用，是目前4diac 不支持的。

运行时软件架构

     

 结束语

        不同的技术相互碰撞，可能会涌现出创新的功能，我们尝试将OPCUA 与IEC61499 深度融合，面向数字化制造领域新的应用场景。这是值得探讨的。

        目前实验项目已经迭代到第二版测试，测试结果将在后续的文章中介绍。