Apparatus for managing digital twins

Abstract

Data integration apparatus (10) comprising input interfaces (2a,...,2d), each of which is connectable to an apparatus (20a,...,20d) which provides runtime data to the input interface (2a,...,2d), wherein the runtime data of the respective apparatus (20a,...,20d) is characterized by means of at least one aspect model (AM1, AM2) which is assigned to the respective input interface (2a,...,2d) and which characterizes an aspect of the runtime data, respectively, characterized in that the respective input interface (2a,...,2d) is associated with the respective aspect model (AM1, AM2).

Description

Technical Field

[0001] This invention relates to a data integration device. Background Technology

[0002] A method for generating a digital twin of a physical object is known from DE 10 2018 205 872 A1, wherein descriptive data containing digital data attributes is generated based on a descriptive meta-model. Communication information is also created. To generate the digital twin, the descriptive data, the communication information, and the name of the physical object are combined. Summary of the Invention

[0003] In comparison, the advantage of the present invention, which has the features of independent claim 1, is that it realizes a flexible system that can process runtime data from a large number of heterogeneous data sources without additional communication costs and uniformly provide the runtime data.

[0004] Other aspects of the invention are the subject of the independent claims. Advantageous extensions are the subject of the dependent claims. Attached Figure Description

[0005] Embodiments of the present invention will now be explained in more detail with reference to the accompanying drawings. In the drawings:

[0006] Figure 1 The use of the invention is illustrated by way of example;

[0007] Figure 2 The data flow through the data integration device is illustrated schematically;

[0008] Figure 3 The mechanism for coupling the data transmission device is illustrated schematically;

[0009] Figure 4 The flowchart illustrates, for example, a method for providing digital twins;

[0010] Figure 5 The data for the blast furnace provided by the aspect agent is shown as an example;

[0011] Figure 6 An example is shown of the aspect model of the aspect proxy;

[0012] Figure 7 An exemplary class hierarchy for defining the properties of a subgraph of an aspect model is shown. Detailed Implementation

[0013] Figure 1The use of the invention is illustrated by way of example. A data integration device (10) is provided to be coupled to a device (20) and a client device (30). The device (20) may be, for example, a sensor and / or an ERP system and / or a manufacturing machine such as a blast furnace and / or a robot such as a welding robot and / or a vehicle and / or a charging station, such as a charging station for an electric vehicle. The coupled device (20) is configured to transmit information to the data integration device (10).

[0014] The client device (30) may be, for example, a playback device, but it may also be a device that accesses the device (20) in a controlled manner.

[0015] Figure 2 In one embodiment, a data flow is illustrated through a data integration device (10). Each device (20a...d) is coupled to the data integration device (10) via an input interface (2a...2d). Each data integration device (10) is connected to one or more aspect agents (1a...k) (also referred to as aspect processing devices), where it is possible that different coupled devices (20a...d) are connected to the same aspect agent (1a...k) via their respective input interfaces (2a...d).

[0016] Therefore, it can be specified that multiple input interfaces (2a, ..., 2d) are connected to the same aspect processing device (1a, ..., 1k). Alternatively or additionally, it can be specified that multiple aspect models (AM1, AM2) are associated with at least one input interface (2a, ..., 2d), and / or at least one input interface (2a, ..., 2d) is connected to multiple aspect processing devices (1a, ..., 1k).

[0017] The aspect agents are referred to as the first aspect agent (1a), the second aspect agent (1b), the third aspect agent (1c), the fourth aspect agent (1d), the fifth aspect agent (1e), the sixth aspect agent (1f), the seventh aspect agent (1g), the eighth aspect agent (1h), the ninth aspect agent (1i), the tenth aspect agent (1j), and the eleventh aspect agent (1k). Each aspect agent has an output interface (3a...3k), which is designated with the same number as the aspect agent as the first output interface (3a), the second output interface (3b), the third output interface (3c), the fourth output interface (3d), the fifth output interface (3e), the sixth output interface (3f), the seventh output interface (3g), the eighth output interface (3h), the ninth output interface (3i), the tenth output interface (3j), and the eleventh output interface (3k), wherein the first aspect agent (1a) has the first output interface (3a), the second aspect agent has the second output interface, and so on.

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

[0019] The third device (20c) is coupled to the ninth-aspect agent (1h) via the third input interface (2c). Similarly, the fourth device (20d) is coupled to the ninth-aspect agent (1h) via the fourth input interface (2d).

