Method and apparatus for generating data integration

Abstract

Data integration apparatus (10) comprising input interfaces (2a,...,2d), each of which is connectable to an apparatus (20a,...,20d) providing 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) assigned to the respective input interface (2a,...,2d) and respectively characterizing one aspect of the runtime data, characterized in that the respective input interface (2a,...,2d) is associated with the respective aspect model (AM1, AM2).

Description

TECHNICAL FIELD

[0001] The invention relates to a method for producing a data integration device, a computer program, a machine-readable storage medium and a computer. BACKGROUND

[0002] From DE 10 2018 205 872 A1 a method for producing a digital twin of a physical object is known, wherein a description data containing digital data attributes is produced on the basis of a description meta model. Communication information is also created. To produce the digital twin, the description data, the communication information and a name of the physical object are combined. SUMMARY

[0003] In comparison, the invention having the features of independent claim 1 is advantageous in that it provides a data integration device which can be flexibly coupled with a large number of (runtime) data, wherein it is ensured that various specific properties of the respective (runtime) data can be taken into account in the interpretation in order to be able to ensure that the respective (runtime) data is correctly interpreted.

[0004] Further aspects of the invention are subject of the dependent claims. Advantageous extensions are subject of the dependent claims. BRIEF DESCRIPTION OF DRAWINGS

[0005] Embodiments of the invention are explained in more detail below with reference to the drawings. In the drawings:

[0006] Figure 1 The use of the invention is exemplarily shown;

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

[0008] Figure 3 The mechanism for coupling the data sending device is schematically shown;

[0009] Figure 4 The method for providing a digital twin is exemplarily shown in a flow chart;

[0010] Figure 5 The data provided by the aspect agent for a blast furnace is exemplarily shown;

[0011] Figure 6 The aspect model of the aspect agent is exemplarily shown;

[0012] Figure 7 The class hierarchy for setting properties of subgraphs of the aspect model is exemplarily shown. DETAILED DESCRIPTION

[0013] Figure 1 The use of the application is exemplarily shown. A data integration device (10) is provided which is coupled with devices (20) and a client device (30). The devices (20) can be, for example, sensors and / or ERP systems and / or manufacturing machines such as blast furnaces and / or robots such as welding robots and / or vehicles and / or charging stations, for example for electric vehicles. The coupled devices (20) are arranged to transmit information to the data integration device (10).

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

[0015] Figure 2 In one embodiment it is shown how the data flow through the 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 called 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 interface (2a...d). The aspect agents are called first aspect agent (1a), second aspect agent (1b), third aspect agent (1c), fourth aspect agent (1d), fifth aspect agent (1e), sixth aspect agent (1f), seventh aspect agent (1g), eighth aspect agent (1h), ninth aspect agent (1i), tenth aspect agent (1j) and eleventh aspect agent (1k). Each aspect agent has an output interface (3a...3k) which is called first output interface (3a), second output interface (3b), third output interface (3c), fourth output interface (3d), fifth output interface (3e), sixth output interface (3f), seventh output interface (3g), eighth output interface (3h), ninth output interface (3i), tenth output interface (3j) and eleventh output interface (3k) with the same numbering as the aspect agents, where the first aspect agent (1a) has the first output interface (3a), the second aspect agent has the second output interface, and so on.

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

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

[0018] Each input interface (2a...d) is arranged to receive data from the device (20a...d) connected to it in a format specific to the device (20a...d) connected to it, respectively.

[0019] Referring to Figure 3 , one or more (semantic) aspect models (AM1, AM2) are stored in a dedicated location in a memory (21) assigned to the data integration device (10), a so-called model base. The data integration device (10) has access to these aspect models (AM1, AM2). For each aspect agent (1a...k) a reference to the aspect model (AM1, AM2) assigned to the respective aspect agent (1a...k) is stored. Each aspect model (AM1, AM2) describes at least a part of the properties of the data received from the respective data sending device (20a...20d) connected via one of the input interfaces (2a...2d).

[0020] By being stored in the model base, each aspect model (AM1, AM2) can be assigned to multiple aspect agents (1a...1k).

