DE102020215230A1 - Device for managing digital twins - Google Patents

Abstract

Data integration device (10), comprising input interfaces (2a, ..., 2d), to which a runtime data to the input interface (2a, ..., 2d) supplying device (20a, ..., 20d) can be connected, wherein the Runtime data of the respective device (20a, ..., 20d) are characterized by means of at least one aspect model (AM1, AM2) assigned to the respective input interface (2a, ..., 2d) and characterizing an aspect of the runtime data, characterized in that the respective input interface (2a, ..., 2d) is associated with the respective aspect model (AM1, AM2).

Description

The invention relates to a data integration device.

State of the art

From the DE 10 2018 205 872 A1 a method for generating a digital twin of a physical object is known, in which descriptive data containing properties of digital data are generated using a descriptive meta model. Communication information is also created. To create the digital twin, the description data, the communication information and a designation of the physical object are combined.

Disclosure of Invention

In contrast, the invention with the features of independent claim 1 has the advantage that it enables a flexible system that can process runtime data from a large number of heterogeneous data sources and provide it in a standardized manner without additional communication effort.

Further aspects of the invention are the subject matter of the independent claims. Advantageous developments are the subject of the dependent claims.

• 1 beispielhaft einen Einsatz der Erfindung;
• 2 schematisch Datenflüssen durch die Datenintegrationsvorrichtung;
• 3 schematisch einen Mechanismus zur Ankopplung einer datensendenden Vorrichtung;
• 4 beispielhaft in einem Flussdiagramm ein Verfahren zum Bereitstellen eines digitalen Zwillings;
• 5 beispielhaft von einem Aspekt-Agenten bereitgestellte Daten eines Hochofens;
• 6 beispielhaft ein Aspektmodell für diesen Aspekt-Agenten;
• 7 beispielhaft eine Klassen-Hierarchie zur Festlegung von Eigenschaften von Teilgraphen des Aspektmodells.

Embodiments of the invention are explained in more detail below with reference to the accompanying drawings. In the drawings show:

• 1 exemplary use of the invention;
• 2 schematic data flows through the data integration device;
• 3 schematically a mechanism for coupling a data-transmitting device;
• 4 by way of example in a flow chart a method for providing a digital twin;
• 5 exemplary data of a blast furnace provided by an aspect agent;
• 6 an exemplary aspect model for this aspect agent;
• 7 exemplarily a class hierarchy for defining properties of partial graphs of the aspect model.

Description of the exemplary embodiments

1 shows an example of an application of the invention. A data integration device (10) is intended to be coupled to devices (20) and client-side devices (30). The device (20) can be, for example, a sensor and/or an ERP system and/or a production machine such as a blast furnace and/or a robot, e.g. a welding robot, and/or a vehicle and/or a charging station, eg for an electric vehicle. The coupled devices (20) are set up to transmit information to the data integration device (10).

The client-side devices (30) can be playback devices, for example, but also devices that access the devices (20) in a controlling manner.

2 shows in one embodiment how the data flows through the data integration device (10). Devices (20a...d) are each coupled to the data integration device (10) via an input interface (2a...2d). Each of the data integration devices (10) is connected to one or more aspect agents (1a...k) (also called aspect processing devices), it being possible for different coupled devices (20a...d) via their respective Input interfaces (2a...d) are connected to the same aspect agents (1a...k).

Provision can therefore be made for a plurality of input interfaces (2a, ..., 2d) to be connected to the same aspect processing device (1a, ..., 1k). Alternatively or additionally, it can be provided that a plurality of aspect models (AM ₁ , AM ₂ ) are associated with at least one input interface (2a, ..., 2d), and/or that at least one input interface (2a, ..., 2d) connected to a plurality of aspect processing devices (1a, ..., 1k).