[0020] Each input interface (2a...d) is configured to receive data from the respective connected device (20a...d) in a format specific to the device (20a...d) connected to that input interface.

[0021] See Figure 3 One or more (semantic) aspect models (AM1, AM2) are stored in a dedicated location in the memory (21) allocated to the data integration device (10), i.e., the so-called model library. The data integration device (10) can access these aspect models (AM1, AM2). A reference to the aspect model (AM1, AM2) allocated to each aspect agent (1a...k) is stored. Each aspect model (AM1, AM2) describes at least a portion of the attributes of the data received from the corresponding data transmitting device (20a...20d) connected via one of the input interfaces (2a...2d). Thus, it can be specified that the aspect model (AM1, AM2) includes a semantic description of the runtime data present at the corresponding input interface (2a,...,2d), wherein the semantic description includes a description of the data type of the runtime data and / or a description of the allowed value range of the values ​​contained in the runtime data and / or a description of the physical units of the variables described by the values ​​contained in the runtime data.

[0022] By storing them in the model library, each aspect model (AM1, AM2) can be assigned to multiple aspect agents (1a...1k).

[0023] Each aspect agent (1a...1k) is configured to receive data from the connected data transmission device (20a...20d) and provide at least a portion of the data at its output interface (3a...3k).

[0024] Each aspect model (AM1, AM2) describes, for example, the structure of at least a portion of the data provided by the corresponding aspect agent (1a...k) that references that aspect model (AM1, AM2), and / or the attributes of the data provided by that aspect agent (1a...k).

[0025] The attributes of the described data include, for example, the data type, the possible or allowed range of values, and / or the physical unit represented by the corresponding data.

[0026] The corresponding data received by the data transmitting device (20a...d) is provided at the output interface (3a...k) and can be invoked there. Here, a reference to one or more associated aspect models (AM1, AM2) is also assigned to each output interface (3a...k). The following data from the data transmitting device (20a...d) can be invoked via the output interface (3a...k), for which descriptions exist in the respective associated aspect models (AM1, AM2).

[0027] Therefore, each aspect model (AM1, AM2) describes the following data structure, through which the associated output interface (3a...k) can access the data portion defined by that aspect model (AM1, AM2) respectively, and each aspect model (AM1, AM2) provides descriptive information for this purpose.

[0028] The first output interface (3a), the second output interface (3b), and the third output interface (3c) are connected to the first terminal (30a) (e.g., a monitor for displaying data received via the connected output interfaces) or a data processing device for further processing the received data, such as storing it in a database.

[0029] Since the output interface (3a...k) provides access to the data through the assigned aspect model (AM1, AM2), the data is accessed uniformly, even though different devices (20a...d) can be connected to the input interface (2a...d).

[0030] Figure 3 The diagram illustrates a mechanism for coupling data transmission devices—exemplarily, here, coupling a first device (20a). For coupling, a digital twin (14) of the first device (20a) is created (specifically, such a digital twin is provided for each coupled device) and this data twin is provided under an access address (13). This is accomplished based on pre-given aspect proxies (1a...1k), as shown here... Figure 2 As shown, the example is based on the first aspect agent (1a) and the fourth aspect agent (1d).

[0031] For this purpose, one or more identifiers (12) and access addresses (17a, 17d) of the first device (20a) to be coupled are stored in a registry (11), which may be stored, for example, in memory (21), under which the output interfaces (3a...3k) assigned to aspect agents (1a...k) to be coupled, in this case, the first device (20a), can be accessed. In this embodiment, the access addresses (17a, 17b) address the first output interface (3a) and the fourth output interface (3b).

[0032] In addition, the registry (11) provides a reference (16a, 16b) to the descriptive aspect model (AM1, AM2) provided in the model repository for each output interface (3a, 3d), i.e. each aspect agent (1a, 1d).

[0033] The topology can, of course, be different. In particular, data structures, such as tables, that can be filtered according to identifiers (12) can be stored in the registry.

[0034] If the terminal (30a) is now required to perform a user-predefined action on the first device (20a) (in this example), then data provided by the first device (20a) via the first input interface (2a) can be retrieved at the first output interface (3a) and the fourth output interface (3d) in association with the stored aspect models (AM1, AM2), where each aspect model describes a sub-aspect of the provided data.

[0035] Figure 4 The flowchart exemplarily illustrates a method for providing a digital twin (14) with aspect agents (1a...k) and its use, exemplified by a blast furnace and a welding robot as coupled data transmission devices (20a...d).

