构建OPC UA 可执行模型

Posted 姚家湾

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了构建OPC UA 可执行模型相关的知识，希望对你有一定的参考价值。

        OPC UA是工业自动化领域的一项重要的通信协议。它是一种基于信息模型构建的。当一个信息系统中都采用了OPC UA通信协议之后，组件之间能够以模型中的对象，变量，方法和事件来相互交换信息。它将是工业4，0 技术的重要组成部分。

     IEC61499是分布式控制系统建模标准，它的核心是基于事件的功能块。是被人们看好的一项开放自动化领域的技术标准。

    这两项技术们都是一种建模的方法，OPC UA 侧重于信息交换的信息模型，关注设备之间的互联互通，数据交换。而IEC61499 侧重于分布式控制测量系统执行组件的建模。关注程序的执行。所以也有人将IEC61499称为分布式自动化的可执行建模语言。它们之间的互补性非常大。另一方面，它们都是基于面向对象的思想，许多的方法，概念和术语具有相似性。

      从应用的角度来看，OPC UA发展非常迅速，已经被工业界广泛采纳和应用，目前大多数工业自动化厂商的产品和软件中都融合了OPC UA 的技术。大量的工业数字化标准都建立在OPC UA 的基础之上的。最近OPC UA 基金会又提出了OPC UA FX 现场总线的规范。将OPC UA协议与时间敏感网络技术相结合，建立OPC UA 的现场总线协议。这将进一步推动OPC UA 称为工业自动化领域统一的协议。

        相比之下，IEC61499 没有那么幸运，尽管IEC61499 基于时间的功能块在分布式控制与测量领域具有实时性，确定性等诸多优势，而且十几年来学术界不断地研究，但是始终没有被自动控制行业广泛地接受。目前除了施耐德电气公司具有商业化的IEC61499 PAC 产品以外，没有多少企业跟进。而OT行业的系统集成商更不熟悉这项技术。IEC61499 标准被OT行业接纳，流行也许有很长的道路要走。

OPC UA 与IEC61499 深度融合

        作为一个IEC61499 标准以及相关技术的研究人员，我一直在研究和探索IEC61499 技术如何破局？使这项技术能够在工程中实际应用。最近我们的研究表明，将IEC61499 功能块与OPC UA信息模型深度融合也许是IEC61499 标准一条出路。具体的做法是采用OPC UA 构建IEC-61499 的模型，它们包括功能块类型，功能块网络和系统模型。采用OPC UA 通信协议和数据模型实现IEC-611499 中的通信协议。在设备的内部将OPC UA 的模型转换成为IEC-61499 运行时内部的数据。IEC-61499 仍然以原来的方式运行，并将数据注入OPC UA 信息模型中。

        IEC-61499 嵌入在OPC UA 之中。以OPC UA 的信息模型呈现在OT 工程师面前。可以使用OPCUA的所有工具来编排IEC61499 功能块应用。工程师不再需要学习另外一套名称，术语。

隐藏在OPC UA模型背后的运行时

        初学OPC UA 信息模型，给人的感觉OPCUA 模型是用来描述数据。这些数据模型的被动的，由应用程序注入数据，由Client 读取数据。信息模型如何建立行为模型呢？比如，当传感器接收到电机转速的数据之后，由PID 算法来保持转速的恒定？OPC UA中提供了描述对象算法的方法（Method）。而Mehtod 如何被调用。由此看来，要由一个更高层次的程序来调度和编排OPC UA 信息模型中数据流动和方法的执行流程。它就像一双上帝之手，神一般地存在。

        在OPC UA 信息模型的背后有一个强大的运行时（runTime）支撑。这类似于IEC61131-3 和IEC61499 的功能块，通过调度（schedule），状态机（stateMachine），和引用（reference ） 的支撑，来描述功能块被执行的流程。当然这些控制对象执行的对象和对象背后的功能实现是需要服务器内部的程序支撑的。也就是说，如果OPCUA 信息模型具有一个运行时（专家称其为解释器，不过我喜欢使用运行时这个称呼）和程序库支撑下，OPCUA 就成以一种程序执行模型。它们可以采用数据流方式，也可以是基于事件的方法来运行。

        不过，无论是解析器，还是运行时。这都将会引发一个问题出来，这就是不同厂商解释器的兼容性问题。比如不同厂商对于特定reference 的解析方式是否兼容。这似乎又不是OPCUA 标准中的内容。这里关键是reference的处理方式以及数据发生改变后的处理与算法，

          例如我们可以在节点之间设置“Execute” 引用。当源对象的值发生变化时，运行时沿着“Execute”引用，执行目标节点的功能块的程序（EventAction）。每个OPC UA 对象有一个C++ 对象与之对应。

     采用PLCopen 功能块，或者IEC61499 功能块作为进一步的规范也许是一个好办法。OPC UA 模型背后的运行时遵循PLCopen或者IEC61499 功能块的方式。

用OPC UA 信息模型构建IEC61499模型

        IEC61499 的模型相对比较简单，完全能够使用OPC UA来构建，反过来，以IEC61499 的模型来构建OPC UA 信息模型要简单的多。