The Aspect Agents are classified as First (1a), Second (1b), Third (1c), Fourth (1d), Fifth (1e), Sixth (1f), Seventh (1g), Eighth (1h), Ninth (1i), tenth (1j) and eleventh (1k) aspect agents denoted. Each of the aspect agents has an output interface (3a...3k), which is numbered like the aspect agents as first (3a), second (3b), third (3c), fourth (3d), fifth ( 3e), sixth (3f), seventh (3g), eighth (3h), ninth (3i), tenth (3j), and eleventh (3k) output interface, wherein the first aspect agent (1a) denotes the first output interface (3a ), the second the second, etc.

In the illustrated embodiment, a first device (20a) is coupled to the first aspect agent (1a) and the fourth aspect agent (1d) via a first input interface (2a), as is a second device (20b) via a second input interface ( 2 B).

A third device (20c) is coupled to the ninth aspect agent (1h) via a third input interface (2c). A fourth device (20d) is also coupled via a fourth input interface (2d).

The input interfaces (2a...d) are each set up to receive data from the devices (20a...d) connected to them in a format specific to the respective connected device (20a...d).

A single or multiple (semantic) aspect models (AM ₁ ,AM ₂ ), cf. 3 , are stored in a dedicated location, in a memory (21) assigned to the data integration device (10), a so-called model repository. The data integration device (10) can access these aspect models (AM ₁ , AM ₂ ). A reference to an aspect model (AM ₁ , AM ₂ ) assigned to this respective aspect agent (1a . . . k) is stored for each aspect agent (1a . . . k). Each of the aspect models (AM ₁ , AM ₂ ) describes at least part of the properties of the data received from the respective data-transmitting device (20a...20d) connected via one of the input interfaces (2a...2d). It can therefore be provided that the aspect model (AM ₁ , AM ₂ ) includes a semantic description of the runtime data that is present at the respective input interface (2a, ..., 2d), the semantic description being a description of a data type of the runtime data and /or a description of a permissible value range of values contained in the runtime data and/or description a description of a physical unit of the quantity described by values contained in the runtime data..

By being stored in the model repository, each of the aspect models (AM ₁ , AM ₂ ) can be assigned to a plurality of aspect agents (1a...1k).

Each of the aspect agents (1a...1k) is set up to receive data from the respectively connected data-transmitting device (20a...20d) and to make at least part of the data available at its output interface (3a...3k). place.

The aspect models (AM ₁ , AM ₂ ) each describe, for example, the structure of at least part of the data provided by the respective aspect model (AM ₁ , AM ₂ ) referring to aspect agents (1a...k), and/or properties of the data provided to these aspect agents (1a...k).

The properties of the data described include, for example, data types, possible or permissible value ranges, and/or a physical unit that represents the respective data.

The respective data received from the data-transmitting device (20a...d) are made available at the output interfaces (3a...k) and can be called up there. A reference to one or more associated aspect models (AM ₁ , AM ₂ ) is also assigned to each output interface (3a...k). The output interface (3a...k) can be used to call up those data from the data-transmitting device (20a...d) for which there are descriptions in the respective associated aspect models (AM ₁ , AM ₂ ).

Each aspect model (AM ₁ ,AM ₂ ) describes a data structure via which the associated output interface (3a...k) allows access to the parts of the data defined by the aspect model (AM ₁ ,AM ₂ ) and provides descriptive information for this ready.

First (3a), second (3b) and third output interface (3c) are connected to a first terminal (30a), for example a monitor for displaying the output interfaces connected to emp catch data, or a data processing device that further processes the received data, eg stores it in a database.

Because the data, to which the output interface (3a...k) offers access, takes place through the assigned aspect model (AM ₁ ,AM ₂ ), the data is accessed homogeneously, although at the input interface (2a... d) different devices (20a...d) can be connected.

3 illustrates a mechanism for coupling a data-transmitting device - here by way of example the coupling of the first device (20a). For coupling, a digital twin (14) of the first device (20a) is created (in particular, such a twin is provided for each coupled device) and made available under an access address (13). This happens based on definable aspect agents (1a...1k), here as in 2 illustrated by way of example on the first aspect agent (1a) and the fourth aspect agent (1d).

