IEC61499 与OPC UA

 

          第四次工业革命的一个关键点就是将车间里的所有东西都数字化，它们包括生产过程，设备和部件数字化，增加它们的互操作性。为了达到数字化，需要努力建立一系列标准来建立统一的接口，实现异构的项目透明地通信。通过这种标准化技术，传统的物理设备和数字技术相互的融合。构建所谓的信息物理系统（ Cyber-Physical  System），将这些CPS 连接到网络中。在这个概念下，一个电机，泵，阀门或者一台CNC 机床都是一个CPS。在信息系统中，CPS 可以看作为物理设备的数字孪生（digital twin）。CPS 是计算机科学，信息技术和通信技术发展的产物。而CPPS 称为信息物理生产系统，它代表了CPS 进一步融入制造业科学和技术。比如工艺，控制流程等技术诀窍。制造领域数字化的目标就是将车间中的所以东西都改造成为CPPS。

     下面是工业4.0 的组件模型（The Industrie 4.0 Component model）。这个组件模型指定每个资产（逻辑的或者物理）封装在一个标准化的数字容器中-管理壳（Adminsitration Shell）。它能够实现所有I4.0 组件之间的描述，协同操作和通信。

CPPS 中涉及的计算机和通信技术非常多，基本的数字化目标有两项：

    协同操作   

       各个CPPS能够通过网络实现协同操作是实现工业4.0 的理想，人们甚至提出了“即插即生产”的概念，不同厂商的软件，设备通过网络协议能够实现相互操作。显然，需要有一个统一的协议标准，而且这个协议将是语义网协议。也就是说，既要听的见，还要听的懂。 OPC UA 协议就是为此设计的。OPC UA 已经成为工业4.0 RAM I4.0 模板通信协议事实标准(de facto Standard). 

    作业流/制程控制

          如果一个物理资产（asset）不需要可编程控制，比如一个传感器，或者一个阀门。那么CPPS 中只要有OPC UA 服务器就足够了。但是如果控制设备中包含了作业流/制程控制（Work flow / recipe control)。就需要一种高效率的编排工具。 IEC61499 是分布式工业控制的模型，它提出了基于事件功能块编排应用程序的方法。可以作为调用资产中各种软件部件的工具。

    将OPC UA 和IEC61499 标准融入CPPS 模型中。可以建立可编程自动化控制器（PAC）的CPPS架构。如下图所示：

I

 OPC UA 和IEC61499 成为了两个工业4.0 的重要标准，我们就来探讨基于OPC UA 和IEC61499 标准的PAC的架构以及实现过程中需要考虑的问题。

OPC UA

     网络和各种论坛上讨论OPC UA的人也也来越多了起来。几年内前，我写了一篇关于OPC UA 的博文《OPC UA的本质》，从面向对象的概念出发，介绍OPC UA 的基本概念和逻辑。虽然比较粗糙，但是却是我所有博文中获得点赞最多的一篇。这样充分说明，OPC UA 技术已经开始普及。关心它的人也越来越多。

     OPC UA 是建立数字化模型的工具。可以实现设备，软件组件和服务的统一的数字化呈现。对照传统的网络OSI 七层模型，它应该是表示层协议，而且它是一个语义网协议。OPC UA描述语义的方式采取了面向对象程序设计的思想。OPC UA 信息模型是节点的网络（Network of Node,），或者称为结构化图（graph），由节点(node)和引用(References)组成，这种结构图称之为OPC UA 的地址空间。这种图形结构可以描述各种各样的结构化信息(对象)。

​​节点(nodes) : 共计有8种节点(对象,对象类型,变量,变量类型,视图,方法,引用,数据类型)。节点之间的相互引用构建成为Node 网络图。

在OPC UA 能够广泛地应用之前，需要建立各个行业统一的OPC UA 模型。比如建立泵，阀门，CNC机床，注塑机等等物理设备的OPC UA 模型。这不仅需要研究部门，自动控制化厂商和标准化组织的努力，更需要其它行业达成共识。

           推动OPC UA 升温的一个原因是大型自动控制系统厂商的软件开始支持OPC UA 了（比如西门子的WinCC）。如果第三方研发的设备具有了OPC UA 服务器功能，就可以顺畅地接入由这些大型的软件构建的系统之中。毕竟小型设备厂商自行开发大型的上位机软件是困难的。当然，从更高的站位思考的问题，由于OPC UA 是一个开放的，与厂商无关的国际标准。我们有机会借此摆脱传统大厂的垄断，开发自主可控的工业自动化系统，软件和设备。当然，这需要我们足够努力，并且达成共识。

 IEC61499

        控制设备中普遍采用PLC 的梯形图，后来发展成为IEC61131-3 编程方式。它们是一种基于周期执行方式的编程方式。这种编程方式已经移植到工业PC上，实现所谓的软件PLC。当大数据，人工智能，数据分析，云计算等技术开始引入工业领域时，人们发现PLC 的计算能力是有限的。IEC61131-3也同样具有很大的局限性。    

             IEC61499 支持基于模型地开发分布式工业测量，控制与监督系统。它的最大特点是基于事件的功能块。应用程序是一个由功能块实例通过链接构成的功能块网络。通过远程部署的方式将应用分段部署到分布式设备中运行。实现总体设计，分布式部署运营。IEC16499 基于事件的功能块网络的概念更加体现了面向对象的程序设计思想。事件的产生与传递类似与面向对象程序设计中类实例的调用关系。从概念上讲，IEC61499 是一种面向分布式工业控制系统的建模工具，但是它本质上是通过为分布式控制系统建模，实现控制策略，算法，软件组件等资源的形式化应用。OT 工程师最终是使用它来建立功能块网络图。尽管在IEC61499 中没有称之为“程序program”，而叫做“应用Application”。所以，我仍然觉得IEC61499 标准提供了一种基于模型的分布式工业自动控制系统编程方式。

