Method and arrangement for the automated creation of an industrial instance model

Abstract

To achieve automated creation of an instance model of an industrial installation, new instance data are received, these describing an instance of an entity and being present in a data structure specified by a domain model. The new instance data are stored in a database, wherein a check is carried out, in automated fashion, to determine whether the new instance data contain a search query for an identification goal, in response to which the database is automatically searched for instance data that achieve the sought identification goal, or whether the new instance data contain an offer, in response to which the database is automatically searched for instance data whose identification goal is achieved by the offer. For all pairs thereby found, an edge is inserted between the respective instance data in the instance model. These receiving and storing operations are repeated iteratively until the instance model is fully created. Preferred developments address the resolving of relationships between objects at the instance level using an abstract relationship stored in or able to be derived from the domain model. At least some embodiments enable domain-driven linking of data objects, allowing domain experts to define specific data products, to assign customer-specific and general identity features, and to forward these to the appropriate technical infrastructure without deep technical knowledge.

Description

[0001] Description

[0002] Method and arrangement for the automated creation of an industrial instance model

[0003] Technical area

[0004] The invention relates to a method and an arrangement for the automated creation of an industrial instance model.

[0005] Technical background

[0006] An instance model is a data model that contains and links instances, i.e., concrete, realized variants, of data objects. An industrial instance model describes a specific industrial plant in part or as a whole, for example, the specific properties of fully automated workstations on a production line with their associated workpieces and process steps, as well as the corresponding links and dependencies between these instances.

[0007] The development of such data models and data structures is based - explicitly or implicitly - on so-called domain models.

[0008] A domain model is an abstract “business model” that describes entities (“things”), their respective structure, and relationships to one another in an application area. These domain models therefore represent a common understanding of the objects in this application area and offer a uniform vocabulary and a uniform data structure, thereby simplifying and standardizing communication across a business area. They have the following properties, among others: a. Domain models (or functional models) are very general, i.e. they often operate at an abstract level and are not sufficiently specific for the respective application case. b. Relationships are often only formulated using an abstract relationship, such as “a process step is carried out at a workstation.” For example, it is not clear how the respective workstation can be identified, how many workstations there are, etc. c.Some functional object types in domain models do have identifiers, but these are very unspecific and usually only recognizable as such by their name. Furthermore, usually only selected and particularly important identifiers are present in these models. (Example: "Orderld") . This means that there is often a lack of a systematic description of all identifiers occurring in the domain and their structures, with the consequence that corresponding strings are not recognizable as "Orderld" at runtime. d. Furthermore, identifiers are rarely or never described by the domain model, but - with much more serious consequences - are often even customer- or context-specific. An example: Siemens identifies material by so-called A5E numbers, orderable products by an MLFB, machine instances in plants with FIO numbers, etc.There are abstract identifiers ("material class identifier") and specific identifiers ("A5E number at Siemens for material"). The former are often not explicit enough, the latter not general enough, and often not linked to the corresponding context in the domain model.

[0009] To implement a specific use case, such as value stream analysis, data is generated at runtime and sent to a central data backend, for example via data pipelines.

[0010] If one now wishes to relate corresponding entities from reality (i.e., the concrete data structures representing an instance of an event, a material, or an order) to the domain model, the following difficulties arise solely due to the difference in the level of abstraction: i. The assignment of a concrete date to its equivalent in the domain model is difficult. (Which instance object actually corresponds to which domain object?) ii. The relationships between the different data objects are usually not resolved directly for the reasons stated above, in particular due to point d), but the data objects carry the information as text. For example, some entities carry identifiers (e.g., an "ID" field in an order, a kind of primary key) or refer to them by specifying the identifier (e.g.,a field "Orderld" on another object that wants to refer to a specific order, a foreign key, so to speak), without it being guaranteed, for example, that this Orderld even exists. This means: o There is no semantically marked indication as to whether an identifier is a primary or foreign key o The identifiers are simple sequence numbers that do not represent real relations because it is unclear whether the target of the relation actually exists or can be found through simple pattern matching (cf., for example, the different conventions for representing IRDIs in CDD vs. Eclass).

[0011] In the area of ​​operational technology (OT), there is a typical tendency to develop domain models as quasi-static models that also represent the instance data in a correspondingly rigid manner. For example,

[0012] • the values ​​of resource properties are typically represented as “last value” or “time series”, from which it is difficult to extract individual data points,