[0036] First (100) users (e.g., maintenance engineers) provide aspect models (AM1, AM2) for maintenance information in the model library.

[0037] Then (110) receives user input to access the provided aspect model (AM1, AM2). Then an aspect agent (1a...k) is generated, specifically automatically, which is set to receive data from the blast furnace, select maintenance data contained in the data, transform the maintenance data if necessary, and provide it at its output interface (3a...k).

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

[0039] Specifically, one or more entries can be added (130) to the registry for each digital twin, along with the identifier of the corresponding blast furnace. This allows tracking of which devices (20a...d) the aspect agent (1a...k) receives data from.

[0040] Generally, a digital twin can be a standalone data structure, but it can also be embedded within a larger data structure. Thus, for example, it's possible that the information constituting the digital twin is compiled in a list. A digital twin of a pre-defined connected device can then be provided, for example, by filtering the list according to indicators of a pre-defined connected device.

[0041] Subsequently (140) for each digital twin (14), the output interface (3a...k) of the corresponding aspect agent (1a...k) is entered into the registry (11), which is the maintenance aspect model.

[0042] The blast furnace is coupled with the agency in this area.

[0043] Then other users can also access the aspect model (AM1, AM2) and generate aspect agents, which obtain data from the welding robot, select and transform maintenance data accordingly, and provide the maintenance data at the output interface.

[0044] Next, step (150) is similar to step (120).

[0045] Then comes step (160), which is similar to step (130).

[0046] Then comes step (170), which is similar to step (140).

[0047] In this example, a computer program that can now access the maintenance aspect model can be provided to plan maintenance work. This computer program can now be used for both the blast furnace and the welding robot. This computer program can access the registry (11) as described above.

[0048] The corresponding aspect models (AM1, AM2) follow the rules of the metamodel. In particular, the aspect models (AM1, AM2) are structurally directed graphs, in which nodes represent, describe, and identify individual data points (so-called "properties") and groups of data points provided at the output interfaces (3a...k) of the aspect agents (1a...k).

[0049] The structure of a directed graph (i.e., the connections between nodes of data points and groups of data points) thus allows for the explicit export of the structure of the (runtime) data provided at the output interface (3a..k) of the aspect agent (1a...k).

[0050] Furthermore, the aspect model (AM1, AM2) graph contains one or more subgraphs (so-called "characteristics") that define the attributes (data type, value range, physical unit, etc.) of the data points they represent. When traversing the graph until a predefined data point is reached, at least one or more such characteristic subgraphs can be explicitly reached for that data point. This is important because the (runtime) data provided through the aspect agent has predefined attributes and must be interpreted accordingly. These attributes can thus be explicitly determined and provided during traversal.

[0051] exist Figure 5 The example shown is data about a blast furnace provided by an aspect agent (1a...k). This data includes information about the furnace's internal and external operating temperatures and current power consumption.

[0052] The first two data points are displayed, named "Power Consumption" and "Operating Temperature". While the power consumption scalar value is "35000", the "Operating Temperature" value is a complex object that contains two additional data points: "Internal" and "External", with scalar values ​​of "600.0" and "35.6" respectively.

[0053] Figure 6 An example of the aspect model of this aspect proxy is shown. The name of the data point, namely "operating temperature" or "power consumption," points to a feature subgraph that sets attributes about the data type and, if possible, its physical unit. The complex data type of "operating temperature" is also defined in the aspect model. This is done by specifying the included data points. The values ​​of the data points do not exist in this aspect model because these values ​​are only provided at runtime and can change continuously.

[0054] Finally, it is also possible that the terminal (30a...c) can pre-define access to runtime data, or access information about runtime data, or access functions that can be used to manipulate connected devices at the output interface via so-called "operations".

[0055] Similarly, operations in an aspect model can be defined as functions that can be called (e.g., "start the blast furnace" or "stop the blast furnace"). Such operations may require input data and can provide output data. They can also be described in the aspect model, where the attributes of the data points represented by the input / output data are described using feature subgraphs. This input / output data may or may not be part of the data that would otherwise be callable.

[0056] For example, the furnace's "operational state aspect model" contains representations of data point "states," where a feature subgraph describes two possible values ​​as a range: "on" or "off." Furthermore, the operational state aspect model can describe the operation "on," whose output data also contains representations of data point "states."

[0057] An aspect agent that follows an aspect model with operations must provide calls to these operations at its "output interface," which serves as the input interface for information flow in the opposite direction.

