System and method for exchanging data between a server and a client in an industrial data network

Abstract

The invention relates to a system and a method for exchanging data between a server and a client in an industrial data network, wherein the server employs a first information model for the information exchange, wherein the client employs a second information model for the information exchange. The method further requires that in a first step the first information model and the second information model are converted into a first machine interpretable description and a second machine interpretable description, in a second step similarities between elements of the first machine interpretable description and elements of the second machine interpretable description are derived, in a third step based on the derived similarities in the text and structure a mapping of at least one element of the first information model to an element of the second information model is proposed and implemented, and in a fourth step the mapping is employed by a gateway entity for the data exchange between the server and the client. The solution is beneficial for the time a user has to spend on the mapping and the occurrence of the implemented mapping.

Description

[0001] The goal of the platform-independent OPC UA protocol (see https: / / opcfoundation.org / ) and its information model is to facilitate standardized and interoperable communication in industrial automation. In this sense, interoperability is the ability of industrial automation systems (or parts thereof) to exchange data in a well-defined, shared meaning. This feature greatly reduces implementation effort and enables communication with industrial devices across manufacturers. In addition to this, applications that operate on data from industrial devices can be developed independently of the device, no matter where in the architecture the application runs. The only prerequisite for communicating with an industrial automation system is the use of the OPC UA communication interface and its standardized information model. In order to feature standardized and interoperable communication, new industrial automation systems can be designed to comply with the OPC UA standard.

[0002] However, if existing (so-called "brownfield") automation systems are to feature the same, the systems need to be integrated with the standard.

[0003] Figure 1 A process is shown that creates a standardized information model for an existing field device with a brownfield programmable logic controller (PLC) that has been designed using an Engineering Tool. The Engineering Tool contains all information required for the PLC to operate, but this information is provided in a vendor-specific data model (indicated as "unknown system structure" in Figure 1 ). This information needs to be mapped into the OPC UA standardized information model (indicated as "information mapping" in Figure 1 ). In this way, a new standardized server interface is generated for the PLC that is fully described using the OPC UA information model (indicated as "standard information model" in Figure 1 ). This model can be hosted by the PLC (if the PLC has an OPC UA server).

[0004] In addition, it can be delivered to any OPC UA client to access data from the PLC (see Figure 1 ). Developers can now easily create applications without needing to know the specifics of PLCs from individual vendors, knowing the standardized model is enough. It also does not matter where in the architecture the OPC UA client runs (at the edge, in the cloud, or elsewhere), and whether the client is an application or another industrial device. Overall, the standardized information model of the field device enhances interoperability in industrial automation.

[0005] The technical challenge of the underlying invention is that the mapping from a vendor-specific data model to an OPC UA standardized information model is not trivial. First, the original data model can be quite different from the OPC UA information model. Second, the OPC UA information model is rich and therefore complex. Therefore, such a task is mostly done manually nowadays, and therefore it is an expensive and error-prone job.

[0006] Figure 2 It is shown that a standardized information model is created for existing field devices by a gateway utilizing a brownfield PLC that does not host an OPC UA server. In this case, a gateway is needed to provide the protocol binding between the PLC protocol and the OPC UA protocol. Furthermore, the gateway hosts an OPC UA server that exposes the standardized interface with the OPC UA information model of the PLC. There are architectures that use a platform instead of a gateway. The platform usually integrates various devices and provides its own information model. It can still be desirable to map this model into the OPC UA standardized information model. The task of mapping a vendor-specific data model into the OPC UA standardized information model is as challenging as in the first case (see Figure 1 ).

[0007] The invention solves the problem of mapping the metadata of existing automation systems and devices into a common standardized information model. Therefore, the invention enables data exchange between systems and devices that have different information models. The existing metadata can be in different forms, from simple tags to more complex engineering object models, see the left part of Figure 3 .

