US20200210869A1

US20200210869A1 - Gateway and method for transforming a description of an industrial process equipment into a data information model

Info

Publication number: US20200210869A1
Application number: US16/235,557
Authority: US
Inventors: Darko Anicic; Alexander Hoffman
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2018-12-28
Filing date: 2018-12-28
Publication date: 2020-07-02
Also published as: WO2020135968A1; CN113196192A; EP3853680A1; US20220058502A1

Abstract

Modern industrial processes demand flexibility in terms of how data flows are structured in an automation pyramid. Instead of only upward and downward flows, the data should be accessible directly at each level of the pyramid. A gateway for facilitating an integration of process equipment within an industrial environment supporting an open industry standard is provided. Field devices having characteristics, capabilities and/or requirements that are expressed by a description language for industrial process equipment such as EDDL are integrated into a contemporary communication environment enabling a direct data access. The communication environment is operated based on a semantically enriched and graph-based data information model such as provided by OPC UA.

Description

TECHNICAL FIELD

The present embodiments relate to a gateway for transforming a description of an industrial process equipment into a data information model. More specifically, the present embodiments relate to a transformation of a description of an industrial process equipment into a semantically enriched and graph-based data information model for automation purposes.

BACKGROUND

Industrial automation system components of the past have traditionally been interconnected by specialized networks using a variety of different protocols for access and data exchange.
The development of present and future automation systems and field devices has put considerable focus on common industry standards aiming for a standardized access to process data in order to reduce the effort for device-engineering, configuration, management, operation, and versioning, as well as enable applications that are based on integration and processing of the process data.
An Open Platform Communications Unified Architecture, or OPC UA, provides an architecture for the integration of field devices. OPC UA is an industrial standard protocol of the OPC Foundation for manufacturer-independent communication with the purpose of interchanging industrial data, in particular in process automation.
Many field devices of today, however, are described by alternative approaches such as a description language entitled Electronic Device Description Language, or EDDL. Accordingly, there is a need in the art to facilitate an integration of process equipment described by a description language according to a different description scheme data within an industrial environment of process equipment described by open industry standards such as OPC UA.

SUMMARY AND DESCRIPTION

Embodiments herein generally involve a gateway for facilitating an integration of process equipment within an industrial environment supporting an open industry standard such as OPC UA.
In one embodiment, a gateway for transforming a description of an industrial process equipment into a semantically enriched and graph-based data information model for automation purposes is disclosed. The gateway includes a parsing module for parsing information entities in the description of the industrial process equipment by a field communication protocol and for transforming the parsed information entities into declarative logic facts and asserting the declarative logic facts within a deductive database. The gateway further includes a knowledge engine using a mapping knowledge base for applying mapping rules to said declarative logic facts, whereby said declarative logic facts are deductively mapped onto the graph-based data information model. Eventually the gateway includes an interface module for accessing the graph-based data object model.
Although there many alternative formalisms for declarative logic facts, e.g. a formalism based on W3C OWL, the usage of Datalog is regarded as superior for a deployment on resource constrained devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects as well as further advantages of the present embodiments will become more apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawing in which:

FIG. 1 shows a hierarchically layered architecture of manufacturing control in an industrial automation domain;

FIG. 2 shows a block diagram of functional units for exchanging data within an automation control system;

FIG. 3 shows a block diagram of basic functional units of a gateway according to an embodiment;

FIG. 4 shows a graphical representation of a declarative logic rule applied to declarative logic facts;

FIG. 5 shows a model structure for modeling a generic variable in a graph-based data information model;

FIG. 6 shows a node structure for modeling a description of an industrial process equipment in a graph-based data information model;

FIG. 7 shows a block diagram of a gateway according to an embodiment amongst other functional units for exchanging data within an automation control system; and

FIG. 8 shows a diagram illustrating an operational flowchart for transforming a description of an industrial process equipment into a semantically enriched and graph-based data information model according to an embodiment.

DETAILED DESCRIPTION