IEC61499 与OPC UA相结合

     OPC UA 是一个统一架构的信息模型，而IEC61499 是构建分布式工业控制系统的模型。OPC UA 用于不同设备和软件组件之间的信息交换，而IEC61499 用于建立分布式控制系统的应用。前者更适合通信，而后者更适合建立应用。由此看来，它们的关注点有所不同。如果将OPC UA 和IEC61499 两大标准的技术相结合，可以构建成为工业4.0 中的所谓信息物理生产系统（Cyber-Physical Production System）的模型。

   我们来讨论如何在IEC61499 可编程自动化控制器中融合OPC UA 。首先，我们以著名的IEC61499 开源项目4diac和施耐德公司最近发布的EcoStruxure开放自动化平台  为例，介绍目前这两种技术融合的方式。然后再讨论如何进一步地融合这两项重要的技术。

 4idac 项目中的OPC UA  

         4diac 项目中实现OPC UA 的方式比较直接，IEC61499运行时IForte 内部采用了开源open62541 OPC UA 协议栈，通过现有的通信服务接口功能块来实现OPC UA 的服务器和客户端的实现。 它们包括了Publish/Subscribe,Server/Client 功能块。

     与实现诸如MQTT，HTTP等其它通信协议类似， 4diac 采用通信功能块的ID 参数（ID  数据输入）来指定与OPC UA 软件模块的操作，它分为两部分（远程操作为三部分）由逗号区分：

opc_ua[ACTION;ENDPOINT;PAIR1;PAIR2;...]

ACTION

ACTION 指定OPC UA 的操作， 包括：

1. READ
2. WRITE
3. CREATE_METHOD
4. CALL_METHOD
5. SUBSCRIBE
6. CREATE_OBJECT
7. DELETE_OBJECT
8. CREATE_VARIABLE
9. DELETE_VARIABLE

ENDPOINT

     ENDPOINT 限于opc ua Client模式，指定了 远程OPC UA 服务器的IP 地址，使用# 结束。

例如：

 opc.tcp://192.168.0.100:4840#

PAIR

指定节点的名称和数据类型。

格式为：BROWSENAME,NODE_ID

 4diac 完全是依靠 通信功能块的ID 来操作opc ua的 。它的缺点是ID格式复杂，容易搞错。如果OPCUA 模型比较复杂，功能块应用中通信服务接口功能块会比较多，而且容易造成某些混乱。

下面是4diac 中使用opc ua的一些例子:

使用变量的Flip-Flop 应用

使用变量的加应用

通过OPC UA 方法调用IEC 61499 功能块子程序

  下面是一个加法的例子，在应用中分别使用了OPC UA 的服务器和客户端。

由此可见，4diac 中的forte 实现OPC UA 还是十分简单的做法，不过，如果要实现复制的OPC UA 模型，功能块网络会比较复杂。