For this purpose, a single or multiple identifiers (12) of the first device (20a) to be coupled are stored in a registry (11), which can be stored in the memory (21), for example, as well as access addresses (17a, 17d) under which the output interfaces (3a...3k) can be accessed which are assigned to the aspect agents (1a...k) which are assigned to the device to be coupled, here: the first device (20a). In the exemplary embodiment, access addresses (17a, 17b) address the first output interface (3a) and the fourth output interface (3b).

Furthermore, in the registry (11) for each output interface (3a, 3d), i.e. each aspect agent (1a, 1d), a reference (16a, 16b) to the descriptive aspect model (AM ₁ , AM ₂ ) provided in the model repository will be provided.

The topology can of course vary. In particular, it is possible for a data structure, for example a table, that can be filtered according to identifiers (12) to be stored in the registry.

If a terminal (30a) is to perform an action that can be specified by the user on the first device (20a) - in the example - then access addresses (17a, 17b) are those of the first device (20a) via the first Input interface (2a) supplied data at the first (3a) and fourth (3d) output interface can be tapped, connected to stored aspect models (AM ₁ , AM ₂ ), each describing a partial aspect of the data supplied.

4 Illustrates an example in a flowchart of a method for providing a digital twin (14) with aspect agents (1a...k) and their use using the example of a blast furnace and a welding robot as data-transmitting devices (20a...d) to be coupled.

First (100) a user, for example a maintenance engineer, provides an aspect model (AM ₁ , AM ₂ ) for maintenance information in the model repository.

Then (110) a user input is received that accesses this provided aspect model (AM ₁ , AM ₂ ). An aspect agent (1a...k) is then generated, in particular automatically, which is set up to receive data from the blast furnace, to select the maintenance data contained therein, to transform it if necessary and at its output interface (3a...k) to provide.

Then (120) a separate digital twin (14) is entered in the registry (11) for each blast furnace of this type to be connected.

In particular, one or more entries in the registry can be added to each digital twin (130) with identifiers of the respective connected blast furnace. This allows the traceability of which devices (20a...d) an aspect agent (1a...k) provides data.

In general, the digital twin can be a separately maintained data structure, but it is also possible that it is embedded in a larger data structure. For example, it is possible for the information that makes up the digital twin to be aggregated in a list. The digital twin of a specifiable connected device can then be provided, for example, by filtering the list according to the indicator of the specifiable connected device.

Then (140) an entry of the output interface (3a...k) for the respective aspect agent (1a...k), here the maintenance aspect model, is made for each digital twin (14) in the registry (11).

This connects the blast furnace.

Another user can then also access this aspect model (AM ₁ ,AM ₂ ) and generate an aspect agent that collects data from a welding robot, selects maintenance data accordingly, transforms it and makes it available at the output interface.

First (150) there follows a step which is analogous to step (120).

Then (160) follows a step analogous to step (130).

Then (170) follows a step analogous to step (140).

In this example, a computer program that accesses this maintenance aspect model can now be provided for planning maintenance work. This computer program can now be used for both blast furnaces and welding robots. This computer program can access the registry (11) as described.

The respective aspect model (AM ₁ , AM ₂ ) follows the rules of a meta model. In particular, the aspect model (AM ₁ ,AM ₂ ) is structurally a directed graph in which nodes represent, describe, and identify individual data points (so-called "properties") as well as groups of data points that are generated at the exit interface (3a...k) of an aspect agent (1a...k) are provided.

The structure of the directed graph (i.e., the connections between the nodes of the data points and data point groups) thus allows the clear derivation of the structure of the (runtime) data at the output interface (3a..k) of the aspect agent (1a...k ) to be provided.

Furthermore, an aspect model (AM ₁ , AM ₂ ) graph contains one or more partial graphs (so-called "characteristics" after the English word for "characteristics"), which define the properties (data type, value range, physical unit, etc.) of the represented data points , wherein when the graph is traversed up to a predefinable data point, at least one or more such characteristic partial graphs can also be unambiguously reached for the data point. This is important because the (runtime) data provided by an aspect agent has the specified properties and must be interpreted accordingly. This makes it possible to clearly determine and provide these properties when traversing.