Industrial processes are complex as they involve technologies of different fields, ranging from mechanics, electronics, communication, and computer science. Further on, different systems play different roles in industrial processes, ranging from field devices, control devices, manufacturing execution systems, and enterprise management systems.
Until today industrial processes are categorized by a so-called Automation Pyramid. A right part of FIG. 1 shows such a hierarchically layered Automation Pyramid, wherein: a first level or field level FLD comprises physical field devices such as actuators and sensors; a second control level CRT includes control devices such as Programmable Logic Controllers or PLCs; a third manufacturing level MAN includes manufacturing execution systems; and a top enterprise level ENT of the pyramid comprises an enterprise management system.
A data flow is structured by these well-defined layers FLD, CRT, MAN, ENT such that data flows upwards from individual field devices to the enterprise level via control supervision and manufacturing execution systems. In the same vein, data flows from enterprise systems flows downwards to field devices.
Modern industrial processes, however, demand flexibility in terms of how data flows are structured in the automation pyramid. Instead of only upward and downward flows, the data should be accessible directly at each level of the pyramid. This direct access by each of the layers of the pyramid is symbolized by an oblique layer DAC on the left side of FIG. 1 which is configured for a cross-layered data access in all levels FLD, CRT, MAN, ENT of the automation pyramid.
A protocol of choice for enabling a cross-layered data access is OPC UA. OPC UA (Open Platform Communications Unified Architecture) is an industrial standard protocol of the OPC Foundation for manufacturer-independent communication with the purpose of interchanging industrial data, in particular in process automation.
OPC UA offers direct data access, regardless of the level of the automation pyramid. OPC UA further provides an information model and transport layer communications, where clients at any level of the pyramid can directly access data served by one or more OPC UA servers, hosted at any level. This includes OPC UA servers hosted at the field device level. OPC UA imposes a prerequisite in that information of heterogeneous automation devices and systems need to be represented with the OPC UA Information Model—or OPC UA IM—which is a semantically enriched and graph-based data information model for automation purposes.
Current field devices in an environment of a current automation systems, however, are predominantly operated by a differing description language for industrial process equipment. One prevalent description language in the industrial domain is EDDL or Electronic Device Description Language. Until today, EDDL is a widely used standard in the process industry. As EDDL is nothing more but a structured listing of parameters, characteristics, capabilities and/or requirements of a device, direct data access of EDDL described devices interfacing servers operated on the basis of a semantically enriched and graph-based data information model for automation purposes is not possible at present.
It is therefore an object of the proposed embodiments to support an integration of field devices—or process equipment in general—whose characteristics, capabilities and/or requirements are expressed by a description language for industrial process equipment such as EDDL, into a contemporary communication environment enabling a direct data access, wherein the communication environment is operated on the basis of a semantically enriched and graph-based data information model such as provided by OPC UA.
More specifically, the problem is how to make information from »brownfield« devices available in the address space of an OPC UA server. The term brownfield refers to state-of-the-art-devices operated by a legacy description language which are to be deployed in a more contemporary environment. EDDL is not the only example of such legacy description languages. There are several other device description languages implemented on brownfield devices which need to be integrated into a communication environment for facilitating a direct data access. Legacy description languages include languages or protocols such as FDT/DTM or Field Device Tool/Device Type Manager, GSD or General Station Description, IO Device Description etc. It is an object of the proposed embodiments to support an integration of field devices operated by such legacy description languages of any kind.
In existing automation systems information from field devices is typically accessible via a controller for controlling these field devices. This control is localized on the field level FLD or at the control level CRT according to FIG. 1. The control is typically performed during an engineering process wherein automation system parameters of field devices are set and exposed over a controller.
Such Controllers could then assist to export this information to an OPC UA server located on higher levels of the automation pyramid. In this way, information from field devices would be indirectly accessible by a server and could be used further above at different levels of the automation pyramid.
For many applications, however, it is desirable not to access field information by an intermediate controller. These applications include added-value applications, e.g. applications related to monitoring, management, and optimization of field level assets. The reason for favoring a direct access of field information over an indirect access by an intermediate controller is due to a design principle of dedicating a controller solely for enduring system stability. For other applications it is desirable to access the field device information aside form the core control, possibly in a cheap and flexible way.
The present embodiments generally propose a gateway for transforming a description of an industrial process equipment into a semantically enriched and graph-based data information model for automation purposes with the goal of enabling industrial process equipment such as brown-field field devices to be used in modern industrial applications.
The gateway includes a knowledge-based mapping system and allows for a connection to one or more process equipment—particularly field devices—in order to collect information from each field device and exchanging this information with a server or an application on the basis of a semantically enriched and graph-based data information model for automation purposes, such as OPC UA. For the »upward« exchange of information—e.g. exchange with a server or an application based on a semantically enriched and graph-based data information model—the gateway includes an interface module for accessing the graph-based data information model. This interface module is may be embodied by one or more processors (e.g., an OPC UA server operated by and/or on the gateway, such as a gateway-internal OPC UA server).
FIG. 2 shows a proposed gateway GW connected to one field device FD—or, alternatively to one or more industrial process equipment FD of any kind—and communicating information collected from the description of the industrial process equipment FD to one or more applications, such as a cloud-based application CA, a portable application PA and/or an application MO for asset-monitoring, management, and/or optimization. Said applications CA, PA, MO can access the—not shown—description of the industrial process equipment FD over a standard OPC UA server provided by the—not shown—interface module of the gateway GW.
Referring now to FIG. 3, the knowledge-based mapping MAP of the gateway is detailed as an intermediary model between an input delivering a conventional or legacy field device description FDD—e.g. expressed by the description language EDDL—mapping information from said description to a graph-based data information model and allocating the data information model by a gateway-internal server SRV. For the process of knowledge-based mapping MAP a mapping knowledge base MKN is used, the details of which will be described further down below.
The gateway acts in a plug-and-play fashion, i.e., it connects to the field device FD, reads its field device description FDD, and maps field device information (e.g., device parameters) to an OPC UA address space. Device parameters and corresponding values can then be accessed by the gateway-internal server SRV using any—not shown—standard OPC UA client or any—not shown—standard OPC UA server connected to the gateway-internal server SRV.
A mapping of information models according to the present embodiments is performed using one or more declarative logic rules or facts for applying a deductive inference mechanism. In the following, a deductive inference method is described using Datalog as one exemplary programming language for expressing said declarative logic rules.
A Datalog language section—also referred to as a Datalog program—consists of declarative rules. A rule has a rule body and a rule head, which is expressed as:

- head <=body

If a Datalog system can proof that body is TRUE—as a Boolean TRUE—then it can infer that the head is TRUE as well. This is a mechanism how a Datalog system can derive new knowledge from existing knowledge.
Further on, Datalog programs and Datalog rules are built up from atomic formulas of a type:

- p(t1, t2, . . . , tn)
  wherein p is a predicate symbol and t1, t2, . . . , tn denote terms. Some predicates have predefined meaning in a Datalog system. They denote a built-in operation, and thus are called built-in predicates. In anticipation of embodiments to be described further down below, built-in predicates and compound terms can be used to handle external calls or functions, which can be used to map EDDL (Electronic Device Description Language) methods and commands into OPC UA methods. Further on, built-in predicates and compound terms can be used to call or execute methods and commands specified in an EDD or Electronic Device Description.

Returning back to the description of Datalog, an atomic formula—or short: an atom—is a formula that cannot be divided into strict sub-formulas. Literals are positive or negative atoms. Terms are constants, variables or compound terms. Variables are denoted with strings consisting of capital letters or beginning with a capital letter—e.g. VAR or Var—and constants are quoted, e.g. “constant_unit”. Compound terms implement functions.
A function is an expression of a type:

