用于将工业过程装备的描述转换成数据信息模型的网关和方法与流程

本实施例涉及用于将工业过程装备的描述转换成数据信息模型的网关。更具体地，本实施例涉及将工业过程装备的描述转换成用于自动化目的的语义丰富且基于图形的数据信息模型。

背景技术：

过去的工业自动化系统组件传统上已经通过专用网络使用各种用于访问和数据交换的不同协议而互连。

当前和未来的自动化系统和现场设备的发展已经将相当大的注意力放在通用工业标准上，所述通用工业标准旨在标准化对过程数据的访问，以便减少用于设备工程设计、配置、管理、操作和版本控制的努力，以及使能实现基于过程数据的集成和处理的应用。

开放平台通信统一架构或opcua为现场设备的集成提供了一种架构。opcua是opc基金会的一个工业标准协议，其以（特别是在过程自动化中）交换工业数据为目的用于独立于制造商的通信。

然而，今天的许多现场设备是通过替代方法、诸如命名为电子设备描述语言或eddl的描述语言来描述的。因此，在本领域中存在如下需要：即促进由描述语言根据不同的描述方案数据描述的过程装备在由开放工业标准（诸如opcua）描述的过程装备的工业环境内的集成。

技术实现要素：

本文中的实施例总体地涉及一种用于促进过程装备在支持开放工业标准（诸如opcua）的工业环境内的集成的网关。

在一个实施例中，公开了一种用于将工业过程装备的描述转换成用于自动化目的的语义丰富且基于图形的数据信息模型的网关。所述网关包括解析模块，所述解析模块用于通过现场通信协议解析工业过程装备描述中的信息实体，并用于将解析的信息实体转换成声明式逻辑事实并在演绎数据库内断言声明式逻辑事实。所述网关进一步包括使用映射知识库的知识引擎，用于将映射规则应用于所述声明式逻辑事实，由此所述声明式逻辑事实被演绎地映射到基于图形的数据信息模型上。最终，所述网关包括接口模块，用于访问基于图形的数据对象模型。

尽管对于声明式逻辑事实存在许多替代的形式化，例如基于w3cowl的形式化，但是对于在资源受限的设备上部署，datalog的使用被认为是优势。

附图说明

从下面结合附图考虑的对优选实施例的描述中，本实施例的目的以及另外的优势将变得更加清楚和容易领会，其中：

图1示出了工业自动化领域中制造控制的层级分层架构；

图2示出了用于在自动化控制系统内交换数据的功能单元的框图；

图3示出了根据实施例的网关的基本功能单元的框图；

图4示出了应用于声明式逻辑事实的声明式逻辑规则的图形表示；

图5示出了用于在基于图形的数据信息模型中对通用变量进行建模的模型结构；

图6示出了用于在基于图形的数据信息模型中对工业过程装备的描述进行建模的节点结构；

图7示出了在自动化控制系统内用于交换数据的其他功能单元间的根据实施例的网关的框图；和；

图8示出了图示根据实施例的用于将工业过程装备的描述转换成语义丰富且基于图形的数据信息模型的操作流程图的示图。

具体实施方式

工业过程是复杂的，因为它们涉及范围从机械、电子、通信到计算机科学的不同领域的技术。此外，不同的系统在工业过程中扮演范围从现场设备、控制设备、制造执行系统到企业管理系统的不同角色。

直到今天，工业过程被所谓的自动化金字塔分类。图1的右边部分示出了这样的层级分层的自动化金字塔，其中：

-第一级或现场级fld包括物理现场设备，诸如致动器和传感器；

-第二控制级crt包括诸如可编程逻辑控制器或plc之类的控制设备；

-第三制造级man包括制造执行系统；和；

-金字塔的顶部企业级ent包括企业管理系统。

数据流由这些良好定义的层fld、crt、man、ent结构化，使得数据从个体现场设备经由控制监督和制造执行系统向上流动到企业级。同样，数据从企业系统向下流动到现场设备。

然而，现代工业过程要求在自动化金字塔中如何结构化数据流方面的灵活性。数据应当可在金字塔的每一级处直接访问，而不仅仅是向上和向下的流动。金字塔每层的这种直接访问由图1左侧的倾斜层dac符号化，所述倾斜层dac被配置用于在自动化金字塔的所有级fld、crt、man、ent中进行跨层数据访问。