[0008] Figure 3 It is shown that the metadata mapping from existing automation systems to the OPC UA information model. This metadata is usually available from existing engineering tools or platforms and needs to be mapped into a standardized data model. For example, for the standardized model we use the OPC UA information model and specific domain extensions called OPC UA Companions. The OPC UA information model is organized such that each layer provides additional information, from basic OPC UA concepts to domain-specific information, even vendor-specific information, and so on. It is not a single model, but a stack of information, see the right part of Figure 3 . Therefore, it is difficult, time-consuming, and error-prone to map tags or information artifacts from the existing engineering data model into the semantically equivalent structure of the OPC UA information model.

[0009] In the invention, a solution to the described problem is explained. The solution is not limited to the OPC UA information model.

[0010] In the prior art there are tools, such as SiOME (see https: / / support.industry.siemens.com / cs / document / 109755133 / siemens-opc-ua-modeling-editor-(siome)-for-implementing-opc-ua-companion-specifications?dti=0&lc=en-WW), which can be used for the task of mapping existing vendor-specific metadata to a standardized OPC UA model, see Figure 4 .

[0011] Figure 4 Mapping of existing vendor-specific metadata to a standardized OPC UA model using a graphical tool is shown. On the right side of the Figure 4 we see the existing metadata, e.g. from an engineering tool or platform (in this case, the TIA Portal tool by Siemens). On the left side of the Figure 4 we see the OPC UA-based information model that the user wants to map into. In the middle part of the diagram there is the mapping. The user can do this mapping by dragging and dropping information artifacts from right to left. Figure 4

[0012] Figure 5 A fragment of the resulting OPC UA NodeSet after mapping of the vendor-specific metadata to a standardized OPC UA model is shown. Thus, Figure 5 represents the OPC UA NodeSet that implements the mapping. This NodeSet is automatically generated from the graphical tool. Although this tool provides a great help in the mapping task, the user still needs to manually find the appropriate information artifacts from the standardized model. As mentioned before, the OPC UA model is very extensive and requires a lot of knowledge to use. Therefore, even with the help of such a tool, it is difficult, time-consuming and error-prone to map the information from an existing engineering data model into the semantic equivalent structure of an OPC UA information model.

[0013] It is therefore the task of the present invention to provide a method and a system supporting information model mapping for data exchange in industrial data networks.

[0014] This task is solved by the method according to the invention and by the system according to the invention.

[0015] ​The solution is provided by a method for exchanging data between a server and a client in an industrial data network, wherein the server employs a first information model for the information exchange and the client employs a second information model for the information exchange. The method further requires that in a first step the first information model and the second information model are converted into a first machine interpretable description and a second machine interpretable description, in a second step a similarity between elements of the first machine interpretable description and elements of the second machine interpretable description is derived, in a third step a mapping of at least one element of the first information model to an element of the second information model is proposed and implemented based on the derived textual and structural similarity, and in a fourth step the mapping is employed by a gateway entity for the data exchange between the server and the client. The solution is beneficial for the time a user has to spend on the mapping and for the occurrence of the implemented mapping. In a sense, the solution is generic, it provides semantic mapping of almost any input, vendor specific metadata and any output model including OPC UA based models.

[0016] The task is also solved by a system for exchanging data between a server and a client in an industrial data network, wherein the server employs a first information model for the information exchange and wherein the client employs a second information model for the information exchange. The system comprises a conversion unit for converting the first information model and the second information model into a first machine interpretable description and a second machine interpretable description, a derivation unit for deriving a similarity between elements of the first machine interpretable description and elements of the second machine interpretable description, a proposal unit for proposing and implementing a mapping of at least one element of the first information model to an element of the second information model based on the derived textual and structural similarity, and a gateway entity employing the mapping for the data exchange between the server and the client. With such a system the advantages described in connection with the method can be achieved.

[0017] Advantageous embodiments are disclosed with the dependent claims. These embodiments can be realized individually or in combination. The features of the dependent method claims and their advantages also hold true for the system in the analog sense and vice versa.

[0018] An advantageous application of the invention is given if the server is an industrial controller, if the first information model is a tag based information model described by first metadata, and if the first metadata are used as the first machine interpretable description. In particular, the client can be an industrial application program employing a standardized OPC UA information model. In this case, the OPC UA information model should be converted into a RDF / OWL representation, which is the second machine interpretable representation.