- f(t1, t2, . . . , tn)
  wherein f is a function symbol of arity n, and t1, t2, . . . , tn are terms.

A fact is a ground atomic formula, e.g. expressed by:

- p(“c1”, “c2”, . . . , “cn”)
  wherein “c1”, “c2”, . . . , “cn” are constants.

FIG. 4 shows a graphical representation of a declarative logic rule applied to declarative logic facts with the aim of mapping data from one information model to another one.
It can be seen that terms in the Body literal—right side of FIG. 4—are related to terms in the head atom—left side of FIG. 4. In this case, upon input of a single fact matching the structure of the body literal, a Datalog fact will be deduced using the inputted fact and the existing Datalog rule.
Datalog rules can be constructed in such a way that they recursively work with each other to populate complete mapping rules using many individuals, and smaller Datalog rules that define information relationships. As such, in the example, a new Datalog fact with the format of the rule head will be asserted into the database if there are literals matching the body literals' constant terms with the terms also being satisfied as wildcards.
In the following a Representation of OPC UA Information in Datalog is described. Compound names with one or more medial capitals—e.g. a compound name »TypeDefinitionNodes«—are used to refer to authoritative names used in the specification »OPC Unified Architecture« of the OPC Foundation. These authoritative names are assumed to be known and for a person skilled in the art. Hereinafter, these authoritative names are, therefore, introduced without explanation.
The OPC UA specification comprises nine OPC UA node classes, including a Base Node class. Each of these node classes has standardized attributes that are stored directly within the node. Each of these node classes can be stored in Datalog using the predicate to specify the node class.
For the exemplary OPC UA class » ReferenceType« three attributes are specified by the OPC UA standard, namely:


Attribute Name	Use	Type
IsAbstract	Mandatory	Boolean
Symmetric	Optional	Boolean
InverseName	Optional	LocalizedText

These three attributes can be stored as an atomic formula by using the three terms in a semantic order along with the unique node ID that explicitly references the node to be stored. The respective representation of the OPC UA class » ReferenceType« as an atomic formula in Datalog is then:

- opc_ReferenceType(NodeID, IsAbstract, Symmetric, InverseName).
  An example of storing a ReferenceType node by a Datalog formalism whose OPC UA namespace ID is 1, is an abstract type, not symmetric and does not have an inverse name would be as follows:
  opc_ReferenceType(1, true, false, NULL).

The inventors have verified a feasible utilization of Datalog in defining relational rules for mapping the facts' term semantics into different facts' semantics, thereby mapping one information model to another, all within a same Datalog database.
While one could create very large collections of top-level mapping rules which would handle entire information models, such creation would result in a large number of mapping rules, thereby neglecting usage of the deductive power of Datalog. This deductive power of Datalog, however, allows for fewer mapping rules, as smaller components of an information model can be mapped using rules that are then utilized by higher level rules in a deductive manner. Meaning mapping rules are advantageously structured in a hierarchical fashion so as to utilize a re-usability of rules. This construction of mapping rules is similar to the art of programming functions used for a modularization of program code, wherein a function is called by a multitude of higher-level function calls rather than being repeatedly coded within the higher level. On the other hand, unlike programming functions being rather procedural statements, Datalog rules are rather declarative statements, which means they can be interpreted regardless of a position in a program.
In the following a mapping of EDD Information to an OPC UA information model—or OPC UA IM—is described. An exemplary EDDL variable in an EDD file is considered as follows:


	MANUFACTURER 66,
	DEVICE_TYPE 0x070E,
	DEVICE_REVISION 1,
	DD_REVISION 1
	VARIABLE DEMO_Temperature_Sensor
	{
	LABEL DEMO_Temperature_Sensor
	HELP measures_actual_temperature;
	CLASS CONTAINED;
	TYPE FLOAT;
	{
	DEFAULT_VALUE 0.0;
	}
	HANDLING READ & WRITE;
	}

In order to accomplish a mapping of the above shown EDD information into an OPC UA information model, a mapping of typical EDD file attributes is done in a first step, which is followed by a step of mapping the variable itself.
As each EDD file has four top level attributes—manufacturer ID, device type, device revision and the device description revision, see first four lines in the EDDL code shown above—there are four OPC UA property nodes to be attached to the top-level object node representing the EDD file.
Each property node is constructed from a Variable node that is referenced from its parent object by a reference entitled »HasProperty«. Variables are defined using the Variable node class. Two types of variables in OPC UA IM are defined: properties and data variables. The Variable node is always part of at least one other node.
FIG. 5 shows the resulting model structure modeling the generic variable and top-level attributes of a general EDD file in the graph-based data information model of OPC UA.
In the following a mapping of an EDDL variable in the structure of an EDDL variable to an address space of the OPC UA information model is described.
A variable typically describes parameters contained in a field device or in an EDD application. A Datalog atomic formula representing an EDDL variable is expressed by:


eddl_Variable(
EDDL_ID, EDDL_ID_1, EDDL_ID_2, EDDL_ID_3, EDDL_ID_4,
EDDL_ID_5, EDDL_ID_6,
EDDL_VariableName, EDDL_CLASS, EDDL_LABEL, EDDL_TYPE,
EDDL_CONSTANT_UNIT,
EDDL_DEFAULT_VALUE, EDDL_HANDLING, 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, EDDL_REFRESH_ACTIONS,
EDDL_RESPONSE_CODES, EDDL_STYLE,
EDDL_VALIDITY, EDDL_WRITE_TIMEOUT).

According to an Industry Standard Specification entitled »IEC 62769-109-1:2015—Field Devices Integration (FDI)—Part 109-1: Profiles—HART and WirelessHART« the description of attributes of an EDDL variable is specified as:

- EDDL_ID—UAObject node ID;
- EDDL_ID_1—variable node ID;
- EDDL_ID_2—variableType node ID;
- EDDL_ID_3—OPC_DataType node ID;
- EDDL_ID_4—node ID for variable EDDL_CONSTANT_UNIT;
- EDDL_ID_5—node ID for variable EDDL_STYLE;
- EDDL_ID_6—node ID for variable EDDL_VALIDITY;
- EDDL_VariableName—specifies identifier of a variable;
- EDDL_CLASS—specifies how the variable is used by the device and the EDD application for organization purposes and display;
- EDDL_LABEL—specifies the displayed designation of an element;
- EDDL_TYPE—specifies the data type of a variable;
- EDDL_CONSTANT_UNIT—is used, if a variable has a units code which never changes;
- EDDL_DEFAULT_VALUE—specifies the default setting for the variable;
- EDDL_HANDLING—specifies the operations that can be performed on an element;
- EDDL_HELP—specifies text, which provides a description of the construct;
- EDDL_INITIAL_VALUE—specifies the value of a variable that is displayed when a device is instantiated for the first time;
- EDDL_POST_EDIT_ACTIONS—specifies methods that shall be executed after the variable has been written to the device;
- EDDL_POST_READ_ACTIONS—specifies methods that shall be executed after the variable was read from the device;
- EDDL_POST_WRITE_ACTIONS—specifies methods that shall be executed after the variable has been written to the device;
- EDDL_PRE_EDIT_ACTIONS—specifies methods that shall be executed immediately when the variable is going to be edited;
- EDDL_PRE_READ_ACTIONS—specifies methods that shall be executed before the variable is read;
- EDDL_PRE_WRITE_ACTIONS—specifies methods that shall be executed before the variable is written to the device;
- EDDL_READ_TIMEOUT—specifies the length of time, in ms, the EDD application shall wait for the returned variable;
- EDDL_REFRESH_ACTIONS—specifies EDD methods that shall be executed whenever the variable is displayed or refreshed;
- EDDL_RESPONSE_CODES—specify values a device may return as error information;
- EDDL_STYLE—specifies the way a variable is displayed;
- EDDL_VALIDITY—specifies whether an element is valid or invalid; and;
- EDDL_WRITE_TIMEOUT—specifies the length of time, in ms, an EDD application shall wait for confirmation that the variable is successfully written to the device.

The leading seven variables—EDDL_ID, EDDL_ID_1, EDDL_ID_2, EDDL_ID_3, EDDL_ID_4, EDDL_ID_5, EDDL_ID_6—are used as placeholders for certain OPC UA node identifiers or IDs.
In the following a mapping of an EDDL variable to a variable in the OPC UA information model is described. A Datalog atomic formula representing an OPC UA variable is specified as:


opc_UAVariable(
OPC_NodeId, OPC_Value, OPC_DataType, OPC_ValueRank,
OPC_ArrayDimensions, OPC_IsAbstract, OPC_AccessLevel,
OPC_UserAccessLevel, OPC_MinSamplingInterval, OPC_Historizing)

According to an Industry Standard Specification entitled »OPC UA Part 5—Information Model RC 1.04.15 Specification« the description of attributes of the OPC UA Base Node class is specified as:

- OPC_NodeId—a node identifier in the address space of an OPC UA server;
- OPC_NodeClass—identifies the class of a node;
- OPC_BrowseName—specifies a non-localized human-readable name of a node;
- OPC_DisplayName—specifies the localized name of the node (used to display the name of the node to the user);
- OPC_Description—optional description to explain the meaning of the node;
- OPC_WriteMask—specifies possibility of a client to write attributes of the node; and;
- OPC_UserWriteMask—optionally specifies possibility of a client to write attributes of the node taking user access rights into account.

The following Datalog rule will create an OPC UA Base Node Class with certain attributes taken from the corresponding EDDL variable:


opc_BaseNodeClass(
EDDL_ID_1, “UAVariable”, EDDL_VariableName, EDDL_LABEL,
EDDL_HELP, “Not_Used”, “Not_Used”)
<= eddl_Variable.

This rule defines a base node for an OPC UA variable by the term:

- <=eddl_Variable

Further on, the variable in the OPC UA information model has an ID specified as »EDDL_ID_1«. Browse name, display name and the description is respectively mapped to corresponding EDDL variable values, i.e. EDDL_VariableName, EDDL_LABEL, EDDL_HELP, respectively. WriteMask and UserWriteMask are not set in the example above.
In the following a definition of an OPC UA Variable Type Node Class is described. Defining an OPC Variable Type—see box with the same name in FIG. 5—for an OPC Variable—see box with the same name in FIG. 5—for an OPC variable is a common practice.
The signature of a variable type is represented with the following Datalog atomic formula:

- opc_UAVariableType(OPC_NodeId, DefaultValue, DataType, ValueRank, ArrayDimensions, IsAbstract).

Consequently, a default value of the variable—see the second term »DefaultValue« in the signature of the formula above is specified. The following rule creates an OPC UA variable type by mapping the default value from a corresponding EDDL variable, namely EDDL_DEFAULT_VALUE:


opc_UAVariableType(
EDDL_ID_2, EDDL_DEFAULT_VALUE, EDDL_ID_3, “−1”,
“Not_Used”, “Not_Used”)
<= eddl_Variable.

For identifiers OPC_NodeId and OPC_DataType, EDDL_ID_2 and EDDL_ID_3 are used respectively.
Consequently, opc_BaseNodeClass for opc_UAVariableType needs to be created too. The same rule as shown above can be used for this purpose. Only the identifier and the type (UAVariableType instead of UAVariable) need to change:


	opc_BaseNodeClass(
	“EDDL_ID_2”, “UAVariableType”, EDDL_VariableName,
	EDDL_LABEL, EDDL_HELP, “Not_Used”,“Not_Used”)
	<= eddl_Variable.

