Patent Application
20200210869
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.
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.
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.
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:
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
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
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
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).
Referring now to
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:
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:
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:
A fact is a ground atomic formula, e.g. expressed by:
It can be seen that terms in the Body literal—right side of
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:
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:
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:
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.
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:
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:
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:
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:
The following Datalog rule will create an OPC UA Base Node Class with certain attributes taken from the corresponding EDDL variable:
This rule defines a base node for an OPC UA variable by the term:
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
The signature of a variable type is represented with the following Datalog atomic formula:
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:
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:
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:
For the exemplary variable used before the following rule creates an OPC UA DataTypeNode:
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:
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:
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:
The BaseNodeClass of the property is realized with the following rule:
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:
The BaseNodeClass of the property can be realized with the following rule.
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:
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)«
An inherited base node class for the OPC UA Object node is realized with the rule:
For the sake of readability, the term
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:
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:
An inherited base node class for the attribute »manufacturer ID« is realized with the rule:
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:
The OPC UA Reference is represented by the following Datalog atomic formula:
The attributes of the OPC UA Reference have the following meaning:
Additionally, however optionally, it is common to state that the ObjectsFolder and the top-level node are related via the »HasComponent« reference:
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):
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:
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:
The variable node has been defined via the variable type node:
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:
Property variables, CONSTANT UNIT, STYLE, and VALIDITY, are connected with the exemplary variable node:
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
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.
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
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.
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.