[0019] In a second step, several full-text similarity indexes can be built on the machine interpretable description, each similarity index covering a specific type of standardized information model, and one of the indexes used for the derivation of the second step can be selected.

[0020] After the third step, the mapping information, i.e. the Knowledge Pack, in the data structure can be built and stored and deployed into the gateway entity. Thus, the mapping information is portable and reusable for other applications. Furthermore, the Knowledge Pack can serve as a starting point for new mapping tasks.

[0021] Examples of the application will be explained by means of the attached drawings; in this context, the Figures 1 to 5 The present application relates mainly to the prior art.

[0022] Figure 1 shows the creation of a standardized information model for an existing field device using a brownfield programmable logic controller (PLC),

[0023] Figure 2 shows the creation of a standardized information model for an existing field device using a gateway,

[0024] Figure 3 shows the mapping of metadata from an existing automation system to an OPC UA information model,

[0025] Figure 4 shows the mapping of existing vendor-specific metadata to a standardized OPC UA model using a graphical tool,

[0026] Figure 5 shows a final OPC UA node set fragment after mapping of vendor-specific metadata to a standardized OPC UA model,

[0027] Figure 6 shows the mapping of existing field metadata to an OPC UA information model,

[0028] Figure 7 shows an injection molding machine example designed with engineering software "Siemens TIA Portal",

[0029] Figure 8 shows an example fragment of an Automation Markup Language (AutomationML) file,

[0030] Figure 9 shows an example of label-based field metadata,

[0031] Figure 10 shows an overview of the problem of mapping an existing model to an OPC UA information model,

[0032] Figure 11 This diagram shows an overview of the interface used for data exchange between the injection molding machine (IMM) and the manufacturing execution system (MES).

[0033] Figure 12 This provides an overview of semantic mapping—finding similarity through text-based and structure-based searches.

[0034] Figure 13 This example demonstrates a SPARQL query used to build a similarity index for our OPC UA instance model.

[0035] Figure 14 This example demonstrates a SPARQL query for finding leaf nodes based on labels and data types.

[0036] Figure 15 Showing from Figure 14 Example results of a SPARQL query.

[0037] Figure 16 An example of performing a tree search on supplier-specific data is shown.

[0038] Figure 17 An example SPARQL query for finding the join node between two leaf nodes is disclosed.

[0039] Figure 18 Showing from Figure 17 Example results of SPARQL queries, and

[0040] Figure 19 The application of the "knowledge package," a data structure that makes semantic mapping more general, is shown.

[0041] In mapping the metadata of existing automated systems and equipment to a standardized information model, we distinguish three phases: Definition, Mapping, and Instantiation (see [link to documentation]). Figure 6 (The right side). For example, these three stages can be applied in information modeling tools to simplify the mapping process.

[0042] During the definition phase, we select the OPC UA information model, which includes the components that should be used to describe our existing automation systems or equipment. For example, if we want to create an OPC UA machine interface for an injection molding machine, we can choose the following standardized model as our target model:

[0043] • Device Information Model (OPC UA DI) - Companion Specification characterizing the information model for devices;

[0044] • EUROMAP (European Association of Plastics and Rubber Machinery Manufacturers) 77 Companion Specification describing the data exchange interface between injection molding machines (IMM) and manufacturing execution systems (MES);

[0045] • EUROMAP 83 Companion Specification, which is a standardized model for general information about plastic and rubber machines.

[0046] In the instantiation phase, we create the OPC UA machine interface for our device (or machine) by instantiating the standard model for our machine.

[0047] The definition and instantiation phase belong to the common practice when using OPC UA information models. These phases are done by existing OPC UA information modeling tools (e.g. SiOME). Therefore, they are not the subject of this work.

[0048] In the mapping phase, we have to map the metadata (simple tags or engineering object models) from our existing automation system or device into our instantiated (target) model. The mapping phase is now done manually. It requires a lot of expert knowledge, is time-consuming and error-prone.

[0049] The invention solves the mapping problem by proposing a method for semantic mapping. Semantic mapping automatically maps data from the original model to the target model by deriving textual and structure-based similarities and complex combinations of results.