The following section describes a creation of an OPC UA Data Type Class. Data type of an OPC UA variable can be specified with a following Datalog atomic formula:

- opc_DataTypeNode(OPC_NodeId, OPC IsAbstract).

For the exemplary variable used before the following rule creates an OPC UA DataTypeNode:


	opc_DataTypeNode(EDDL_ID_3, “Not_Used”)
	<= eddl_Variable.

Optionally, if an opc_BaseNodeClass for opc_DataTypeNode needs to be created, the same rule as shown above can be used. Only the identifier and the type (UADataType) need to change.
The following section describes a creation of an OPC UA Variable Node Class: EDDL_CONSTANT_UNIT. The signature of eddl_Variable has a term called EDDL_CONSTANT_UNIT. This term from an EDDL variable is to be mapped to an OPC UA Property, which is a type of an OPC UA Variable:


opc_ UAVariable(
EDDL_ID_4, EDDL_CONSTANT_UNIT, “String”, “−1”, “Not_Used”,
“Not_Used”, “Not_Used”, “Not_Used”, “Not_Used”)
<= eddl_Variable.

The data type »String« above has its code in the OPC UA information model. Often the code is used in an OPC UA address space to denote a string.
The Class »BaseNodeClass« of the property is created by the following rule:


opc_ BaseNodeClass(
“EDDL_ID_4”, “UAVariable”, “CONSTANT_UNIT”,
“CONSTANT_UNIT”, “Not_Used”, “Not_Used”, “Not_Used”)
<= eddl_Variable.

The following section describes a creation of an OPC UA Variable Node Class: EDDL_STYLE. The signature of eddl_Variable has a term called EDDL_STYLE. This term from an EDDL variable is to be mapped to an OPC UA Property, which is a type of an OPC UA Variable:


opc_ UAVariable(
EDDL_ID_5, “EDDL_STYLE”, “String”, “−1”, “Not_Used”,
“Not_Used”, “Not_Used”, “Not_Used”, “Not_Used”)
<= eddl_Variable.

The BaseNodeClass of the property is realized with the following rule:


opc_ BaseNodeClass(
“EDDL_ID_5”, “UAVariable”, “STYLE”, “STYLE”, “Not_Used”,
“Not_Used”, “Not_Used”)
<= eddl_Variable.

The following section describes a creation of an OPC UA Variable Node Class: EDDL_VALIDITY. The signature of eddl_Variable has a term called EDDL_VALIDITY. This term from an EDDL variable is to be mapped to an OPC UA Property, which is a type of an OPC UA Variable:


opc_ UAVariable(
EDDL_ID_6, “EDDL_VALIDITY”, “String”, “−1”, “Not_Used”,
“Not_Used”, “Not_Used”, “Not_Used”, “Not_Used”)
<= eddl_Variable.

The BaseNodeClass of the property can be realized with the following rule.


opc_BaseNodeClass(
“EDDL_ID_6”, “UAVariable”, “VALIDITY”, “VALIDITY”,
“Not_Used”,
“Not_Used”, “Not_Used”)
<= eddl_Variable.

As mentioned above, actions in EDD, such as POST EDIT ACTIONS, POST READ ACTIONS, POST WRITE ACTIONS, PRE EDIT ACTIONS, PRE READ ACTIONS, PRE WRITE ACTIONS etc. can be mapped to OPC UA IM by using Datalog built-in predicates and compound terms. Since they can be used to handle external calls or functions, they can also be used to map EDD actions into OPC UA methods, as well as to call or execute methods and commands specified in an EDD.
The following section describes a creation of an OPC UA Object node. The EDD file attributes of the created OPC UA Object node, such as manufacturer ID, device type, device revision and the device description revision, serve as reference. The OPC UA Object node is realized with the following rule:


opc_UAObject(EDDL_ID)
<=
eddl_FileInformation(
EDDL_ID, EDDL_ID_1, EDDL_ID_2, EDDL_ID_3, EDDL_ID_4,
EDDL_ID_5,
EDDL_MANUFACTURER, EDDL_DEVICE_TYPE,
EDDL_DEVICE_REVISION, EDDL_DD_REVISION).

The rule body for creating the OPC UA Object node is apparently differing from other rule bodies. Terms in eddl_FileInformation have the following meaning according to a specification defining EDDL and entitled »IEC 61804-3: Function blocks (FB) for process control—Part 3: Electronic Device Description Language (EDDL)«

- EDDL_ID—UAObject node ID;
- EDDL_ID_1—UAObjectType node ID;
- EDDL_ID_2—node ID for variable EDDL_MANUFACTURER;
- EDDL_ID_3—node ID for variable EDDL_DEVICE_TYPE;
- EDDL_ID_4—node ID for variable EDDL_DEVICE_REVISION;
- EDDL_ID_5—node ID for variable EDDL_DD_REVISION;
- EDDL_MANUFACTURER—identifies the manufacturer;
- EDDL_DEVICE_TYPE—specifies an identifier for the device type, as defined by the manufacturer of the device;
- EDDL_DEVICE_REVISION—specifies a unique code for the device revision of the field device, as defined by the manufacturer;
- EDDL_DD_REVISION—specifies a unique code for the EDD revision of this device, as defined by the manufacturer.

An inherited base node class for the OPC UA Object node is realized with the rule:


opc_ BaseNodeClass(
“EDDL_ID”, “UAObject”, “EDD DOCUMENT”, “EDD DOCUMENT”,
“Not_Used”, “Not_Used”, “Not_Used”)
<= eddl_FileInformation.

For the sake of readability, the term

- eddl_FileInformation
  hereinafter replaces the complete atomic formula:
- eddl_FileInformation(EDDL_ID, EDDL_ID_1, EDDL_ID_2, EDDL_ID_3, EDDL_ID_4, EDDL_ID_5, EDDL_MANUFACTURER, EDDL_DEVICE_TYPE, EDDL_DEVICE_REVISION, EDDL_DD_REVISION).

The following section describes a creation of an OPC UA ObjectType class. An OPC UA ObjectType class for the OPC UA Object node is realized with the rule:

- opc_UAObjectType(EDDL_ID_1)<=eddl_FileInformation.

The following section describes a creation of an OPC UA Variable Node Class: EDDL_MANUFACTURER. The EDD file attribute »manufacturer ID« is realized with the rule:


opc_ UAVariable(
EDDL_ID_2, EDDL_MANUFACTURER, “String”, “−1”, “Not_Used”,
“Not_Used”, “Not_Used”, “Not_Used”, “Not_Used”)
<= eddl_FileInformation.

An inherited base node class for the attribute »manufacturer ID« is realized with the rule:


opc_BaseNodeClass(
“EDDL_ID_2”, “UAVariable”, “MANUFACTURER”,
“MANUFACTURER”, “Not_Used”, “Not_Used”, “Not_Used”)
<= eddl_FileInformation.

Remaining variables for EDDL_DEVICE_TYPE, EDDL_DEVICE_REVISION and EDDL_DD_REVISION are created in a substantially similar manner. A further description regarding the creation of these variables is, therefore, omitted.
Hitherto the creation of nodes has been shown. Subsequent parts of this description will now define and elucidate how to link these nodes using references. An absence of references would result in an absence of semantic connections between nodes, and, therefore, result in an absence of an overall semantic structure.
In the exemplary EDDL variable in an EDD file as stated above, the top-level file Object must be referenced to the top-level Objects folder in the OPC UA server as this is the root node for an OPC UA server. As such, all top-level nodes within an information model should be direct children of this node. The reference which accomplishes this is an »Organizes« reference to an in-built node having an ID with a value of 85 or »ObjectsFolder«.
This reference is realized by:


	opc_Reference(“i=85”, “Organizes”, EDDL_ID) <=
	eddl_FileInformation.

The OPC UA Reference is represented by the following Datalog atomic formula:


	opc_Reference(opc_SourceNodeId, opc_ReferenceType,
	opc_TargetNodeId).

The attributes of the OPC UA Reference have the following meaning:

- opc_SourceNodeId—a source Node ID of a reference;
- opc_ReferenceType—a reference type. As specified by OPC UA IM. Possible values are: HasTypeDefinition, HasComponent, HasProperty, HasSubtype, Organizes, HasSubtype etc.;
- opc_TargetNodeId—a target Node ID of a reference.

Additionally, however optionally, it is common to state that the ObjectsFolder and the top-level node are related via the »HasComponent« reference:


	opc_Reference(“i=85”, “HasComponent”, EDDL_ID)
	<= eddl_FileInformation

The ObjectsFolder is then semantically linked using a HasTypeDenition reference in order to show announce that it contains the type definition, i.e., the in-built type FolderType (i=61):


	opc_Reference(“i=85”, “HasTypeDefinition”, “i=61”)
	<= eddl_FileInformation.

Further on, references between the core Object and the MANUFACTURE ID property Variable node are instantiated. Similar references are instantiated for remaining properties, i.e., DEVICE TYPE, DEVICE REVISION, and DD REVISION:


	opc_Reference(EDDL_ID, “HasProperty”, “EDDL_ID_2”)
	<= eddl_FileInformation.
	opc_Reference(EDDL_ID, “HasProperty”, “EDDL_ID_3”)
	<= eddl_FileInformation.
	opc_Reference(EDDL_ID, “HasProperty”, “EDDL_ID_4”)
	<= eddl_FileInformation.
	opc_Reference(EDDL_ID, “HasProperty”, “EDDL_ID_5”)
	<= eddl_FileInformation.

Additionally, however optionally, the above described variables EDDL_ID_2, EDDL_ID_3, EDDL_ID_4 and EDDL_ID_5 are referenced by BaseDataVariableType (“i=63”) via “HasSubtype” and “HasTypeDefinition” references. This references are expressed in a substantially similar manner as described before. A further description regarding the creation of these references is, therefore, omitted.
The core object is then related to the variable node as expressed by:


	opc_Reference(EDDL_ID, “HasComponent”, EDDL_ID_1)
	<= eddl_Variable.

The variable node has been defined via the variable type node:


opc_Reference(EDDL_ID_1, “HasTypeDefinition”, EDDL_ID_2)
<= eddl_Variable.

Additionally, however optionally, a “HasSubtype” reference to the BaseDataVariableType (“i=63”) node is added regarding EDDL_ID_2. Further on, relation to the float datatype (“i=10”), of the temperature variable, is accomplished by the reference:


	opc_Reference(EDDL_ID_3, “HasSubtype”, “i=10”) <=
	eddl_Variable.

Property variables, CONSTANT UNIT, STYLE, and VALIDITY, are connected with the exemplary variable node:


	opc_Reference(EDDL_ID_1, “HasProperty”, “EDDL_ID_4”)
	<= eddl_Variable.
	opc_Reference(EDDL_ID_1, “HasProperty”, “EDDL_ID_5”)
	<= eddl_Variable.
	opc_Reference(EDDL_ID_1, “HasProperty”, “EDDL_ID_6”)
	<= eddl_Variable.

Additionally, however optionally, “HasSubtype” and “HasTypeDefinition” references are added to the BaseDataVariableType (“i=63”) node is added regarding EDDL_ID_4, EDDL_ID_5 and EDDL_ID_6.
A variable in the EDD file is modeled as a separate variable object, using the basic structure as shown in FIG. 5, where the variable is based around a Variable object with accompanying property Variable nodes, VariableType node and a simple DataType node. Accordingly, each variable in the EDD file has a number of various properties that are specific to the variable.
FIG. 6 shows an extended information model using the standard OPC UA Information Model, and realized by Datalog rules for nodes and references as described above.
Through the use of a collection of different OPC UA nodes, it can thus be seen that it is easy to map the unique information model of an EDD file and its variables into the OPC UA IM. The mappings of an EDD variable into the OPC UA IM have been summarized up in Table 5.


