CN113557505A

CN113557505A - System and method for interoperable communication between entities having different architectures

Info

Publication number: CN113557505A
Application number: CN202080020540.XA
Authority: CN
Inventors: 玛丽·普拉特纽斯-莫尔; 索迈耶·马拉库蒂; 托马斯·戈尔德施米特
Original assignee: ABB Schweiz AG
Current assignee: ABB Schweiz AG
Priority date: 2019-03-11
Filing date: 2020-03-11
Publication date: 2021-10-26
Anticipated expiration: 2040-03-11
Also published as: US20210409521A1; WO2020182892A1; EP3709195B1; US11677861B2; EP3709195A1; CN113557505B

Abstract

A computer-implemented method, a computer program product and a computer system (100) for enabling communication between a first real-world entity (101) and a second real-world entity (102) having different digital twin formats (F1, F2) Interoperable data exchange. The second entity receives a request (IR1) to provide data (D1) to the first entity in the format (F1) of the first entity. The analyzer (142) evaluates the predefined mapping strategies (133) and determines the mapping similarity for each mapping strategy based on the similarity in structure and semantics of the corresponding data models (DM1, DM2) of the first digital twin and the second digital twin Sexual Metrics. A mapping module (132) generates a mapping (M1) between the first and second formats (F1, F2). At least one mapping strategy is selected from a predefined set of mapping strategies (133) based on the determined similarity measures (SM1 to SMn) to perform mapping between the data models of the first and second formats (F1, F2). The request data (D1) is then provided to the first entity via said mapping (M1) in the format (F1) of its digital twin.

Description

System and method for interoperable communication between entities having different architectures

Technical Field

The present invention relates generally to electronic data processing and more particularly to a method, computer program product and system for interoperable communication between real world entities.

Background

In the digital retrofitting process, many real world entities, such as, for example, companies, factories, cities, etc., have digital representations commonly referred to as digital twins (digital twins). Such numbers are represented as virtual entities that replicate data, structure, and functionality associated with real-world entities (and from time to time also associated with other related real-world entities). A real-world entity may have multiple digital twins, each of which encompasses certain aspects of the real-world entity. Typically, multiple real world entities use the digital twin in their own (proprietary) format. If such real-world entities want to exchange digital data, they need to be able to map their digital twin formats to those of other real-world entities that are the desired communication partners.

To date, creating such mapping rules has been a manual task requiring engineers to have a good understanding of the source and target formats. Thus, creating such a mapping is tedious and error prone. Errors in the mapping are obstacles to interoperable communication between real world entities.

Disclosure of Invention

Accordingly, there is a need to provide systems and methods for interoperable data exchange between two real-world entities over a communication network that use digital representations in different formats to allow robust interoperable communication between the real-world entities. Thus, data exchange is defined as the process of taking data structured in a source schema and transforming it into data structured in a target schema so that the target data is an accurate representation of the source data. Data exchange allows sharing of data between different computer programs. The different formats may differ in syntax of the respective data models or semantics of the respective data models, or in syntax and semantics. The embodiments of the invention as disclosed in the independent claims solve this technical problem by generating the required mapping using an automatic generation process. As a result, the mapping between the digital representations (digital twins) becomes less error prone, thereby enabling more stable (robust) communication between real world entities. In some embodiments, the generated mappings may be stored in corresponding individual mapping models, allowing subsequent customization of the mappings by users with domain-specific knowledge. Thus, the separate mapping model completely separates the customization step from the real world entities having proprietary formats, especially if the source and target formats change over time.

Many real world entities, such as automation companies, have a so-called internet of things (IoT) platform. For example, such platforms provide information models to store and access information about the characteristics and behavior of devices in an automation system. Such an information model may be used to define a digital twin of devices for a desired use case. Typically, each IoT platform employs its proprietary format to describe the digital twin's information model. In other words, each digital representation uses a data model defined in its own proprietary format, providing the flexibility to describe information about a device in a separate manner for a respective real-world entity, e.g., customized for use cases of the corresponding entity. However, this also hinders interoperability across multiple IoT platforms, and thus is an obstacle to advanced cross-entity data intensive use cases that improve the performance and/or reliability of devices. An example use case is predictive maintenance that combines information from devices running at a first entity and engineering details available at a site of a second entity.

For robust interoperable communication, it is advantageous to share at least part of the digital twin between the different entities for this purpose. For example, each company needs to be able to understand and process the proprietary formats of the other companies. Since there is no standard available at present, each company attempts to map its digital twin to another (e.g., commonly agreed) format that the target company can use with. Creating such mapping rules is often a manual task that an engineer needs to have a good knowledge of the source and target formats, which makes it error-prone, especially if a large number of different data objects are involved. Further, engineers must manually adjust the mapping each time a change occurs in the source or target format, which is again an error-prone process.

The embodiments according to the independent claims propose a way to automatically create the mapping required to transform a digital representation of a real world entity (digital twin) from its proprietary format to the format of another real world entity by a generation process to achieve interoperability. This approach may also be used in digital twins where there are multiple standard definitions to require the transformation from one standard to another to be performed.

In one embodiment, a computer-implemented method for interoperable data exchange between a first real-world entity and a second real-world entity is provided. Both real world entities are connected to the same communication network. The first and second real-world entities have corresponding first and second digital representations. Each digital representation is a virtual entity that replicates data, structure, and functionality associated with ones of the real-world entities. That is, the digital representation of the real-world entity may also include data originating from other real-world entities. The first digital representation and the second digital representation have different formats (i.e., the digital representations use different data models). The method described below is performed by a second real-world entity. That is, the method is described from the perspective of one of the communication partners.

The second real world entity has an interface for receiving a request to provide data of the second digital representation to the first digital representation. For example, the request may be associated with a data request of an application that queries a digital representation of a first real-world entity to provide data originating from a second real-world entity. In another embodiment, the request may be triggered at runtime by a change in the data value of the second digital representation. In this context, runtime refers to the time during which the real world component is operated and data is generated that causes the data value in the second digital representation to change.

The analyzer module of the second real-world entity evaluates a set of predefined mapping policies. Thus, each mapping policy is associated with a target model template. The target model template indicates the structure and semantics of the target data model to which the corresponding mapping policy may transform the corresponding source data model. The analyzer determines a mapping similarity metric for each mapping policy based on the structural and semantic similarity of the respective data model of the first and second digital representations to the corresponding target model template. In more detail, each mapping policy is associated with a set of mapping rules that reflect the potential target data models that may be generated using the rules. For each mapping policy, a corresponding mapping rule is applied to the one or more source data models of the second representation, thereby generating a corresponding target model template.