[0013] • Events (alarms, status changes, scan events) are usually always generated from the asset or in close relation to it, ie in order to address a single event or a series of events of a certain type, you always have to go through the asset from which the event originated,

[0014] • In a similar way, sensors and I / Os are typically mapped to values ​​of the instances.

[0015] In addition, domain and instance models are traditionally managed in rigid structured tag or asset models, which make it very difficult to view individual entities in a use-case-dependent manner.

[0016] In the field of information technology (IT), the focus is traditionally on functional models in which numerous instances are continuously created in a highly dynamic manner.

[0017] Thus, each event creates a new instance, which is then typically persisted in an increasingly large table or even a simple list, where each row represents an instance. This type of data persistence makes it very difficult to make it useful and effective in other use cases, such as reasoning in a knowledge graph.

[0018] A paradigm break in data capture can also regularly be observed between OT and IT, for example with regard to the time of creation of entities (in OT during engineering, in IT during runtime), or the basic representation concept (lists vs. structures / objects).

[0019] Traditionally, the problems of linking and assigning data objects described above are solved afterwards - on the data consumption side - typically during a query by specifying references and conditions (e.g. in SQL within a WHERE clause). This approach has the following disadvantages: a. The data must be of good quality so that as few deviations as possible (e.g. in the formatting of identifier values) have to be handled b. The application must know the relationships between the data objects, or they must be known to the specialist who, for example, builds the SQL queries (i.e. they need domain knowledge) c. The application must know the customer-specific variations in the application of different identification schemes (e.g. the different ways of structuring an IRDI) d.Queries created in this way, and the knowledge contained in them, cannot be easily transferred to new or changed data sources (low degree of reuse).

[0020] Another known possibility is the creation of a data ingestion, where data can be linked based on the order in which it is retrieved. Here, too, knowledge of the data dependencies and customer-specific solutions is required. Further complicating the situation is that the data is usually stored in tables, so the relationships to be created must necessarily be established during the query using complex JOINs. Summary of the Invention

[0021] The object of the invention is to provide an alternative to the prior art.

[0022] The object of the invention is solved by the independent patent claims.

[0023] In the method for the automated creation of an industrial instance model, the following operations are performed by components, wherein the components are hardware components and / or software components, and wherein the software components are executed by one or more processors:

[0024] Receiving, through a network interface, new instance data describing an instance of an entity and present in a data structure specified by a domain model describing entities and relationships between them, and wherein the domain model specifies for each entity a data structure for instance data belonging to the entity,

[0025] Storing, via a database, the new instance data in an instance model which describes a concrete industrial plant at least partially by a graph which contains existing instance data as nodes and relationships between the existing instance data as edges, and wherein it is automatically checked whether the new instance data contain a search query for an identification target, in particular a single identifier, a combination of identifiers or a rule-based identification target, whereupon the database is automatically searched for instance data which fulfills the sought identification target, or whether the new instance data contain an offer, in particular consisting of at least one identifier, whereupon the database is automatically searched for instance data whose identification target is fulfilled by the offer,and wherein, for all pairs found in this way, an edge is inserted between the respective instance data in the instance model, and the receiving and storing operations are iteratively repeated until the instance model is completely created. The arrangement for the automated creation of an industrial instance model comprises the following components, wherein the components are hardware components and / or software components, and wherein the software components are executable by one or more processors: a network interface configured to receive new instance data describing an instance of an entity and present in a data structure specified by a domain model that describes entities and relationships between them, and wherein the domain model specifies a data structure for instance data belonging to the entity for each entity, and a database,configured to store the new instance data in an instance model which describes a specific industrial plant at least partially by a graph which contains existing instance data as nodes and relationships between the existing instance data as edges, and wherein it is automatically checked whether the new instance data contain a search query for an identification target, in particular a single identifier, a combination of identifiers or a rule-based identification target, whereupon the database is automatically searched for instance data which fulfill the sought identification target, or whether the new instance data contain an offer, in particular consisting of at least one identifier, whereupon the database is automatically searched for instance data whose identification target is fulfilled by the offer,and for all pairs found in this way, an edge is inserted between the respective instance data in the instance model.,

[0026] The advantages mentioned below do not necessarily have to be achieved by the subject matter of the independent patent claims. Rather, they may also be advantages achieved solely by individual embodiments, variants, or further developments. The same applies to the following explanations.