施耐德EAE中的OPC UA 服务器

       施耐德公司最近推出了他们基于IEC61499 的EcoStruxure开放自动化平台     EcoStruxure™Automation Expert，简称 EAE 2.0）.实际上，这个平台基于了他们早年收购的nexControl 公司的技术。笔者有幸成为了这个系统的早期使用者。有关使用的细节，在我以前的博文中有描述，这里就不再赘述。我们介绍一下EAE2.0 中实现OPC UA 的方法。

 EAE 的软件运行时中包含了一个OPC UA server。我们可以按照下面的方式测试EAE 的OPC UA 服务器。

     在 EAE 2.0 中，开发环境是支持HMI 的。EAE 通过添加CAT 的方式来实现HMI 。CAT 是nxtControl 的概念，也就是 Composite Automation Type（CAT）复合自动化类型。CAT 并不是IEC61499 的概念和术语。它其实是一个复合功能块，内部包含了一个HMI的服务功能块。EAE 就是使用CAT 及其实例来构建HMI 的。为什么这么做呢，我猜想HMI 设置和选择的东西要比功能块更多，如果单纯使用功能块来组态HMI 的化会比较麻烦，所以他们在IEC61499 标准外面，搞了一个CAT ，对HMI 复合功能块做额外的组态。有开发环境自动地产生HMI 界面和相应的功能块配置。这样要简单一些。

          在EAE 的运行时上有一个OPC UA 服务器。当你使用EAE 2.0 开发环境时，设备属性中有一个OPC UA Stack Configuration。将OPC UA Stack Configuration 属性有Default 改成OVERWRITE 后，可以看见OPC UA 的各项属性。

     但是你会发现OPC UA 参数列表中空空如也，不知道如何将IEC61499 功能块网络的变量和OPC UA 模型中的变量关联起来。后来才发现，只有 CAT_HMI  功能块的输入和输出数据才会在OPC UA 模型中作为变量出现。

 

       这充分表明，EAE 2.0的设计思想非常清楚，OPC UA 和HMI一样，是对外呈现信息的接口。和HMI 接口本质上是一致的。所以这样安排非常的合理。正是应为EAE 的OPC UA 是建立在HMI 功能块参数之上，而且采用了具有更强组态能里的CAT 方式。使EAE 的OPC UA 组态能力要比4diac更强一些。

进一步研究

      是否有更好的方式来融合OPC UA 和IEC 61499 两项技术呢？我们要从现有IEC61499 运行时的不足谈起。我们先来看看IEC61499 设备运行时的通信架构谈起

     IEC 61499 运行时通信架构

   IEC61499 运行时具有两个基本的通信端口，一个是管理命令口，用于功能块应用的下载，管理和监控。它是IEC61499 开发环境和运行时之间的通信。另一个是不同设备中功能块之间的通信。IEC61499 运行时的内部架构如下图所示。

事实上，控制器还需要其它的通信接口，比如访问上位机或者云端系统的通信接口。因此，系统架构就变成为下面的样子：

更合理的架构

   上面的这种结构并不是合理的方式，首先，现在的IEC61499 控制系统普遍是将IDE和系统的监控，部署结合在一起的。在实际的控制系统中，系统中会保留一个IDE 工作站，又有一个SCADA 工作站。为什么不可以使用OPC UA 来管理和监控IEC61499 的应用呢？

 

OPC UA 成为统一的接口

          更进一步地，可以将跨设备的功能块通信也可以通过OPC UA 来实现。是OPC UA  成为真正统一的协议。这对于促进开发自动化系统的实现是十分重要的。就目前几个基于IEC61499 的项目来看，虽然在功能块定义，描述方面部分实现了开放。但是不同的项目之间依然存在鸿沟，比如IDE 和运行时之间的通信协议，跨设备的功能块通信协议。不同的系统相互是不兼容的。4diac 使用的是TCP/IP 加ANS.1 编码，而施耐德EAE 中使用的是加密的websocket 协议。这些协议不统一，不开放，开发自动化系统就是不完全。

     笔者认为，使用OPC UA 作为IEC61499 系统的统一标准是解决这些问题的好方法。采用OPC UA 作为统一接口的IEC61499 系统如下图所示：

     

  在图中，IEC61499 PAC 也能够通过OPC UA Client 去访问具有OPC UA Server 的CPS，例如西门子的CNC机床，或者某个机械臂。毕竟，现在具有OPCUA接口的设备越来越多了。

当然，全部采用OPC UA 协议的话，可能会增加设备处理器的开销，从而增加CPU 的负担。

实现的考虑

在基于opc ua /iec61499 运行时的实现中，有许多问题值得探讨：

1  IEC61499运行时核心与OPC UA 服务器之间的信息交互方式

PAC 中建立一个opc ua 的守护线程，每当外部client 接入，就新建一个线程来实现交互。IEC61499 运行时内核通过线程之间的消息队列实现RPC 调用实现交互。

 

2  构建更加清晰的OPC UA 功能块库

   本人比较喜欢4diac 项目的OPC UA 的实现方式，因为这样做能够使得OPC UA 独立于HMI 软件实现。但是，它将通信服务接口功能块来直接操作UPC UA的方法使用起来比较麻烦，特别是ID 字符串容易写错。可读性差。我们可以尝试构建独立的OPC UA 功能块库，是概念上更清晰一些，并且提高IEC61499 运行时与OPC UA 服务器之间交互的效率。我们会在后续的博文中介绍这方面的工作。

结束语

      本文结合工业4.0 中的I40 组件模型和CPPS 架构，讨论了IEC61499 PAC 中结合OPC UA 的几种方式。最后提出了OPC UA+IEC61499 的统一架构，并且讨论在IEC61499 runtime 中实现的方法。这只是笔者的一些思考。供读者共同讨论。