In 5 data of a blast furnace provided by an aspect agent (1a...k) is shown as an example. These show data regarding the internal and external operating temperature and current power consumption of the oven.

First, two data points are shown with the designations "power consumption" and "operating temperature". While power consumption has a scalar value of "35000", the value of "operating temperature" is a complex object, which in turn contains two more data points: "inside" and "outside", with scalar values of "600.0" and "35.6", respectively “.

6 shows an example of an aspect model for this aspect agents. The identifiers of the data points, i.e. "operating temperature" or "power consumption", each point to a characteristic partial graph that defines properties with regard to the data type and, as far as possible, its physical unit. The complex data type for "operating temperature" is also defined in the aspect model. This is done by specifying the data points contained. The values of the data points are not available in the aspect model because they are only provided at runtime and can change continuously.

Finally, it is also possible for the end device (30a...c) at the output interface to be able to specify access to runtime data via so-called "operations", or for information about the runtime data to be accessed, or for functions to be accessed, via which the connected device can be controlled.

It is also possible to define an operation in the aspect model as its function that can be called (e.g. "Switch on blast furnace" or "Switch off blast furnace"). Such an operation may require input data, and may provide output data. These can also be described in the aspect models, with the properties of the represented data points of the input/output data also being described with characteristic partial graphs. This input/output data may or may not be part of the otherwise retrievable data.

For example, an "operating state aspect model" of the furnace contains the representation of a data point "Status", with the characteristic subgraph describing two possible values as a value range: "on" or "off". In addition, the operating state aspect model can specify the operation "switch on" whose output data also contains the representation of the data point "status".

An aspect agent that follows an aspect model with operations must therefore offer the call of these operations at its "output interface" as an input interface for the flow of information in the opposite direction.

The properties that can be defined by the characteristic subgraphs within an aspect model in order to describe the data points represented in the aspect model are specified by a meta model. The properties that can be used for the description are divided into classes. These classes are specified in a hierarchical structure for describing a represented data point of selectable classes.

In addition, defining the properties that can be used to describe the data points in a class hierarchy allows the creation of aspect models in an editor that allows users to easily select the elements available for description.

An example of such a class hierarchy is in 7 shown. , where "A→ B" means that class A is a derived class from class B. It is important here that the hierarchical arrangement represents inheritance relations in an “is a” relationship, i.e. descriptive properties which can be represented by class B in an aspect model can also be represented by class A, where in class A additional properties can be shown. This makes it particularly easy to expand the classes.

• Die „Temp-Set-Eigenschaften“ sind von der Klasse „Single Entity“, die „Temperatur-Eigenschaften“ sind von der Klasse „Measurement und die „Power-Eigenschaften“ sind ebenfalls von der Klasse „Measurement“.

In the 7 The class hierarchy shown as an example serves to define usable properties in characteristic subgraphs as an example. Using this example hierarchy, the characteristic subgraphs from the in 6 exemplary aspect model can be assigned to the following classes:

• The "Temp Set Properties" are of the "Single Entity" class, the "Temperature Properties" are of the "Measurement" class and the "Power Properties" are also of the "Measurement" class.

In this case, the concrete occurrences of the characteristic partial graphs are instantiations of the classes provided in the class hierarchy.

The specification of a hierarchical structure of classes in a meta model with properties for data point description is a prerequisite for using the aspect models that follow the meta model.

For example, an aspect agent (1a...k) can be created automatically from existing aspect models.
•

Alternatively or additionally, evaluation functions (more precisely: a program code for this evaluation function) for the automated processing of data provided by aspect agents (1a...k) at their respective output interface (3a...k) can be generated.

Alternatively or additionally, the evaluation functions can be parameterized with aspect models.

Alternatively or additionally, descriptions in IDL (Interface Description Language) can be generated from provided aspect models. In turn, these can be used to enable an application to consume the data provided by the respective aspect agents. Alternatively or additionally, it is possible to generate semantic descriptions in ontology or logic formats such as OWL (Web Ontology Language) or CL (Common Logic) from existing aspect models. This makes it possible to integrate the data provided by an aspect agent and the associated aspect models in a structured database such as a knowledge graph.