[0021] Each aspect agent (1a...1k) is arranged to receive data from the connected data sending device (20a...20d), respectively, and to provide at least a part of said data at its output interface (3a.....3k).

[0022] Each aspect model (AM1, AM2) describes, for example, the structure of at least a part of the data provided by the respective aspect agent (1a...k) referring to this aspect model (AM1, AM2), and / or the properties of the data provided by the aspect agent (1a...k).

[0023] The properties of the data described include, for example, the data type, possible or allowed value ranges and / or the physical unit the respective data represents.

[0024] The respective data received by the data sending device (20a...d) is provided at the output interface (3a...k) and can be invoked there. Here, each output interface (3a...k) is also assigned a reference to one or more associated aspect models (AM1, AM2). The following data of the data sending device (20a...d) can be invoked via the output interface (3a...k) for which a description exists in the respectively associated aspect model (AM1, AM2).

[0025] Thus, each aspect model (AM1, AM2) here describes a data structure by means of which the associated output interface (3a...k) is enabled to access the data portion defined by the aspect model (AM1, AM2) respectively, and each aspect model (AM1, AM2) for this purpose provides descriptive information.

[0026] The first output interface (3a), the second output interface (3b) and the third output interface (3c) are connected to a first terminal (30a) (for example a monitor for displaying the data received via the connected output interface) or to a data processing device for further processing the received data, for example for storage in a database.

[0027] Since the data to which the output interfaces (3a...k) provide access is provided by the assigned aspect models (AM1, AM2), the data is accessed uniformly, although different devices (20a...d) can be connected to the input interfaces (2a...d).

[0028] Figure 3 A mechanism for coupling the data sending device, here exemplarily the first device (20a), is illustrated. For the coupling, a digital twin (14) of the first device (20a) is created (in particular, such a digital twin is provided for each coupled device) and provided under an access address (13). This is done on the basis of the predefinable aspect agents (1a...1k), here exemplarily on the basis of the first aspect agent (1a) and the fourth aspect agent (1d), as is shown. Figure 2 The first aspect agent (1a) and the fourth aspect agent (1d) are assigned to the first device (20a) to be coupled, as is shown.

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

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

[0031] The topology can of course be different. In particular, a data structure, for example a table, which can be filtered by the identifier (12), can be stored in the registry.

[0032] If now the terminal (30a) shall perform a user predefinable action on the first device (20a) in this example, data provided by the first device (20a) via the first input interface (2a) can be extracted at the first output interface (3a) and the fourth output interface (3d) in association with the stored aspect models (AM1, AM2) by accessing the addresses (17a, 17b), wherein each aspect model describes one sub-aspect of the provided data.

[0033] Figure 4 A method for providing digital twins (14) with aspect agents (1a...k) and its use exemplarily illustrated in a flow chart and exemplarily using a blast furnace and a welding robot as coupled data providing devices (20a...d) is shown.

[0034] First (100) a user, e.g. a maintenance engineer, provides aspect models (AM1, AM2) of maintenance information in a model library.

[0035] Then (110) a user input is received accessing the provided aspect models (AM1, AM2). Then aspect agents (1a...k) are generated, in particular automatically, which are set up to receive data from the blast furnace, select maintenance data contained in said data, convert said maintenance data if necessary and provide at their output interfaces (3a...k).

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

[0037] In particular, one or more entries can be added (130) to the registry for each digital twin with the identifier of the respective connected blast furnace. This allows to track from which devices (20a...d) the aspect agents (1a...k) provide data.

[0038] Generally, the digital twin can be a separately held data structure, but it is also possible to embed the digital twin into a larger data structure. Thereby, for example, it is possible that the information constituting the digital twin is pooled in a list. Thereby, the digital twin of a predefinable connected device can then be provided, for example, by filtering said list by an indicator of the predefinable connected device.

[0039] Subsequently (140) the output interfaces (3a...k) of the respective aspect agents (1a...k), here also the maintenance aspect models, are entered in the registry (11) for each digital twin (14).

[0040] The blast furnace is coupled with the aspect agent.

[0041] The other users can then likewise access the aspect model (AM1, AM2) and generate aspect agents which retrieve data from the welding robot, select and transform the maintenance data accordingly and provide the maintenance data at the output interface.