使用OPC UA 信息模型构建IEC61499 模型的任务包括下面几个部分

  1. 使用OPC UA信息模型构建IEC61499 功能块类型
  2. 使用OPC UA 信息模型构建IECIEC61499 功能块网络的信息模型
  3. 使用OPC UA 构建IEC61499 系统，资源的信息模型

IEC61499 功能块OPC 模型

        单从IEC61488 的外部封装来看，IEC61499功能块包括了事件的输入，事件的输出，数据的输入和数据的输出。它们完全可以使用OPC UA 信息模型来构建功能块。下图是一个简单Inv功能块的OPC UA 模型封装示意图。

IEC61499 功能块网络的OPC UA模型

        IEC614999 的应用是功能块网络。功能块网络是功能块实例通过连接（connection）构成的。在OPC UA信息模型中，connection 对应于reference。我们可以使用hasConnection来作为功能块的连连接。

例如下面是一个最简单的IEC61499 功能块网络。

 

IEC61499 系统的OPC UA 模型

        使用OPC UA 构建IEC61499 的设备模型，资源模型和系统模型。

IEC-61499 系统模型建立在OPCUA DI 之上构建。

模型分层结构

Device

     ParameterSet

     MethodSet

     AlarmSet

 resource

    FBNetwork

FunctionBlocks Type 

参数集(ParameterSet)

设备变量

  • 设备的型号（Model）
  • 制造厂商
  • 制造厂商的Uri
  • 硬件版本
  • 设备版本
  • 软件版本
  • 网络地址
  • 设备序列号
  • 产品代码

 全局变量

   设备中针对应用的变量同样放置在ParameterSet 中。尽管Client 能够访问所有功能块的输入、输出事件和数据，但是作为一个设备而言，对外呈现的名称可能不同。所以对外的数据还是独立呈现在ParameterSet 中。

 在IEC61499 功能块中UA_Variable功能块。用于读写OPCUA 的变量。

算法集（MethodSet）

算法集中包括了OPC UA Client 能够调用的所以方法，这些方法包括了设备固有的方法，例如：

启动Start

停止Stop

下载功能块网络（Load FBNetwork）

另外，也可以调动IEC61499 的服务接口功能块（SIFB）。例如，我们可以定义一个UA_Method.

告警集（AlarmSet）

设备向Client 发出警告，同样地，构建了一个IEC61499 SIFB 功能块。

 

 当该功能块接收到REQ事件时，触发该事件。当INIT 事件时，在AlarmSet 中构建一个Alarm 

基于OPC UA 的IEC61499 控制系统的架构

        有一部分技术是IEC61499 标准中没有具体规定的内容，例如运行时的管理协议，它们采样可Client/Server 方式实现。具体的语义没有特别的指定，分布式控制器之间的网络协议，信息的语义也没有具体规范。数据采用了ASN.1抽象语法标记（Abstract Syntax Notation One）是国际标准ISO 8825-1。。所有这些在IEC 61499兼容性规范（Compliance Profile）。这样同样会造成厂商不独立的情形。比如4diac 的运行时与施耐德的运行时就无法互联互通。

        使用OPC UA的信息模型，将使上面这些不确定的部分采纳OPC UA的模型，改善IEC61499 兼容性的问题。具体的做法如下：

        控制器的管理采样OPC UA client/server 协议。任何OPC UA Client 都能够实现对控制器的管理，OPC UA 的监督，订阅功能能够实现IEC61499 控制器的管理和数据监督。

        控制器和控制器之间采样OPC UA pub/sub 协议实现。数据交换的格式符合OPC UA 信息模型。如此一来，OPC UA 实现了IEC61499 控制器南北向和东西向的协议标准。

IEC61499 与OPC UA深度融合带来的优势

        IEC-61499 与OPC UA 相互融合带来了独特的优势，并且为IEC-61499 在OT 领域的商业化应用打开了一扇门，具体地优点包括：

  • 统一使用OPC UA 信息模型构建模型，避免OT工程师额外学习IEC-61499 的模型。降低了IEC61499 的学习曲线。
  • 统一采用OPC UA 的协议和数据类型，可以借助OPC UA 的设计工具。更好融入以OPC UA 为基础的工业4.0 体系。与其它工业软件互联。
  • 弥补了OPC UA 算法描述能力的不足，提供了构建基于OPCUA 信息模型的分布式控制系统的方法。
  • 以IEC-61499 的方式构建OPC UA 的算法库，模型库。以及逻辑执行模型。

实现方案

        为了验证OPC UA与IEC61499 深度融合的想法，我们计划一个实验性项目。OPCUA-Forte。这是一个基于OPC UA 模型的IEC61499运行时，它接受IEC61499 开源项目4diac 的功能块类型描述（XML）文件和项目的文档Project.sys(XML 文档) 转换成为OPC UA 的功能块类型对象。和功能块实例UPC UA对象。

下面是E_CTD 功能块转换后的格式