Alternatively or additionally, professional or technical descriptions can be generated from provided aspect models, which describe the semantics of the aspect model in the respective domain in textual and graphical form, with the description of the structure of the aspect agents (1a...k) on contains the data provided at its output interface (3a...k) and also includes the classification in the technical context and the connection to elements from the relevant standards and norms.

Such fragments, ie evaluation functions or descriptions, can be generated from provided aspect models according to one of the methods presented below.

An embodiment of the first such method provides that the graph of the aspect model is traversed (preferably recursively). Furthermore, a mapping function is applied, which generates a suitable sub-element of the target format from the respective element of the aspect model, taking into account the associated semantics of the meta-model.

In the case of the evaluation function, the sub-elements are classes or functions, for example.

Property(Characteristic.class = Quantifiable) -> Class<Property.name>
 
(Characteristic.class = Quantifiable).unit -> Funktion: getUnit()

For example, to generate a monitoring application for operating data for blast furnaces in production, a mapping function can be defined, according to which all data points that are described by a characteristic subgraph, which is an instantiation of the "Measurement" class, are mapped to a specifiable class. Furthermore, the generated classes then allow automatic access to the unit of the data point with a specified function, as shown in the following lines of pseudocode as an example.

 Property(Characteristic.class = Quantifiable) ->Class<Property.name>
 
(Characteristic.class = Quantifiable).unit -> Function: getUnit()

Temperatur.innen 
Temperatur.außen
Leistungsaufnahme

The application of these mapping functions to the associated with 6 illustrated aspect model 1 using the associated with 7 The following three program code classes can then be generated from the class hierarchy shown as an example:

 temperature.inside 
temperature.outside
power consumption

Since the "Measurement" class corresponds to the in 8th hierarchy specified as an example is also a "quantifiable", the data points "Temperature. inside" and "Temperature. outside” can be recognized as applicable to the imaging condition.

Each of the generated program code classes allows access to the respective physical unit (Celsius or Watt) by calling the specified .getUnit () function.

The program code classes generated in this way allow the display of the data provided at its output interface (3a...k) of an aspect agent (1a...k), which provides data according to the aspect model, with automatic correct display of the physical unit of the values shown.

In addition, the same application can display any other data points (with a "quantifiable" characteristic) of other aspect agents by analogously automated generation of further program code classes for the corresponding aspect models.

A more specific use of the semantics of the elements in the aspect model is also possible, e.g. by configuration by the user of the application, which can specify, for example, that data points according to the characteristic “temperature properties” in a definable graphical form, for example in the form of a thermometer , or data points of the "Power Properties" characteristic are to be displayed as a level display.

An embodiment of a second method for generating the evaluation functions or descriptions provides a set of patterns ("patterns") for each target format that can recognize subgraphs of an aspect model (structural and content-related), i.e. a pattern check function checks all subgraphs of the aspect model whether these (structurally or in terms of content) match the provided pattern and, if they match, this subgraph is provided as recognized.

An associated set of partial elements of the target format is assigned to each pattern. For the generation process, all patterns for the respective target format are run through, each pattern is applied to the starting aspect model, and the subgraph of the aspect model resulting from pattern recognition is mapped to the subsets of the target format. Finally, all subsets are combined to get the result.

For example, in the automatic generation of an aspect agent that is to be linked to a blast furnace, it can be provided that the access addresses of the output interfaces are generated, so that in addition to the complete retrieval of all data points described in the associated aspect model, an individual retrieval of the individual data points by one of these data consuming application is enabled.

• Jeder repräsentierte Datenpunkt ergibt ein Pfadelement mit dem Namen des Datenpunktes. Ist ein repräsentierter Datenpunkt Teil einer Datenpunktsgruppe, ist das zugehörige Pfadelement der Nachfolger desjenigen Pfadelements, das dieser Datenpunktsgruppe zugeordnet ist.