The similarity module determines a similarity measure for each target model template by evaluating the structure and semantics of the respective target model template using the structure (i.e., expected structure to which the data model needs to be mapped) and semantics of the one or more data models of the first digital representation. After this evaluation step, the analyzer may provide the mapped information which one of the mapping policies may result in allowing exchange of data thereby minimizing errors and information loss.

In one embodiment, the analyzer may determine partial similarity measures for different sub-models of the data model. For example, a particular mapping strategy may result in a higher similarity measure for a subset of submodels. However, this particular mapping strategy may not be applicable to other submodels at all. In this case, the analyzer may generate multiple target model templates for different sub-models, where each target model template is based on the rules of a different mapping strategy. The determined mapping similarity measure provides a quantitative measure of the similarity between the one or more data models of the first and second digital representations and the metadata of the respective target model template for the structure and/or characteristic, thus providing a measure of the applicability of the respective mapping strategy to generate an appropriate mapping for performing the desired model transformation. The data model has a particular structure, with the leaves of the model structure having metadata such as, for example, the names of the leaf elements, measure units, semantic annotations, and the like. The similarity measure may be determined based on similarity of structures of the respective data models alone, similarity of certain metadata of the characteristics (leaves) alone, or a combination thereof, depending on the corresponding mapping policy to be evaluated. The mapping module of the second real-world entity generates a mapping between the format of the first digital representation and the format of the second digital representation. To generate the mapping, the mapping module selects at least one mapping policy from a predefined set of mapping policies based on a previously determined mapping similarity metric. The predefined set of mapping policies may be part of the mapping module, or may be stored in the second real world entity, or may even be stored on the outside of a remote data storage device that is accessible via a digitally represented interface.

The predefined set of mapping policies includes at least two of the following policies:

-a structure preserving mapping strategy adapted to generate a mapping when the structure of the first digital representation is similar to the structure of the second digital representation, which structure of the second digital representation is similar to the corresponding mapping model template of said mapping strategy. For example, a structure preserving mapping strategy may be selected when the structure of the first numerical representation contains the same number of models resulting in a high structural similarity score, and when leaves of the source model have a correspondence in leaves of the target model template. If the model contains even the same number of leaves, an even higher structural similarity score can be determined, resulting in the selection of the strategy.

-a minimization of the mapping strategy adapted to generate a mapping of the second digital representation data model to a minimum number of the first digital representation data models. For example, if the structure of the target digital representation has the least number of models (e.g., only one model), the policy may be selected in accordance with its target model template to aggregate all the characteristics of the multiple models from the second digital representation into a single model of the first digital representation without any additional structure.

-a maximization mapping strategy adapted to generate a mapping of the second digital representation data model to a maximum number of first digital representation data models. This policy is a policy corresponding to the previous policy in that the structure of the target number representation has the largest number of models (e.g., one model per model leaf). That is, each leaf element of the second digital representation model is mapped to a separate model of the first digital representation in accordance with the target model template of the mapping strategy.

-a name-based heuristic mapping strategy adapted to generate a mapping to the first digital representation based on a domain-specific, customizable heuristic with respect to the naming of the elements in the second digital representation. To select this strategy, the similarity between model elements is detected at the metadata level of the model properties. For example, source model elements beginning with the same character sequence may be mapped to corresponding target models. Based on these similarities, a target model template may be created and used to evaluate a mapping similarity measure between the target model template and the first digital representation.

-a semantic reference based mapping policy adapted to generate a mapping to the first digital representation based on a heuristic on semantic references assignable to elements in the second digital representation. To evaluate the policy, the analyzer identifies similarities between model elements based on the semantic references of the annotated model elements. Such annotations point to classifications that allow similar source model elements to be grouped into respective target models according to the corresponding target model templates.

One skilled in the art can add other mapping policies to the predefined set of mapping policies.

The mapping module performs the mapping at an instance level of the mapping by executing the selected mapping policy. That is, one or more source data models associated with the requested data of the second digital representation are correspondingly mapped to corresponding one or more target data models of the first digital representation.

After generating the mapping in accordance with the selected policy, the requested data is provided to the first real-world entity via the mapping in the format of the first digital representation.

The analyzing and generating steps of the disclosed method may be iteratively repeated to subsequently attempt a plurality of mapping strategies until a mapping strategy is identified that produces the best mapping between the source format and the target format. The optimal mapping is defined by showing the highest correspondence between the source model and the target model. In one embodiment, the predefined mapping strategy is part of a knowledge base, and after each mapping generation, the knowledge base is optimized by using a machine learning method that incorporates mapping knowledge learned from previously generated mappings. By means of the optimized knowledge base, it is facilitated to select the best mapping strategy when the mapping situation corresponds to a situation that has been learned earlier.

In one embodiment, the mapping resides in a separate mapping model that is independent of the different formats used for the digital representation. The retained mapping may be adjusted if a change in the format of the first digital identifier or the second digital representation is detected. In other words, the separate mapping model decouples the source (original) digital representation and the target (transformed) digital representation, allowing simple adjustments in case the source format and/or the target format evolves.

In one embodiment, customization input may be received for the persisted mapping, and the persisted mapping may be adjusted in accordance with the customization input. This allows the retained mapping to be enhanced later by domain-specific knowledge.

In one embodiment, the generated mapping may be bi-directional and adapted to be applied to a export request from the first digital representation to push data of the first digital representation to the second digital representation.

In one embodiment, a request is received from a first digital representation to import data of a second digital representation into the first digital representation as the first digital representation. This embodiment may be considered a pull mode, where a first entity queries a second entity for specific data.

In another embodiment, the request may be triggered at runtime by a change in the data value of the second digital representation. This may result in automatic re-execution of the mapping as changed. The second digital representation may then inform the first digital representation of the change and provide corresponding update data. This embodiment can be seen as a push mode, where the second entity is aware of the data of interest to the first entity and automatically provides notification of any changes to the data that the first entity has "subscribed" earlier by initiating a corresponding request.

In one embodiment, a computer program product is provided with instructions which, when loaded into a memory of a computing device and executed by at least one processor of the computing device, perform the method steps of the computer-implemented method according to any of the preceding claims. For example, the computer program is loaded into a memory component of a second real world entity and executed by one or more processors of the entity.