用于使能实现跨层数据访问的协议选择是opcua。opcua（开放平台通信统一架构）是opc基金会的一个工业标准协议，其以（特别是在过程自动化中）交换工业数据为目的用于独立于制造商的通信。

opcua提供直接的数据访问，无论自动化金字塔级如何。opcua进一步提供信息模型和传输层通信，其中金字塔任何级处的客户端都可以直接访问由任何级处托管的一个或多个opcua服务器提供服务的数据。这包括现场设备级处托管的opcua服务器。opcua提出了一个先决条件，即异构的自动化设备和系统的信息需要利用opcua信息模型（或opcuaim）来表示，opcua信息模型是用于自动化目的的语义丰富且基于图形的数据信息模型。

然而，当前自动化系统环境中的当前现场设备主要由用于工业过程装备的不同描述语言操作。工业领域中一种流行的描述语言是eddl或电子设备描述语言。直到今天，eddl仍是过程工业中广泛使用的标准。由于eddl仅仅是设备的参数、特性、能力和/或要求的结构化列表，因此目前是不可能对接在用于自动化目的的语义丰富且基于图形的数据信息模型的基础上操作的服务器对eddl描述的设备进行直接数据访问。

因此，所提出的实施例的目的是要支持将其特性、能力和/或要求由用于工业过程装备的描述语言（诸如eddl）表达的现场设备（或一般地过程装备）集成到使能实现直接数据访问的当代通信环境中，其中通信环境在语义丰富且基于图形的数据信息模型（诸如由opcua提供）的基础上操作。

更具体地说，问题是如何使来自“棕色地带（brownfield）”设备的信息在opcua服务器的地址空间中可用。术语棕色地带指代由传统描述语言操作的最先进的设备，这些设备要在更当代的环境中部署。eddl并非这样的传统描述语言的唯一示例。存在在棕色地带设备上实现的几种其他设备描述语言，它们需要被集成到通信环境中，以用于促进直接访问数据。传统描述语言包括诸如fdt/dtm或现场设备工具/设备类型管理器、gsd或通用站点描述、io设备描述等语言或协议。所提出的实施例的目的是要支持由任何种类的这样的传统描述语言操作的现场设备的集成。

在现有的自动化系统中，来自现场设备的信息典型地可经由用于控制这些现场设备的控制器来访问。根据图1，该控制定位在现场级fld上或控制级crt处。该控制典型地在工程设计过程期间执行，其中现场设备的自动化系统参数被通过控制器设置和披露。

然后，这样的控制器可以帮助将该信息导出到位于自动化金字塔更高级上的opcua服务器。这样，来自现场设备的信息将可由服务器间接访问，并可以在自动化金字塔的不同级处进一步使用。

然而，对于许多应用，合期望的是不通过中间控制器访问现场信息。这些应用包括增值应用，例如，与现场级资产的监控、管理和优化相关的应用。与通过中间控制器的间接访问相比，更倾向于直接访问现场信息的原因是由于将控制器单独专用于保持系统稳定性的设计原则。对于其他应用，合期望的是除了核心控制之外还可能以廉价且灵活的方式访问现场设备信息。

本实施例总体上提出了一种用于将工业过程装备的描述转换成用于自动化目的的语义丰富且基于图形的数据信息模型的网关，目的是使得诸如棕色地带现场设备之类的工业过程装备能够用于现代工业应用中。

该网关包括基于知识的映射系统，并允许到一个或多个过程装备（特别是现场设备）的连接，以便从每个现场设备收集信息，并在用于自动化目的的语义丰富且基于图形的数据信息模型（诸如opcua）的基础上与服务器或应用交换该信息。对于“向上”的信息交换——例如基于语义丰富且基于图形的数据信息模型的与服务器或应用的交换——网关包括用于访问基于图形的数据信息模型的接口模块。该接口模块优选地通过由网关操作的和/或在网关上操作的opcua服务器（诸如网关内部的opcua服务器）体现。

图2示出了提出的网关gw，该网关gw连接到一个现场设备fd，或者可替代地连接到任何种类的一个或多个工业过程装备fd，并且将从工业过程装备fd的描述中收集的信息传送到一个或多个应用，诸如基于云的应用ca、便携式应用pa和/或用于资产监控、管理和/或优化的应用mo。所述应用ca、pa、mo可以通过由网关ga的接口模块（未示出）提供的标准opcua服务器访问工业过程装备fd的描述（未示出）。