[0050] In the following, the method is motivated and explained in more detail by an example. It should be noted that we can create new instances during the mapping phase. Therefore, the border between the instantiation and the mapping phase is not strict. Furthermore, it should be noted that there is an information flow between the definition, instantiation and mapping, which is not marked with arrows (they represent the phases and not the processing components).

[0051] Figure 6 The left side of Fig. 6 shows the input of the mapping phase. The existing vendor-specific metadata can appear in different forms. In Figure 6 we only show two instances of metadata: simple tags 620 and engineering object models 621, both of which should be converted to the standardized information model 622. But the vendor-specific metadata from the existing automation system can vary in many ways and our solution is not limited to these two forms of existing field metadata.

[0052] Let us consider the metadata from existing systems in more detail (e.g. this data can be exported from the engineering platform).

[0053] One example of such a platform is Siemens TIA Portal. In Figure 7 we can see the engineering tool TIA Portal as well as an example project of an injection molding machine. On the right side of the figure, the data structure of the machine's injection unit, namely "injectionUnitl", can be seen. The machine can be seen as a server and the data structure can be defined according to the first information model. It is a complex data structure consisting of several variables: "barrelld", "index", "inProduction", etc. Further, we see the data type of each variable (e.g. "index" is UDInt, which is an unsigned double integer) and an annotation of what it is (e.g. "IndexProperty gives the number of injection units."). All this metadata can be exported from the engineering tool in the standardized AutomationML format, thus forming the first machine interpretable description.

[0054] Figure 8 An excerpt of the AutomationML file in our example is shown in

[0055] Figure 9 Another example of representing existing vendor specific metadata. Here, we again have an existing injection molding machine whose metadata is provided in text form by a proprietary platform. This format cannot be machine interpreted by standardized semantics. However, there is a proprietary data model consisting of tags with predefined meaning (semantics). In this particular data model, we define our own type "InjectionUnitType" as "TypeName" (TypeName is a specific tag for defining a new custom type). In this type, we define the state, which is a complex data structure (indicated by the number 1, see Figure 9). This structure consists of several variables (e.g. "Index", "Barrelld", "IsPresent", etc.) each of which is assigned a data type (e.g. "Index" is represented by the number 22, which means it is a 64-bit floating point number (Float64)). Once we have defined this complex type, we are also able to instantiate it. In our example, "InjectionUnit_1" is an instance (data point) of the type "InjectionUnitType", see Figure 9 .

[0056] The two instances of existing metadata (see Figure 8 and Figure 9 ) represent data and structure in different serialization formats (text vs. XML). But both instances have a common part as well. In essence, they both contain information about data points (possibly including sub-data points) and their data types. Based on this fact, we are able to abstract the input from existing vendor-specific automation systems, as shown on the left-hand side of Figure 10 .

[0057] Now let's also consider the standardized OPC UA information model 1022 (see right-hand side of Figure 10 ) we aim to map the proprietary information model 1021 into. This information model can be referred to as the second information model of the client. As mentioned before, for our example we will use the OPC UA model provided by EUROMAP.

[0058] Figure 11 An overview of the interface between an injection molding machine (IMM) and a manufacturing execution system (MES) for data exchange is shown. Figure 11 Taken from the EUROMAP 77 companion specification, it refers to parts of the model from OPC UA DI and EUROMAP 83. It can be seen as a second machine interpretable description.

[0059] The MES (manufacturing execution system) is used to collect information generated by the IMM. The MES provides a central point for easier quality assurance as well as management of jobs and data sets. The goal of EUROMAP 77 is to enable a unique interface for IMM and MES, thus ensuring interoperability between different vendors.

[0060] Figure 9 The model shown in the middle covers the following functions: general information about the IMM (manufacturer, serial number, etc.), current configuration and status of the IMM (molds, injection units, power units, machine related change log, etc.), job management (job information and production parameters running on the machine), etc.