In one embodiment, a computer system is provided for interoperable data exchange between a first real-world entity and a second real-world entity. Both real world entities are connected to the same communication network. The first and second real-world entities have first and second digital representations, respectively. Each digital representation is a virtual entity that replicates data, structure, and functionality associated with any of the real-world entities. The first digital representation and the second digital representation have different formats.

The computer system includes an interface to receive a request to provide data of the second digital representation to the first digital representation and to provide the requested data to the first real-world entity in a format of the first digital representation via the mapping.

Further, an analyzer module of the system determines a similarity measure between the metadata of the structure and/or characteristics of the one or more data models of the first digital representation and the metadata of the structure and/or characteristics of the one or more data models of the second digital representation by applying the similarity measure to the data models.

A mapping module of the system generates a mapping between the format of the first digital representation and the format of the second digital representation. To this end, it first selects a mapping policy from a predefined set of mapping policies based on a similarity measure. Second, it maps one or more data models associated with the requested data of the second digital representation to a corresponding one or more data models of the first digital representation by executing a selected mapping policy.

The computer system is also configured to perform the functions as disclosed in the context of the disclosed method.

Other aspects of the invention are realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as described.

Drawings

FIG. 1 includes a block diagram of a computer system for interoperable data exchange between two real-world entities, according to an embodiment;

FIG. 2 is a simplified flow diagram of a computer-implemented method for interoperable data exchange between two real-world entities, according to an embodiment;

FIGS. 3A and 3B illustrate detailed implementation examples for data exchange between two entities, in accordance with various embodiments;

FIG. 4 is a simplified flowchart of the steps of generating a mapping between different formats of two real world entities, according to an embodiment;

5A-5E illustrate concepts of various mapping policy examples according to various embodiments;

6A-6D illustrate specific mapping examples through the use of various mapping policies;

FIG. 7 is a diagram illustrating an example of a general-purpose computer device and a general-purpose mobile computer device that may be used with the techniques described herein.

Detailed Description

Fig. 1 is a block diagram 10 of an example embodiment including a computer system 100 for interoperable data exchange between a first real-world entity 101 and a second real-world entity 102. Fig. 2 is a simplified flow diagram of a computer-implemented method 1000 for interoperable data exchange between two real-world entities, according to an embodiment. The method 1000 of fig. 2 is performed by a computer system 100 associated with a second real-world entity 102. The description of fig. 1 refers to the method steps illustrated in fig. 2. For this reason, reference is made to the reference numerals of fig. 1 and 2 in the following description.

Both real world entities are connected to the same communication network. For example, the real world entities may be two companies, each of which operates its own intranet. Communication between real world entities is typically via a wide area network such as, for example, the internet. Such communication within a real-world entity may be based on a proprietary data model and/or a proprietary communication protocol, which is referred to herein as a proprietary format of such real-world entity. The first and second real-world entities have a first and second

digital representation

111, 112, respectively. Such digital representations are often referred to as digital twins of entities, as they are virtual entities that replicate the data, structure and functionality associated with either of the real-world entities 101, 102. It should be noted that a real-world entity may include multiple models that may encompass different aspects of the entity, such as, for example, operational data, engineering data, and so forth. Digital twins of different real world entities typically have different formats F1, F2, as each entity uses its own (typically proprietary) data model and communication protocol. In the following, the term "entity" is used as an abbreviation for the term real world entity.

In this example, the first entity 101 receives a query from the application 200. The application 200 may be any application that is interested in receiving data provided by the first entity and/or the second entity. For example, the application 200 may be an application that manages the maintenance of certain devices (e.g., DEV1) operating within the intranet of the second entity 102. The application may require actual operational data of the device as well as historical data associated with the device as input to the predictive maintenance algorithm. The first entity 101 may only have historical data available in its own digital representation 111, which may be sent directly to the application as a response to the query. However, the first entity does not have information in its own digital representation 111 about the actual device operation data of the device DEV1 operated by the second entity 102. The digital representation 112 may provide such current operation data D1 of the device DEV 1. For example, the device DEV1 may be a device (e.g., a controller or sensor) of an automation system operated by the second entity 102 via the edge 122 on the private internet of things platform. Device DEV1 may automatically push its actual operating data to the digital representation 112. Unfortunately, the format F2 of the digital representation 112 of the second entity 102 is different from the format of the first representation. Thus, because the data model DM1 of the digital representation of the first entity 101 is different from the data model DM2 of the digital representation of the second entity, the second entity cannot understand any request R1 sent by the first entity 101 to the second entity 102 via the appropriate interface to the wide area network.

In order to be able to respond to the request R1, the second entity 102 has to perform a corresponding mapping that allows mapping said data D1 to data D1' to be transformed into a format that the first entity 101 can understand. The mapping function is performed by a computer system 100 associated with the second entity 102. In this example, computer system 100 is shown as an integral part of the second entity. However, it should be noted that the system 100 may also operate outside the physical intranet of the second entity (e.g., by an external service provider in the form of a remote service). In the case where the computer system 100 is operated by the second entity 102 itself, the digital representation 112 is advantageously an integral part of the computer system 100. However, in the remote service scenario, the digital representation 112 is advantageously stored within the physical network of the second company 102, but the computer system 100 may access the digital representation via a corresponding interface.