[0027] The term "computer" should be interpreted as broadly as possible, particularly to cover all electronic devices with data processing capabilities. Computers can therefore include, for example, personal computers, servers, clients, programmable logic controllers (PLCs), handheld computer systems, mobile devices, tablets, smartphones, or any other devices capable of computer-assisted data processing, such as processors or other electronic data processing devices. Computers can, in particular, comprise one or more processors and memory units.

[0028] In the context of the invention, "memory", "memory unit" or "memory module" and the like may, for example, be a volatile memory in the form of random-access memory (RAM) or a permanent memory such as a hard disk, a solid state drive or a floppy disk.

[0029] The method and the arrangement, or at least one of their embodiments, address in particular the second aspect mentioned at the beginning (point ii), ie the resolution of the relationships between objects at the instance level with the aid of an abstract relationship that is stored in the domain model or can be derived therefrom.

[0030] The method and arrangement, or at least one of their embodiments, address the difficulties in combining data from the OT and IT domains, as well as the disadvantageous characteristics of current approaches when it comes to establishing relationships between entities. Previous approaches require subsequent manual effort or are not flexible enough to meet the requirements. The method and arrangement, or at least one of their embodiments, on the other hand, enable domain-driven linking of data objects, allowing domain experts to define specific data products, assign customer-specific and general identity attributes, and transmit them to the corresponding technical infrastructure without in-depth technical knowledge.

[0031] Key differences and advantages of the method and arrangement, or at least one of their embodiments, lie in the automatic creation of links between entities at the instance level, with the relationships being defined by the expert in a functional domain model. This enables more efficient and higher-quality provision of data products, as well as effective reasoning on instance data, without having to manually consider the relationships through text matching for each query.

[0032] The method and arrangement, or at least one of their embodiments, aim to represent and manage both data from the OT domain and data from the IT domain in an object-oriented manner. The actual (physical) persistence is an implementation detail that can even vary depending on the deployment. The method and arrangement, or at least one of their embodiments, also involves transferring the relationships from the functional model at the IT level (where the entities are created at runtime) to the instances and reconciling them via entity resolution.

[0033] The method and arrangement, or at least one of their embodiments, link the various paradigms of the IT and OT worlds through an object-oriented perspective, creating a direct connection to the functional domain model. The links between the concrete instances are instantiated fully automatically once and are then available for reuse. This means that they do not have to be re-matched and generated for each query. The links become "first-class citizens" that can also be used in other, non-SQL-based systems and can be effectively employed, for example, for reasoning over data.

[0034] The method and arrangement, or at least one of their embodiments, allows a domain expert to perform the linking of entities at the domain level (i.e., independent of the underlying concrete implementations). The domain expert already possesses the necessary knowledge of their domain in general and of the respective use case and is thus closer to the specific information needs than, for example, a database developer.

[0035] The method and arrangement, or at least one of its embodiments, enable a type of "low-code linking" of data pools, empowering the domain expert to formulate their data requirements in such a way that they can be efficiently translated into the necessary code to compile these data products. This shortens the process of providing and linking data from different data pools, makes it more efficient, and—due to the domain knowledge of the person performing these links—is presumably of better quality.

[0036] Embodiments of the invention

[0037] According to one embodiment, the new instance data is received iteratively from different source systems. In a further development, the domain model, which specifies a data structure for instance data belonging to the entity for each entity in the different source systems, is adapted in advance by the following operations: in a first step, receiving, via a user interface, user inputs, based on which a selection of entities relevant to a use case is automatically determined in the domain model; in a second step, outputting, via the user interface, relationships existing in the domain model between the selected entities; and receiving, via the user interface, user inputs, based on which further relationships between the selected entities in the domain model are automatically determined.

[0038] According to one embodiment, the domain model is further adapted in advance by the following operation: in a third step, receiving, through the user interface, user inputs on the basis of which at least one identification feature is automatically assigned to each selected entity as an offer.

[0039] In a further development, the domain model is further adapted in advance by the following operation: in a fourth step, receiving, by the user interface, user inputs, on the basis of which a search request for an identification target, in particular a single identification feature, a combination of identification features or a rule-based identification target, is automatically assigned to at least one selected entity.

[0040] According to one embodiment, the domain model contains at least one ontology, at least one UML model, and / or at least one Anchor Advanced Domain Model.

[0041] In further training, the database is a graph database, a relational database, a key-value database or an object database.

[0042] The graph can be stored as an abstract structure in any database. For example, the graph's nodes and edges can be stored in a graph database, a relational database, or a key-value database. To represent the graph in a relational database, for example, one table is created for the nodes and another table for the edges. Graphs can also be represented in object databases by storing the outgoing edges as a list of destination nodes.