现在参考图3，网关的基于知识的映射map被详细描述为在递送常规或传统现场设备描述fdd（例如由描述语言eddl表达）的输入之间的中间模型，其将信息从所述描述映射到基于图形的数据信息模型，以及由网关内部服务器srv分配数据信息模型。对于基于知识的映射map的过程，使用了映射知识库mkn，其细节将在下面进一步描述。

网关以即插即用的方式操作，即，它连接到现场设备fd，读取其现场设备描述fdd，并将现场设备信息（例如，设备参数）映射到opcua地址空间。然后，可以由网关内部服务器srv使用连接到网关内部服务器srv的任何标准opcua客户端（未示出）或任何标准opcua服务器（未示出）来访问设备参数和对应的值。

根据本实施例的信息模型的映射是使用用于应用演绎推理机制的一个或多个声明式逻辑规则或事实来执行。在下文中，使用datalog作为用于表达所述演绎逻辑规则的一个示例性编程语言来描述演绎推理方法。

datalog语言部分——也称为datalog程序——由声明式规则组成。规则具有规则体（body）和规则头（head），其被表达为：

。

如果datalog系统可以证明体为真——如布尔真——那么它可以推断头也为真。这是datalog系统可以如何从现有知识中导出新知识的机制。

此外，datalog程序和datalog规则是由以下类型的原子公式构建的：

其中p是谓词符号并且标示项。在datalog系统中，一些谓词具有预定义的含义。它们标示内置操作，并且因此被称为内置谓词。考虑到下面将进一步描述的实施例，内置谓词和复合项可以用于处置外部调用或函数，其可以用于将eddl（电子设备描述语言）方法和命令映射到opcua方法。此外，内置谓词和复合项可以用于调用或执行edd或电子设备描述中指定的方法和命令。

回到对datalog的描述，原子公式——或简称：原子——是不能分成严格的子公式的公式。文字是正或负原子。项是常量、变量或复合项。变量利用由大写字母组成或以大写字母开头的字符串（例如var或var）标示，并且引用例如“constant_unit”的常量。复合项实现函数。

函数是如下类型的表达式：

其中f是元数n的函数符号，并且是项。

事实是基准原子公式，例如由下式表达：、

其中“c1”、“c2”和“cn”是常量。

图4示出了应用于声明式逻辑事实的声明式逻辑规则的图形表示，其目的是将数据从一个信息模型映射到另一个信息模型。

可以看出，体文字中的项（图4的右侧）与头原子中的项（图4的左侧）相关。在这种情况下，在输入与体文字结构匹配的单个事实时，将使用输入的事实和现有的datalog规则来演绎datalog事实。

datalog规则可以以这样的方式构造，即它们递归地相互作用，以使用许多个体和定义信息关系的更小的datalog规则来填充完整的映射规则。因此，在该示例中，如果有文字与体文字的常量项匹配并且所述项也作为通配符满足，则具有规则头格式的新的datalog事实将被断言到数据库中。

在下文中，描述了datalog中的opcua信息的表示。带有一个或多个中间大写字母的复合名称（例如，复合名称“typedefinitionnodes（类型定义节点）”）用于指代opc基金会的“opc统一架构”规范中使用的权威名称。这些权威名称假定是已知的，并且对于本领域技术人员来说是已知的。因此，在下文中，引入这些权威名称而不进行解释。

opcua规范包括九个opcua节点类，这包括基节点类。这些节点类中的每一个具有直接存储在节点中的标准化属性。这些节点类中的每一个可以使用谓词指定节点类来存储在datalog中。

对于示例性的opcua类“referencetype（引用类型）”，opcua标准指定了三个属性，即：

通过以语义顺序使用这三个项连同明确引用要存储的节点的唯一节点id，可以将这三个属性存储为原子公式。然后，作为在datalog中的原子公式的opcua类“referencetype”的相应表示是：

opc_referencetype(nodeid,isabstract,symmetric,inversename)。

其opcua名称空间id为1、是抽象类型的、非对称、并且没有逆名称的通过datalog形式化存储referencetype节点的示例是：

。