[0058] The attributes that describe the data points represented in the aspect model can be defined through feature subgraphs within the aspect model, pre-defined by the metamodel. Here, the attributes that can be used for description are categorized into classes. These classes are pre-defined in a hierarchy that describes the data points represented by optional classes.

[0059] Furthermore, setting possible attributes for describing data points in the class hierarchy allows the creation of aspect models in an editor that enables users to easily select elements that can be used for description.

[0060] An example of this class hierarchy is... Figure 7 As shown, "A->B" indicates that class A is derived from class B. Importantly, the hierarchical arrangement uses an "is a" relationship to represent inheritance, meaning that descriptive attributes that can be represented by class B in the aspect model can also be represented by class A, where additional attributes can be represented in class A. This makes extending these classes particularly simple.

[0061] Figure 7 The exemplary class hierarchy shown is used to exemplarily define the available attributes in a feature subgraph. Using this exemplary hierarchy, attributes from... Figure 6 The feature subgraphs of the aspect model illustrated in the example are assigned to the following classes:

[0062] The "Temp-Set-Eigenschaften" attribute belongs to the class "Single Entity", the "Temp attribute" belongs to the class "Measurement", and the "Power attribute" also belongs to the class "Measurement".

[0063] Here, the specific representation of the feature subgraph is the instantiation of classes provided in the class hierarchy.

[0064] In a metamodel with attributes for describing data points, a predefined hierarchy of classes is a prerequisite for using an aspect model that follows the metamodel.

[0065] For example, aspect proxies (1a...k) can be automatically created from an existing aspect model.

[0066] Alternatively or additionally, an evaluation function (more precisely, the program code of the evaluation function) can be generated for automatically processing the data provided by the aspect agent (1a...k) at its respective output interface (3a...k).

[0067] Alternatively or additionally, the evaluation function can be parameterized using an aspect model.

[0068] Alternatively or additionally, descriptions in IDL (Interface Description Language) can be generated from the provided aspect model. These descriptions can then be used to enable applications to consume data provided through the corresponding aspect proxies.

[0069] Alternatively or additionally, semantic descriptions in ontology or logical formats—such as OWL (Web Ontology Language) or CL (General Logic)—can be generated from existing aspect models. This allows data provided through aspect agents, along with associated aspect models, to be integrated into structured databases such as knowledge graphs.

[0070] Alternatively or additionally, descriptions of functions or technologies can be generated from the provided aspect model, which describe the semantics of the aspect model in the corresponding domain in textual and graphical form, wherein the description includes the structure of the data provided by the aspect agent (1a...k) at its output interface (3a...k), and also includes classifications in the functional context and connections with various elements from relevant standards and specifications.

[0071] Such a fragment, namely the evaluation function or description, can be generated from the provided aspect model according to one of the methods shown below.

[0072] One implementation of this first method specifies that the graph of the aspect model is traversed (preferably recursively). Furthermore, a mapping function is applied that generates suitable sub-elements of the target format from the corresponding elements of the aspect model, taking into account the associated semantics of the meta-model.

[0073] In the case of the evaluation function, the sub-element is, for example, a class or a function.

[0074] For example, to generate a monitoring application for blast furnace operating data in production, a mapping function can be defined that maps all data points described by a feature subgraph to a predefined class, where the feature subgraph is an instantiation of the class "Measurement". Furthermore, the resulting class then allows automatic access to the units of the data points using a predefined function, as exemplified by the following pseudocode line:

[0075] .

[0076] Then, use combination Figure 7 The exemplary class hierarchy shown applies these mapping functions to the combination Figure 6 The aspect model 1 shown can generate the following three program code classes:

[0077] .

[0078] Because the class "Measurement" corresponds to Figure 7 The hierarchical structure exemplified in the example is also "Quantifiable," therefore data points can be "quantifiable." "and" "Identified as applicable to the mapping conditions."

[0079] Each generated program code class allows calling pre-given functions. To access the corresponding physical unit (Celsius or Watt).

[0080] The program code class generated in this way allows the display of data provided by the aspect agent (1a...k) at its output interface (3a...k), which corresponds to the data provided by the aspect model, and automatically corrects the display of the physical units of the values ​​displayed.

[0081] Furthermore, the same application can automatically generate additional program code classes for the corresponding aspect model to display any other data points (with the "Quantifiable" characteristic) that are proxies of other aspects.

[0082] More specific use of element semantics in the aspect model is also possible, for example by configuration by the user of the application, which may be set to display data points on a level display in a predefined graphical form (e.g., in the form of a thermometer) according to the feature "temperature attribute" or the feature "power attribute".