[0043] The computer program includes instructions which, when executed by a computer, cause the computer to carry out the method.

[0044] The device for providing the computer program is a computer-readable storage medium on which the computer program is stored or a server which is set up to provide the computer program in a network.

[0045] Exemplary embodiments of the drawing

[0046] The above and other aspects of the present invention can best be understood from the following detailed description in conjunction with the accompanying figures. For the purpose of illustrating the invention, currently preferred embodiments are shown in the figures, although it is understood that the invention is not limited to the specific means disclosed. In the figures, identical or functionally equivalent elements are provided with the same reference numerals unless otherwise indicated. The features of the individual embodiments can also be combined with one another. Furthermore, the embodiments shown in the figures can be combined with the features outlined above. They show:

[0047] Fig. 1 shows a first embodiment,

[0048] Fig. 2 shows another embodiment,

[0049] Fig. 3 is a flowchart of a possible exemplary embodiment.

[0050] In the following description, various aspects of the present invention and embodiments thereof are described. It will be apparent to those skilled in the art that the respective embodiments can be implemented with only some or all of the described aspects. For example, for explanatory purposes, specific numbers and / or configurations are provided to enable a thorough understanding. However, those skilled in the art will also be able to implement the respective embodiments without these specific details. The described components can be hardware components or software components. A software component can be, for example, a software module such as a software library; a single procedure, a subroutine, or a function; or, depending on the programming paradigm, any section of program code that implements the function of the software component.A combination of hardware and software components is also possible, for example, if some operations are preferably implemented exclusively by dedicated hardware (e.g., a processor in the form of an ASIC or FPGA) and others by software. Furthermore, it is also possible for one and the same operation to be performed through the interaction of a hardware component with a software component.

[0051] Detailed description of the implementation examples

[0052] Fig. 1 shows an exemplary arrangement for the computer-based implementation of the invention, which comprises:

[0053] (101) Computer system

[0054] (102) Processor

[0055] (103) Storage

[0056] (104) Computer program

[0057] (105) User interface

[0058] In this embodiment of the invention, computer program 104 contains program instructions for implementing the invention. Computer program 104 is stored in memory 103, making memory 103 and / or the associated computer system 101 a delivery device for computer program 104. Computer system 101 can implement the invention by executing the program instructions of computer program 104 through processor 102. The results of the invention can be presented on user interface 105. Alternatively, they can be stored in memory 103 or on another suitable data storage medium.

[0059] Fig. 2 shows a further exemplary arrangement for the computer-based implementation of the invention, comprising: (201) Provision device

[0060] (202) Computer program

[0061] (203) Computer network / Internet

[0062] (204) Computer system

[0063] (205) Mobile device / smartphone

[0064] In this embodiment, the provision device 201 stores a computer program 202 containing program instructions for implementing the invention. The provision device 201 makes the computer program 202 available via a computer network / internet 203. For example, a computer system 204 or a mobile device / smartphone 205 can load the computer program 202 and execute the invention by executing the program instructions of the computer program 202.

[0065] In a variant of this embodiment, the provisioning device 201 is a computer-readable storage medium, such as an SD card, that stores the computer program 202 and is directly connected to the computer system 204 or the mobile device / smartphone 205 in order to load the computer program 202 and to execute the invention by executing the program instructions of the computer program 202.

[0066] Preferably, the embodiment shown in Figure 3 can be implemented with an arrangement according to Figure 1 or Figure 2.

[0067] The following implementation examples describe a domain-driven, application- and persistence-independent way of linking data objects, which allows a domain expert to create the necessary links between entities based on the respective use case and then to forward them to the appropriate technical infrastructures (pipelines, mapping services, etc.) and have them implemented "at the push of a button."

[0068] This enables the domain expert to define use case-specific data products and order them from the underlying data infrastructure without having to go to the level of SQL queries or data pipelines.

[0069] The following three prerequisites must be met: First, a domain model formalized for the respective use case must exist, along with associated data structures for the instance data that will later belong to the respective entity. This means that every definition of an entity within this model also defines the data structure of the instance data that will later belong to it. This domain model can either be pre-defined and generally applicable, or it can extend pre-defined domain models for a specific use case, or it can be completely use case-specific. The specific representation formalisms for this domain model are selected by the specialist based on their expertise. The following formalisms or combinations thereof are conceivable: ontologies (RDF / OWL), UML models, Anchor Advanced Domain Models.