For this purpose, paths of the access address are generated as follows: The generation includes the definition of a pattern, application to the respective aspect model and mapping to path elements, as follows:

• Each data point represented results in a path element with the name of the data point. If a represented data point is part of a data point group, the associated path element is the descendant of the path element that is assigned to this data point group.

This takes place within the characteristic subgraph specified by the metamodel.

/Betriebsdaten/Temperatur/innen
/Betriebsdaten/Temperatur/außen
/Betriebsdaten/Leistungsaufnahme

Applied to the example related to 6 The aspect model shown results in the following paths for the output interface of the aspect agent:

 /Operating data/Temperature/Inside
/operating data/temperature/outside
/Operating data/Power consumption

/Betriebsdaten

angenommen.)(This is used as a general access address for retrieving all data points described by the aspect model

 /Operational data

assumed.)

The hierarchical structure of the meta-model and compliance with the rules of the meta-model by the respective aspect model are essential for the two methods presented to be practicable. In addition, the description of the semantics that go beyond the structure of the data in the form of characteristics, which as model elements are an inherent part of an aspect model, is required. Mapping functions from aspect model elements or subgraphs of the aspect model to the respective target format must not only be able to refer to the semantics of the respective model elements specified by the meta model, but must also be able to evaluate the inheritance hierarchies of the referenced meta model elements. This is necessary both for the generation of program code for evaluation functions, in which the inheritance hierarchy can also be used in order - where necessary - to achieve analogous structures in generated classes. It is also required when generating other formats, where only inheritance ensures the degree of decoupling of the generated structures that is necessary for their effective use.

In a further aspect, the invention relates to an information processing system comprising the data integration device (10) according to one of the preceding claims and at least one connected device (20a, ..., 20d).

Provision can be made here for the connected device (20a, . . . , 20d) to be a sensor and/or an ERP system and/or a production machine and/or a robot and/or a vehicle and/or a charging station.

Furthermore, an information processing system comprising the data integration device (10) can be provided, comprising a terminal (30a...c) for processing data which is sent to the output interface (3a...k) to which the terminal (30a...c ) is connected.

Furthermore, an information processing system comprising the data integration device can be provided comprising an evaluation function for processing the data provided at the output interface (3a...k), the evaluation function using the aspect model (AM ₁ ,AM ₂ ) of the output interface (3a... k) associated aspect processing device (1a...k) is generated.

An information processing system can also be provided, the evaluation function being parameterized with the aspect model (AM ₁ , AM ₂ ) of the aspect processing device (1a...k) associated with the output interface (3a...k).

An information processing system can also be provided, with the terminal (30a...c) being set up to use a description generated with an aspect model (AM ₁ , AM ₂ ).

It can be provided that the description includes a semantic description in an ontology or logic format.

Provision can be made here for the end device (30a...c) to include a knowledge graph, and the end device (30a...c) being set up to be connected to an output interface (30a...c) by the associated aspect processing device (1a ... k) to integrate the data provided and the associated aspect models (AM ₁ , AM ₂ ) in the knowledge graph.

An information processing system can also be provided in which the terminal (30) provides a description that describes the semantics of one of the aspect models (AM ₁ , AM ₂ ), this description being generated using the respective aspect model (AM ₁ , AM ₂ ).

It can be provided that the description contains a structure of the data provided by the aspect processing device (1a...k) at its output interface (3a...k).

Furthermore, an information processing system can be provided, in which the generation includes a traversal of the graph of the aspect model (AM ₁ , AM ₂ ).

Provision can be made here for the generation to include the application of a mapping function, which generates a corresponding sub-element of the evaluation function or description from an element of the aspect model (AM ₁ , AM ₂ ), taking into account semantics of the meta-model.

It can also be provided that the corresponding partial element of the evaluation function is a class or a callable function.

Furthermore, an information processing system can be provided, in which the generating includes providing at least one pattern for identifying subgraphs of the graph of the aspect model (AM ₁ ,AM ₂ ).

Reference List

1a...1k

Aspect Processing Device, Aspect Agent