[0042] Then comes first (150) a step similar to step (120).

[0043] Then comes step (160) similar to step (130).

[0044] Then comes step (170) similar to step (140).

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

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

[0047] The structure of the directed graph (i.e. the connections between the nodes of the data points and the nodes of the data point groups) thus allows the structure of the (runtime) data provided at the output interfaces (3a..k) of the aspect agents (1a...k) to be derived explicitly.

[0048] Furthermore, the aspect models (AM1, AM2) graph contain one or more subgraphs (so-called "characteristics") which set the properties (data type, value range, physical unit, etc.) of the represented data points, wherein on traversing the graph up to a pre-given data point, at least one or more such characteristic subgraphs can also be reached explicitly for this data point. This is important because the (runtime) data provided by the aspect agents has pre-given properties and must be interpreted accordingly. These properties can thus be determined and provided explicitly on traversal.

[0049] In Figure 5 The data of the blast furnace provided by the aspect agents (1a...k) are exemplary shown in

[0050] First, two data points are shown, named "power consumption" and "operating temperature". While the scalar value of the power consumption is "35000", the value of the operating temperature is a complex object, which in turn contains two further data points: "internal" and "external", with the scalar values "600.0" and "35.6", respectively.

[0051] Figure 6 The aspect model of the aspect agent is exemplarily shown. The name of the data point, i.e. "operating temperature" or "power consumption", points to a feature subgraph, which sets the attributes about the data type and, if possible, also about its physical unit. The complex data type of the "operating temperature" is defined in the aspect model as well. This is done by specifying the contained data points. The values of the data points are not present in the aspect model, as these values are provided at runtime and can vary continuously.

[0052] It is also possible that the terminal (30a...c) can predefine at the output interface, by so-called "operations", the access to runtime data, or to information about runtime data, or to functions that can be used to manipulate the connected device.

[0053] Operations in the aspect model can also be defined as functions that can be called (e.g. "start blast furnace" or "stop blast furnace"). Such operations can require input data and can provide output data. They can also be described in the aspect model, where the attributes of the represented data points of the input / output data are described by feature subgraphs as well. These input / output data can or can not be part of the data that can be called originally.

[0054] For example, the "operating state aspect model" of the blast furnace contains a representation of the data point "state", where the feature subgraph describes the two possible values as value ranges: "on" or "off". In addition, the operating state aspect model can specify the operation "start", whose output data also contains a representation of the data point "state".

[0055] An aspect agent following an aspect model with operations must provide the calls of these operations at its "output interface", so that the "output interface" serves as an input interface for the information flow in the opposite direction.

[0056] The properties of the represented data points in the aspect model can be pre-defined by a meta-model through the feature subgraphs within the aspect model. Here, the properties that can be used for the description are grouped into classes. These classes are pre-defined in a hierarchy, which is used to describe the represented data points in the selected class.

[0057] Furthermore, the setting of possible attributes for describing data points in a class hierarchy allows for the creation of aspect models in an editor which enables a user to simply select elements which can be used for the description.

[0058] An example of such a class hierarchy is shown in Figure 7 where "A -> B" means that class A is a class derived from class B. It is important here that the hierarchy represents inheritance relationships in "is a" relationships, i.e. the descriptive attributes which can be represented by class B can likewise be represented by class A, wherein in class A further attributes can additionally be represented. These classes can thus be particularly easily extended.

[0059] Figure 7 The class hierarchy shown exemplary in Figure 6 can be used to set the available attributes in the feature subgraph exemplary shown in

[0060] "Temperature Set Eigenschaften" belongs to the class "Single Entity", "Temperature Eigenschaften" belongs to the class "Measurement" and "Power Eigenschaften" likewise belongs to the class "Measurement".

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

[0062] The predefinition of the hierarchy of classes in the meta model with attributes for describing data points is a prerequisite for the use of aspect models which adhere to the meta model.

[0063] For example, aspect agents (1a...k) can be created automatically from existing aspect models.