EDDL	OPC UA
EDD File	OPC UA Object
EDD File Information	OPC UA Properties
EDD Variable	OPC UA Variable, VariableType and DataType
VARIABLE NAME	OPC UA Variable Base Node, BrowseName
LABEL	OPC UA Variable Base Node, DisplayName
HELP	OPC UA Variable Base Node, Description
HANDLING	OPC UA Variable AccessLevel
DEFAULT VALUE	OPC UA VariableType Value
CLASS	OPC UA DataType Base Node, BrowseName
TYPE	OPC UA DataType, HasSubType reference to
	respective OPC UA standard data type

The following section describes an overall system architecture and flow of data in a gateway GW according to an embodiment for transforming a field device description FDD—or more generally: a description of an industrial process equipment—into a OPC UA information model—or more generally: into a semantically enriched and graph-based data information model for automation purposes—with reference to FIG. 7.
A parsing module PRS of the gateway GW is reading a field device description FDD of a—not shown—field device or other arbitrary process equipment. The field device description FDD is stored in the field device and accessed via a field communication protocol, e.g. the well-known HART (Highway Addressable Remote Transducer) protocol.
The parsing module PRS is parsing information entities in the field device description FDD of the field device by said field communication protocol. The parsed information entities are then transformed into a data object representation—declarative logic facts—which are asserted within a deductive database or knowledge base KNB. The parsing module PRS may optionally use an—not shown—accompanying asserter for wrapping the extracted information into Datalog facts and asserting the declarative logic Datalog facts within the knowledge base KNB, e.g. Datalog database KNB. The contents of the knowledge base KNB are used for applying mapping rules or mapping knowledge MKN in general to said declarative logic facts using a Datalog Engine DLE. The parsing module PRS may be formed by one or more processors (e.g., the same or different processors as the one or more processors of the interface module).
It is to be noted here, that the knowledge base KNB or knowledge engine KNB is not only a passively queried database but also acting in a sense of applying rules, mapping facts etc. Depending on the implementation of a particular embodiment, the knowledge base KNB co-operates with the parsing module PRS and a Datalog Engine DLE and may include one or more of these components.
In order to map the declarative logic facts using the Datalog Engine DLE, the knowledge base KNB is loaded with Mapping Knowledge MKN. The Mapping Knowledge MKN is operated to deductively map the data objects transformed by the field device description FDD within the knowledge base KNB with a structure to allow them to be later extracted as OPC UA objects. These mapping rules are asserted before any mappings occur, such that they are able to be applied to input information throughout the mapping process.
It has been shown how the Mapping Knowledge MKN can be operated for EDDL and OPC UA IM. Applying similar procedures, it is possible to create Mapping Knowledge MKN for another field device description model, or an extension of this one, for example, if one needs to represent EDD data over OPC UA IM with the semantics from another model, e.g., the NAMUR Open Architecture or NOA model. Applicability of this approach is thus not limited to other standard information models, e.g., IODD or IO Device Description, FDT/DTM14 or Field Device Tool/Device Type Manager, or NOA (NAMUR Open Architecture).
Unlike most mapping systems, the functionality of the knowledge base KNB—one core of the gateway GW—has been abstracted away from the system itself. By doing so there is a larger degree of flexibility and portability when implementing application specific mappings. By removing all mapping logic from within the source code, the system's flexibility is bounded only by the modeling abilities of the OPC UA IM.
With the mapped EDD information stored within the Knowledge Base KNB the information is then processed and queried in a way that this information can be extracted and eventually exposed via an gateway-internal OPC UA server ISF. These tasks are accomplished by the Datalog Engine DLE and a Query Engine QYE. The recursive querying algorithms for Datalog formalism are well known.
According to embodiments, Datalog has been chosen as a formalism to implement the proposed mapping method due to the of efficiency of Datalog algorithms and their suitability on even resource constraint devices, e.g., non-expensive IoT devices (Internet of Things) and IoT gateways.
FIG. 8 shows a flowchart for querying and extracting OPC UA information from the Datalog Engine in order to recursively instantiate all references pointing from a source node.
By a first step 802, the database is queried for a starting base node using a given NodeID.
In a subsequent decision step 804 a decision is made whether the node with the given NodeID is a base node or not. If the given node is no base node—represented by a branch N (»No«) of decision step 804—a subsequent step 806 is carried out. The subsequent step 806 returns the node with the NodeID.
In a subsequent decision step 804 a decision is made whether a base node with the given NodeID exists or not. If the node does not exist—represented by a branch N (»No«) of decision step 804—there is nothing to map anymore. The procedure is completed by step 806. If a base node with the current NodeID exists—which is represented by a branch Y (»Yes«) pointing vertically downward from decision step 804—a subsequent step 808 is carried out. In the subsequent step 808 the database is queried for node attributes and node type of the base node.
In a subsequent step 810, the node information is processed, and the current node is marked as known. In a subsequent step 812, the database is queried for references with a (source) node ID which matches with the current NodeID. In a subsequent step 814, the queried reference information is stored. In a subsequent step 816, for each of the stored reference information one or more NodeIDs are targeted and/or extracted.
In a subsequent decision step 818 a decision is made of whether a target node is already known or not. Once all nodes are known—represented by a branch Y (»Yes«) pointing vertically upward from decision step 818—the procedure is completed by step 822.
If the referenced target node is not known—represented by a branch N (»No«) of decision step 818—the flow branches to the step 808, which will be recursively called—see reference sign 820—with NodeID as target ID.
The source node would be an OPC UA server's object root node. One has only to query the database for references with a source node ID matching that of the root node. The database will return a list of all references associated with the root node, thus giving a list of all the reference's target node IDs. This returned list can in turn can be recursively processed, allowing for the hierarchical information model of the OPC UA IM to be traversed and processed.
Finally the OPC UA information extracted from the Query Engine is advantageously converted into XML, nodes within an XML Schema of OPC UA. OPC UA Server Config Generator accomplishes this task, and then passes the information downstream to the OPC UA Server. In this way every standard OPC UA client can access data, which originated as EDD field device descriptions.
In conclusion, the embodiments show the following benefits.
The mapping system of the gateway according to the embodiments is capable of interpreting input information, particularly EDD, using stored mapping knowledge, deductively creating information mappings from the input information model into the OPC UA information model, thus eliminating the need for trivial one-to-one hard-coded mapping approaches and allowing for the external storage and querying of mapping knowledge.
The mapping knowledge is extensible for enabling new classes of applications. Beyond a usage for monitoring field devices, the mapping knowledge is also capable of supporting a management of field assets.
The mapping is suited to be implemented on edge or constrained devices. Typically, these are IoT (Internet of Things) gateways or constrained and inexpensive devices. While the mapping can be also accomplished with other semantic formalism, Datalog can be easily implemented on constrained devices. At the same time, Datalog is expressive enough to be used for the mapping of EDD to an OPC UA information model. Datalog was chosen as a formalism for implementing the knowledge mapping system because of its algorithmic efficiency and its possibility to implement the algorithms on constraint devices. The semantics of Datalog is well understood and efficient algorithms have been developed over the past 30 years.
The mapping according to the embodiments is particularly applicable for edge or constrained devices, however, suited to be implemented in a cloud environment as well.
The embodiments allow for a discovery of the mapping knowledge or a part thereof. A user or an application can, for example, query the storage of mapping knowledge via expressive semantic queries.
Extensibility of the mapping knowledge with other models is a further advantage. It has been shown how the Mapping Knowledge can be created for EDDL and OPC UA IM. Applying similar procedures, it is possible to create Mapping Knowledge for another field device description model or an extension of this one.
Further advantages are achieved by the portability and modularity of the system. The mapping knowledge is transparently available instead of being hard-coded. As such it can be, for example, downloaded, exchanged, updated etc.
The embodiments advantageously allow for a validation of field device data against the mapping knowledge. For example, it can be advantageously checked whether field device data are in conformance to a specification.
The embodiments advantageously allow a direct access of information. For many added-value applications, e.g., related to monitoring, management, and optimization of field level assets, it is desirable not to access field information over a controller.
The mapping system reduces the complexity of mapping complex information models where large parts of mapping knowledge can be inherited from previous mappings or complex structures can be mapped by deductively applying mapping rules in a bottom-up fashion.
It is to be understood that the elements and features recited in the appended claims may be combined in different ways to produce new claims that likewise fall within the scope of the present invention. Thus, whereas the dependent claims appended below depend from only a single independent or dependent claim, it is to be understood that these dependent claims can, alternatively, be made to depend in the alternative from any preceding or following claim, whether independent or dependent, and that such new combinations are to be understood as forming a part of the present specification.
While the present invention has been described above by reference to various embodiments, it should be understood that many changes and modifications can be made to the described embodiments. It is therefore intended that the foregoing description be regarded as illustrative rather than limiting, and that it be understood that all equivalents and/or combinations of embodiments are intended to be included in this description.