发明人已经验证了datalog在定义用于将事实的项语义映射到不同事实的语义——从而将一个信息模型映射到另一个信息模型，所有这些都在同一datalog数据库中——的关系规则中的可行利用。

虽然可以创建将处置整个信息模型的非常大的顶级映射规则集合，但是这样的创建将会导致大量的映射规则，从而忽略了使用datalog的演绎能力。然而，datalog的这种演绎能力允许更少的映射规则，因为信息模型的更小组件可以使用然后由更高级的规则以演绎方式利用的规则来映射。这意味着映射规则有利地以层级方式结构化，以便利用规则的可重用性。映射规则的这种构造类似于用于程序代码模块化的编程函数的技术，其中一个函数由多个更高级的函数调用来调用，而不是在更高级内重复编码。另一方面，与编程函数是相当过程化的语句不同，datalog规则是相当声明式的语句，这意味着它们可以不管在程序中的定位如何地被解释。

在下文中，描述了edd信息到opcua信息模型（或opcuaim）的映射。edd文件中的示例性eddl变量被认为如下：

为了完成上面所示的edd信息到opcua信息模型的映射，在第一步骤中完成典型edd文件属性的映射，其后续是映射变量本身的步骤。

由于每个edd文件具有四个顶级属性——制造商id、设备类型、设备修订和设备描述修订，参见上面所示的eddl代码中的前四行——存在四个opcua特性节点要被附加到表示edd文件的顶级对象节点。

每个特性节点是由variable（变量）节点构造的，该变量节点通过命名为“hasproperty（具有特性）”的引用从其父对象引用。变量是使用变量节点类定义的。opcuaim中定义了两种类型的变量：属性和数据变量。variable（变量）节点始终是至少一个其他节点的一部分。

图5示出了在opcua的基于图形的数据信息模型中对一般edd文件的通用变量和顶级属性进行建模的所得模型结构。

在下文中，描述了eddl变量结构中的eddl变量到opcua信息模型的地址空间的映射。

变量典型地描述包含在现场设备中或edd应用中的参数。表示eddl变量的datalog原子公式由如下表达：

根据名为“iec62769-109-1：2015-fielddevicesintegration(fdi)-part109-1:profiles-hartandwirelesshart”的行业标准规范，eddl变量的属性描述被指定为：

-eddl_id——ua对象（uaobject）节点id；

-eddl_id_1——变量（variable）节点id；

-eddl_id_2——变量类型（variabletype）节点id；

-eddl_id_3——opc_数据类型（opc_datatype）节点id；

-eddl_id_4——变量eddl_constant_unit的节点id；

-eddl_id_5——变量eddl_style的节点id；

-eddl_id_6——变量eddl_validity的节点id；

-eddl_variablename——指定变量的标识符；

-eddl_class——指定设备和edd应用如何使用变量以用于组织目的和显示；

-eddl_label——指定元件的所显示标示；

-eddl_type——指定变量的数据类型；

-eddl_constant_unit——如果变量具有永不改变的单位代码，则使用；

-eddl_default_value——指定变量的默认设置；

-eddl_handing——指定可以对元件执行的操作；

-eddl_help——指定文本，其提供对构造的描述；

-eddl_initial_value——指定第一次实例化设备时显示的变量值；

-eddl_post_edit_actions——指定在变量已经写入设备之后应执行的方法；

-eddl_post_read_actions——指定在从设备读取变量之后应执行的方法；

-eddl_post_write_actions——指定在变量已经写入设备之后应执行的方法；

-eddl_pre_edit_actions——指定当变量正要被编辑时应立即执行的方法；

-eddl_pre_read_actions——指定在读取变量之前应执行的方法；

-eddl_pre_write_actions——指定在将变量写入设备之前应执行的方法；

-eddl_read_timeout——指定edd应用应等待返回变量的时间长度，单位为ms；

-eddl_refresh_actions——指定每当显示或刷新变量时应执行的edd方法；

-eddl_response_codes——指定设备可能作为错误信息返回的值；

-eddl_style——指定变量被显示的方式；

-eddl_validity——指定元素是有效的还是无效的；以及；

-eddl_write_timeout——指定edd应用应等待变量成功写入设备的确认的时间长度，单位为ms。