[0064] Alternatively or additionally, evaluation functions (more precisely: program code of the evaluation functions) for automatically processing the data provided by the aspect agents (1a...k) at their respective output interfaces (3a...k) can be generated.

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

[0066] Alternatively or additionally, descriptions in IDL (Interface Description Language) can be generated from the provided aspect models. These descriptions can in turn be used to enable applications to consume the data provided by the respective aspect agents.

[0067] Alternatively or additionally, semantic descriptions in an ontological or logical format, for example OWL (Web Ontology Language) or CL (Common Logic), can be generated from the existing aspect models. Thereby, the data provided by the aspect agents as well as the associated aspect models can be integrated in a structured database such as a Knowledge Graph.

[0068] Alternatively or additionally, descriptions of functions or technologies can be generated from the provided aspect models, which describe the semantics of the aspect models in the respective domain in textual and graphical form, wherein the descriptions contain the structure of the data provided by the aspect agents (1a...k) at their output interfaces (3a...k), in addition also the classification in the functional context as well as the connection to individual elements from the relevant standards and specifications.

[0069] Such fragments, i.e. evaluation functions or descriptions, can be generated from the provided aspect models according to one of the following shown methods.

[0070] One embodiment of the first such method provides for a here (preferably recursively) traversal of the graph of the aspect model. In addition, the following mapping function is applied, which produces suitable sub-elements of the target format from the respective elements of the aspect model, taking into account the associated semantics of the meta-model.

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

[0072] For example, in order to produce a monitoring application for the data of a blast furnace operation in production, a mapping function can be defined according to which all data points described by a feature sub-graph, which is an instantiation of the class "Measurement", are mapped to a pre-given class. In addition, the resulting class then allows the automatic use of a pre-given function to access the unit of the data points, as exemplarily shown in the following pseudo code lines:

[0073] .

[0074] Then, using the mapping functions combined with the Figure 7 The exemplary shown class hierarchy applies these mapping functions to the aspect model 1 shown in combination with Figure 6 The following three program code classes can be generated from the aspect model 1 shown in combination with

[0075] .

[0076] Since the class "Measurement" corresponds to the hierarchy exemplarily set in Figure 7 "Quantifiable", the data points "Value" and "Unit" can be mapped to the classes "Value" and "Unit" as exemplarily shown in ​" is identified as being suitable for mapping conditions.

[0077] Each generated program code class allows access to the corresponding physical unit (Celsius or Watt) by calling a predefined function

[0078] The program code classes generated in this way allow displaying the data provided at their output interface (3a...k) by the aspect agents (1a...k) corresponding to the aspect model providing the data and automatically correcting the physical unit of the displayed values.

[0079] In addition, the same application can display any other data point (with the "Quantifiable" feature) of other aspect agents by similarly automatically generating further program code classes for corresponding aspect models.

[0080] A more specific use of the element semantics in the aspect model is also possible, for example by configuration by a user of the application, which can for example set that a data point according to the feature "temperature property" or a data point according to the feature "power property" should be displayed on a level display in a predefinable graphical form, for example in the form of a thermometer.

[0081] An embodiment of the second method for generating evaluation functions or descriptions provides for providing a set of patterns for each target format, which patterns can identify subgraphs of the aspect model (in terms of structure and in terms of content), i.e. the pattern checking function checks for all subgraphs of the aspect model whether the subgraphs are consistent with the provided patterns (in terms of structure or in terms of content) and provides the subgraph as identified in case of consistency.

[0082] Here, each pattern is assigned an associated set of subelements of the target format. For the generation process, all patterns of the respective target format are traversed, each pattern is applied to the output aspect model and the aspect model subgraph resulting from the pattern recognition is mapped to a subcollection of the target format. Finally, all subcollections are unified to obtain the result.

[0083] For example, when automatically generating aspect agents that should be coupled to a blast furnace, it can be provided that access addresses for the output interfaces are generated, which make it possible to call individual data points by the application consuming these data in addition to a complete call of all data points described in the associated aspect model.

[0084] For this, the path of the access addresses is generated as follows: the generation comprises the setting of a pattern, the application to the respective aspect model and the mapping to a path element, as follows:

[0085] ​Each represented data point results in a path element with the name of the data point. If the represented data point is part of a group of data points, the associated path element is a successor of the path element assigned to the group of data points.

[0086] This is done within the feature subgraph pre-given by the meta model.

[0087] is applied to the combination Figure 6 The exemplary shown aspect model results in the following paths for the output interface of the aspect agent:

[0088]

[0089] Here it is assumed for the invocation of all data points described by the aspect model that

[0090]

[0091] is the generic access address.

[0092] In order to be able to execute the two presented methods, the hierarchy of the meta model and the compliance of the respective aspect model to the meta model rules is important. Furthermore, it is necessary to describe semantics beyond the data structure in the form of features, which are an inherent part of the aspect model as model elements. The mapping function, which maps the aspect model elements or subgraphs of the aspect model into the respective target format, must be able to refer to the semantics of the respective model elements pre-given by the meta model not only, but must also be able to evaluate the inheritance hierarchy of the referred meta model elements. This is necessary for the program code, which generates the evaluation function, where the inheritance hierarchy can also be used together to implement similar structures in the generated classes, if necessary. Likewise, this is necessary when generating other formats, in which only inheritance can guarantee the degree of decoupling of the generated structure, which is actually necessary for the use of the structure.

[0093] Furthermore, an information processing system can be provided, wherein a terminal (30) is prepared to describe a description of the semantics of one of the aspect models (AM1, AM2), wherein the description is generated by means of the respective aspect model (AM1, AM2).

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

[0095] Furthermore, an information processing system can be provided, wherein the generation comprises traversing the graph of the aspect model (AM1, AM2).

[0096] It can be provided here that the generation comprises applying a mapping function which generates the evaluation function or the described corresponding sub-element from the elements of the aspect model (AM1, AM2) taking into account the semantics of the meta model.

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

[0098] Furthermore, an information processing system can be provided, wherein the generation comprises providing at least one pattern for identifying a subgraph of the graph of the aspect model (AM1, AM2).

[0099] It can be provided in another aspect of the application that the data integration device (10) comprises parts provided at the output interfaces (3a,..., 3k) comprising all of the following runtime data, which characterizes the aspect model (AM1, AM2) associated with the aspect processing device (1a,..., 1k) to which the output interface (3a,..., 3k) belongs.

[0100] Here, the data integration device (10) can be set up to provide at the output interfaces (31,..., 3k) also meta data describing the provided runtime data.

[0101] Furthermore, a data integration device (10) can be provided, wherein a plurality of input interfaces (2a,..., 2d) are associated with the same aspect model (AM1, AM2).

[0102] Furthermore, a data integration device (10) can be provided, wherein a plurality of input interfaces (2a,..., 2d) are connected to the same aspect processing device (1a,..., 1k).

[0103] Furthermore, a data integration device (10) can be provided, wherein a plurality of aspect models (AM1, AM2) are associated with at least one input interface (2a,..., 2d).

[0104] Furthermore, a data integration device (10) can be provided, wherein at least one input interface (2a,..., 2d) is connected to a plurality of aspect processing devices (1a,..., 1k).

[0105] Furthermore, a data integration device (10) can be provided, wherein the aspect model (AM1, AM2) comprises a semantic description of the runtime data present at the respective input interface (2a,..., 2d).

[0106] It can be provided here that the semantic description comprises a description of the data type of the runtime data.

[0107] It can be further provided here that the semantic description comprises a description of the allowed value range of values contained in the runtime data and / or a description of the physical unit of variables described by values contained in the runtime data.

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

[0109] It can be provided 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.

[0110] Furthermore, an information processing system comprising a data integration device (10) can be provided, comprising a terminal (30a...c) for processing data provided at the output interface (3a...k), the terminal (30a...c) being connected to the output interface.

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

[0112] Furthermore, an information processing system can be provided, wherein 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).

[0113] Furthermore, an information processing system can be provided, wherein the terminal (30a...c) is set up to use a description generated by the aspect model (AM1, AM2).

[0114] It can be provided here that the description comprises a semantic description in an ontological or logical format.