[0070] Second, identification systems were defined regarding: o Identification standard (e.g., "Siemens A5E material numbers" or "IRDI") o Structure, variants, and standardized target format. In some cases, different notations are permitted, or different variants simply occur. Example IRDI:

[0071] ■ 0173-1#02-AA0677#002 (ECLASS notation with minus, without empty groups)

[0072] ■ 0112 / 2 / / / 61987#ABA300#006 (CDD notation with slash and separators also for empty groups)

[0073] Thirdly, there is a data sink that allows graph- or object-oriented access (with full-fledged reference types).

[0074] Fig. 3 shows a flowchart of a possible exemplary embodiment of the method for the automated creation of an industrial instance model, which consists of a process with several steps.

[0075] In a first step (1), a user interface receives user input that defines a selection of entities relevant to a use case from a domain model. Some of the entities in the selection may have previously been individually added by a user specifically for the use case.

[0076] In a second step (2), the relationships between the selected entities are output from the domain model via the user interface. Where no direct relationships exist, entities are only connected via many intermediate identities, or individual entities have been inserted, the user interface now captures user inputs that define relationships between entities—either directly, i.e., through existing mapping rules or mapping tables, or by defining a corresponding path. If necessary, the user interface also captures user inputs that insert entities between them to enable these paths.

[0077] In a third step (3), the user interface receives user input that assigns one or more identification features to each entity according to the available identification systems. For this purpose, the user interface offers specific features for each identity that help identify it: o Existing properties from the domain model can be marked. ("Id" of type String is displayed as "Siemens A5E material number") o New properties with identifying potential can be added if the domain model does not provide corresponding identifiers for the entity.

[0078] In a fourth step (4), if an entity refers to another entity, the user interface receives user input that assigns an identification target to this reference, so that the respective entity can search for the referenced target entity based on specific features available to it. Identification targets can be based on individual identification features (1:1 mapping), consist of combinations of features (e.g., "process step is identified by workstation and workpiece"), and / or consist of rules (referring to other properties of the entity, even if these do not represent a direct identification feature).

[0079] In a fifth step (5), data from various source systems is transmitted in the standardized data structure specified by the domain model to a target system, such as a data store that serves as an information source for a dashboard and maintains a database for this purpose. In this "inject" step, the identifiers that instantiate the identification features in the concrete instances of the entities are advantageously brought directly to the normalized representation. In a sixth step (6), the instances of the entities are stored in the target system. When a new instance arrives in the target system, a check is performed to determine whether it is SEARCHING for identifiers itself (as an identification target, analogous to a foreign key) or PROVIDING them (analogous to a primary key).a) If the new instance is searching for the resolution of a specific identification target (analogous to a foreign key), a check is automatically performed to determine whether there are already instances that offer matching identifiers (analogous to a primary key) ("Does the person I'm looking for already exist?" scenario). If no target is found, the reference remains unsatisfied and is checked again when additional instances arrive. b) If other instances are still searching for targets for their references, a check is now performed to determine who is looking for identifiers that the new instance has to offer ("Who is looking for me but hasn't found me yet?" scenario).

[0080] Whenever a bid-search pair is found, the relationship is established directly in the instance model. Instead of only having the target ID available, a direct connection is established. This means that an "edge" is created between the two entities, which is then available and can be used without having to repeat the matchmaking process with each new query / analysis.

[0081] Advantageously, the original information of the sought or offered identifier is not completely discarded in the target system, but remains available in the form of reference information / metadata.

[0082] The method can be executed by one or more processors. Examples of processors include a microcontroller or a microprocessor, an application-specific integrated circuit (ASIC), or a neuromorphic microchip, in particular a neuromorphic processor unit.

[0083] The processor can be part of any type of computer, including mobile devices such as tablets, smartphones or laptops, or part of a server in an operations center or a cloud.

[0084] The method described above can be implemented by a computer program whose instructions, executable by one or more processors of a computer system, are stored on one or more computer-readable storage media. By executing the instructions, the computer system performs actions corresponding to the operations of the method described above.

