阅读说明：本技术 用于自动化系统组件与多个信息源的可互操作通信的系统和方法 (System and method for interoperable communication of automation system components with multiple information sources ) 是由 S·马拉库蒂 J·施密特 P·朱林 于 2020-03-11 设计创作，主要内容包括：用于多个信息系统(201至20n)之间经由与物理装置的数字表示(111)关联的数字表示服务(S1,S2,Sn)的可互操作数据交换的计算机实现方法、计算机程序产品和计算机系统(100)。该系统具有：用于所述物理装置的数字表示服务(S1至Sn),其包括：接口(110),其用来接收对于装置相关数据的请求；管理模块(120),其配置成生成和更新装置的数字表示(111),数字表示配置成存储多个数据模型(DM1),其中每个所存储数据模型与特定信息系统(201至20n)关联；以及语义关系库(150),其存储来自不同信息源(201至20n)的数据模型的模型元素类型之间的语义关系。数字表示服务配置成：发现与信息系统(201至20n)关联的模型提供方(231至23n)；生成由信息源所提供的模型元素与数字表示的对应模型元素之间经由语义关系的映射；以及响应于该请求,按照该映射来执行至少两个信息系统之间的数据交换。(A computer implemented method, computer program product and computer system (100) for interoperable data exchange between a plurality of information systems (201 to 20n) via a digital representation service (S1, S2, Sn) associated with a digital representation (111) of a physical device. The system has: a digital representation service (S1 to Sn) for the physical device, comprising: an interface (110) to receive a request for device-related data; a management module (120) configured to generate and update a digital representation (111) of the apparatus, the digital representation configured to store a plurality of data models (DM1), wherein each stored data model is associated with a particular information system (201-20 n); and semantic relationshipsA repository (150) storing semantic relationships between model element types of data models from different information sources (201 to 20 n). The digital representation service is configured to: discovery and information system (201 to 20n) ) Associated model providers (231 to 23 n); generating a mapping between model elements provided by an information source and corresponding model elements of a digital representation via a semantic relationship; and in response to the request, performing an exchange of data between the at least two information systems in accordance with the mapping.)

1. A computer system (100) for interoperable data exchange between a plurality of information systems (201 to 20n) via a digital representation service (S1, S2, Sn) associated with a digital representation (111) of a physical device, wherein each information system is at least one of an information source and an information consumer related to data associated with the physical device, the digital representation (111) being a virtual entity that replicates the data of the physical device and data associated with a device lifetime, the system comprising:

at least one digital representation service (S1-Sn) for the physical device, the at least one digital representation service comprising:

an interface (110) to receive a request for device-related data;

a management module (120) configured to generate and update the digital representation (111) of the apparatus, the digital representation configured to store a plurality of data models (DM1), wherein each stored data model is associated with a particular information system (201-20 n); and

a semantic relation library (150) storing semantic relations between model element types of stored data models from different information systems (201-20 n); and

each digital representation service (S1-Sn) is configured to:

generating a mapping between model elements of a data model associated with at least two different information systems via the semantic relationships as defined in the semantic relationship library (150); and

in response to the request, data exchange between at least two information systems is performed in accordance with the generated mapping.

2. The computer system of claim 1, wherein the digital representation service further comprises:

a semantic description (140) of the digital representation (111) comprising a model class of interest for the digital representation (111);

and further configured to establish a new semantic relationship in the semantic relationship library (150) by:

discovering one or more model providers (231 to 23n), wherein each model provider is associated with one or more information systems (201 to 20 n);

obtaining, from the discovered one or more model providers (231 to 23n), semantic model class descriptions (231-1 to 23n-1) about the information provided by the respective one or more information systems (201 to 20n), wherein a particular model class description (231-1) provides semantic metadata related to one or more data models (DM21, DM22) of one or more corresponding information systems (201);

identifying a particular discovered model provider (232) having a particular model class description (232-1) that matches the model class of interest included in the semantic description (140);

adding a corresponding data model (DM22) as provided by the particular model provider (232) to the plurality of data models (DM1) if a data model (DM22) corresponding to the particular model class description is not included in the plurality of data models (DM 1);

deriving one or more model element types from the added data model;

receiving semantic relationships between the one or more model element types of the added data model and model element types of pre-existing data models from a user or from a technical specification to connect model elements from different information sources along the lifecycle of the apparatus.

3. The computer system of any of the preceding claims, wherein the digital representation service is further configured to:

processing model elements derived from the discovered information sources to manage the lifecycle of the digital representation using a state machine that reflects the lifecycle of the digital representation.

4. The computer system of any of the preceding claims, wherein the digital representation service is further configured to:

generating a graphical representation reflecting the semantic relationships between model element types for a query by a user.

5. The computer system of any of the preceding claims, wherein the digital representation service further comprises:

a configuration module adapted to switch between a copy mode in which accessed information source data is copied to the digital representation and a reference mode in which a reference to the accessed information source data is stored in the digital representation.

6. The computer system of claim 5, wherein the configuration module is further adapted to:

selecting a deployment mode for the digital representation, wherein the deployment mode for each data model of the digital representation can be chosen from any of: deployment of the data model on a cloud network, deployment of the data model to an edge, or deployment of the data model to a device.

7. The computer system of any of claims 5 or 6, wherein the configuration module is further adapted to:

activating a synchronization mode for the digital representation in which a data model associated with an information source associated with a first life cycle phase of the apparatus is synchronized with a data model associated with an information source associated with a second life cycle phase in that parameters of the first life cycle phase are loaded into parameters of the second life cycle phase.

8. A computer-implemented method (1000) for interoperable data exchange between a plurality of information systems (201 to 20n) via a digital representation service (S1, S2, Sn) associated with a digital representation (111) of a physical device (101), wherein each information system is at least one of an information source and an information consumer related to data associated with the physical device, the digital representation (111) is a virtual entity that replicates data of the physical device and data associated with a device lifetime, wherein the method is performed by a digital representation service associated with a particular digital representation of the physical device, wherein the digital representation service comprises a semantic relation library (150) storing semantic relations between model element types of stored data models from different information systems (201 to 20n), the method comprising:

receiving (1100) a request from an information consumer for data associated with the physical device;

generating (1500) a mapping between model elements of a data model associated with at least a requested information consumer and a corresponding information source via the semantic relationships as defined in the semantic relationship library (150) of the digital representation service; and

in response to the request, performing (1600) a data exchange between at least the requested information consumer and the corresponding information source in accordance with the generated mapping.

9. The method of claim 8, further comprising:

discovering (1200) one or more model providers (231 to 23n), wherein each model provider is associated with one or more information systems (201 to 20 n);

obtaining (1300), from the discovered one or more model providers (231 to 23n), semantic model class descriptions (231-1 to 23n-1) regarding the data provided by the respective one or more information systems (201 to 20n), wherein a particular model class description (231-1) provides semantic metadata related to one or more particular data models (DM21, DM22) of one or more corresponding information sources (201, 202);