<Model>
    <UAObject BrowseName="E_CTD">
        <DisplayName>E_CTD</DisplayName>
        <UAObject BrowseName="InputEvents">
            <DisplayName>InputEvents</DisplayName>
            <UAVariable BrowseName="CD" DataType="INT32" AccessLevel="3">
                <DisplayName>CD</DisplayName>
            </UAVariable>
            <UAVariable BrowseName="LD" DataType="INT32" AccessLevel="3">
                <DisplayName>LD</DisplayName>
            </UAVariable>
        </UAObject>
        <UAObject BrowseName="OutputEvents">
            <DisplayName>OutputEvents</DisplayName>
            <UAVariable BrowseName="CDO" DataType="INT32" AccessLevel="3">
                <DisplayName>CDO</DisplayName>
            </UAVariable>
            <UAVariable BrowseName="LDO" DataType="INT32" AccessLevel="3">
                <DisplayName>LDO</DisplayName>
            </UAVariable>
        </UAObject>
        <UAObject BrowseName="InputVars">
            <DisplayName>InputVars</DisplayName>
            <UAVariable BrowseName="PV" DataType="UINT" AccessLevel="3">
                <DisplayName>PV</DisplayName>
            </UAVariable>
        </UAObject>
        <UAObject BrowseName="OutputVars">
            <DisplayName>OutputVars</DisplayName>
            <UAVariable BrowseName="Q" DataType="BOOL" AccessLevel="3">
                <DisplayName>Q</DisplayName>
            </UAVariable>
            <UAVariable BrowseName="CV" DataType="UINT" AccessLevel="3">
                <DisplayName>CV</DisplayName>
            </UAVariable>
        </UAObject>
    </UAObject>
</Model>

        在IEC61499 运行时中，构建了与功能块对象对应的功能块C++类和实例。在建立OPC UA 功能块对象的同时，创建相应的C++功能块对象。

        运行时根据OPC UA 功能块对象的数据引用（DataConnectTo）改变相应功能块的输入数据。根据OPC UA 功能块对象的事件引用（EventConnectTo）执行响应的C++对象中的事件处理程序执行。

IEC61499 运行时根据OPC UA 模型的对象和引用顺藤摸瓜地运行IEC61499 网络。

        由这个实验项目可见，OPC UA 信息模型除了描述设备的数据模型之外，还能够描述控制器的执行逻辑，背后需要一个运行时来支撑。而执行逻辑的规范化同样十分重要。IEC61131-3 和IEC61499 是两个不错的选择。

        由于IEC61499 适合分布式控制系统，所有采用IEC61499 的机制来构建OPC UA 的控制逻辑更具有灵活性。

IEC运行时API接口

OPC UA->Runtime

  1. 事件执行EventAction
  2. 回调CallBack

Runtime->OPC UA Server

  1. 事件通知NotifyEvent
  2. 读变量值ReadVariableValue
  3. 写变量值WriteVariableValue
  4. 设置时钟

进一步的工作

IEC61499 分布式协议

        目前我们构建的OPC UA Forte 已经能够运行，在后续的文章中我们将进一步报告分布式互联协议OPC UA Pub/Sub来支撑IEC61499 控制器之间的协议。以及IEC61499 与物理IO 的SIFB 功能块的实现和融合。

IEC61499 模型集（NodeSet）

        OPC UA已经为控制设备建立了OPC UA For Device 模型集，已经支持PLCopen 的OPC For PLCopen 模型集（PLCopenNodeSet.XML）参考这些模型集，

我们尝试构建OPCUA for IEC-61499模型集（IEC61499Nodeset.xml）

基于图形化的建模方式

        设计一种简约的模型构建方法至关重要。uaModeler 建模软件采用了圆圈-线图形表示方法，当模型复杂的时候会造成眼花缭乱。我们更倾向使用类似IEC61499 功能块的方式来表达模型。IEC-61499 的复合功能块能够有效地表达模型的分层结构。结构性比较好。

结束语

      当OPC UA 信息模型来构建行为模型时，需要在OPC UA基础上构建描述行为逻辑的信息模型。可以参考IEC61131-3 PLCopen以及IEC61499 的建模方法。在行为模型的背后需要一个运行时（RunTIme）。通过运行时能够使OPC UA 行为模型中的数据和计算方法流动起来。本文介绍了我们构建IEC61499 OPCUA 运行时的方案和某些考虑。

    另一方面，将IEC61499 基于事件的功能块建模方法融入OPC UA 信息模型。有助于IEC61499 以一种全新的方式进入工程应用领域。这是一个有意义的设想。我们为此做了一个实验系统

以上是关于构建OPC UA 可执行模型的主要内容，如果未能解决你的问题，请参考以下文章

构建OPC UA 可执行模型-建模工具

构建OPC UA 可执行模型-建模工具

构建OPC UA 可执行模型

OPC UA 与IEC61499 深度融合

使用OPC UA 封装IEC61499模型

SharpNodeSettings项目，可配置的数据采集，统一的工业数据网关，OPC UA服务器开发，PLC数据发布到自身内存，redis，opc ua，以及数据可视化开发