2a...2d

contraption

3a...3k

output interface

10

data integration device

11

registry

12

identifier (of the device to be paired)

13

Access address to digital twin

14

digital twin

15a, i.e

Reference to Aspect Agent

20

contraption

20a...d

contraption

30

end device

30a...c

end device

QUOTES INCLUDED IN DESCRIPTION

This list of the documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• DE 102018205872 A1 [0002]

Claims (16)

Data integration device (10), comprising input interfaces (2a, ..., 2d), to which a runtime data to the input interface (2a, ..., 2d) supplying device (20a, ..., 20d) can be connected, wherein the Runtime data of the respective device (20a, ..., 20d) are characterized by means of at least one of the respective input interface (2a, ..., 2d) assigned and each aspect of the runtime data characterizing aspect model (AM ₁ , AM ₂ ), characterized in that that the respective input interface (2a, ..., 2d) is associated with the respective aspect model (AM ₁ , AM ₂ ). Data integration device (10) after claim 1 , characterized in that the respective input interface (2a, ..., 2d) is connected to an aspect processing device (1a, ..., 1k) with which the respective aspect model (AM ₁ , AM ₂ ) is associated. Data integration device (10) according to one of the preceding claims, wherein at least one of the aspect processing devices (1a, ..., 1k) has an output interface (3a, ..., 3k), in particular each of the aspect processing devices has an output interface (3a, ..., 3k). Data integration device (10) after claim 3 , wherein the at least one aspect processing device (1a, ..., 1k), in particular all aspect processing devices (1a, ..., 1k), are set up to provide part of that runtime data at its output interface (3a, ..., 3k), which are provided at those input interfaces (2a, ..., 2d) with which the respective aspect processing device (1a, ..., 1k) is associated. Data integration device (10) after claim 4 , wherein the part of the runtime data provided at the output interface (3a, ..., 3k) is contained in the aspect of the runtime data that characterizes that aspect model (AM ₁ , AM ₂ ) that is processed with the aspect processing device (1a, ..., 1k) to which the output interface (3a, ..., 3k) belongs. Data integration device (10) after claim 5 , wherein the part provided at the output interface (3a, ..., 3k) comprises all those runtime data that characterizes that aspect model (AM ₁ , AM ₂ ) that is associated with the aspect processing device (1a, ..., 1k), to which the output interface (3a, ..., 3k) belongs. A data integration device (10) according to any one of the preceding claims, wherein a plurality of input interfaces (2a, ..., 2d) are associated with the same aspect model (AM ₁ , AM ₂ ). Data integration device (10) according to one of the preceding claims, comprising a registry (11) in which a reference (12) to a provided digital twin (14) is registered for each connected device (20a...d). Data integration device (10) after claim 8 if related to claim 2 , wherein the respective digital twin (14) to the connected device (20a, ..., 20d) comprises references to the aspect processing devices (1a, ..., 1k) with which the input interface (2a, ..., 2d) to which the device is connected. Data integration device (10) according to one of the preceding claims, wherein the aspect model (AM ₁ , AM ₂ ) is constructed according to rules defined in a meta model. Data integration device (10) after claim 10 , wherein a structure of the aspect model (AM ₁ ,AM ₂ ) is a directed graph, in which directed graph nodes particularly identify individual data points and/or groups of data points. Data integration device (10) after claim 11 , wherein the structure of the aspect model (AM ₁ ,AM ₂ ) contains at least one partial graph that describes the properties of the data points identified by the nodes and/or the properties of the data points of the group identified by the nodes. Data integration device (10) after claim 12 , where when traversing the graph up to a specifiable node, at least one such partial graph can also be reached unambiguously. Data integration device (10) after Claim 13 , which is set up to interpret data received from the connected device (20a...d) in accordance with the properties described in this partial graph. Data integration device (10) according to one of Claims 13 or 14 , where the properties defined by the subgraph are given by the metamodel. Data integration device (10) after claim 15 , where the properties are divided into classes, and where the classes are given in a hierarchical structure of selectable classes.

Images