comparing (1400) the resulting model class description with a model class of interest stored in a semantic description (140) of the digital representation service (S1);

if a particular discovered model provider (232) has a particular model class description (232-1) that matches the model class of interest included in the semantic description (150), and if a data model (DM22) corresponding to the particular model class description is not included in a plurality of data models (DM1) of the digital representation (111), adding (1420) the corresponding data model (DM22) as provided by the particular model provider (232) to the plurality of data models (DM 1).

10. The method of claim 9, further comprising:

deriving (1440) one or more model element types from the added data model;

receiving (1460), from a user or from a technical specification, semantic relationships between the one or more model element types of the added data model and model element types of pre-existing data models to connect model elements from different information sources along the lifecycle of the apparatus.

11. The method of any of claims 9 or 10, further comprising:

processing model elements derived from the discovered information sources to manage the lifecycle of the digital representation using a state machine that reflects the lifecycle of the digital representation.

12. The method of any of claims 8 to 11, further comprising:

switching between a copy mode and a reference mode, wherein in the copy mode accessed information source data is copied to the digital representation and in the reference mode a reference to the accessed information source data is stored in the digital representation.

13. The method of any of claims 8 to 12, further comprising:

activating a synchronization mode for the digital representation in which a data model associated with an information system associated with a first lifecycle stage of the apparatus is synchronized with a data model associated with an information system associated with a second lifecycle stage in that parameters of the first lifecycle stage are loaded into parameters of the second lifecycle stage.

14. A method as claimed in any one of claims 8 to 13, wherein the semantic relationships between model element types can be chosen from any one of: defining ontological relationships, describing ontological relationships, and mathematical relationships.

15. 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 of any of claims 9 to 14.

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 a plurality of information systems providing data related to a device having connectivity to a network.

Background

For a correct operation of a physical device used by or in a technical system, such as for example an automation system, the information relating to the life cycle (life cycle) of the device can have a high relevance. For example, information associated with the device that has been created during the engineering phase of the device may have relevance when operating the device or for maintenance of the device. Typically, such information associated with a device is distributed across multiple heterogeneous information sources, all of which store a portion of the device's lifecycle information. Typically, such information sources (e.g., database systems or knowledge management systems) are interoperable with each other.

Many devices used in technical systems today have a digital representation commonly referred to as a digital twin. Both terms are used herein as synonyms. Such digital representations are virtual entities that replicate the data, structure, and functionality associated with the device. Such a digital representation (digital twin) includes a data model in a particular format for describing the life cycle of the physical device.

Information useful to the digital twin of the device is typically created and maintained in a separate database/tool (information source), which is expressed in a different proprietary or standardized format; thereby not being easily exchanged with other tools and with the digital twin itself of the device. Furthermore, the relationships between the individual data of different information sources are not typically documented in a machine-readable manner, thereby creating the possibility of missing analyses, unnecessary duplication, and even leading to erroneous inconsistencies. Often, these information sources cannot exchange information with each other in a seamless manner due to a lack of interoperability at the syntactic or semantic level.

This results in an interrupted information flow across the lifetime of the device and increases the risk of: when a device or any related information consumer seeks to access device-related data in various information sources, the exchange of data between the device and such information sources fails due to the lack of interoperability.

Disclosure of Invention

There is a need to provide systems and methods for improving interoperable data exchange between information systems (i.e., information consumers and information sources) that are connected to the same network to exchange data associated with a particular physical device (i.e., data related to the life cycle of the device). Thus, information consumers/sources often have incompatible data models that prevent communication and data exchange between such information systems. The approach disclosed herein enables any information consumer to exchange device-related data with any information source via a digital representation of the physical device and avoids failure of data exchange between such information systems.

This technical problem is solved by the features of the embodiments according to the independent claims. Thus, a semantic description is employed to augment a digital representation of a device (i.e., a digital twin of a device) that defines life cycle aspects and related information about the device to be included in the digital representation. In other words, a digital twin of devices can be viewed as an aggregation of data models associated with an information system that provides device-related data over a device lifetime. The digital twin further knows the local identifiers of the devices used in the various information systems. For example, such a local identifier can be assigned to a primary ID for a device in its digital twin. Semantic descriptions (including descriptions of the kind of data models provided by the information system) are also employed to augment the data provided by the information system. The information systems are then dynamically discovered by using a discovery module of the digital representation service, and based on the semantic descriptions, the data obtained from the information sources is automatically matched with the data requested by the respective information consumers, thereby generating corresponding mappings of data model elements that allow for interoperable data exchange of device-related data by the respective information systems (consumer and source systems) via the mappings.

Information for a digital twin of a device typically comes from various life cycle phases of the device, such as, for example, early configuration, order phase, different engineering phases, and operation and maintenance phases of the device. There is typically a semantic relationship between corresponding data objects of different information sources. For example, the "output power" of a particular motor (physical device) during its ordering phase as given in a particular specification is related to the "power loss" calculated during its engineering phase as well as the "output power" and "efficiency" as measured during its actual operation. In the past, the different semantics and syntax for different use cases have been addressed by means of repeated manual work that is error-prone: a professional must peruse the available data in the different information sources to find data that is meaningfully relevant to the use case at hand, and then manually extract the corresponding individual data values for utilization. The different syntax and semantics of the interrupted information flow across the life cycle of the device and the data in each information source/consumer are obstacles to interpreting the semantics of the information and mapping the information from one life cycle phase to another. Thus, the operation of the device may be slowed down and the number of errors in the exchanged data may be increased.

The shortcomings of the approaches applied in the prior art can be overcome for devices with network connectivity by enabling a digital twin of the device to collect the required data from the associated information system without human interaction. The collection of data may depend on the life cycle of the corresponding digital twin. For example, it may be started when the device is in operation or even before the device is installed into the system.

In one embodiment, a computer system is presented for interoperable data exchange between a plurality of information systems via a digital representation service associated with a digital representation of a physical device. The device has network connectivity and an external information source provides data related to the device via the network. Network connectivity as used herein means that a device can connect to a network either directly or via a gateway. The data exchange takes place via so-called model providers (provider). There can be multiple model providers that can be seen as a layer of abstraction between the device and the information system (source/consumer). Each model provider can be connected to one or more information systems. Each model provider has a discovery supervisor (daemon) that allows the model provider to expose itself via the network in such a way that it can be discovered by other network components via a discovery mechanism. Furthermore, the model providers have semantic model class descriptions, which are semantic descriptions of the class of models provided by the one or more information systems to which the respective model providers are connected. Furthermore, each model provider has a function that allows the model provider to retrieve a data model from the connected information system and provide it to the model requesting entity. For example, the model requesting entity can be a physical device.

The device has at least one coexisting digital representation (digital twin) that is a virtual entity that replicates data of the physical device and data associated with the device lifetime. The computer system provides one or more digital representation services. A device may have multiple digital representations. Thus, in other words, a plurality of digital representation services may be provided by the system, wherein each digital representation service is for a corresponding digital representation of the device. The digital representation service has a management module that is capable of updating a digital representation of the service.