[0115] It can be provided here that the terminal (30a...c) comprises a knowledge graph, and wherein the terminal (30a...c) is set up to integrate data provided at the output interface (30a...c) by the associated aspect processing device (1a...k) and the associated aspect model (AM1, AM2) into the knowledge graph.

[0116] Furthermore, an information processing system can be provided, wherein the terminal (30) is prepared with a description of the semantics of one of the aspect models (AM1, AM2), wherein the description is generated with the aid of the respective aspect model (AM1, AM2).

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

[0118] Furthermore, an information processing system can be provided, wherein the generation comprises traversing a graph of the aspect model (AM1, AM2).

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

[0120] It can also be provided here that the corresponding sub-elements of the evaluation function are classes or callable functions.

[0121] Furthermore, an information processing system can be provided, wherein the generation comprises providing at least one pattern for identifying a sub-graph of the graph of the aspect model (AM1, AM2).

[0122] List of reference signs

[0123] 1a...1k Aspect processing device, aspect agent

[0124] 2a...2d Device

[0125] 3a...3k Output interface

[0126] 10 Data integration device

[0127] 11 Registry

[0128] 12 Identifier (of a device to be coupled)

[0129] 13 Access address pointing to a digital twin

[0130] 14 Digital twin

[0131] 15a, d Reference to an aspect agent

[0132] 20 Device

[0133] 20a...d Device

[0134] 30 Terminal

[0135] 30a...c Terminal

Claims

1. A method for generating a data integration apparatus (10), the data integration apparatus comprising input interfaces (2a, ..., 2d) and output interfaces (3a, ..., 3k), each input interface being connectable to a means (20a, ..., 20d) for providing runtime data to the input interface (2a, ..., 2d), the runtime data being provided from the means (20a, ..., 20d) to the output interface and being invoked at the output interface, wherein the runtime data of the respective means (20a, ..., 20d) is characterized by at least one aspect model (AM1, AM2) assigned to the respective input interface (2a, ..., 2d) and respectively characterizing one aspect of the runtime data, characterized in that, The corresponding input interfaces (2a, ..., 2d) are associated with the corresponding aspect models (AM1, AM2), wherein rules defined by the metamodel are provided from the metamodel, and the aspect models (AM1, AM2) are constructed according to the rules. Each output interface (3a, ..., 3k) is assigned a reference to one or more associated aspect models (AM1, AM2), and the following runtime data of the device (20a, ..., 20d) can be invoked through the output interface (3a, ..., 3k), for which descriptions exist in the respective associated aspect models (AM1, AM2). Access to runtime data of the device (20a, ..., 20d) can be pre-given through operation at the output interface (3a, ..., 3k).

2. The method according to claim 1, wherein the structure of the aspect model (AM1, AM2) is a directed graph.

3. The method of claim 2, wherein the nodes in the directed graph identify individual data points and / or groups of data points.

4. The method of claim 3, wherein the structure of the aspect model (AM1, AM2) includes at least one subgraph, the subgraph describing the attributes of data points identified by the nodes and / or the attributes of data points of groups identified by the nodes.

5. The method of claim 4, wherein at least one such subgraph can be explicitly reached while traversing the graph up to a pre-given node.

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

7. The method according to any one of the preceding claims, characterized in that, The corresponding input interfaces (2a, ..., 2d) are connected to the aspect processing devices (1a, ..., 1k) associated with the corresponding aspect models (AM1, AM2).

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

9. The method of claim 7, 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 device (1a, ..., 1k) to which the output interface (3a, ..., 3k) belongs.

10. The method according to any one of claims 4 to 6, wherein the data points of each data point and / or group of data points are provided at the output interface (3a...k).

11. The method according to any one of claims 4 to 6, wherein the attributes defined by the subgraph are pre-given by the meta-model, the attributes being pre-given in a hierarchy of selectable classes.

12. The method according to any one of claims 1 to 6, wherein an aspect processing apparatus (1a...k) is created from the provided aspect model (AM1, AM2).

13. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 12.

14. A machine-readable storage medium having a computer program product according to claim 13 stored thereon.

15. A computer including a memory containing instructions that, when executed by the computer, cause the computer to perform the method according to any one of claims 1 to 12.

Images