前七个变量——eddl_id、eddl_id_1、eddl_id_2、eddl_id_3、eddl_id_4、eddl_id_5、eddl_id_6——被用作某些opcua节点标识符或id的占位符。

在下文中，描述了eddl变量到opcua信息模型中变量的映射。表示opcua变量的datalog原子公式被指定为：

根据名为“opcuapart5-informationmodelrc1.04.15specification”的行业标准规范，opcua基节点类的属性描述被指定为：

-opc_nodeid——opcua服务器的地址空间中的节点标识符；

-opc_nodeclass——标识节点的类；

-opc_browsename——指定节点的非本地化人类可读名称；

-opc_displayname——指定节点的本地化名称（用于向用户显示节点的名称）；

-opc_description——可选描述，用以解释节点含义；

-opc_writemask——指定客户端写入节点属性的可能性；以及；

-opc_userwritemask——可选地指定在考虑用户访问权限的情况下客户端写入节点属性的可能性。

以下datalog规则将创建opcuabasenodeclass（opcua基节点类），其具有取自对应的eddl变量的某些属性：

该规则通过以下项定义了opcua变量的基节点：

。

此外，opcua信息模型中的变量具有指定为“eddl_id_1”的id。浏览名称、显示名称和描述分别映射到对应的eddl变量值，即，分别为eddl_variablename、eddl_label、eddl_help。在上面示例中没有设置writemask和userwritemask。

在下文中，描述了opcuavariabletype（opcua变量类型）节点类的定义。为opc变量（参见图5中具有相同名称的框）定义opc变量类型（参见图5中具有相同名称的框），对于opc变量来说是常见做法。

变量类型的签名利用以下datalog原子公式表示：

因此，变量的默认值——参见上面公式签名中的第二项“defaultvalue（默认值）”。以下规则通过从对应的eddl变量（即eddl_default_value）映射默认值来创建opcua变量类型：

对于标识符opc_nodeid和opc_datatype，分别使用eddl_id_2和eddl_id_3。

因此，也需要创建opc_uavariabletype的opc_basenodeclass。如上所示的相同规则可以用于此目的。只需要改变标识符和类型（用uavariabletype替代uavariable）：

以下部分描述了opcuadatatype（opcua数据类型）类的创建。opcua变量的数据类型可以利用以下datalog原子公式来指定：

。

对于之前使用的示例性变量，以下规则创建opcuadatatypenode（opcua数据类型节点）：

可选地，如果需要创建opc_datatypenode（opc数据类型节点）的opc_basenodeclass（opc基节点类），则可以使用如上所示的相同规则。只需要改变标识符和类型（uadatatype）。

以下部分描述了opcuavariable（opcua变量）节点类的创建：eddl_constant_unit。eddl_variable的签名具有被称为eddl_constant_unit的项。来自eddl变量的该项将被映射到opcua特性，其是一种类型的opcua变量：

上面的数据类型“string（字符串）”在opcua信息模型中具有其代码。该代码通常用在opcua地址空间中来标示字符串。

特性的类“basenodeclass（基节点类）”由以下规则创建：

以下部分描述了opcuavariable（opcua变量）节点类的创建：eddl_style。eddl_variable的签名具有被称为eddl_style的项。来自eddl变量的该项将被映射到opcua特性，其是一种类型的opcua变量：

该特性的basenodeclass（基节点类）是利用以下规则实现的：

以下部分描述了opcuavariable（opcua变量）节点类的创建：eddl_validity。eddl_variable的签名具有称为eddl_validation的项。来自eddl变量的该项将被映射到opcua特性，其是一种类型的opcua变量：

该特性的basenodeclass（基节点类）可以利用以下规则实现：

如上面所提及的，在edd中的动作（诸如后编辑动作（posteditactions）、后读取动作（postreadactions）、后写入动作（postwriteactions）、预编辑动作（preeditactions）、预读取动作（prewriteactions）、预写入动作（prewriteactions）等）可以通过使用datalog内置谓词和复合项映射到opcuaim。因为它们可以用来处置外部调用或函数，所以它们也可以用来将edd动作映射到opcua方法，以及用来调用或执行在edd中指定的方法和命令。

以下部分描述了opcuaobject（opcua对象）节点的创建。创建的opcuaobject节点的edd文件属性（诸如制造商id、设备类型、设备修订和设备描述修订）充当引用。opcuaobject节点利用以下规则实现：