For example, the digital representation service may initially not include a digital representation, but rather generate a digital representation based on the lifecycle semantics stored in the digital representation service. The example semantics may cause a digital representation to be generated when a corresponding physical device is connected to a network. The physical device can then be discovered (like other information systems), and the digital twin (i.e., a digital representation thereof) can be generated by the management module, reflecting the data model(s) presented by the physical device. This digital twin can then be enhanced by data models from other information sources related to the data model of the physical device. In other words, by enriching digital twins with data models of the respective information systems when they become useful, the digital twins of the device can evolve within the lifetime of the device, as the availability of the digital twins is enhanced for obtaining device-related data from other information sources. The relationship can be defined via an identifier that identifies the device in various information systems.

Each digital representation service has an interface to receive requests for device life cycles from information consumers connected to the network. For example, the request may be received from an application via a corresponding API (digital twin API) and request lifecycle data stored by an external information source.

In one embodiment, the digital representation service further stores and provides a semantic description of the digital representation of the device. The semantic description includes at least a description of the kind of model of interest for the digital representation. The class of model of interest describes a data model having a class defined to provide useful data to a digital twin of a device. Thus, the semantic description is a component that supports the evolution of the digital twin over time, as it allows dynamic augmentation of the data model of the digital twin for provisioning (provisioning) of device-related data.

The digital representation service further stores a plurality of data models, wherein each data model is associated with a particular information source. The plurality of stored data models actually form a digital twin of devices associated with the digital representation service. In other words, the current digital twin of the device already includes some data models that are derived from the data models used by the information sources that provide the lifecycle data for the device. It is noted that the plurality of models can include copies of the data model or references to the data model only. As used herein, a storage model can represent a copy of the storage model or a corresponding reference to the model. In any case, it is possible to access the data model via the stored plurality of data models. Furthermore, the digital representation stores an identifier of the device used in such an information system, according to which the data model has been stored in the digital representation. For example, the digital twin may use the serial number of the device as the primary ID in the digital representation and store a further ID of the device, which ID is used as the device identifier in such information systems that provide device related data via the digital twin.

The digital representation service further includes a semantic relationship library that stores semantic relationships between model element types of the data model from different information sources.

The management module of the digital representation service coordinates various tasks performed by the service. In one embodiment, the discovery module is configured to discover one or more model providers via the digitally represented interface. The discovery module is advantageous when a request for data is received by the digital representation service that cannot be answered by an information source whose data model has been stored in the digital representation. In this case, the discovery module may search for additional model providers, which may be adapted to gain access to the requested data provided by the respective information source. The discovery mechanism utilizes discovery supervisors of various model providers. The discoverable model providers have an active discovery supervisor that indicates the availability of the respective model provider to the discovery module of the physical device.

In case one or more model providers are discovered, their semantic model class descriptions can be derived from the discovered model providers with respect to information provided by the respective one or more information sources via the interface. Getting information from the model provider can be done via a pull or push mechanism. Using a pull mechanism, the digital representation service can query the model provider for the corresponding information, and the model provider responds to such queries to provide the requested information to the digital representation service. The push mechanism may advantageously be used for information sources that mainly comprise data related to the device, e.g. the device itself or an engineering tool storing engineering data related to the device. Such information sources may already know the primary ID used by the digital representation and be able to automatically push device-related data to the digital twin of the device after a connection has been established via discovery by the corresponding model provider.

The manager module coordinates these activities. In other words, once notified by the discovery module that the manager module is available with respect to the model provider, the manager module may receive information pushed by the discovered model provider(s) or may trigger one or more queries sent to the model provider via the interface. The query retrieves a model class description from the discovered model provider. Thus, the particular model class description provides semantic metadata related to the particular data model of the corresponding information source. When operating in the pull mode, the manager module compares the discovered model class description with the model class of interest stored in the semantic description of the digital representation itself. That is, a check is performed by the digital representation service as to whether the discovered model provider is able to provide any data useful to the digital twin of the device from an external information source (e.g., to answer a particular application request). If a particular model class description corresponds to a stored model class of interest, the manager module infers that the corresponding data model behind is useful for answering the request, and decides to retrieve the corresponding data from the data model. When operating in push mode, the manager module may simply receive information from the push-based model provider and update the digital twin accordingly. In one embodiment, when a model provider is discovered, it advertises the types of models it supports, and the manager module maintains this information. Based on this information, the manager module may only query from model providers that provide models of interest for the digital representation.

Typically, mappings between model elements of a data model associated with at least two different information systems are generated via semantic relationships as defined in a semantic relationship library. In embodiments where additional data models are dynamically derived via corresponding model providers to enhance the digital twin over time, a mapping may be generated between data elements of a data model that are described by a model category associated with a discovered model provider and corresponding model elements of the data model stored in the digital representation. This mapping is also generated via semantic relationships as defined in the semantic relationship library.

For example, using a semantic relationship (a, B, "with an actual value"), model element a, which is an instance of model element type a, is mapped to model element B, which is instantiated from model element type B. Furthermore, the corresponding semantic relationship can also be inherited. When a request comes in, a mapping is generated immediately. Semantic relationships between data models of different information sources are defined at the model element type level in a semantic relationship library. At runtime (i.e., the time at which a request is processed to provide a corresponding response), a mapping is generated at the instance level of the model element. That is, once the mapping is generated, the digital representation service knows which model element of the first data model in the first data format corresponds to which model element of the second data model in the second data format. This describes a situation where a digital twin of devices will be enhanced with data from two different information systems having different formats.

Once the mapping is generated, the manager module retrieves the requested data from the respective information source via the corresponding model provider directly by: data access to the requested data is performed according to the mapping and the requested data is provided to the requesting information consumer (i.e., a data exchange between at least two information sources is performed).

Embodiments of the disclosed system architecture and method allow for the adoption of a digital twin of data dynamics enhancement devices from any information system discoverable via a corresponding model provider. The mapping to the requested data is performed automatically using predefined semantic relationships from the corresponding library without any human intervention. That is, the digital representation service of the device automatically establishes a connection to the requested data of the information source in an interoperable manner even when the information source has a different format.

In one previously described embodiment, it is assumed that the semantic relationships required to respond to a data request have been defined in a semantic relationship library. In one embodiment, the semantic relationships can be continuously enhanced on the fly by establishing new semantic relationships in the semantic relationship library (as they are known by the digital twin service). Assume that the discovery module discovers a particular model provider that has a particular model class description that matches a model class of interest included in the semantic description, but the digital twin of the device does not yet have a copy or reference of a respective data model of the plurality of data models, as the corresponding data model provided by the particular model provider is added to the plurality of data models (by storing a copy of the entire data model or a reference to only the data model).