Once the second entity 102 has received 1100 the request IR1 for the data D1, the data D1 being provided by the second digital representation 112 to the first digital representation 111, the computer system 100 generates 1300 an appropriate mapping M1 to provide the requested data D1 to the first entity 101 via said mapping M1 in the format F1 of the first digital representation 111 (as data D1'). In more detail, the computer system 100 has an analyzer module 142 to evaluate 1200 a predefined set of mapping policies 133 and finally select 1320 one or more appropriate mapping policies to generate 1300 the mapping. Each mapping policy 133 is associated with a target model template 133-T. The target model template describes a target model to which the source model can be mapped by a corresponding mapping strategy. The mapping similarity measures SM1 to SMn for each mapping policy 133 are determined based on the structural and semantic similarity of the respective data models DM1, DM2 of the first and second digital representations to the corresponding target model template 133.

In more detail, each mapping policy 133 is associated with a set of mapping rules that reflect the potential target data models that may be generated using the rules. Such mapping rules are now applied to the one or more source data models DM2 of the second entity 102. That is, for each mapping policy 133, the corresponding mapping rule is applied to the one or more data models DM2 of the second representation 112, the one or more data models DM2 being related to the request data D1, thereby producing a corresponding target model template 133-T for each mapping policy. For some mapping policies, when generating the target model template, the similarity of the individual model elements of the first digitally represented data model DM1 may be evaluated (e.g., their names are evaluated for name-based policies as explained later in the context of fig. 5D). This similarity between data elements can be expressed as an element similarity measure.

The similarity module SM determines the similarity measures SM1 to SMn (i.e. the values representing the similarity) for each target model template by evaluating the structure (i.e. the expected structure to which the one or more data models DM2 need to be mapped) and semantics of the respective target model template using the structure and semantics of the first numerically represented one or more data models DM 1. After this evaluation step, the analyzer 142 may provide information of the following mapping policies, i.e. which mapping policies may result in mappings that allow the data D1 to be exchanged without any errors or losses. Multiple mapping strategies may result in the same similarity measure. In such a case, the computer system may determine any of such policies.

The analyzer may also determine partial similarity measures for different sub-models of the data models DM1, DM 2. That is, DM2 may include multiple submodels for which a particular mapping strategy results in a high similarity metric. However, this particular mapping strategy may not be applicable at all to the other submodels of DM 2. In this case, the analyzer may generate multiple target model templates for different sub-models, where each target model template is based on the rules of a different mapping strategy. That is, the analyzer may try various mapping policies for different sub-models that may result in a higher similarity metric than applying a single mapping policy to the entire data model DM 2.

The determination of which mapping policies are to be used by the computer system 100 is ultimately made by the mapping module 132. The mapping module 132 generates a mapping M1 between formats F1 and F2. First, the mapping module selects at least one mapping policy from a set of predefined mapping policies 133 based on the determined similarity measures SM1 to SMn. In a simple example, the analyzer provides a set of similarity metrics, where one of the metrics clearly indicates the maximum value of a particular mapping policy. In this case, the mapping module simply selects the policy associated with the highest similarity metric. In the case where multiple policies are evaluated with the same high similarity metric, the mapping module may simply select any of these policies, as they appear to be equally applicable to mapping generation. In the case where the analyzer provides multiple similarity measures for various sub-models, where such similarity measures relate to different mapping strategies of one or more of the same source models, the mapping module selects multiple mapping strategies. Generally, the mapping strategy is selected 1320 by the mapping module such that the overall similarity of the mapping between the source model and the target model is maximized. In other words, the mapping strategy that results in the model structure with the highest similarity of the model elements to the target model is selected by the mapping module. Once the one or more mapping policies are selected, the mapping module 132 maps 1340 the one or more data models DM2 associated with the requested data D1 of the second digital representation 112 to the corresponding one or more data models DM1 of the first digital representation by executing the one or more selected mapping policies. In other words, the actual mapping between data models is done at the model element instance level. This final map 1340 allows defining mapping links between the model elements of DM1 and DM 2. Once the mapping is generated, the computer system 100 may provide 1400 the transformed data D1' in the format F1 of the first representation to the first entity in a format understood by the first representation 111.

Now, the first representation has all the data needed to respond to the query application 200. It should be noted that the explanation of the scenario disclosed in the context of fig. 1 is only that the request R1 is sent by the first entity in response to an application query. Other embodiments are possible, such as the embodiment illustrated in fig. 3B for example, where the request is actually triggered by the second entity itself in response to detecting a change in the structure or data of the second representation 112. The disclosed mechanism allows two real world entities having different formats to exchange data without any human interaction. Data exchange is reliable and robust (i.e., the likelihood of data exchange errors is low) due to the flexible selection of mapping strategies for dynamically generated response maps in view of the actual data models of the different formats quickly.

Fig. 3A illustrates a particular embodiment 301 having two companies A, B as real world entities that exchange data between digital twins (i.e., their respective digital representations) representing their respective IoT platforms. Each company is operating its own IoT platform. In company a, devices connect to the IoT platform via edge nodes to provide device specific data for company a's digital twin. In general, the purpose of edge computing is to bring intelligence, analysis, computation, communication, etc. very close to and increasingly into the world, such as programmable logic controllers and other more powerful and smaller devices at the edge, and after analysis, etc. into the appropriate system or cloud. The device data may be static data, such as, for example, a serial number or a device type, and may also include operational data, such as sensor values or other technical parameter values that reflect the internal state of the device. Company B may run various application systems such as, for example, engineering systems and maintenance systems linked to company B's IoT platform. The engineering system may provide engineering data related to the equipment of company a to the digital twin of company B via an engineering server. Also, a maintenance application of the maintenance system may provide data associated with maintenance of the device. For example, although the two digital twins use different formats, by enabling data exchange between company a and company B's digital twins, the data available in company B's digital twin's content may be automatically enriched with operating device data provided by company a's digital twin.

Fig. 3B illustrates a push scenario 302 in which company a may actively push data from its own original digital twin to company B to update company B's digital twin. The overall scenario is similar to the embodiment described in fig. 1 and 3A. However, company a's IoT platform in this embodiment has a monitoring module configured to detect changes in structure or data values relative to its original digital twin's data model DM. In the push embodiment, the request (see request R1 in fig. 1) triggering the mapping and transformation step is not received from company B, but is initiated by the monitoring module when such a change is detected. Assume that the mapping between the original digital twin of a and the digital twin of B persists in the IoT platform of a as a separate mapping model independent of the format of the two digital twins. In the event that a change in the structure of the original twin of company a is detected, then the persisted mapping model, which has been applied to the mapping rules of the original digital twin, is adjusted. It should be noted that the monitoring module may also be configured to receive such a change of the digital twin of B via the corresponding interface. In this case, the mapping request may also be triggered by the detection of a structural change of B. For example, the adjustment to the mapping rules may be driven by an artificial intelligence component AI configured to learn new mappings over time as changes occur. This knowledge can then be applied to adjust 1 the previously persisted model rules according to the detected changes.

In an alternative embodiment, the mapping may be adjusted, for example, by receiving customization input for the persisted mapping model via a human machine interface of company a's IoT platform that allows a user to edit and adjust 1 the persisted mapping, for example, based on the respective domain knowledge.

The adjusted mapping is interpreted by the analyzer 2 and applied to the 3 company a's digital twin (i.e., the second representation) to generate an adjusted target model template, and the corresponding similarity measures are re-determined. The mapping module may then select one or more mapping strategies again based on the re-determined similarity measures, eventually completing 4 the transformation (mapping) as disclosed in fig. 1. The data of the digital twin of company a is now available in a format compatible with the digital twin of company B and can be provided to company B for updating in a push operation 5, whether a structural change of company a or B has occurred.

Alternatively or in addition to detecting a structural change, the monitoring module may detect a change in the data (i.e., values) of the digital twin provided by the device to company a at runtime. In this case, the request may also be triggered by a value change. When a change in the data value is detected, the mapping rules need not be adjusted. Instead, the existing mapping rules may be re-executed as changed, and the digital twin data of company B is notified of the change when updated data is provided to company B.

FIG. 4 provides an additional view 400 of the steps leading to generating a mapping between the data models of two entities. Therefore, the steps within the dashed box are considered optional steps. As explained previously, generating the mapping begins with analyzing a data model of the digital twin, which provides input to the intended transformation, and the digital twin is the output (target) of the transformation. One or more mapping strategies are selected based on a pre-existing knowledge base that includes domain knowledge related to the two digital twin DTs. The relevant mapping rules may be stored as templates for future mappings between corresponding data models. Finally, the selected last strategy is executed, resulting in a transformed digital twin. Optionally, the computer system may allow a user to edit mapping rules via a human machine interface, and augment such rules by appending manual rules, which may further refine the final mapping, thereby enhancing the transformed digital twin.

In the following description of fig. 5A-5E, various examples of mapping strategies are discussed, wherein the left side of the arrow symbolizing the respective format transformation illustrates the one or more source data models of the second digital representation, and the right side of the arrow illustrates the one or more target data models of the first digital representation. It should be noted that the predefined set of mapping policies comprises at least two of said mapping policies, one or more of which are finally selected by the mapping module from the predefined set of mapping policies.

FIG. 5A illustrates an example of a structure preserving mapping policy 501, the structure preserving mapping policy 501 being adapted to generate a mapping according to a corresponding target model template when the structure of the first digital representation is similar to the structure of the second digital representation. When the analyzer module evaluates the structure retention policy, the relevant mapping rules are applied to the source data model. In example 501, the source data model includes two sub-models, where the upper sub-model includes two leaf elements and the lower sub-model includes one leaf element. Thus, a target model template is generated, as shown in the right diagram, which fully preserves the structure of the one or more source data models. The object model template is then compared with the structure of one or more object models of the first entity (not shown here). If the structure of the generated target model template is similar to the structure of one or more target models, the structure retention strategy may be a good candidate for generating the expected mapping between the respective (digital twin) formats. However, to assess the degree of similarity, the analyzer also takes into account the semantics of the leaf elements. Even in the case of perfect matches at the structure level, it is also possible to determine only a low similarity measure if there is no similarity at the semantic leaf element level. However, if there is also high similarity between the semantics of the leaf elements, the analyzer determines a high similarity measure for the policy.

For example, a digital twin of a drive may include three models in the source data model (e.g., one model including operational data, one model containing links to document material, and one model describing maintenance data). The source model may be transformed into a digital twin target format in which the source model structure is maintained such that the target digital twin also contains exactly three models whose content is the same as that of the original digital twin. The way in which the source and target models and their contents are modeled may vary depending on the concept of the target format. For example, different attributes may be used to describe the nature of the content.

FIG. 5B illustrates an example of a minimization mapping strategy 502, the minimization mapping strategy 502 being adapted to generate a mapping of a second digital representation data model to a minimum number of first digital representation data models in accordance with a corresponding target model template. In example 502, the same source data model as in FIG. 5A is used. However, it is contemplated that the format of the object model includes only a single sub-model with three leaves. That is, the format of the first representation includes a minimum number of models with a flat list of leaf elements (flat list). To evaluate the minimization policy, the analyzer applies the mapping rules associated with the mapping policy to one or more source data models and generates a target model template having only one sub-model and a flat list of leaf elements. The object model template is then again compared to the expected object model and a corresponding similarity measure is determined.

For example, a digital twin with a second representation comprising three models needs to be transformed into a target digital twin with one model aggregating all the features from the three source models without any additional structure. This strategy is useful, for example, where the source digital twin use case is very different from the target digital twin use case. In general, in such a scenario, the structure of the source digital twinning does not typically add value to the target digital twinning.

Fig. 5C shows an example of a maximization mapping strategy 503, the maximization mapping strategy 503 being adapted to generate a mapping of the second digital representation data model to the maximum number of first digital representation data models in accordance with the corresponding target model template. The maximization strategy 503 may be viewed as the inverse of the minimization strategy 502 of fig. 5B. In example 503, the same source data model as in FIG. 5A is used. However, it is contemplated that the format of the object model includes a single sub-model for each leaf element. That is, the format of the first representation includes a maximum number of models corresponding to a plurality of leaf elements of the one or more source data models. To evaluate a maximization policy, the analyzer applies a mapping rule associated with the mapping policy to one or more source data models and generates a target model template having as many sub-models as leaf elements. The object model template is then again compared to the expected object model and a corresponding similarity measure is determined.

This strategy may be useful, for example, where a target digital twin is used as the basis for many models envisioned by engineers. Typically, the mapping generated based on the maximization mapping strategy requires further customization later in the mapping process by a user or a machine learning algorithm.

FIG. 5D illustrates an example of a name-based heuristic mapping policy 504, the name-based heuristic mapping policy 504 adapted to generate a mapping to the first digital representation based on a domain-specific, customizable heuristic with respect to naming of elements in the second digital representation in accordance with a corresponding target model template. In example 504, the mapping rule used to generate the target model template analyzes the source model with respect to leaf model elements, which are related to element naming. For example, there are two model leaf elements that include "a. The mapping rules implement the following assumptions: leaf elements showing such name-based similarity may be grouped into corresponding sub-models of the target model template. In this example, the sub-model "a" is generated using the leaf element "a. For a leaf element named "b." in the source model, a corresponding sub-model "b" is generated in the target model template with the corresponding leaf element "b.". In a next step, a similarity measure of similarity between the generated target model template and the one or more actual data models of the first digital representation is determined.

For example, there may be a rule like "model elements of a source data model whose name starts with 'motor" always refer to the' motor 'model assigned to one or more target data models "or" source data model elements whose name contains a string "service" always map to a' maintenance model "or" source model elements whose name is a serial number "always map to a 'identification' model (if present). Different sets of such rules may be added to the mapping rules as custom inputs received from engineers and then loaded into the mapping module at runtime.

Fig. 5E illustrates an example of a semantic reference based mapping policy 505, which semantic reference based mapping policy 505 is adapted to generate a mapping to a first digital representation based on a heuristic on semantic references assignable to elements in a second digital representation model according to a corresponding target model template. In other words, the digitally twin target model template of the first entity is generated based on heuristics with respect to semantic references to model elements of one or more data models assigned to the second digital representation (i.e., the source digital representation). In example 505, the model element of the first submodel has the annotation "x …". Further, a second leaf element of the sub-model has the same annotation "x. The mapping rules associated with the mapping policy generate a corresponding sub-model in the target model template that groups all model elements annotated as "x. Example 505 further illustrates a mapping rule for a semantic reference-based mapping policy, where model leaf elements of a source model are annotated with "y..", but there is no corresponding annotation for sub-model elements of the source model. In this case, the mapping rule generates a corresponding submodel node with the annotation "y.." in the target model template and groups all model leaf elements with the annotation "y.." under that submodel. For example, model elements in a source/target model may be annotated with semantic references containing links to a global dictionary (e.g., an ecalas), thereby appending semantics to the elements. From these semantic references, the elements are grouped into corresponding sub-models of the target model template. Again, the similarity of the generated target model template to the target digital twin (first representation) is determined.

Finally, after evaluating all available mapping policies in the predefined set of mapping policies, the system may select at least one of the evaluated policies for the actual data transformation. Advantageously, the mapping strategy with the highest similarity measure is selected. Where multiple mapping policies produce the same similarity metric value, any of such policies may be selected (e.g., randomly). An example of selecting a mapping strategy mix is described in more detail in the context of FIG. 6D.

Figure 6A illustrates an example 601 in which a digital representation reflecting a digital twin of a drive in the format of entity a is transformed into a digital twin of entity B reflecting the drive in the format of entity B. The source data model for a is shown above with an arrow 504 representing a selected mapping policy (name-based heuristic mapping policy). For example, evaluation of mapping policies is discussed only by looking at structure retention policies and name-based heuristic mapping policies. When the target model template is generated for the structure preserving strategy, the "motor model" of the source data model will indeed map to the "motor model" of the target digital twin. However, for the remaining sub-models "engineering model" and "operational model", the target model template may not resemble the target data model of B. Thus, the similarity metric may be below 50% since only two fifths of the source's model leaf elements may map to the target's corresponding elements.

When evaluating a name-based strategy, the mapping of the "motor model" is almost as good as the mapping of the structure preserving strategy. The corresponding mapping rule is to group all model elements containing "motor" as part of their name into the corresponding "motor model" of the target. No common named elements are found for the remaining leaf elements "serial number", "maximum frequency", and "voltage". The rules of the mapping policy deal with this situation by grouping all elements that do not have a common named part into one sub-model "others". The submodel performs like a collector for all elements whose names have no common strings with other names. The target model template generated based on this strategy has a very high (e.g., 100%) match with the target digital twin data model of B. Thus, the mapping module selects the name-based mapping policy 504 and performs the mapping for transforming the source format to the target format. More generally, the similarity measure may be calculated by different algorithms and different implementations. A common trait of these algorithms is that they compare two elements or two (structured) groups of elements based on their characteristics (e.g., name, location within the structure, other types of metadata) and determine an ordinal score, e.g., a percentage value. The higher the similarity, the higher the score returned.

FIG. 6B illustrates an example 602 in which a semantic reference based mapping policy 505 is selected. When evaluating structure-preserving strategies, the source and target formats are indeed similar when comparing only the pure structure of the model. On both sides, there are three sub-models, two of which have two leaf elements and one of which has a single leaf element. However, when the semantics of the source model leaf elements and the target model leaf elements are now examined, there is no match at all. In other words, the groupings of source models cannot be mapped to the groupings of target models. Thus, regardless of the initial similarity when looking at the model structure alone, the similarity measure of the structure retention policy in this example may be very low, e.g., "0", depending on the implementation of the similarity score. The similarity measure (i.e., a value or score reflecting the degree of similarity) can be calculated in various ways by those skilled in the art. For example, the score may consider the percentage of all matching elements at the model element leaf level, or it may consider similarities related to portions of one or more data models.

In this example 602, some source model leaf elements have semantic annotations indicating references to some standard classifications. The "maximum frequency" annotation "0173-1 #02-AAE229# 004" indicates that there is a reference to the model with the "AAE" classification. The same is true for the "voltage" annotation "0173-1 #02-AAE229# 005". As a result, the mapping rules of the semantic-reference-based mapping policy 505 group such model leaf elements into an "AAE model" of the target model template. Likewise, the source leaf element "motor temperature" is assigned to the "AAG model" of the target model template by evaluating the annotation "0173-1 #02-AAG321# 002" of the corresponding source leaf element using the corresponding mapping rule. The correspondence mapping rule in this example analyzes semantic references of string components corresponding to a predefined target model. For example, such a predefined object model may be an object of a leaf element, where a portion of the semantic reference string indicates an association of the corresponding model element with a certain technical specification (e.g., AAE, AAG, etc.). Similar to name-based mapping policies, semantic-reference-based policy source leaf elements without annotations may be grouped into "other" sub-models of the target model template. When the generated target model template is now compared to the digital twin format of B, there is a 100% match (i.e., similarity measure ═ 1). That is, from the two mapping policies discussed, the mapping module explicitly selects the semantic reference-based mapping policy that yields the highest similarity metric.

Fig. 6C illustrates an example 603 in which the maximization mapping strategy 503 is selected. The numerical representation of source a (i.e., the corresponding data model) is the same as that in fig. 6A. Assuming that all other mapping policies in the predefined set of mapping policies result in a very low similarity measure, the mapping rules of the maximization policy may provide a fallback mapping policy to serve as an intermediate step for model mapping between different digital twins formats. In example 603, each source leaf element is simply assigned to a separate sub-model in the target model template as a single target leaf element. Such single model leaf elements need to be merged into the corresponding sub-models at a later point in time. The merging step may be performed in response to receiving corresponding mapping input from a human domain expert, or may be performed by a machine learning algorithm, a custom application, or other suitable set of rules. The mapping module may select a maximize mapping strategy if all other mapping strategies fail to generate a target model template having a similarity metric indicating substantial similarity to the target format of the digital twin of the target entity. In this case, a policy is selected to generate an intermediate format B' that serves as a basis for further customizing the mapping rules to improve future automation mappings that may ultimately be used to map the source model to the data model of the target entity.

Fig. 6D illustrates an example 604 in which two mapping policies are partially applied by combining the maximization mapping policy 503 with a second mapping policy (e.g., a structure preserving mapping or a name-based mapping 504) to generate a target model template. In an example, the evaluation of 604 name-based policies results in a 100 "similarity measure for" motor models, "while the overall similarity measure for name-based policies is lower (e.g., 40% since only two-fifths of the model leaf elements can be mapped). In this case, the mapping module may still select a mapping strategy for a portion of the digital twins that determine a high degree of similarity for one or more sub-models. For the remaining nodes, a maximization strategy 503 may be selected to generate an intermediate format B' as a basis for further customization, as explained in fig. 6C.

FIG. 7 is a diagram illustrating an example of a general-purpose computer device 900 and a general-purpose mobile computer device 950 that may be used with the techniques described herein. Computing device 900 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The general purpose computer device 900 may correspond to the computer system 100 of fig. 1. Computing device 950 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart phones, and other similar computing devices. For example, the computing device 950 may be used as a GUI front-end for user-customized mapping rules. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed in this document.

Computing device 900 includes a processor 902, memory 904, a storage device 906, a high-speed interface 908 connecting to memory 904 and high-speed expansion ports 910, and a low-speed interface 912 connecting to low-

speed buses

914 and 910 and storage device 906. Each of the

components

902, 904, 906, 908, 910, and 912, are interconnected using various buses, and may be mounted on a common motherboard or in other manners as appropriate. The processor 902 can process instructions for execution within the computing device 900, including instructions stored in the memory 904 or on the storage device 906 to display graphical information for a GUI on an external input/output device, such as display 916 coupled to high speed interface 908. In other implementations, multiple processing units and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Further, multiple computing devices 900 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a blade server bank, or a processing device).