[0061] For our example, let's focus on just the InjectionUnit part of the model (surrounded by a dashed line in Figure 11 Figure 1). This model provides a container for different injection units. Each unit is identified by a number (InjectionUnit <nr>) and is an instance of the Injection Unit Type (InjectionUnitType). InjectionUnitType is characterized by Index (providing a numerical identifier of the injection unit), BarrelId (providing a serial number of the barrel), IsPresent (providing information whether the injection unit is installed on the injection machine or not), etc. Interested readers are referred to the EUROMAP 77 and EUROMAP 83 specifications for further details on the EUROMAP model.

[0062] Our goal is to generate an OPC UA information model based interface including the accompanying specifications (e.g. EUROMAP) and link it to the variables and methods of the existing vendor specific models (see Figure 8 and Figure 9 for examples). This goal is illustrated in Figure 12 .

[0063] To achieve this goal, we provide a semantic mapping method, see Figure 12 . The semantic mapping combines a full-text similarity search and a structure based search. Figure 12 The left side of illustrates the existing vendor specific metadata, which consists of free text and structured data (vendor specific data model 1221). During the engineering of an automation system, free text is often used to name variables, data points, data structures, etc. (e.g. "Barrel", "Screw Diameter", etc.). We have to map these freely defined labels to standardized concepts (OPC UA information model 1222). For this purpose, we deploy a full-text similarity search. Further, we see that data structures can also be extracted from the existing metadata. In our example, the structure consists of variables (e.g. "Barrel", "Screw Diameter", etc.), each of which is assigned a data type. Variables can further be combined to form more complex structures. Data types (e.g. String, Float64) can also be combined to complex data types. All this information is not free text. Thus, we see that in the existing vendor specific metadata we also have structure information. These structures can be used during the mapping to standardized semantics. For this reason, we also deploy a structure based search.

[0064] Our semantic mapping method is based on a combination of a full-text similarity search and a structure based search and is done in three steps:

[0065]

[0066] • Derive similarities (build similarity index).

[0067] • Suggest and implement semantic mappings.

[0068] First, we have to make the OPC UA information machine interpretable. To be able to search the semantic structure of the information model, we convert the OPC UA information model into a machine interpretable version. For this, we use the W3C standards RDF and OWL. In Appendix A.2, an excerpt from the definition of InjectionUnitsType from the OPC UA EUROPMAP77 companion specification is shown. InjectionUnitsType, an instance declaration (InjectionUnit <nr>) and variables (BarrelId, ScrewDiameter, etc.) are shown on the right side of Figure 11 and Figure 12 The same information is formally defined in the OPC UA EUROPMAP 77 companion specification, see Appendix A.2.1, Appendix A.2.2, Appendix A.2.3 and Appendix A.2.4, respectively. As mentioned before, a machine interpretable version of this information is required. The conversion can be implemented programmatically. The conversion output of the examples in Appendix A.2 is provided in Appendix A.3, i.e. in Appendix A.3.1, Appendix A.3.2, Appendix A.3.3 and Appendix A.3.4, respectively.

[0069] Second, we have to build a similarity index. To implement full-text similarity search, we have to build a similarity index for the information model. But we do not build an index for unstructured text. Instead, we do this for structured information. By converting the OPC UA information model into a machine interpretable form, we create a knowledge graph. In this graph, standardized concepts are connected with semantic relations. By building a full-text similarity index on such a knowledge graph, we basically implement a match of concepts that are semantically close. The results obtained from full-text similarity search cannot be obtained by structured query alone nor by full-text search query alone. But a combination of both is advantageous.

[0070] In natural language processing (NLP) and text mining, there are multiple methods to build a similarity index, e.g. random projection, random indexing, singular value decomposition, etc. statistical semantics methods.