The digital representation service can then derive one or more model element types from the added data model. In this embodiment, the interface of the digital representation service allows for receiving semantic relationships between one or more model element types of the added data model and model element types of the pre-existing data model from a user or from a technical specification to connect model elements from different information sources along the lifetime of the apparatus. For example, the graphical user interface may provide the resulting model element types to a user with domain expert knowledge to receive a new semantic relationship that can be established between the added data model and other data models of the plurality of data models that already pre-exist. In alternative implementations, the semantic relationships may be derived from a technical specification that defines a standard for the semantics of such devices.

In one embodiment, the digital representation service is further configured to process model elements derived from the discovered information sources to manage the life cycle of the digital representation using a state machine that reflects the life cycle of the digital representation. For example, different semantics can be considered to constitute or destroy instances of the digital representation. A state machine may be used to describe these semantics. The state machine can be interpreted with respect to information from the model provider and the digital representation instance constructed or destroyed accordingly.

In one embodiment, the digital representation service is further configured to generate a graphical representation reflecting semantic relationships between model element types for future queries by the user.

In an embodiment, the digital representation service further comprises a configuration module adapted to switch between a copy mode and a reference mode for each data model, wherein in the copy mode the accessed information source data is copied to the digital representation and in the reference mode a reference to the accessed information source data is stored in the digital representation.

In one embodiment, the configuration module is further adapted to: selecting a deployment mode for the digital representation, wherein the deployment mode can be selected for each data model contained in the digital representation from any one of: deployment to a cloud network, edge, or to the device itself. The deployment strategy employed may vary per data model.

In one embodiment, the configuration module is further adapted to activate a synchronization mode for the digital representation in which the data model associated with the information source associated with the first life cycle phase of the apparatus is synchronized with the data model associated with the information source associated with the second life cycle phase in that the parameters of the first life cycle phase are loaded into the parameters of the second life cycle phase.

In one embodiment, a computer-implemented method is provided that is executable by a module of a computer system to perform the functions and steps described herein for interoperable data exchange between information systems via a digital representation service of a device.

In one embodiment, a computer program product has instructions which, when loaded into the memory of the computer system and executed by at least one processor of the computer system, perform the method steps of the computer-implemented method.

Additional aspects of the invention will be 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 claimed.

Drawings

FIG. 1 is a block diagram illustrating a system layout (landscapes) with a computer system for interoperable data exchange between multiple information systems, according to an embodiment;

FIG. 2 is a simplified flow diagram of a computer-implemented method for interoperable data exchange between multiple information systems, according to an embodiment;

FIG. 3 illustrates an example embodiment of a system layout having various information systems communicating via digital representations of associated devices;

FIG. 4 illustrates examples of various device lifecycle data categories provided by various information sources;

FIG. 5 is an example of semantic relationships stored in a semantic relationship library, according to an embodiment;

FIG. 6 illustrates multiple layers of a digital representation of a physical device, and depicts how semantic model class descriptions and semantic relationships are incorporated in the digital representation, in accordance with embodiments;

FIG. 7 illustrates a particular digital twin example for a drive device; and

FIG. 8 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 of a system layout having a plurality of information systems 201 through 20n communicating via a computer system 100, according to one embodiment. Computer system 100 is used as an example only and is not intended to limit the scope of the independent claims to any implementation details as disclosed in the description of fig. 1. Fig. 2 is a simplified flow diagram of a computer-implemented method 1000 of interoperable data exchange between multiple information systems, according to an embodiment. Method 1000 is performed by computer system 100. Thus, the following description describes the computer system 100 in view of the method 1000 being performed, and thus makes reference to the reference numerals of fig. 1 and 2 as well. It is noted that the following description describes possible functionalities of the computer system 100 in a comprehensive manner, including optional features that may be used to perform optional method steps of the computer-implemented method 1000. Such optional steps are illustrated by blocks with dashed boxes in fig. 2.

Computer system 100 communicates with other computer systems over network 300. Thereby, communication with the plurality of information systems 201 to 20n is performed via the middle layer of the model providers 231 to 23 n. The computer system 100 is intended to enable interoperable data exchange between a plurality of information systems 201 to 20n via digital representation services S1, S2, Sn associated with a digital representation 111 of a physical device. The information system can be an information source and/or an information consumer related to data associated with the physical device. The digital representation 111 is a virtual entity that replicates data of a physical device as well as data associated with a device lifecycle, where such device lifecycle data can be spread across various information systems. In general, the data models of the various information systems differ from one another, so that data exchange of device-related data is not possible between such information systems without error-prone manual interaction by the user. The computer system 100 employs the following features to overcome this technical problem.

The computer system 100 runs one or more digital representation services S1 to Sn for the physical devices. In an initial phase, when a physical device may not even be present but engineering data for the device may already be available, the digital representation service (e.g., S1) may only include logic to generate a digital twin 111 of the device upon receiving an indication that the device is now available. Once the physical device is finally rendered as a real-world object, the digital representation service S1 provides all the functionality to maintain and expand the digital representation 111 of the device. For one device, multiple digital representations may be useful, where each digital representation is provided and maintained by its respective digital representation service S1, S2, Sn. The special digital representation service S1 includes an interface 110 for receiving requests for device-related data. Such a request may be received 1100 from any of the information systems 201 through 20n that function as information consumers. For example, a maintenance system application may request engineering data of a device that is useful for maintenance decisions to be made by the requesting maintenance application.

The received request is then processed by the management module 120 of the service S1. The management module 120 includes logic configured to generate and update a digital representation 111 of the device. The digital representation, once created, stores a plurality of data models DM1, where each stored data model is associated with a particular information system 201 through 20 n. It is to be noted that the device itself is also considered an information system in this context. When a device is initially discovered by the digital representation service S1 (the discovery mechanism is explained further below in this description), the device provides its data model to the service S1 to employ the provided data model to generate a digital twin 111 of the device. One possible scenario for creating a digital twin is that when the device starts to operate, it triggers the creation of the digital twin and provides the digital twin with a master ID for the device. This primary ID is then used by the digital twin for the associated device specific data of the different information systems by storing an assignment data structure that assigns to the primary ID a local identifier of the device used by the other information system.

The digital representation service S1 further has a discovery module 130, the discovery module 130 configured to discover one or more model providers 231 to 23 n. Thus, each model provider is associated with one or more information systems 201 to 20 n. The information system is able to communicate with its associated model provider via interfaces 221, 222, 22 n. In an example, model provider 231 is associated with information systems 201 and 202. Model providers 232 and 23n are associated with information systems 202 and 20n, respectively. Each model provider also has a so-called model class description 231-1 to 231-n, which provides a semantic description of the information provided by the underlying information system. In an example, the model class description 231-1 of the model provider 231 has semantic descriptions related to the class of data models DM21, DM22, which are provided by the information sources 201 and 202, DM21, DM 22. The model class description 232-1 of the model provider 232 has a semantic description related to the class of the data model DM22, which data model DM22 is provided by the information source 202, and so on.