Memory 904 stores information within computing device 900. In one implementation, the memory 904 is a volatile memory unit or units. In another implementation, the memory 904 is a non-volatile memory unit or units. The memory 904 may also be another form of computer-readable medium, such as a magnetic or optical disk.

The storage device 906 can provide mass storage for the computing device 900. In one implementation, the storage device 906 may be or contain a computer-readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. The computer program product may be tangibly embodied in an information carrier. The computer program product may also contain instructions that, when executed, perform one or more methods, such as the methods described above. The information carrier is a computer-readable medium or machine-readable medium, such as the memory 904, the storage device 906, or memory on processor 902.

The high speed controller 908 manages bandwidth-intensive operations for the computing device 900, while the low speed controller 912 manages lower bandwidth-intensive operations. Such allocation of functions is exemplary only. In one implementation, the high-speed controller 908 is coupled to memory 904, display 916 (e.g., through a graphics processor or accelerator), and high-speed expansion ports 910, which may accept various expansion cards (not shown). In this implementation, low-speed controller 912 is coupled to storage device 906 and low-speed expansion port 914. The low-speed expansion port may include various communication ports (e.g., USB, bluetooth, ethernet, wireless ethernet) that may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device (such as a switch or router), for example, through a network adapter.

As shown, the computing device 900 may be implemented in a number of different forms. For example, it may be implemented as a standard server 920 or multiple times in a group of such servers. It may also be implemented as part of a rack server system 924. Additionally, it may be implemented in a personal computer such as laptop computer 922. Alternatively, components from computing device 900 may be combined with other components in a mobile device (not shown), such as device 950. Each of such devices may contain one or more of