[0085] The program code for implementing the processes described herein may be provided on a computer-readable storage medium or data storage such as a cache memory, buffer memory, RAM, FLASH, removable media, a hard disk, or other computer-readable storage medium. Computer-readable storage media includes various types of volatile and non-volatile storage media. The functions, operations, or tasks illustrated in the figures or described herein may be performed in response to one or more sets of program instructions stored on computer-readable storage media. The functions, operations, or tasks may be independent of the instruction set used and the type of storage medium, the processor, or its execution strategy, and may be performed by software, hardware, integrated circuits, firmware, microcode, and the like, operating alone or in conjunction with one another.Simultaneous processing, multi-program operation, parallel processing and the like can also be used when executing the program code.

[0086] The invention has been described in detail with reference to exemplary embodiments. Deviations and modifications are possible if they correspond to the spirit of the invention and fall within the scope of protection defined by the claims. The term "A, B and / or C" as an alternative formulation can mean that one, several, or all of the elements of A, B, and C can be used.

[0087] Regardless of the grammatical gender of a particular term, persons with male, female or other gender identities are included.

Claims

Patent claims 1. A computer-implemented method for the automated creation of an industrial instance model, in which the following operations are performed by components, wherein the components are hardware components and / or software components, and wherein the software components are executed by one or more processors: Receiving (5), through a network interface, new instance data describing an instance of an entity and present in a data structure specified by a domain model describing entities and relationships between them, and wherein the domain model specifies for each entity a data structure for instance data belonging to the entity, Storing (6), by a database, the new instance data in an instance model which describes a concrete industrial plant at least partially by a graph which contains existing instance data as nodes and relationships between the existing instance data as edges, and wherein it is automatically checked whether the new instance data contain a search query for an identification target, in particular a single identifier, a combination of identifiers or a rule-based identification target, whereupon the database is automatically searched for instance data which fulfill the sought identification target, or whether the new instance data contain an offer, in particular consisting of at least one identifier, whereupon the database is automatically searched for instance data whose identification target is fulfilled by the offer,and wherein for all pairs found in this way, an edge is inserted between the respective instance data in the instance model, and iteratively repeating the operations of receiving (5) and storing (6) until the instance model is completely created., 2. The method according to claim 1, wherein the new instance data is received iteratively from different source systems.

3. Method according to one of the preceding claims, in which the domain model, which specifies a data structure for instance data belonging to the entity for each entity in the different source systems, is adapted in advance by the following operations: in a first step (1) receiving, through a user interface, user inputs on the basis of which a selection of entities relevant for a use case is automatically defined in the domain model, in a second step (2) outputting, through the user interface, relationships existing in the domain model between the selected entities and receiving, through the user interface, user inputs on the basis of which further relationships between the selected entities in the domain model are automatically defined.

4. The method according to claim 3, wherein the domain model is further adapted in advance by the following operation: in a third step (3) receiving, by the user interface, user inputs on the basis of which at least one identification feature is automatically assigned to each selected entity as an offer.

5. The method according to claim 4, wherein the domain model is further adapted in advance by the following operation: in a fourth step (4) receiving, by the user interface, user inputs on the basis of which a search request for an identification target, in particular a single identification feature, a combination of identification features or a rule-based identification target, is automatically assigned to at least one selected entity.

6. Method according to one of the preceding claims, wherein the domain model contains at least one ontology, at least one UML model, and / or at least one Anchor Advanced Domain Model.

7. Method according to one of the preceding claims, wherein the database is a graph database, a relational database, a key-value database or an object database.

8. An arrangement for the automated creation of an industrial instance model, comprising the following components, wherein the components are hardware components and / or software components, and wherein the software components are executable by one or more processors: a network interface configured to receive (5) new instance data describing an instance of an entity and present in a data structure specified by a domain model that describes entities and relationships between them, and wherein the domain model specifies a data structure for instance data belonging to the entity for each entity, and a database configured to store (6) the new instance data in an instance model that describes a specific industrial plant at least partially by means of a graph that contains existing instance data as nodes and relationships between the existing instance data as edges,and wherein it is automatically checked whether the new instance data contains a search request for an identification target, in particular a single identifier, a combination of identifiers, or a rule-based identification target, whereupon the database is automatically searched for instance data that fulfills the sought-after identification target, or whether the new instance data contains an offer, in particular consisting of at least one identifier, whereupon the database is automatically searched for instance data whose identification target is fulfilled by the offer, and wherein for all pairs found in this way, an edge is inserted between the respective instance data in the instance model.

9. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method according to claim 1.

10. A device for providing a computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method according to claim 1, wherein the device is a computer-readable storage medium on which the computer program is stored, or a server that is set up to provide the computer program in a network.

Images