The discovery component is capable of discovering (1200) model providers connected to the network 300 when such model providers indicate their presence in the network. For example, to support an extensible number of information systems, it is possible for the digital representation service S1 to look up the information systems according to their semantics rather than according to name or address. To this end, machine-readable semantics of information and discovery mechanisms in a distributed network interconnection automation system may be used. In the special case where the device itself is first connected to the network, the device itself may act as a model provider that indicates the presence of the device via the network 300. Of course, the device may also act as the only information source and use an independent model provider for signaling its presence in the network. The discovery module 130 is then able to discover the device (or its independent model provider) and retrieve the data model(s) of the device and its serial number to be used as the master ID for the digital twin of the device. The management module 120 can then generate the digital representation 111 and populate it with the resulting data model(s) and the master ID of the device. The master ID may be deployed to all other discovered model providers to enable the corresponding information system to correlate the local identifier for the device with the master ID. For example, an installation-based database of information sources may store records including an installation ID, an installation address, installation data, and a serial number of the device (i.e., a master ID).

The management module derives (1300), from the discovered one or more model providers 231 to 23n, corresponding semantic model class descriptions 231-1 to 23n-1 regarding information provided by the respective one or more information systems 201 to 20n associated with the respective model provider. In general, the model-specific class description 231-1 provides semantic metadata related to one or more data models DM21, DM22 of one or more corresponding information systems 201, 202. Turning briefly to FIG. 6, as an example, a model class description is shown in layer 2. The model class description comprises a model type and a model element type within the model type, augmented with an attribute providing a semantic description SD of the respective element and with an attribute providing an identifier ID of the respective element. "IS used in fig. 6 as an abbreviation for" information system ". The semantic description SD can be defined based on some global semantic dictionary (e.g. eCl @ ss) or a local semantic dictionary defined internally by a set of companies. For example, eCl @ ss 10.0.1 can be obtained from http:// www.eclassdownload.com/catalog/product _ info.php/cPath/1/products _ id/5028/language/de. An example model class description is "subscription model 1 type," which defines a model containing subscription information for a device and includes a list of subscription model 1 element types. Other examples in layer 2 are at a glance. The models in the model library of layer 1 are instantiated from types as defined in the model type library of layer 2. Fig. 6 is described in more detail below.

The digital representation service S1 further includes a semantic relation repository 150, the semantic relation repository 150 storing semantic relations between model element types of data models from different information sources 201 through 20 n. In a situation where the computer system has been operating for a period of time during which multiple requests for data from different information systems are received and processed by the digital representation service, the digital representation 111 already includes multiple data models from the different information systems. For such data models, the semantic relations repository 150 has stored semantic relations that can be used for mapping between elements of the data model across the information system. The management module is configured to generate (1500) such a mapping between model elements of different data models via semantic relationships as defined in the semantic relationship library.

In response to the request, the management module finally performs (1600) an exchange of data between the at least two information systems according to the mapping. That is, the digital twin 111 of the physical device, along with the semantic relationships defined in the semantic relationship library 150, acts as a transformer of the different formats of the data model for the respective information consumer and information source. The digital twin 111 stores a copy of the corresponding data model and the semantic relationships define how such models can be mapped. The mapping itself at the model element instance level is then performed when the request is received, and the management module knows which data is requested from which information source for which information consumer.

An additional feature of the computer system 100 is that the digital representations 111 and corresponding semantic relationships can dynamically evolve over time. In this embodiment, the digital representation service S1 further includes a semantic description 140 of the digital representation 111 that includes the model class of interest for the digital representation 111. In other words, the semantic description knows which kinds of data models may be of interest to further enhance the digital twin of the device. The management module 120 may obtain 1300 semantic model class descriptions 231-1 through 23n-1 from the discovered one or more model providers 231 through 23n regarding information provided by the respective one or more information systems 201 through 20 n. As described, the particular model class description 231-1 provides semantic metadata related to one or more data models DM21, DM22 of one or more corresponding information systems 201, 202. In other words, the management module compares the specific model class description 232-1 of the discovered model provider 232 with the model class of interest included in the semantic description 140 (1400). If there is no match ("NO"), then no data exchange in response to the request can be performed for the current request. In this case, the computer system 100 waits for a new request. If there is a match ("yes"), and if the data model DM22 corresponding to the particular model class description 232-1 is not already included in the plurality of data models DM1, the management module adds (1420) the corresponding data model DM22 as provided by the particular model provider 232 to the plurality of data models DM1 in the digital twin 111. At this point in time, the necessary data model for performing the requested data exchange is known. One or more model element types are then derived from the added data model. At this point, a semantic relationship is established for performing the data exchange. To establish semantic relationships, the computer system receives (1460), from a user or from a technical specification, semantic relationships between one or more model element types of the added data model and model element types of a pre-existing data model to connect model elements from different information sources. In general, various information systems provide data related to different phases of the device life cycle. That is, in other words, the received semantic relationships connect model elements along the device's lifecycle. In one implementation, semantic relationships can be received from domain professionals via corresponding human-machine interfaces that provide mapping tools to professional users to define semantic relationships between resulting model element types. In another implementation, the mapping module may access a technical specification that defines semantics for the resulting model element types, and may automatically derive corresponding semantic relationships from such specification.

By expanding the data model and semantic relationships of a digital twin on the fly (i.e., during operation of the computer system) to facilitate interoperable data exchange between information systems, the digital twin of a device continuously evolves during operation of the computer system and enhances its mapping capabilities to improve the ability to establish interoperable data exchange for an ever-increasing number of new requests.

Fig. 3 illustrates an example system layout 300 with multiple information systems C1, C2, DB, a1 exchanging data via a digital representation (twin) service DTS. The digital twinning service DTS maintains a digital twinning of the device. It is noted that there can be multiple digital twins in multiple DTS services for a particular device, each including a particular kind of data model and having its own lifecycle semantics. In an example, external cloud computer C1 and internal cloud computer C2 connect to the network via corresponding application programming interfaces APIs. Furthermore, the existing database DB is connected to the network via a corresponding WEB API. Further, the existing application a1 connects to the network via a corresponding App API. In an example, a1 may act as an information consumer requesting device-related data that can be provided by a DB as an information source. In an example, each information source has its own dedicated model provider MP 1-MP 4, which model providers MP 1-MP 4 are able to communicate with the information system via their APIs. Furthermore, each model provider is able to communicate with the digital twin service over the network via its interface DT API.

Model providers MP 1-MP 4 can retrieve information from the information system and feed it into the DTS. For example, data models of associated information sources can be retrieved by the corresponding model collectors MC 1-MC 4. Such data models are then provided to the digital twin of the DTS, where they are stored as collected models CM 1. To be able to communicate with the DTS, various model providers are initially discovered by the DTS through the use of a discovery component DC. Each model provider runs a discovery supervisor DD 1-DD 2, which DD 1-DD 2 expose information to the network that can be discovered by the discovery component of the DTS. The discovery component may use standard discovery mechanisms (e.g., name or address based discovery) to find information sources, or it may discover information sources through semantics disclosed by a discovery supervisor as machine-readable semantics of the information. Any discovery mechanism suitable for discovering components in a distributed network interconnected automation system may be used by those skilled in the art to implement the discovery component DC. For example, the DC may discover the information source as an OPC UA server via a corresponding discovery supervisor of the association model provider.