[0083] The implementation of the second method for generating evaluation functions or descriptions specifies that a set of patterns is provided for each target format. These patterns can identify subgraphs of the aspect model (in terms of structure and content). That is, the pattern checking function checks all subgraphs of the aspect model to see if they are consistent with the provided patterns (in terms of structure or content), and if they are consistent, the subgraph is provided as identified.

[0084] Here, each pattern is assigned an associated set of sub-elements of the target format. For the generation process, all patterns of the corresponding target format are traversed, each pattern is applied to the output aspect model, and the aspect model subgraph generated by pattern recognition is mapped to a subset of the target format. Finally, all subsets are unified to obtain the result.

[0085] For example, when automatically generating aspect proxies that should be coupled to the blast furnace, the access address of the output interface can be specified, thereby enabling individual data points to be invoked by the application consuming the data, in addition to fully invoking all data points described in the associated aspect model.

[0086] Therefore, the path for the access address is generated as follows: the generation includes setting the pattern, applying the corresponding aspect model, and mapping to path elements, as follows:

[0087] Each data point generates a path element with the name of that data point. If the data point being represented is part of a group of data points, the associated path element is the successor to the path element assigned to that group of data points.

[0088] This is done within the feature subgraphs pre-given by the metamodel.

[0089] Applied to combination Figure 6 The exemplary aspect model generates the following path for the output interface of the aspect proxy:

[0090]

[0091] (Here, in order to call all data points described by the aspect model, it is assumed that...)

[0092]

[0093] (This is a generic access address.)

[0094] For the two proposed methods to be implemented, the hierarchy of the metamodel and the adherence of the corresponding aspect models to the metamodel rules are crucial. Furthermore, the semantics beyond the data structure need to be described in the form of features, which are inherent parts of the aspect model as model elements. The mapping function that maps aspect model elements or subgraphs of the aspect model to the corresponding target format must not only be able to reference the semantics of the corresponding model elements pre-given by the metamodel, but also be able to evaluate the inheritance hierarchy of the referenced metamodel elements. This is necessary for the program code that generates the evaluation function, where the inheritance hierarchy can also be used (if necessary) to implement a similar structure in the generated class. Similarly, this is required when generating other formats, where only inheritance can guarantee the degree of decoupling of the generated structure, which is practically necessary for the use of the structure.

[0095] In another aspect, the present invention relates to an information processing system comprising a data integration device (10) according to any one of the preceding claims and at least one connecting device (20a, ..., 20d).

[0096] It can be specified here that the connected devices (20a, ..., 20d) are sensors and / or ERP systems and / or manufacturing machines and / or robots and / or vehicles and / or charging stations.

[0097] In addition, an information processing system including a data integration device (10) may be provided, including a terminal (30a...c) for processing data provided at an output interface (3a...k), the terminal (30a...c) being connected to the output interface.

[0098] Furthermore, an information processing system including a data integration device can be provided, comprising an evaluation function for processing data provided at an output interface (3a...k), wherein the evaluation function is generated using an aspect model (AM1, AM2) of an aspect processing device (1a...k) associated with the output interface (3a...k).

[0099] In addition, an information processing system can be provided in which the evaluation function is parameterized using the aspect model (AM1, AM2) of the aspect processing device (1a...k) associated with the output interface (3a...k).

[0100] In addition, an information processing system can be provided in which terminals (30a...c) are configured to use descriptions generated by aspect models (AM1, AM2).

[0101] It may be specified here that the description includes a semantic description in an ontology or logical format.

[0102] It can be specified here that the terminal (30a...c) includes a knowledge graph, and wherein the terminal (30a...c) is configured to integrate data provided at the output interface (30a...c) by the associated aspect processing device (1a...k) and the associated aspect models (AM1, AM2) into the knowledge graph.

[0103] In addition, an information processing system may be provided in which a terminal (30) prepares a description of the semantics of one of the aspect models (AM1, AM2), wherein the description is generated by means of the corresponding aspect model (AM1, AM2).

[0104] It can be specified here that the description includes the structure of the data provided by the aspect processing device (1a...k) at its output interface (3a...k).

[0105] In addition, an information processing system may be provided in which the generation includes a graph of traversing aspect models (AM1, AM2).

[0106] It can be specified here that the generation includes applying a mapping function that generates the evaluation function or the corresponding sub-elements of the description from the elements of the aspect model (AM1, AM2) while taking into account the semantics of the meta-model.