computing device

900, 950, and an entire system may be made up of

multiple computing devices

900, 950 communicating with each other.

Computing device 950 includes a processor 952, memory 964, an input/output device such as a display 954, a communication interface 966, and a transceiver 968, among other components. The device 950 may also be provided with a storage device, such as a microdrive or other device, to provide additional storage. Each of the

components

950, 952, 964, 954, 966, and 968, are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.

The processor 952 may execute instructions within the computing device 950, including instructions stored in the memory 964. A processor may be implemented as a chipset of chips that include separate analog and digital processing units and a plurality of analog and digital processing units. For example, the processor may provide coordination of the other components of the device 950, such as control of user interfaces, applications run by device 950, and wireless communication by device 950.

The processor 952 may communicate with a user through the control interface 958 and the display interface 956 coupled to a display 954. The display 954 may be, for example, a TFT LCD (thin film transistor liquid Crystal display) or OLED (organic light emitting diode) display or other suitable display technology. The display interface 956 may comprise appropriate circuitry for driving the display 954 to present graphical and other information to a user. The control interface 958 may receive commands from a user and convert them for submission to the processor 952. In addition, an external interface 962 may be provided in communication with processor 952, so as to enable near area communication of device 950 with other devices. External interface 962 may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used.

The memory 964 stores information within the computing device 950. The memory 964 may be implemented as one or more of the following: one or more computer-readable media, one or more volatile memory units, or one or more non-volatile memory units. Expansion memory 984 may also be provided and connected to device 950 through expansion interface 982, which may include, for example, a SIMM (Single in line memory Module) card interface. Such expansion memory 984 may provide additional storage space for device 950, or may also store applications or other information for device 950. Specifically, expansion memory 984 may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, expansion memory 984 may serve as a security module for device 950, and may be programmed with instructions that permit secure use of device 950. In addition, secure applications may be provided via the SIMM card, as well as additional information, such as placing identifying information on the SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as the methods described above. The information carrier is a computer-or machine-readable medium, such as the memory 964, expansion memory 984, or memory on processor 952, that may be received, for example, over transceiver 968 or external interface 962.