Each model provider has model class descriptions MK1 through MK 4. The model class description of a particular model provider provides a semantic description of the underlying information. In other words, MK1 provides a semantic description of the data model provided by C1. Once a model provider has been discovered, such model class descriptions can be read by the DTS. Thus, each information source may use the device's proprietary local identifier represented by the digital twin of the DTS. The local identifier of a device is a unique identifier of the device with the corresponding information system. To associate data records of a particular information source with a particular local identifier for a device, the local identifier may be mapped to a globally unique master ID of the device. Such a mapping can be stored in the DTS as an integral part of the digital twin description DTD and/or it can be stored by the information source or its associated model provider. Generally, the digital twin description DTD stores the semantics of the digital twin, including the model class of interest for that particular digital twin, the life cycle semantics of the digital twin, etc.

The DTS has a digital twin manager component DTM that is responsible for processing data model elements provided by discovered model providers and managing the life cycle of the digital twin. In one embodiment, the DTS has a lifetime management component LMC that may describe the lifetime semantics of the device by using a form such as, for example, a state machine. Example logic implemented by such a state machine is: when a first data model relating to a digital twin of the apparatus is available, the digital twin is constructed and the data model is added to the collected model CM 1. The lifecycle management component implements such logic. That is, when a new device is discovered by the DTS (which has no digital twin at that moment), the LMC state machine triggers the creation of a corresponding digital twin in the DTS and adds the data model(s) provided by the physical device at that time. The newly created digital twin is then dynamically enhanced over time by adding other data models from other information sources that provide lifecycle data for the device.

For example, when the DTS receives a request from a1 for data associated with a device that cannot be served based on the already collected data model CM1, the DC starts a discovery process to discover the model provider MP3 connected to the information source DB that can provide the requested data. To this end, the DTS derives a semantic model class description MK3 from the discovered model provider MP 3. MK3 provides semantic metadata related to the data model of the DB. The resulting model class description MK3 is compared by DTM to the model class of interest stored in the DTD of DTS. If there is a match, the DTM generates a mapping between model elements of the data model associated with MK3 and corresponding model elements of the collected data CM1 via semantic relationships as defined in the SRD.

Thus, the relationships between data models originating from different information systems having different formats are maintained in the semantic relationship description, SRD, of the DTS. The SRD is interpreted by the digital twin manager DTM to establish references among the various collected data models CM 1. These references are automatically updated as data models are added to or removed from the digital twin. For example, if the model class description MK3 of the discovered model provider MK3 matches the model class of interest included in the semantic description DTD, and the corresponding data model of the DB is thus added to the collected data model DM1, then one or more model element types are derived from the added data model. Semantic relationships between one or more model element types of the added data model and model element types of pre-existing data models are then established in the SRD (e.g., by receiving corresponding input from a user or by extracting relationships from a semantic dictionary of an appropriate technical specification). The semantic relationships defined in the SRD are used at runtime to connect model elements from different information sources along the lifetime of the device.

The digital twin manager DTM may be configured by a digital twin manager configuration component DTMC. Various configurations may be applied. For example, an administrator may configure a digital twin to pull information from a particular source, or just keep a reference to the original data, rather than copy them inside the digital twin. Another example of a particular configuration pertains to deployment of digital twins, which can be wholly or partially on clouds, edges or devices, or any combination of these. In other words, DTMC may be adapted to select a deployment mode for digital twinning. A deployment mode can be selected for each of the collected data models for deployment to a cloud network, an edge, or the device itself. The term edge is used herein in the meaning of edge computing, which pushes applications, data and computing power (services) from a centralized point to a location closer to the user. For example, if the digital twin contains a data model that maintains the operating parameters of the device, a data model for engineering information, and a data model for maintenance information, the first data model can be stored within the device itself, and only references thereto are maintained within the digital twin; other data models and data twins can be stored, for example, in the cloud.

Another configuration relates to the synchronization of multiple models, for example, when engineering and operational models of a device are available, engineering parameters can be downloaded into the operational parameters to facilitate plugging (plug) and a use case is created where device-related data from different life cycles of the device can be exchanged instantly between the engineering and operational models once they are plugged into the DTS. That is, once their models become part of the collected models and the corresponding semantic relationships are established, they are immediately available for "production" (i.e., to enable interoperable data exchange between the respective information systems). In general, the configuration module DTMC is further adapted to activate a synchronization mode for the digital twin to synchronize the data model associated with the information source associated with the first life cycle phase of the device with the data model associated with the information source associated with the second life cycle phase, since the parameters of the first life cycle phase are loaded into the parameters of the second life cycle phase. The information source and its corresponding model provider may be excluded/disappeared from the system at any time, for example, when the device itself is defective and stops operating. Different policies may be supported when each model provider disappears: keeping up-to-date information, displaying missing links to the original information source, etc. Policies can be defined by the referenced semantics and enforced by the instrumentation and collection process.

Fig. 4 illustrates an example 400 of how the life cycle data provided by various information systems can be employed to augment the digital twin DT originally generated for a particular device instance. For simplicity, the functional modules and interfaces of the digital twin service DTS1 and the corresponding model providers are not shown in fig. 4. It is assumed that the digital twin is generated by the state machine of DTS1 when the corresponding OPC UA enabled device D1 is found by DTS 1. The device D1 is able to continuously push its operational data (e.g., sensor data, data related to the internal state of D1, etc.) to a digital twin covering aspects of the operational lifecycle of the device D1. The corresponding collected data model DTO forms part of the digital twin DT. Additional data models of the digital twin DT may be collected from other information systems. For example, a production system hosted in external cloud EC1 may provide a data model DTP related to the production of devices. The database DB1 may provide data models DTI relating to the installation of the device. The engineering tool ET1 may provide the data model DTE to the DT with respect to the engineering phase of the device. And the maintenance application MA1 may provide the data model DTM with respect to the maintenance phase of device D1. Typically, all information systems use their own proprietary data model with the local identifier of device D1, which is mapped to the primary ID of the digital twin (e.g., the serial number of the DT). When a request for data of any of the connected information systems is received by the DTS1, the DTE, DTS1, is included in the semantic relationship library,The semantic relationships between the model element types of the various data models DT of DTI, DTO, DTP and DTM allow the generation of mappings between instances of model elements. For example, the maintenance application MA1 may request operational data from D1 as well as data from the engineering phase. To this end, a mapping is generated between the respective data models DTM, DTO and DTE. Based on this mapping, the MA1 is now able to retrieve the D1's operational data, which may have been stored by the DT if device D1 pushed its data to the digital twin, or the data may be retrieved from device D1, since the DTs1 knows how to access the requested data via the generated mapping. Similarly, an engineering tool ET1Can be accessed by DTS1 via the corresponding mapping. Finally, the retrieved data is provided to the requesting information system MA1 using the mapping between DTE, DTO and DTM. This allows data to be provided to MA1 in the format of the proprietary data model of MA1, enabling MA1 to immediately utilize the provided data without further transformation. As previously described, there may be more digital twins for the same physical device that cover different aspects of the device, with each digital twins being provided by a respective digital twinning service.