[0107] It can also be specified here that the corresponding sub-element of the evaluation function is a class or a callable function.

[0108] In addition, an information processing system may be provided, wherein the generation includes providing at least one pattern of a subgraph of a graph for identifying aspect models (AM1, AM2).

[0109] List of reference numerals

[0110] 1a...1k aspect processing device, aspect agent

[0111] 2a…2d apparatus

[0112] 3a…3k output interface

[0113] 10 Data Integration Device

[0114] 11 Registry

[0115] 12 (Identifier of the device to be coupled)

[0116] 13. Access address pointing to the digital twin

[0117] 14 Digital Twins

[0118] 15a,d References to peer proxy

[0119] 20 devices

[0120] 20a...d apparatus

[0121] 30 terminals

[0122] 30a...c terminal.

Claims

1. A data integration apparatus (10) comprising input interfaces (2a, ..., 2d) and aspect processing devices (1a, ..., 1k), each input interface being connectable to a device (20a, ..., 20d) providing runtime data to the input interface (2a, ..., 2d), each aspect processing device being connected to at least one of the input interfaces, wherein runtime data capable of being connected to a corresponding device (20a, ..., 20d) is characterized by at least one aspect model (AM1, AM2) assigned to the respective input interface (2a, ..., 2d) and respectively representing an aspect of the runtime data, wherein the respective input interface (2a, ..., 2d) is associated with the respective aspect model (AM1, AM2), characterized in that, The data integration device (10) further includes a registry (11) in which references (12) to the provided digital twin (14) are registered for each connected device (20a, ..., 20d), wherein the corresponding digital twin (14) for the connected device (20a, ..., 20d) includes references to aspect processing devices (1a, ..., 1k) connected to an input interface (2a, ..., 2d) connected to the device.

2. The data integration device (10) according to claim 1, characterized in that, The corresponding aspect processing device (1a, ..., 1k) is associated with the corresponding aspect model (AM1, AM2).

3. The data integration apparatus (10) according to any one of claims 1 to 2, wherein at least one aspect processing device (1a, ..., 1k) has an output interface (3a, ..., 3k).

4. The data integration apparatus (10) according to claim 3, wherein the at least one aspect processing device (1a, ..., 1k) is configured to provide a portion of runtime data at its output interface (3a, ..., 3k), the runtime data being provided at an input interface (2a, ..., 2d) associated with the respective aspect processing device (1a, ..., 1k).

5. The data integration apparatus (10) according to claim 4, wherein a portion of the runtime data provided at the output interface (3a, ..., 3k) is included in the runtime data, the aspect being characterized by an aspect model (AM1, AM2) associated with the aspect processing apparatus (1a, ..., 1k) to which the output interface (3a, ..., 3k) belongs.

6. The data integration apparatus (10) according to claim 5, wherein the portion provided at the output interface (3a, ..., 3k) includes all of the following runtime data, which are characterized by aspect models (AM1, AM2) associated with the aspect processing apparatus (1a, ..., 1k) to which the output interface (3a, ..., 3k) belongs.

7. The data integration apparatus (10) according to any one of claims 1 to 2, wherein a plurality of input interfaces (2a, ..., 2d) are associated with the same aspect model (AM1, AM2).

8. The data integration apparatus (10) according to any one of claims 1 to 2, wherein the aspect models (AM1, AM2) are constructed according to rules defined in the metamodel.

9. The data integration apparatus (10) according to claim 8, wherein the aspect model (AM1, AM2) is a directed graph, wherein the nodes in the directed graph identify individual data points and / or groups of data points.

10. The data integration apparatus (10) according to claim 9, wherein the structure of the aspect model (AM1, AM2) includes at least one subgraph describing the attributes of data points identified by the nodes and / or the attributes of groups of data points identified by the nodes.

11. The data integration apparatus (10) according to claim 10, wherein at least one such subgraph can be explicitly reached while traversing the graph up to a pre-given node.

12. The data integration apparatus (10) according to claim 11, wherein the data integration apparatus is configured to interpret data received from the connected apparatus (20a...d) in accordance with the attributes described in the sub-diagram.

13. The data integration apparatus (10) according to any one of claims 11 or 12, wherein the attributes set by the subgraph are pre-given by the meta-model.

14. The data integration apparatus (10) of claim 13, wherein the attributes are divided into classes, and wherein the classes are pre-given in a hierarchy of selectable classes.

Images