用于创建opcua对象节点的规则体显然不同于其他规则体。根据定义eddl和名为“iec61804-3:functionblocks(fb)forprocesscontrol-part3:electronicdevicedescriptionlanguage(eddl)”的规范，eddl_fileinformation中的项具有以下含义：

-eddl_id——ua对象（uaobject）节点id；

-eddl_id_1——ua对象类型（uaobjecttype）节点id；

-eddl_id_2——变量eddl_manufacturer的节点id；

-eddl_id_3——变量eddl_device_type的节点id；

-eddl_id_4——变量eddl_device_revision的节点id；

-eddl_id_5——变量eddl_dd_revision的节点id；

-eddl_manufacturer——标识制造商；

-eddl_device_type——指定设备类型的标识符，如由设备制造商定义的；

-eddl_device_revision——指定现场设备的设备修订的唯一代码，如由制造商定义的；

-eddl_dd_reversion——指定该设备的edd修订的唯一代码，如由制造商定义的。

opcua对象（opcuaobject）节点的继承基节点类利用以下规则实现：

为了可读性，项在下文中代替了完整的原子公式：

以下部分描述了opcuaobjecttype（opcua对象类型）类的创建。opcua对象节点的opcuaobjecttype类用以下规则实现：

。

以下部分描述了opcuavariable（opcua变量）节点类的创建：eddl_manufacturer。edd文件属性“manufacturerid（制造商id）”利用以下规则实现：

属性“manufacturerid（制造商id）”的继承基节点类利用以下规则实现：

剩余变量eddl_device_type、eddl_device_revision和eddl_dd_revision以基本相似的方式创建。因此，省略了关于这些变量的创建的进一步描述。

迄今为止，已经示出了节点的创建。本说明书的后续部分现在将定义和阐明如何使用引用来链接这些节点。缺少引用将导致节点之间缺少语义连接，并且因此，导致缺少整体语义结构。

在如上所述的edd文件中的示例性eddl变量中，顶级文件对象必须被引用到opcua服务器中的顶级对象文件夹，因为这是opcua服务器的根节点。因此，信息模型中的所有顶级节点应当是该节点的直接子节点。实现这一点的引用是对内置节点的“objects（对象）”引用，该内置节点具有值为85或“objectsfolder（对象文件夹）”的id。

该引用通过下式实现：

opcua引用由以下datalog原子公式表示：

opcua引用的属性具有以下含义：

-opc_sourcenodeid——引用的源节点id；

-opc_referencetype——引用类型。如opcuaim指定的。可能的值是：hastypedefinition（具有类型定义）、hascomponent（具有组件）、hasproperty（具有特性）、hassubtype（具有子类型）、organizes（组织）、hassubtype（具有子类型）等；

-opc_targetnodeid——引用的目标节点id。

附加地，然而可选地，声称objectsfolder和顶级节点经由“hascomponent”引用而相关：

然后使用hastypedefinition引用对objectsfolder进行语义链接，以便示出它包含类型定义、即内置类型foldertype（i=61）的宣告：

此外，核心对象和制造商id特性variable节点之间的引用被实例化。为剩余特性实例化类似的引用，即，devicetype（设备类型）、devicerevision（设备修订）和ddrevision（dd修订）：

附加地，然而可选地，上述变量eddl_id_2、eddl_id_3、eddl_id_4和eddl_id_5由basedatavariabletype（基数据变量类型）（“i=63”）经由引用“hassubtype”和“hastypedefinition”来引用。该引用以与前述基本相似的方式表达。因此，省略了关于创建这些引用的进一步描述。

然后，核心对象与变量（variable）节点相关，如下式所表达的：

变量节点已经经由变量类型节点定义：

附加地，然而可选地，关于eddl_id_2添加了对basedatavariabletype（“i=63”）节点的“hassubtype”引用。此外，与温度变量的浮点数据类型（“i=10”）的关联是通过如下引用实现的：

特性变量——constantunit（常量单位）、style（样式）和validity（有效性）——与示例性变量（varaible）节点连接：

附加地，然而可选地，“hassubtype”和“hastypedefinition”引用被添加到basedatavariabletype（“i=63”）节点，其是关于eddl_id_4、eddl_id_5和eddl_id_6添加的。