Drawing (A)5The graphical representation 500 is taken to illustrate an example of semantic relationships stored in a semantic relationship library according to an embodiment. In this example, the semantic relationships are visualized via a graphical representation 500, which graphical representation 500 can be generated reflecting the semantic relationships between model element types. Such graphical representations of connected data model elements can be advantageously used for subsequent queries, for example to retrieve information (e.g., order, project, operation) related to the device life cycle.

Semantic relationships (semantic links) that describe relationships between model element types in data models from different information sources are collected and stored in a semantic relationship library of the digital twin service. First, data model element types can be derived from the information source data model and can be stored in general or proprietary semantics within the semantic relationship library. It is assumed that each model element has a stable unique identifier associated with it that can be used for reference purposes in semantic links. Semantic links are formed using domain expert knowledge from user input or from technical documents (e.g., order specifications, information system code knowledge bases, technical reports, user guides, technical semantic dictionaries, etc.). Semantic links use appropriate forms (e.g., common ontologies and mathematical formulas) to describe one-to-one, one-to-many, and many-to-many relationships between different model element types.

The example in fig. 5 illustrates semantic links indicated by dashed arrows using general terms and formulas to connect data model element types from different information sources along the life cycle (referenced according to their identifiers). The semantic links can be stored as a directed graph, where each edge (illustrated by a dashed arrow) defines a link of the form E = (N1, N2, R), where N1 represents the node at the tail end of the arrow, N2 represents the node at the head of the arrow, and R is a semantic link from N1 to N2.

Here are descriptions of different types of semantic relationships shown in fig. 5:

defining an ontology relationship: (ordering. outputpower, operator. outputpower, "having an actual value") defines a semantic link that expresses that the "output power" specified during the "ordering" phase has an "actual value" given by the "output power" as measured during the "operating" phase.

Describing the ontological relationship: (engineering. powerpages, engineering. type selection, "cause") means that the "engineering. powerpages" value causes or affects the "engineering. type selection" value.

The mathematical relationship is as follows: (ordering. outputpower, engineering. powerloads, "engineering. powerloads. = engineering. inputpower. — ordering. outputpower") expresses a formula-based semantic connection between values of "ordering. outputpower" and "engineering. powerloads.

Semantic links are also used for discovery. For example, given the element engineering.