Claims

1. A gateway for transforming a description of an industrial process equipment into a semantically enriched and graph-based data information model for automation purposes, the gateway including:

a parsing module configured to:

parse information entities in the description of the industrial process equipment by a field communication protocol;

transform the parsed information entities into declarative logic facts; and

assert the declarative logic facts within a deductive database;

a knowledge engine configured to apply mapping rules to the declarative logic facts using a mapping knowledge base, wherein the declarative logic facts are deductively mapped onto the graph-based data information model; and

an interface module configured to access the graph-based data object model.

2. The gateway of claim 1, wherein the semantically enriched and graph-based data information model is an OPC UA information model.

3. The gateway of claim 2, wherein the knowledge engine is configured to apply a mapping rule for creating an OPC UA Base Node Class using attributes taken from a corresponding variable in the description of the industrial process equipment.

4. The gateway of claim 2, wherein the knowledge engine is configured to apply a mapping rule is applied for creating an OPC UA Object node by referencing corresponding attributes in the description of the industrial process equipment including a manufacturer identification, a device type, a device revision, and a device description revision.

5. The gateway of claim 1, wherein the description of the industrial process equipment is expressed by an electronic device description language (EDDL), a field device tool (FDT)/device type manager (DTM) protocol, a general station description (GSD), or an TO device description.

6. The gateway of claim 1, wherein the interface module is a gateway-internal OPC UA server.

7. The gateway of claim 1, wherein the knowledge engine is a Datalog engine.

8. The gateway of claim 7, wherein the knowledge engine, the parsing module, and the Datalog engine are substantially integrated within one functional unit.

9. The gateway of claim 1, wherein the field communication protocol is a highway addressable remote transducer (HART) protocol.

10. The gateway of claim 1, further comprising at least one equipment interface for connecting at least one industrial process equipment.

11. A method for transforming a description of an industrial process equipment into a semantically enriched and graph-based data information model for automation purposes, the method comprising:

parsing information entities in the description of the industrial process equipment by a field communication protocol;

transforming the parsed information entities into declarative logic facts;

asserting the declarative logic facts within a deductive database;

applying mapping rules to the declarative logic facts using a mapping knowledge base, wherein the declarative logic facts are deductively mapped onto the graph-based data information model; and

providing, by an interface module, the graph-based data object model.