[0071] For example, a concrete implementation of this approach can use GraphDB. GraphDB makes use of semantic vectors to build a similarity index. Based on a highly scalable vector space model, RDF graphs enrich the semantic similarity index. We define various indexes, covering specific types of standardized models. For example, in a single knowledge graph, there can be an index covering OPC UA object types defined in the companion specification, another one can cover OPC UA objects, then another index for VariableTapes, Variables, Properties, etc. We are also able to build indexes from existing vendor specific models input. For example, if our input is centered on InjectionUnitsType of the entire IMM_MES_Interface (see Figure 11 ), then we build an index for InjectionUnitsType. Figure 11 The Machine MES Status, Machine MES Configuration and other parts in the can be ignored or we can build separate indexes for these other aspects as well. Thus, depending on the specifics of the user, we can split the information space into smaller chunks and reduce the complexity of the search. The chunks of the complete knowledge graph can be extracted using structure-based search (SPARQL queries).

[0072] In our approach, we can also restructure the knowledge graph into a new one that is better suited for the semantic mapping of the existing input data model. Restructuring one model into another can also be done using structure-based queries (SPARQL queries). Since the information represented in RDF / OWL supports SPARQL queries, this is another benefit of converting the OPC UA information model into RDF / OWL.

[0073] Figure 13 A SPARQL query is shown that builds a similarity index for our OPC UA instance model in GraphDB. After executing this query, the similarity index for a free text search based on any literal in the knowledge graph will be ready for querying. In the remaining part of this work, we will explain how to use this index for semantic mapping.

[0074] Third, we have to suggest and implement semantic mapping. Semantic mapping combines full-text similarity search with structure-based search. Let us consider the in the example. Figure 12 The left side of the graph shows the existing vendor-specific metadata for variables, data points, data structures, etc. (e.g., "Barrel,” "Screw Diameter,” etc.). We have to map these freely defined labels to standardized concepts, e.g., the OPC UA information model and the accompanying specification. Further, we see that data structures can also be extracted from the existing metadata. In our example, the structure consists of variables (e.g., "Barrel,” "Screw Diameter,” etc.) that are each assigned a data type (e.g., String, Float64).

[0075] In general, by mapping the existing vendor-specific metadata, we basically map labels or trees (e.g., data points with their data types) to a graph (the OPC UA-based model). If we start mapping from the leaves of the tree, the mapping is easier, see Figure 11 and then map upwards. Figure 14 An example SPARQL query is shown to find leaf nodes based on a label and data type. In this example, the label is "barrel" and the data type is "String" (as shown in Figure 12 ). This SPARQL query is executed against the RDF information provided in Appendix A.3. The result is shown in Figure 15 . We get the unique ID of the leaf node (documentID) and the score (the probability that the label is similar to the leaf node description). The resulting nodes (ID:i6018 and ID:i6097) are Figure 12 two instances of the property "BarrelId" in the existing vendor-specific model.

[0076] Suppose we now need to find out if there is an unknown node with two leaf nodes, as shown in Figure 16 . The description of one leaf node should be similar to the label "barrel" with data type "String". The second leaf node should be similar to the label "screw diameter" with data type "Double". This structure can be explored using the SPARQL query shown in Figure 17 .

[0077] Figure 17 The query result is shown in Figure 18 . In the first column, the leaf nodes similar to the label "barrel" are retrieved and the similarity score is shown in the second column. Likewise, the third and fourth columns show the results for the second leaf node. Finally, the last column shows the results for the parent node (the unknown node). The user can use these results when mapping the existing data model to the standardized information model.

[0078] In general, a leaf node can be connected to a parent node through n other nodes. For example, BarrelID and Index are connected to the IMM_MES_Interface node through the InjectionUnit node, see Figure 11 . These relationships exist in our knowledge graph. Therefore, by a SPARQL query and a recursive process similar to the one in Figure 17 , we can find any parent node connected to a leaf node. Further, we can map this leaf node to the appropriate data in the existing vendor-specific model.