edd文件中的变量使用如图5中所示的基本结构被建模为独立的变量对象，其中变量基于变量对象，其具有随附的特性variable（变量）节点、variabletype（变量类型）节点和简单的datatype（数据类型）节点。因此，edd文件中的每个变量具有许多特定于该变量的各种特性。

图6示出了使用标准opcua信息模型的扩展信息模型，并通过如上所述的节点和引用的datalog规则来实现。

通过使用不同的opcua节点的集合，因此可以看出容易将edd文件及其变量的唯一信息模型映射到opcuaim中。表5中总结了edd变量到opcuaim的映射：

以下部分描述了根据实施例的网关gw中的总体系统架构和数据流，该实施例用于参考图7将现场设备描述fdd（或更一般地：工业过程装备的描述）转换成opcua信息模型（或更一般地：转换成用于自动化目的的语义丰富且基于图形的数据信息模型）。

网关gw的解析模块prs正在读取现场设备（未示出）或其他任意过程装备的现场设备描述fdd。现场设备描述fdd存储在现场设备中，并经由现场通信协议访问，例如众所周知的hart（高速通道可寻址远程换能器）协议。

解析模块prs通过所述现场通信协议解析现场设备的现场设备描述fdd中的信息实体。解析的信息实体然后被转换成数据对象表示——声明式逻辑事实——其在演绎数据库或知识库knb中被断言。解析模块prs可以可选地使用伴随断言器（未示出），用于将提取的信息包装到datalog事实中，并断言知识库knb（例如datalog数据库knb）内的声明式逻辑datalog事实。知识库knb的内容用于使用datalog引擎dle将映射规则或映射知识mkn总地应用于所述声明式逻辑事实。

这里要注意的是，知识库knb或知识引擎knb不仅是被动查询的数据库，而且还在应用规则、映射事实等意义上起作用。取决于特定实施例的实现，知识库knb与解析模块prs和datalog引擎dle合作，并且可以包括这些组件中的一个或多个。

为了使用datalog引擎dle映射声明式逻辑事实，知识库knb加载有映射知识mkn。映射知识mkn被操作来演绎地映射由在知识库knb内的现场设备描述fdd转换的数据对象，所述数据对象具有允许它们稍后被提取为opcua对象的结构。这些映射规则在任何映射发生之前被断言，使得它们能够贯穿于映射过程而应用于输入信息。

已经示出了可以如何针对eddl和opcuaim操作映射知识mkn。应用类似的过程，有可能为另一个现场设备描述模型或该模型的扩展创建映射知识mkn，例如，如果需要利用来自另一个模型（例如，namur开放架构或noa模型）的语义在opcuaim上表示edd数据的话。因此，该方法的适用性不限于其他标准信息模型，例如iodd或io设备描述，fdt/dtm14或现场设备工具/设备类型管理器，或noa（namur开放架构）。

与大多数映射系统不同，知识库knb的功能——网关gw的一个核心——已经从系统本身中抽象出来。通过这样做，在实现应用特定映射时有了更大程度的灵活性和可移植性。通过从源代码中移除所有的映射逻辑，系统的灵活性仅受限于opcuaim的建模能力。

在将映射的edd信息存储在知识库knb中的情况下，然后以使该信息可以被提取并最终经由网关内部的opcua服务器isf披露的这样一种方式来处理和查询该信息。这些任务由datalog引擎dle和查询引擎qye完成。datalog形式的递归查询算法是众所周知的。

根据优选实施例，由于datalog算法的效率和它们甚至在资源受限设备（例如非昂贵的iot设备（物联网）和iot网关）上的适用性，datalog已经被选取为实现所提出的映射方法的形式化。

图8示出了用于从datalog引擎查询和提取opcua信息以便递归地实例化从源节点指向的所有引用的流程图。

通过第一步骤802，使用给定的nodeid（节点id）针对起始基节点查询数据库。

在后续判定步骤804中，进行具有给定nodeid的节点是否是基节点的判定。如果给定节点不是基节点——由判定步骤804的分支n（“否”）表示——则实行后续步骤806。后续步骤806返回具有nodeid的节点。