Device 950 may communicate wirelessly through communication interface 966, which communication interface 966 may include digital signal processing circuitry as necessary. Communication interface 966 may provide for communications under various modes or protocols, such as GSM voice calls, SMS messaging, EMS messaging, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. Such communication may occur, for example, through radio-frequency transceiver 968. Additionally, short-range communication may occur, such as using a bluetooth, WiFi, or other such transceiver (not shown). In addition, GPS (global positioning system) receiver module 980 may provide additional navigation-related wireless data and location-related wireless data to device 950, which may be used by applications running on device 950, as appropriate.

Device 950 may also communicate audibly using audio codec 960, which audio codec 960 may receive verbal information from a user and convert it to usable digital information. Audio codec 960 may also generate audible sound for a user in a similar manner, such as through a speaker, e.g., in a handset of device 950. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.), and may also include sound generated by applications running on device 950.

The computing device 950 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a cellular telephone 980. It may also be implemented as part of a smart phone 982, personal digital assistant, or other similar mobile device.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software applications or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) monitor or an LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.

The systems and techniques described here can be implemented in a computing device that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), and the internet.

The computing device may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

A number of embodiments have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention.

In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other embodiments are within the scope of the following claims.

Claims

1. A computer-implemented method (1000) for interoperable data exchange between a first real-world entity (101) and a second real-world entity (102), both connected to the same communication network, the first and second real-world entities having a first digital representation (111) and a second digital representation (112), respectively, each digital representation being a virtual entity that replicates data, structure and functionality associated with either of the real-world entities (101, 102), wherein the first and second digital representations (111, 112) have different formats (F1, F2), the method being performed by at least one computing device of the second real-world entity (102), comprising:

receiving (1100) a request (R1) for providing data (D1) of the second digital representation (112) to the first digital representation (111);

evaluating (1200) a set of predefined mapping policies (133) by determining a mapping similarity measure for each mapping policy based on the structural and semantic similarity of the respective data model (DM1, DM2) of the first and second digital representations to the corresponding target model template (133-T), wherein each mapping policy is associated with a target model template;

generating (1300) a mapping (M1) between the format (F1) of the first digital representation and the format (F2) of the second digital representation by:

selecting (1320) at least one mapping policy (133-1, 501, …, 505) from the predefined set of mapping policies (133) based on the determined mapping similarity measure (SM 1-SMn);

mapping (1340) one or more data models (DM2) associated with the requested data (D1) of the second digital representation (112) to corresponding one or more data models (DM1) of the first digital representation by executing the selected at least one mapping policy; and

providing (1400) the requested data (D1) to the first real-world entity via the mapping (M1) in the format (F1) of the first digital representation.

2. The method of claim 1, wherein the request (R1) is associated with a data request of an application (200).

3. The method according to any of the preceding claims, wherein the predefined set of mapping policies (133) comprises at least two of the following policies:

a structure preserving mapping strategy adapted to generate a mapping according to a corresponding target model template when the structure of the first digital representation is similar to the structure of the second digital representation;

a minimization of mapping strategy adapted to generate a mapping of the second digital representation data model to a minimum number of first digital representation data models according to corresponding target model templates;

a maximization mapping strategy adapted to generate a mapping of said second digital representation data model to a maximum number of first digital representation data models in accordance with a corresponding target model template;

a name-based heuristic mapping policy adapted to generate a mapping to the first digital representation in accordance with a corresponding target model template based on a domain-specific customizable heuristic with respect to naming of elements in the second digital representation; and

a semantic reference based mapping policy adapted to generate a mapping to the first digital representation in accordance with a corresponding target model template based on heuristics regarding semantic references assignable to the elements in the second digital representation.

4. The method of any of the preceding claims, wherein the predefined mapping policy is part of a knowledge base, further comprising:

the knowledge base is optimized after each mapping generation by using a machine learning method that incorporates mapping knowledge learned from previously generated mappings.

5. The method of any of the preceding claims, wherein the mapping resides in a separate mapping model independent of the format (F1, F2), the method further comprising:

adjusting the retained mapping if a change is detected in the format of the first digital representation or the second digital representation.

6. The method of any of claims 5, further comprising:

receiving customization input for the persisted mapping; and

adjusting the retained mapping in accordance with the customization input.

7. The method of any preceding claim, wherein the request is received from the first digital representation.

8. The method of any of claims 1 to 6, wherein the request is triggered at runtime by a change in a data value of the second digital representation, and wherein generating the mapping comprises:

re-executing the mapping in accordance with the change; and

providing the requested data includes: notifying the first digital representation of the change.

9. A method according to any one of the preceding claims, wherein the generated mapping is bi-directional and is adapted to be applied to further requests from the first digital representation to push data of the first digital representation to the second digital representation.

10. A computer program product comprising instructions which, when loaded into the memory of a computing device and executed by at least one processor of the computing device, perform the method steps of the computer-implemented method according to any preceding claim.

11. A computer system (100) for interoperable data exchange between a first real-world entity (101) and a second real-world entity (102), both connected to the same communication network, the first and second real-world entities having a first digital representation (111) and a second digital representation (112), respectively, each digital representation being a virtual entity that replicates data, structure and functionality associated with either of the real-world entities (101, 102), wherein the first digital representation (111) and the second digital representation (112) have different formats (F1, F2), the computer system comprising:

an interface configured to receive a request (IR1) for providing data (D1) of the second digital representation (112) to the first digital representation (111) and to provide the requested data (D1) to the first real world entity (101) in a format (F1) of the first digital representation (111) via a mapping (M1);

a parser module (142) configured to evaluate a set of predefined mapping policies (133) by determining a mapping similarity measure for each mapping policy based on the structural and semantic similarity of the respective mapping data model (DM1, DM2) of the first and second digital representations and the corresponding target model template (133-T), wherein each mapping policy is associated with a target model template;

a mapping module (132) configured to generate a mapping (M1) between the format of the first digital representation (F1) and the format of the second digital representation (F2) by:

selecting at least one mapping policy from the set of predefined mapping policies (133) based on the determined similarity measures (SM 1-SMn); and

mapping one or more data models (DM2) associated with the requested data (D1) of the second digital representation (112) to corresponding one or more data models (DM1) of the first digital representation by executing the selected at least one mapping policy.

12. The system of claim 12, wherein the set of predefined mapping policies (133) comprises at least two of the following policies:

a structure preserving mapping strategy (501) adapted to generate a mapping according to a corresponding target model template when the structure of the first digital representation is similar to the structure of the second digital representation;

a minimization of mapping strategy (502) adapted to generate a mapping of said second digital representation data model to a minimum number of first digital representation data models in accordance with a corresponding target model template;

a maximization mapping strategy (503) adapted to generate a mapping of said second digital representation data model to a maximum number of first digital representation data models in accordance with a corresponding target model template;

a name-based heuristic mapping policy (504) adapted to generate a mapping to the first digital representation based on a domain-specific customizable heuristic with respect to naming of elements in the second digital representation, in accordance with a corresponding target model template; and

a semantic reference based mapping policy (505) adapted to generate a mapping to the first digital representation according to a corresponding target model template based on a heuristic on semantic references assignable to the elements in the second digital representation model.

13. The system of claim 12 or 13, wherein the mapping resides in a separate mapping model independent of the format (F1, F2), the mapping module being further configured to:

adjusting the retained mapping if a change in the format of the first digital representation or the second digital representation is detected.

14. The system of any of claims 12 to 14, wherein an import request is triggered at runtime by a change in a data value of the second digital representation, and wherein the mapping module is further configured to re-execute the mapping in accordance with the change; and the interface is configured to provide the requested data and to notify the first digital representation about the change.