[0079] It should be noted that in our example of an existing vendor-specific model (see Figure 12 The data type for "Screw Diameter" is "64-bit floating-point (Float64)". On the other hand, in the standardized OPC UA model, the data type for this attribute is "double-precision floating-point (Double)" (see Appendix A.2.4). Therefore, in order to... Figure 17 To obtain results from queries, we must extend the knowledge graph by declaring that the data type "64-bit floating-point (Float64)" is essentially equivalent to "double floating-point (Double)". In RDF / OWL-based models, the options for achieving this are limited; for example, creating equivalent classes or data types using the "64-bit floating-point (Float64)" subtype "double floating-point (Double)", or using the OWL attribute owl:sameAs (depending on whether the two entities we want to make equivalent are classes or instances). It is also possible to create rules or data structures (KPs) that express this equivalence. We provide extensions to the knowledge graph containing standardized knowledge in Knowledge Packs (KPacks). KPacks are created for each distinct vendor-specific input model. KPs provide a good solution for extending standardized models with proprietary extensions. It is very convenient to implement KPacks in RDF / OWL and integrate them with different parts of the knowledge graph.

[0080] Figure 19 The role of the knowledge package (KP) in our semantic mapping is illustrated. The vendor-specific data model 1921 is an existing data model for brownfield automation systems (e.g., a tag-based unknown system architecture encoded in AutomationML descriptions or similar ways). It needs to be mapped to an OPC UA-based model 1922 to create the output OPC UA model. In practice, different options are available for OPC UA-based models. Therefore, models based on complementary models and / or customer-defined models (such as...) are used. Figure 19 The OPC UA model (shown below) provides the basic model and structure that should be used during mapping. This is the target model that the mapping should guide. Essentially, it provides the template or basic structure to which the input model should be mapped. An example of an OPC UA model is OPC UA DI. In the future, a good candidate for this model will be the upcoming accompanying specification, OPC UA FLC. Companies also define their own models based on the OPC UA standard and tailor them to specific needs. Therefore, any of these options can serve as... Figure 19 The model is represented as an OPC UA model. How the input data model is mapped to this model is defined in a data structure called Knowledge Pack or KPack. The KPack is implemented as a set of mapping OWL axioms, rules and queries, which are created for a specific input data model and a selected OPC UA model. The semantic mapping finally provides the mapping. It is shown in Figure 12 Figure 1 and described throughout the work. The semantic mapping is implemented by executing SPARQL queries using free text similarity search and structure-based search. By evaluating these queries, it can also be necessary to evaluate OWL axioms and rules from the KPack and the knowledge contained in the knowledge graph. For each piece of data mapped to a corresponding standardized information (variable, property, object, etc.), the user gets a set of choices ordered based on a similarity score. The user is able to browse through these results and select the mapping option. In this way, our concept provides a semi-automatic mapping. This solution is beneficial in terms of time the user has to spend on the mapping and the occurrence of the implemented mapping. The final output of the semantic mapping, i.e. the output OPC UA model, is a set of automatically generated nodes, e.g. as shown in Figure 5 Figure 2.

[0081] Finally, the created mapping will be used in a gateway entity or gateway device for performing data exchange between e.g. a PLC and a MES system or in general between a client and a server.

[0082] We achieve the following advantages:

[0083] • This solution is beneficial in terms of time the user has to spend on the mapping and the occurrence of the implemented mapping.

[0084] • In a sense, this solution is generic, it provides semantic mapping of almost any input, vendor-specific metadata and any output model, including OPC UA-based models.

[0085] • This solution is scalable in terms of adding new knowledge packs (to support mapping information for new models) and is easy to maintain (when integrating existing knowledge with new knowledge).

[0086] Appendix

[0087] A.1 : AutomationML file instance

[0088] Instance of an AutomationML file providing semantic metadata from an existing automation system. The file has been exported from the Siemens TIA Portal engineering tool.

[0089]

[0090]

[0091]

[0092]

[0093]

[0094]

[0095] A.2: Excerpt from the InjectionUnitsType definition from the OPC UA EUROPMAP77 companion specification

[0096] A.2.1 : Definition of InjectionUnitsType

[0097]

[0098] A.2.2: Definition of InjectionUnitsType instance declaration

[0099]

[0100]

[0101] A.2.3: Definition of variable "BarrelId"

[0102]

[0103] A.2.4: Definition of variable "ScrewDiameter"

[0104]

[0105] A.3: Excerpt from the InjectionUnitsType from the OPC UA EUROPMAP77 companion specification in RDF / OWL representation

[0106] A.3.1 : Definition of InjectionUnitsType in RDF / OWL

[0107]

[0108]

[0109] A.3.2: Definition of InjectionUnitsType instance declaration in RDF / OWL

[0110]

[0111]

[0112]

[0113] A.3.3: Definition of variable "BarrelId" in RDF / OWL

[0114]

[0115] A.3.4: Definition of variable "ScrewDiameter" in RDF / OWL

[0116]

[0117] < / nr> < / nr>

Claims

1. A method for exchanging data between a server (101, 201) and a client (102, 202) in an industrial data network. in, The servers (101, 201) use a first information model (620, 621, 1021, 1221, 1921) for information exchange, and the clients (102, 202) use a second information model (222, 622, 1022, 1222, 1922) for information exchange. Its features are, - In the first step, the first information model (620, 621, 1021, 1221, 1921) and the second information model (222, 622, 1022, 1222, 1922) are converted into a first machine-interpretable description and a second machine-interpretable description. - In the second step, the similarity between the elements that the first machine-interpretable describe and the elements that the second machine-interpretable describe is derived. - In the third step, based on the derived text and structural similarity, a mapping from at least one element of the first information model to an element of the second information model is proposed and implemented, and - In the fourth step, the gateway entity adopts the mapping for data exchange between the server (101, 201) and the client (102, 202).

2. The method according to claim 1, Its features are, The servers (101, 201) are industrial controllers. The first information model (620, 621, 1021, 1221, 1921) is a tag-based information model described by the first metadata. The first metadata is used as the first machine-interpretable description.

3. The method according to claim 1 or 2, Its features are, The client (102, 202) is an application that uses a standardized OPC UA information model as the second information model (222, 622, 1022, 1222, 1922).

4. The method according to claim 3, Its features are, The OPC UA information model is converted into an RDF / OWL representation. The RDF / OWL representation is a second machine-interpretable representation.

5. The method according to claim 3, Its features are, In the second step, multiple full-text similarity indexes are constructed on the machine-interpretable description, each index covering a specific type of standardized information model, and Choose one index from the indexes for the derivation in the second step.

6. The method according to claim 1 or 2, Its features are, After the third step, the mapped information is stored in a data structure (KP), i.e., a knowledge package, and the data structure is allocated to the gateway entity.

7. A system for exchanging data between servers (101, 201) and clients (102, 202) in an industrial data network. in, The servers (101, 201) use a first information model (620, 621, 1021, 1221, 1921) for information exchange, and the clients (102, 202) use a second information model (222, 622, 1022, 1222, 1922) for information exchange. The system is characterized in that it comprises: A conversion unit is configured to convert the first information model (620, 621, 1021, 1221, 1921) and the second information model (222, 622, 1022, 1222, 1922) into a first machine-interpretable description and a second machine-interpretable description. The derivation unit is used to derive the similarity between the elements that can be explained by the first machine and the elements that can be explained by the second machine. A suggestion unit, configured to propose and implement a mapping from at least one element of the first information model to elements of the second information model based on derived text and structural similarity, and A gateway entity that employs the mapping for data exchange between the server (101, 201) and the client (102, 202).

8. The system according to claim 7, Its features are, The servers (101, 201) are industrial controllers. The first information model (620, 621, 1021, 1221, 1921) is a tag-based information model described by the first metadata. The first metadata is used as the first machine-interpretable description.

9. The system according to claim 7 or 8, Its features are, The client (102, 202) is an application that uses a standardized OPC UA information model as the second information model (222, 622, 1022, 1222, 1922).

10. The system according to claim 9, Its features are, The conversion unit is configured to convert the OPC UA information model into an RDF / OWL representation. The RDF / OWL representation is a second machine-interpretable representation.

11. The system according to claim 9, Its features are, The derivation unit is configured to construct multiple full-text similarity indexes on the machine-interpretable description, each similarity index covering a specific type of standardized information model, and The index is used to select one of the indexes for the derivation of the similarity.

12. The system according to claim 7 or 8, Its features are, The system is configured to store the mapped information in a data structure (KP), i.e., a knowledge package, and to dispatch the data structure to the gateway entity.

Images