Fig. 6 illustrates a plurality of layers of a digital representation (digital twinning) of a physical device in accordance with an embodiment. The digital twin model element representation 600 may be implemented as a hierarchical description of digital twin model elements, model element types, and relationship types. It can be systematically organized using the IEC 62714AutomationML standard with its instance hierarchy, system element class library, role library, and interface class library. IEC 62714-1:2014 (available in http:// www.iec-norm. de/220904/IEC-62714-1-2014-06-ed-1-0-zweisprachig. html) is a solution for data exchange that focuses on the field of automated engineering. The data exchange format defined in the IEC 62714 series (automated markup language, automation ml) is a data format based on an XML schema, and has been developed to support data exchange in heterogeneous engineering tool layouts. AutomationML is the goal of interconnecting engineering tools of different disciplines, such as mechanical equipment engineering, electrical design, process engineering, process control engineering, HMI development, PLC programming, robotic programming, and the like.

The first layer, "layer 1," comprises a "model library. This layer contains various models with model elements (e.g., order model elements, engineering model elements, operational model elements, etc.), attributes, and values associated with the device, such as, for example, the model element "drive efficiency" of the engineering model like a particular driver along with its values: "95%". Using AutomationML, model elements can be represented as internal elements within an instance hierarchy. Internal element attributes with accompanying fields of "value", "unit", "data type" can be used to store model element attributes and their values. Models with model elements can originate from different information systems IS1, IS2 used as original indicators in the corresponding model/model element names. The model/model element of layer 1 is an instance of the corresponding type in layer 2. For example, "engineering model IS 1" IS an instance of model type "engineering model 1 type," engineering model IS2 "IS an instance of model type" engineering model 2 type, "and so on.

The second layer, "layer 2," includes a "model type library. The type of model element (e.g., order model element type, engineering model element type, operation model element type, etc.) can be stored in the second layer along with any element type level information such as semantic description SD and associated attributes (e.g., identifier ID). Any semantic relationship between element types can also be shown at this level. In AutomationML, element types can be classified as system Unit classes designed for reusable components. The semantic description can be stored in a class description field or instantiated from an action class for defining the semantics of the abstract object. Finally, the element type relationships can be instantiated using the interface class.

The third level, "level 3," includes a "semantic relationship type library. Any semantic relationships that describe relationships between element types in "level 2" can be abstracted and stored in a semantic relationship type library for reuse. The "semantic relationship type" is instantiated as a model element type. Within AutomationML, these semantic relationships can be stored as interface classes within a library of interface classes.

Fig. 7 illustrates an example scenario 700 of a digital twin DT2 for a drive 701. For the sake of brevity, only the contents of the digital twin DT2 of the drive, i.e. the collected data model and the identifier, are shown. The functionality of the digital twin service DTS2 (e.g., logic to collect models, compose digital twins, establish semantic relationships, etc.) is omitted from fig. 7. DTS2 runs even before a digital twin (e.g., DT2) is made up, as DTS2 is responsible for the make up. In other words, the DTS2 is able to instantiate the digital twin DT2 when its state machine is executed accordingly.

In an example, each information system has its own identification mechanism. The device in this example is a drive 701 having a serial number 710. Installation-based database 702 has an installation ID 720 and knows that serial number 710 is associated with ID 720. The engineering system 703 uses the engineering ID 730 to represent the drive 701. The ID 720 is different from the serial number 710 because the physical device may not have been manufactured yet at the engineering stage. The driver 701 provides the data model(s) DM71, the database 702 provides the data model(s) DM72, and the engineering system 703 provides the data model(s) DM73 (e.g., via a corresponding model provider — not shown).

To be able to aggregate these models into a digital twin DT2, the serial number 710 of the drive is used as the "master ID" to which all other local IDs 720, 730 are mapped/aliased. The ID mapping is defined by the digital twin service DTS2 and stored in the digital twin DT 2. The mapping between primary ID 710 and local IDs 720, 730 can be implemented in two ways.

In one embodiment, the mapping can be automatically generated if the corresponding information system 702 includes a serial number 710 (primary ID) as part of the drive specific information record. For example, a plug-in for an information source can ensure that every time an information record is composed in the information system 702, corresponding mapping information is also created that maps the local ID 720 to the serial number 710. It is noted that the information source typically only knows its local ID and, when available, also the mapping to the primary ID. For example, if the installation-based database 702 has a data record like (installation ID, installation address, installation date, serial number), the plug-in can extract the serial number 710 from this record and use it to communicate with the digital twin DT 2. In other words, the installation ID is employed to create the data records of database 702, and serial number 710 is added to each record based on knowledge that it is the primary ID for the corresponding local ID 720. The occurrence of the sequence number can then be used as a reference to arrive at the digital twin DT 2. In this setup, the information system is able to push data to the digital twin even when detecting the presence of the digital twin reference 710 in the data record.

In one embodiment, the mapping can be generated manually if the information source 703 does not have a primary ID 710 that is part of the information record. In this case, the digital twin receives ID mapping 710 from a user who provides manual input via semantic relationships 730. Within the digital twin DT2, the local IDs 720, 730 of the information sources 702, 703 can be aggregated and aliased and can be used to communicate with the information sources. In other words, device specific data at the respective information source is identified via the local ID, which is associated with the device in the hierarchy via the primary ID 710.

It is assumed that there is no digital twinning in DTS2 at the beginning. The drive 701 is then inserted into the network with the sequence number 710. The device 710 is discovered by DTS2 as an information source/model provider and uses the master ID 710 to create the corresponding digital twin DT 2. In general, the primary ID can be any identifier and can also be set by DTS 2. For example, any other available ID may become the master ID (e.g., an ID from an engineering stage or even a number generated by a counter of DTS 2). Typically, discovery is about finding model providers on the network, and once found, the DTS2 can pull information from the discovered information system, or the discovered information system can push data to the digital twin DT 2. Devices (e.g., drivers 701) can be viewed as native model providers that tell which models to provide, or they can use model providers that view the device as an information system like any other information system.

The driver 701 passes its sequence number to the digital twin service DTS 2. The DTS2 identifies that there is no digital twin available for the drive 701 and constitutes a digital twin DT 2. The serial number 710 is stored as a primary ID in the digital twin DT 2. In this way, a connection is established between the device 701 and its digital twin DT 2. Furthermore, the data model(s) DM71 of the drive, or at least a reference to such data model(s), is/are imported into the digital twin DT 2. The device 701 is able to push all its operating parameters directly into the corresponding digital twin DT2, since the imported data model(s) DM71 are identical to the original data model(s) of the drive. The use of a push mechanism for the driver 701 ensures that the DT2 remains synchronized with the real device 701. Alternatively, the operational data may be pulled from the device at some sampling frequency, but this may cause additional network traffic.

The digital twin service DTS2 may now discover the model provider based on the installed database 702 as the model provider with the kind of model that is useful to extend the DT2 with the installation information of the driver. The corresponding data model(s) DM72 (or reference) is added to DT 2. After establishing the corresponding semantic relationship, DTS2 may query database 702 using sequence number 710. The installation-based data record already contains a mapping between the serial number 710 and the installation ID 720. Thus, the device-related installation-based data records can be retrieved and provided to the DT 2. In the event that the primary ID is not known at the information source, the device-related data may be identified by using a query that describes the device based on information present in the information source. For example: a device located in building X and installed at a certain date is obtained. The installation-based model provider queries the relevant information based on the installation ID as known from the identifier mapping and returns it to the digital twin DT 2.

The engineering tool 703 may store engineering information on a storage medium. The association model provider monitors the files stored on the folder and reads their contents. Once the engineering tool 703 is discovered via its associated model provider, the DTS2 can import the provided data model(s) DM73 or corresponding references into the DT 2. Semantic relationships between DM73 and DM71, DM72 are established for mapping generation to enable data exchange between information systems 701, 702, 703. For example, the semantic relationship in this example can be meaningful between engineering parameters and operating parameters of the drive. In the case where the engineering tool knows the serial number 710 (master ID) of the drive, the content including the engineering information and the design number 730 can be pushed to the digital twin service DTS 2. The engineering model provider may push only a subset of the engineering information. Another alternative is shown in fig. 7, where the engineering tool 703 does not know the master ID, but only stores a data record about the local device ID (design number 730). In this case, the digital twin service DTS2 queries the engineering model provider for specific information and uses the identifier hierarchy relationship 710 and 730 to retrieve drive-related data from the information source 703.

FIG. 8 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. General purpose computer device 900 may be used to implement 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, computing device 950 may be used by a human skilled practitioner to interact with computer system 900 to define semantic relationships in a semantic relationship library. The components shown here, 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 bus 914 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 is capable of processing 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 processors and/or multiple buses may be used, as appropriate, along with multiple processing units and multiple types of memory. Also, multiple computing devices 900 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a processing device).

The memory 904 stores information within the 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.

Storage 906 is capable of providing mass storage for computing device 900. In one implementation, the storage 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 can be tangibly embodied in an information carrier. The computer program product may also contain instructions which, when executed, perform one or more of the methods as described above. The information carrier is a computer-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. This allocation of functionality 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 to high-speed expansion ports 910, which may accept various expansion cards (not shown). In this implementation, a low-speed controller 912 is coupled to the storage 906 and a low-speed expansion port 914. The low-speed expansion port, which may include various communication ports (e.g., USB, bluetooth, ethernet, wireless ethernet), may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device (e.g., a switch or router), such as through a network adapter.

Computing device 900 may be implemented in a number of different forms, as shown in the figure. 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 an integral part of the rack server system 924. Additionally, it may be implemented in a personal computer (e.g., laptop 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 include one or more of computing devices 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, input/output devices (e.g., display 954), a communication interface 966, and a transceiver 968, among other components. The device 950 may also be provided with a storage device (e.g., 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 is capable of executing instructions within the computing device 950, including instructions stored in the memory 964. The processor may be implemented as a chipset of chips that include separate and multiple analog and digital processing units. The processor may provide, for example, for 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.

Processor 952 may communicate with a user through control interface 958 and 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 can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. Expansion memory 984 may also be provided and connected to apparatus 950 via expansion interface 982 (which expansion interface 982 may comprise, 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. In particular, expansion memory 984 may include instructions to perform or supplement the processes described above, and may also include secure information. 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 along with additional information (e.g., 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 described 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.

The device 950 may communicate wirelessly through the communication interface 966, which communication interface 966 may include digital signal processing circuitry if necessary. Communication interface 966 may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, 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, for example, using a bluetooth, WiFi, or other such transceiver (not shown). In addition, a GPS (global positioning system) receiver module 980 may provide additional navigation-and location-related wireless data to the device 950, which may be used as appropriate by applications running on the device 950.

The device 950 may also communicate audibly using an audio codec 960, which may receive spoken information (spoken information) from a user and convert it into useable digital information. Audio codec 960 may likewise generate audible sound for a user, e.g., via a speaker in a handle (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 operating 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 an integral 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 by one or more computer programs that are executable and/or interpretable in a programmable system including at least one programmable processor 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 can 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" means 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) or 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 can also be used to provide for interaction with the 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 can receive input from the user in any form, including acoustic, speech, 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 can include a client and a server. 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 necessarily 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.