在后续判定步骤804中，进行具有给定nodeid的基节点是否存在的判定。如果该节点不存在——由判定步骤804的分支n（“否”）表示——则不再存在任何东西要映射。该过程由步骤806完成。如果具有当前nodeid的基节点存在——由从判定步骤804垂直向下指向的分支y（“是”）表示——则实行后续步骤808。在后续步骤808中，针对基节点的节点属性和节点类型查询数据库。

在后续步骤810中，节点信息被处理，并且当前节点被标记为已知。在后续步骤812中，针对具有与当前nodeid匹配的（源）节点id的引用查询数据库。在后续步骤814中，存储所查询的参考信息。在后续步骤816中，对于每个存储的参考信息，一个或多个nodeid被作为目标和/或提取。

在后续判定步骤818中，进行目标节点是否已知的判定。一旦已知所有节点——由从判定步骤818垂直向上指向的分支y（“是”）表示——该过程就由步骤822完成。

如果被引用的目标节点是未知的——由判定步骤818的分支n（“否”）表示——则流程分支到步骤808，该步骤将被递归调用——参见参考标号820——以nodeid为目标id。

源节点将是opcua服务器的对象根节点。仅需要针对具有与根节点id匹配的源节点id的引用查询数据库。数据库将返回与根节点相关联的所有引用的列表，从而给出所有引用的目标节点id的列表。该返回的列表可以进而被递归地处理，从而允许对opcuaim的层级信息模型进行遍历和处理。

最后，从查询引擎中提取的opcua信息被有利地变换成opcua的xml模式内的xml节点。opcua服务器配置生成器完成这个任务，并且然后将信息下游传递给opcua服务器。通过该方式，每个标准的opcua客户端可以访问数据，所述数据源于edd现场设备描述。

总之，实施例示出了以下益处：

-根据实施例的网关的映射系统能够使用存储的映射知识来解释输入信息，特别是edd，演绎地创建从输入信息模型到opcua信息模型的信息映射，因此消除了对繁琐的一对一硬编码映射方法的需要，并且允许对映射知识的外部存储和查询；

-映射知识是可扩展的，用于使能实现新的应用类。除了用于监控现场设备之外，映射知识还能够支持现场资产的管理；

-映射适于在边缘或受限设备上实现。典型地，这些是iot（物联网）网关或受限且廉价的设备。虽然映射也可以利用其他语义形式化来完成，但是datalog可以容易地在受限设备上实现。同时，datalog足够有表达性以用于将edd映射到opcua信息模型。datalog由于它的算法效率和在受限设备上实现算法的可能性而被选取为实现知识映射系统的优选形式化。在过去的30年里，datalog的语义被良好理解，并且已经开发了高效的算法；

-根据实施例的映射特别适用于边缘或受限设备，然而，也适于在云环境中实现；

-实施例允许发现映射知识或其一部分。例如，用户或应用可以经由表达性语义查询来查询映射知识的存储；

-映射知识与其他模型的可扩展性是另外的优势。已经示出了如何为eddl和opcuaim创建映射知识。应用类似的过程，为另一个现场设备描述模型或该模型的扩展创建映射知识是可能的；

-通过系统的可移植性和模块化实现了另外的优势。映射知识是可透明地获得的，而不是硬编码的。因此，例如，它可以被下载、交换、更新等；

-实施例有利地允许对照映射知识来验证现场设备数据。例如，可以有利地检查现场设备数据是否符合规范；

-实施例有利地允许直接访问信息。对于例如与现场级资产的监控、管理和优化相关的许多增值应用，通过控制器访问现场信息不合期望；

-映射系统降低了映射复杂信息模型的复杂性，其中大部分映射知识可以从先前的映射继承，或者复杂结构可以通过自下而上的方式演绎地应用映射规则来映射。

要理解，所附权利要求中记载的元素和特征可以以不同的方式组合，以产生同样落入本发明范围内的新的权利要求。因此，尽管下面所附的从属权利要求仅依赖于单个独立或从属权利要求，但是要理解，这些从属权利要求可以可替代地依赖于任何前面或后面的权利要求——无论是独立的还是从属的，并且这样的新的组合要被理解为形成本说明书的一部分。

虽然上面已经参考各种实施例描述了本发明，但是应当理解，可以对所描述的实施例进行许多改变和修改。因此，前述描述旨在被认为是说明性的，而不是限制性的，并且要理解，实施例的所有等同物和/或组合旨在被包括在该描述中。