EP4007940A1

EP4007940A1 - Method for generating self-description data modules

Info

Publication number: EP4007940A1
Application number: EP19786450.7A
Authority: EP
Inventors: Brent HANNIMAN; Steffen Lamparter; Jens Meckel; Jörg NEIDIG
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2019-09-24
Filing date: 2019-09-24
Publication date: 2022-06-08
Also published as: CN114450643A; WO2021058083A1; US20220342372A1

Abstract

The invention relates to a method for generating self-description data modules (380, 390), in each case with respect to at least one functionality and/or at least one component, device, or system. A data collection (100) is provided comprising engineering elements from at least one of the three data sources listed hereinafter: - a first data source with automation engineering data (110) relating to an automation and/or automation plan for the system or device or parts thereof, - a second data source with MCAD data (120) relating to a mechanical and/or spatial plan for the device or system or parts thereof and/or relating to a mechanical and/or spatial design for the device or system or parts thereof, and - a third data source with ECAD data (130) relating to an electric plan and/or circuit plan for the device or system or parts thereof and/or relating to an electric design and/or implemented circuit plan for the device or system or parts thereof. The method has the following steps: a.) ascertaining relationship information (150), each piece of relationship information being assigned to engineering elements of the data collection (100), b.) generating a multigraph (200) comprising nodes (210, 220, 230, 240, 250) and connections (212, 214, 222, 252, 254) between nodes, wherein each of the nodes is assigned to engineering elements of the data collection, and each connection is assigned to pieces of relationship information (150) ascertained in step a.), c.) applying a clustering method to the multigraph (200) in order to ascertain at least one sub-graph (280, 290) within the multigraph (200), d.) selecting a sub-graph (280, 290) from the at least one sub-graph (280, 290) ascertained in step c.), and e.) generating a self-description data module (380, 390) relating to a component and/or a functionality of the device or system, said self-description data module (380, 390) comprising the selected sub-graph (280, 290) and/or information contained in the sub-graph (280, 290).

Description

Method for generating self-description data modules

The present invention relates to a method for generating a self-description data module with regard to at least one functionality and / or at least one component of a device or system.

Such self-description data modules are known from the prior art.

For example, the US patent application 2019/0025785 A1 discloses a module for a system that carries out a technical sub-process of the system. The module comprises an external interface for publishing at least one service that the module can provide to a specific product. The mentioned interface also includes information about the technical hardware and the functional scope of this module as well as dynamic information about time-changing data within the module, which can arise, for example, as part of the control of the module. Furthermore, the mentioned US patent application discloses that the information mentioned above can be made available, for example, as a so-called “Module Type Package (MTP)”.

It is a disadvantage of the cited prior art that, in particular, the compilation of such static information with regard to the functionalities of hardware and other hardware properties can often be correspondingly complex, since such data often originate from different data sources.

It is therefore an object of the present invention to provide a method which is based on simplified way enables information about technical hardware to be collected and compiled from various sources.

This object is achieved by a method with the Merkma len of claim 1.

Such a method is designed and set up for generating a self-description data module with regard to at least one functionality and / or at least one component of a device or system, with a data collection comprising engineering elements from at least one of the three data sources listed below being available:

- A first data source with automation engineering data relating to automation and / or automation planning of the system or device or parts thereof,

- A second data source with MCAD data relating to mechanical and / or spatial planning of the device or system or parts thereof, and / or relating to a mechanical and / or spatial configuration of the device or system or parts thereof,

- A third data source with ECAD data relating to electrical planning and / or circuit planning of the device or system or parts thereof, and / or with regard to an electrical configuration and / or implemented circuit planning of the device or system or parts thereof, the method comprising the the following process steps: a.) Determination of relationship information which are each assigned to engineering elements of the data collection, b.) Generation of a multigraph comprising nodes and connections between nodes, the nodes each being assigned to engineering elements of the data collection and the ver ties between nodes in accordance with Method step a.) The ascertained relationship information is assigned, c.) Applying a clustering method to the multigraph to determine at least one sub-graph within the multigraph, d.) Selecting a sub-graph from the in

Method step c.) Determined at least one sub-graph, e.) Creating a self-description data module with regard to a component and / or a functionality of the device or system, the self-description data module the selected sub-graph and / or in the sub- Information contained in graphs.

A method of this type for generating a self-description data module can, for example, run in an automated or partially automated manner.

The sequence of method steps d.) And e.) According to the present description, for example, can also be carried out multiple times one after the other, so that one sub-graph is selected one after the other, the associated self-description data module comprising this sub-graph is generated and then another sub-graph is subsequently selected again in order to then also generate a self-description data module for this, etc.

The data collection can include a compilation of the engineering elements contained therein, in particular including meta information that may be assigned to the engineering elements. This compilation of the engineering elements within the data collection can be designed as a table or a comparable compilation and be set up. The table can for example contain engineering elements themselves and / or names or designations for engineering elements.

The wording that engineering elements including this possibly assigned meta information are contained in the data collection is understood in the context of the present description and the claims that the engineering elements including these assigned meta information are contained in the data collection if this engine ering elements are actually assigned meta information. If no meta information is assigned to engineering elements, engineering elements are then contained in the data collection without meta information.

A self-description data module can be designed and set up, for example, as a searchable data collection of information relevant to a specific functionality or component of the device or system.

Furthermore, a self-description data module can also be designed as a functional data module or at least comprise functional elements. Such functional data modules or functional elements of such data modules can be designed, for example, in such a way that they are designed and set up for self-executing certain functions or functionalities of the device or system. Such functional data modules or functional elements can be designed and set up, for example, as software elements or modules (or include such software elements), during the course of which the mentioned function or functionality is carried out. The software elements mentioned can, for example, be engineering elements according to the present description, which can be designed and set up, for example, as control programs, user programs, elements of such programs, function blocks, data blocks and / or similar so-called POUs (Program Object Units) or such Can include software modules. The software modules mentioned and / or the executable software elements mentioned can then be contained in an advantageous embodiment wholly or at least partially in a self-description data module or the assigned sub-graph assigned to a corresponding functionality of the device or system. Furthermore, such software modules or executable software elements can also be contained in one of the data sources and / or the compilation of engineering elements.

Such functions or functionalities of such self-description data modules designed as functional data elements or comprising functional data or software elements can be referred to, for example, as so-called “skills”. Skill "is assigned, for example, be designed and set up in such a way that, after input of input parameters and / or call commands necessary for executing the skill, are designed and set up for the automatic execution of the function or functionality assigned to the skill. This can be designed and set up, for example, in such a way that the function or functionality is carried out accordingly when the corresponding software elements of the corresponding self-description data module are, for example, from an execution environment, for example the device or the system.

Such skills can range, for example, from relatively simple activities such as opening a valve or reading out a sensor value to more complex functionalities, which can be composed of several simpler functionalities, for example. Such more complex functionalities can be, for example, the packaging of a product or a so-called “pick & place” process for gripping, moving and placing an object. Such a pick & place process or pick & place skill can, for example, be elementary functionalities or skills such as recognizing an object that include gripping an object, moving the object, recognizing a dropping point and dropping the object.

To execute such a skill it can then be provided, for example, that the parameters necessary for executing the skill are transferred to the corresponding self-description data module, such as the description of an object to be gripped and a placement position for it, and then the skill by means of the sequence from corresponding one or more functional data and / or software elements contained in the self-description data module is executed. Furthermore, the corresponding self-description data module can comprise a skill description information which, for example, contains information about the skills realized or realizable by the self-description data module. The skill description can include information about an implemented functionality as well as the input parameters necessary for executing the functionality. In the context of the present description, for example, a sub-graph related to a specific functionality of the device or system can be viewed as an implementation of a skill related to this functionality. This then applies in a comparable manner to a self-description data module comprising this sub-graph.

Furthermore, the self-description data module can be designed and set up for communicating said skill description information to other devices, devices, computers or comparable data processing devices.

Such a configuration of a self-description data module can be advantageous, for example, for use of the device or system in the context of a “plug and produce” system.

The wording: "at least one of the three data sources listed below" is understood in the context of the present description and claims that the data collection can include a selection of engineering elements from one, two or even all three of the three data sources mentioned The data collection can also consist of a selection of one, two or all three of the three data sources mentioned.

Each of the data sources can include engineering elements of at least one corresponding data category.

Under the formulation that each of the data sources engineering elements comprises at least one corresponding data category, in connection with the present Description understood that the automation engineering data include engineering elements of at least one data category for automation engineering data, the MCAD data engineering elements include at least one data category for MCAD data and the ECAD data engineering elements for at least one data category ECAD data include.

The device or system can be designed and set up, for example, as a machine, a device, a robot, a production system or the like, or it can also include parts of this type as components. Such a device or system can include, for example, one or more components, drives, sensors, machines, devices, communication devices or the like.

In the context of the present description and claims, engineering elements are understood to mean all data, modules, software elements, graphic representations, images, or comparable elements which are necessary for engineering the device or system using the automation engineering data, the mechanical Planning data and the electrical planning data are used or can be used.

Typical types of engineering elements and corresponding engineering elements are explained below with regard to the automation engineering data, the mechanical planning data and the electrical planning data.

The engineering elements can, for example, be taken directly from the respective data sources. For example, you can also use an optical Pattern recognition and / or optical character recognition engineering elements can be taken from images and / or graphic representations present in the data collection. Such images and / or graphics, for example, product _Z calibration calculations, its construction drawings, circuit diagrams, exploded views or similar images or grafi specific representations.

Automation engineering data are, for example, data such as are created and / or provided for the automation and / or control of the system or device. Such data are created, for example, in so-called engineering systems, which are used, for example, to create corresponding control programs and to parameterize the components of the system or device and also the corresponding controls accordingly. An example of such an engineering system is, for example, software available on the market with the product name "TIA Portal".

Automation engineering data can include a wide variety of engineering elements, for example one or more control programs, variables, so-called "tags", program modules, function modules, data modules, program blocks, so-called "program organizational units" (POU), data types used, ID -Information on components, configuration data, call information for program elements, comments, control programs and / or comparable engineering elements.

Data categories of the automation engineering data can be, for example:

• Variables or so-called tags, • Program blocks, function blocks, data blocks, program blocks or so-called POUs (POU: Program Organizational Unit),

• User-defined data types (e.g. so-called UDTs),

• Information on components of the device or system,

• Call information for program blocks or POUs,

• Comments, or comparable data categories.

The engineering elements can each be collected according to a data category within the automation engineering data or assigned to one another, for example in corresponding lists, databases or comparable structures. The compilation of engineering elements in each case from a data category from the automation engineering data can also be created in preparation for the implementation of the method according to the present description. Such a compilation of engineering elements can take place, for example, to export the corresponding engineering elements from a corresponding automation engineering system. This compilation can be automated or partially automated, for example. Such compilations can, for example, also be stored in a corresponding engineering system or a corresponding database and then extracted from there for use as part of a method according to the present description.

The engineering elements belonging to a respective one of the named data categories can be present, for example, as lists, tables and / or database structures within the automation engineering data or made available as such by a corresponding engineering system will. For example, engineering elements of the corresponding data categories mentioned above can be present or available as a tag or variable list, as a POU list, data type list, hardware info list, call structure and / or UDT list be asked.

The individual engineering elements within the data categories of the automation engineering data can furthermore each include meta information on the respective engineering elements. Such meta information can, for example, names, comments, referencing, physical units, ID information (such as type names, serial numbers, ID numbers, function names, functionality, etc.) or other information relating to each temporary engineering elements.

Mechanical data or MCAD data can, for example, be engineering elements that are assigned or assignable to the following data categories: parts, parts or component lists, 3D geometries, kinematic information, point-cloud information, names / designations / meta Information on mechanical components or parts, related information on various mechanical components or parts (e.g. name, designation and / or number of other components connected to a specific part as well as, for example, the type and configuration of such connections), image data on corresponding mechanical components or parts from that.

Electrical planning data or ECAD data can, for example, be engineering elements that are assigned to the following data categories or that can be assigned: Function descriptions, location information, reference numbers for products, parts or parts lists, schematic drawings, circuit diagrams, images, Names, designations or number of inputs and / or outputs, information on dynamic behavior (for example, described by so-called "macros") or comparable engineering elements on electrical properties and / or configurations of the device or system.

Relationship information according to the present description can, for example, be parent-child relationships of program modules, program components and / or program or program modules. Be component instances.

Call information between different program modules, program components and / or program or. Program component instances can be such relational information. Furthermore, relationship information can also be called up and / or usage information of variables,

Tags or by appropriate program components.

Any type of assignment of engineering elements to other engineering elements, such as mechanical components or corresponding ID and / or image information, program elements or comparable engineering elements can be related information within the scope of the present description.

Such relationship information can, for example, also be taken from additional information on individual engineering elements used. Additional information on individual or groups of the engineering elements, which can also be designed and set up as metadata or meta information on these engineering elements, can include, for example, names, superordinate functional classes, collective terms, type descriptions, units, physical units, comments, descriptions, physical units, relational Descriptions of other data, functionalities, authors, authorizations, affiliation to components and / or functionalities or comparable information. The assignment of engineering data to such properties or categories can also be relational information.

Relationship information can, for example, also be taken from cross-referencing or material flow information.

Relationship information can be directional or undirected. Directed relationship information can be symbolized, for example, by an arrow within the multigraph, which can symbolize, for example, relationship information such as “is called by”, “belongs to” or similar relationships. Undirected relationship information can, for example, correspond to information that two different data belong to the same data category or are assigned to the same component. This can be taken into account, for example, when generating the multi-graph.

The identification of the relationship information can for example be done by evaluating, for example, call information and / or call chains of program modules, function modules, data modules or general POUs according to the present description. In this way, for example, functional relationships between different clusters that contain different of the above-mentioned modules can be identified.

Furthermore, relationship information can be used, for example, on the basis of meta information on certain automation Engineering data or comments on such data can be determined. Such meta information or comments can, for example, directly correspond to such relationship information, such as, for example, a functional assignment, a structural assignment and / or a spatial assignment. Furthermore, relationship information can also be determined, for example, from names or ID information, for example from the correspondence of parts of names of different data elements of the same category.

A graph is a mathematical structure made up of so-called "nodes" and so-called "edges" that connect two nodes. A graphic representation of such graphs can be, for example, a representation in which the nodes are represented as points or circles and the edges are represented as lines connecting circles.

A multigraph is understood to mean those graphs in which two nodes can be connected via several edges.

Edges can be, for example, so-called "undirected edges" in which the connection of the respective nodes is not assigned a logical direction. Furthermore, edges can also be designed as so-called "directed edges" in which the connection of the respective nodes is assigned a logical direction .

The multigraph can, for example, be arranged and / or stored in a data format customary for graphs. A multigraph in the context of the present invention is also understood to mean any further data structure which also realizes or contains the information contained in a multigraph. A sub-graph can also be used in each for Graphs can be arranged and / or stored in a data format customary in the field. A sub-graph in the context of the present invention is understood to mean any data structure which realizes and / or contains the information contained in the sub-graph.

The structure of a multigraph in the sense of the present invention can for example be done in such a way that the nodes of such a multigraph correspond to different engineering elements, i.e. each node of the multigraph corresponds to an engineering element of the data collection. The edges or connections within the multigraph are formed by relational information between the respective engineering elements, ie an edge or connection between two nodes of the multigraph corresponds to relational information between the engineering elements corresponding to the two nodes .

Such relationship information, which can be represented as a corresponding connection between two nodes, can be, for example, call information or referencing information between software modules that are assigned to the respective nodes. Furthermore, for example, a node as an engineering element can be assigned a specific category designation or a specific physical unit. In this case, connections of further engineering elements to these named nodes can be assigned, for example, to an affiliation of the further engineering element to this category or also to the use of the corresponding physical unit by the engineering element. Furthermore, for example, a connection between two nodes can also be assigned the information that the two engineering elements assigned to the nodes, for example one of the same Belong to a data category or have other comparable similarity properties.

As part of the structure of the multigraph, a so-called “weighting” can be assigned to an edge or the corresponding connection between two nodes. Such a weighting can for example be used as a strength and / or relevance of the relationship between the two Here, connections or edges between nodes can be weighted differently depending, for example, on their category Directional information can also be weighted differently than non-directional relationships, for example.

For example, in a multigraph, different connections between nodes can each be weighted differently, for example depending on a category of the associated relationship information or comparable criteria.

In a first example, for example, the weighting can be carried out in such a way that relationships between a software component and a mechanical part are rated as the most important connection in the context of a corresponding multigraph and are therefore given the highest weighting relative to the others. In this way, in a subsequent clustering, for example, clusters can preferably arise in which engineering elements are contained which have a relationship to a specific mechanical part. In a further example, for example, the number of calls between software components can be evaluated such that a higher number of calls has a higher weighting assigned to one of these calls Connection between the nodes corresponds to the respective software components are assigned. In this way, for example, clusters can be formed in which engineering elements with comparable functionality are combined or engineering elements that are assigned to a specific functionality. Furthermore, for example, calling information and / or referencing information can also be weighted more heavily than belonging to a certain category or physical unit.

For assigning a weighting to an edge or connection between two nodes, the weighting categories mentioned above can also be combined with one another as required.

Before performing the clustering method, for example, all of the relationships between two nodes can then be added up and / or combined into a single weighted connection between these two nodes, for example, taking into account their respective weightings. This summary connection, e.g. with its respective weighting, can then be used to carry out the subsequent clustering.

Alternatively, however, the clustering can also take place without a previous summing up of several connections or edges between two nodes, where appropriate, in which case, for example, the fact of several connections between two nodes can then be taken into account in the context of the clustering.

In the context of the following description, the words "nodes" and "engineering elements" are used synonymously on graphs in this context. Furthermore, the terms "relationship between nodes", "relationship Information between nodes "," edge between nodes "," relationship between engineering elements "," relational information between engineering elements "and comparable terms used synonymously in the context of the following description in relation to graphs.

The selection, the setting up and / or the execution of the clustering method can be designed and set up in such a way that, for example, clusters or sub-graphs are formed in such a way that such engineering elements are contained within a cluster or sub-graph which are each assigned or can be assigned to a specific component and / or functionality of the device or system.

When applying the clustering method to the multigraph to determine at least one sub-graph, a clustering method or clustering algorithm is used, for example, as is known to the person skilled in the art for such analyzes in order to assign topologies of such multigraphs analyze and use this analysis to segment it into one or more sub-graphs. Such a sub-graph can then, for example, include engineering elements that have an above-average and / or particularly close relationship to one another. For example, these can be engineering elements that are or can be assigned to, or can be assigned to, a specific functionality of the device or installation and / or a specific component of the device or installation.

Such a sub-graph can, for example, already be referred to as a self-description data module in the sense of the present description. A clustering or clustering method is understood to mean a technique of so-called "machine learning" in which data or data points are grouped into so-called "clusters". In the case of a set of data or data points, a cluster analysis method, a clustering method or a clustering algorithm can be used, for example, in order to classify each date or data point into a specific group. Such a group is then referred to as a "cluster". Data or data points that are in the same group (that is, the same cluster) have similar properties and / or features, while data points in different groups have very different properties and / or features.

Mathematically, clusters consist of objects that are closer to each other (or vice versa: higher similarity) than to the objects of other clusters. Corresponding clustering methods can be differentiated, for example, according to the distance or proximity measures used between objects in the clusters, but also between entire clusters. Furthermore, or alternatively, corresponding clustering methods can also be differentiated according to the respective calculation rules for such distance measures.

In general, the clustering method applied to the multigraph can be designed and set up, for example, as a local or global method. In this case, the methods are either applied globally to the entire multigraph or only locally to a subgraph of the multigraph. Accordingly, global methods require information about the topology of the entire multigraph, while with local methods the neighborhood of a single node can only be considered recursively. Thus can networks that are not completely determined a priori can also be considered using local methods.

In the context of a global clustering method, so-called top-down or so-called bottom-up methods, for example, can still be used. In the top-down method, a large start cluster is recursively subdivided into smaller and smaller sub-clusters based on various criteria, while in the bottom-up method, many smaller clusters are successively combined into larger ones until the clustering meets a termination criterion.

The so-called "spectral methods" are an example of a class of top-down methods. Another group of methods that follow the top-down approach are the so-called "Random Walk" or "Markov Chain Methods". For so-called weighted graphs, for example, the "maximum flow method" are also suitable for performing clustering. They also belong to the group of top-down procedures. One example of clustering methods that use a bottom-up approach is known, among other things, from the so-called "modularity optimization". Another representative is the so-called "closest neighbor method", which is also often used for general classification problems. In order to be able to apply the "closest neighbor method" to graphs, a similarity between two nodes must be defined. Such a similarity can take place, for example, on the basis of existing metadata of each node, or on the basis of the intersection of the direct neighbors of two nodes. While the above-mentioned methods can all be assigned to the class of global methods, there is, for example, the so-called "CPM method" as a possible local method. The use of the clustering method can include, for example, the use of a clustering algorithm or also the use of several clustering algorithms, for example one after the other. Such clustering algorithms can, for example, be a so-called “K-Means Clustering”, a so-called “Mean Shift Clustering”, a so-called “Expectation Maximization (EM) Clustering using Gaussian Mixture Models (GMM)” "Agglomerative Hierarchical Clustering" and / or a so-called "Density-Based Spatial Clustering", for example a Density-Based Spatial Clustering of Applications with Noise (DBSCAN) ". Further examples of clustering algorithms can be, for example, the following algorithms:" Mini Batch K-Means "," Affinity Propagation "," Mean Shift "," Spectral Clustering "," Ward "," Agglomeration Clus tering "," Birch "," Gaussian Mixture ".

In method step d.), In the context of the present description, the selection of a sub-graph from the at least one sub-graph determined within method step c.) Is understood to mean that from the at least one sub-graph determined within method step c.) -Graph a sub-graph is selected.

The self-description data module can be created, for example, by storing the sub-graph structure generated in the context of the clustering process directly in the self-description data module.

Furthermore, the creation of the self-description data module can also include, for example, a suitable arrangement and / or storage of the information contained in the sub-graph or the self-description data module can consist of a suitable arrangement of the information contained in the sub-graph. This suitable arrangement and / or storage of the information contained in the sub-graph can for example take place within a suitable database structure in the self-description data module and / or in any suitable database format in the self-description data module. Such database formats can be, for example, so-called relational database formats or SQL database formats or also so-called NoSQL database formats, semantic database formats, multigraph data formats or knowledge graph data formats.

Different parts of the information contained in the sub-graph can also be stored in different of the formats mentioned above.

The aforementioned "NoSQL database formats" ("NoSQL": English for "Not only SQL") are understood to mean databases with a non-relational approach. In particular, NoSQL databases in the context of the present description are document, graph, Understand object, attribute-value pairs and / or column-oriented databases.

A NoSQL database in connection with the present description can be used, for example, as a document-oriented database, a graph-oriented database, a knowledge graph, a distributed ACID database, a key-value database, an attribute-value pair -oriented database, a multivalue database, an object-oriented database and / or as a column-oriented database or a combination or further development of such databases can be set up and designed. In the self-description data module, the information or parts of the information can be stored as a relational database, or the self-description data module can comprise such a database. Furthermore, in the self-description data module, the information or parts of the information can also be used as a NoSQL database, one or more knowledge graphs, a non-relational database, an OWL database, an RDF database and / or a SPARQL as a query database using the database or the self-description data module can comprise one or more such databases.

Furthermore, the self-description data module can be created in such a way that, for example, the program and / or data blocks contained therein are stored in the self-description data module in such a way that they can be integrated directly into the corresponding engineering project as part of a later engineering for another device or system are. Meta information assigned to these program and / or data modules can also be stored in the self-description data module in such a way that this is or can be integrated accordingly in the engineering project as part of a later engineering for the other device or system. In this way it is possible, for example, to build a module library for an engineering system from such self-description data modules or to build a module library which includes such self-description data modules. Using such a library, the engineering of the automation of further devices or systems can be simplified, since in this way it is possible to fall back on experience from previous projects. Furthermore, the self-description data module can comprise corresponding software elements or modules in such a way that these are at least partially stored as directly executable software in the self-description data module. These software elements or modules can be stored as executable software, for example, in such a way that they can be integrated directly into a control program for a corresponding control device for a system or device, or they can also form an independent control program for the system or device.

In this way, self-description data modules can be generated which, by means of the directly executable software elements, enable certain functionalities or program elements to be directly incorporated into corresponding control programs or control devices for the device or system.

In an advantageous embodiment, the method can, for example, also be designed and set up in such a way that, as part of method step e.), A content description file is generated which comprises at least one description element for the functionality and / or component to which the sub-graph data stored in the self-description data module.

The wording that the content description file is generated as part of method step e.) Is understood to mean that the content description file is generated as part of the creation of the self-description data module or only after the self-description data module has already been generated is.

The content description file can be stored in the self-description data module or also separately therefrom. By means of such a content description file, it is made possible in a simplified manner to obtain an overview of the sub-graph data contained in the self-description data module or a component and / or functionality to which this sub-graph data is assigned. This content description file can, for example, also be transmitted to other components or output. For example, a call, an output, an execution and / or a corresponding action with regard to the functionality or component characterized by the self-description information.

The content description file can be set up and designed as a table and / or list, for example. Furthermore, the content description file can also be designed and set up as a database structure in accordance with the present description.

The creation of the content description file can, for example, be automated or partially automated, whereby in this context, for example, designations and / or meta information assigned to the respective engineering elements can be used to generate one or more description elements characteristic of the engineering element within the content description file.

In the case of engineering elements, the executable software code for generating a specific functionality, for example include, an associated description element can include, for example, one or more terms that are characteristic of the functionality. Furthermore, in this case, parameter information relating to the input parameters necessary for executing the functionality can also be part of the content description file and / or a corresponding description element.

This determination of a description element for a certain engineering element can, for example, be automated. This determination can also take place in a semi-automated manner, for example by offering a user various names and / or meta-information elements assigned to the engineering element for selection, for example on a screen. After a corresponding selection by the user, the selected element is then assigned to the content description file.

Such description information for the self-description data module can be information which describes or characterizes data contained in the self-description data module, for example the engineering elements contained therein. Furthermore, such descriptive information can also be names, identifiers and / or descriptive information which characterize the functionality and / or component to which the self-description data module relates. Furthermore, descriptive information, in particular for a functionality, can also be information about, for example, parameters necessary for executing the functionality and / or corresponding parameter ranges. Information about, for example, boundary conditions for performing a functionality (for example with regard to materials, maximum or minimum size ratios, etc.) can also be such descriptive information. The self-description data module can be designed and set up in such a way that when a description element assigned to a specific engineering element is input, a call, output, execution and / or a comparable action of the associated engineering element ensues.

A method according to the present description can furthermore be designed and set up such that the self-description data module created as part of method step e.) Is designed and set up as a skill data module with regard to a functionality of the device or system.

The generation of the self-description data module as a skill data module can take place, for example, in such a way that the self-description data module is generated directly as a skill data module or that the skill data module is generated in a separate work step after a corresponding self-description Data module has already been built. Furthermore, the self-description data module can also be generated first and then converted into a skills data module.

A self-description data module, which is at least among other things characteristic of a functionality of a device or system, can be referred to quite generally, for example, as a so-called “skill”. Such “skills” include such data and / or functions -Modules understood, which for the execution of a certain functionality within a device or system information and / or software elements necessary to comprehend, in particular all for the execution of the Functionality include necessary information and software elements.

Such a self-description data module designed and set up as a skill is also referred to as a “skill data module” in the context of the present description and the claims.

For such a skill data module, a corresponding content description file can then include a skill designation and / or skill description and / or information and parameters necessary for executing the skill.

Furthermore, the skill data module can include software elements necessary for executing the associated functionality - in particular all software elements necessary for executing the functionality. Such software elements can for example be stored as program code within the skill data module. In particular, such software elements can be stored as executable program code within the skill data module. Furthermore, the skill data module can be designed and set up in such a way that it is designed and set up to control the functionality within the device or system when the skill data module is suitably implemented and / or stored within the device or system.

A device or system in which such a skill data module is implemented can then, for example, communicate the corresponding skill description to external devices. They can then, for example, call up this skill with the appropriate parameters, after which the associated functionality and then by means of the process of im Self-description data module contained software elements triggered and / or executed.

Furthermore, a method according to the present description can include the following method step: f.) Identifying description information with regard to the engineering elements assigned to the determined self-description data module within the data collection and within the first, second and / or third data source and storing the identified ones Description information in the self-description data module.

Process step f.) Can preferably be carried out after process step e.), In particular carried out immediately after process step e.).

The identification of description information within the first, second and / or third data source is designed and set up in such a way that research is only carried out in those of the data sources mentioned that are actually available in the context of the implementation of the method.

The description information can be identified and set up in such a way that the description information that has been identified for a specific engineering element is stored in the self-description data module. If no description information has been identified for an engineering element, no description information is stored in the self-description data module for this engineering element either.

Descriptive information on engineering elements (such as function blocks, electrical elements, Wiring diagrams, wiring connections, etc.) can include, for example, keywords, comments, designations, titles, descriptions, manuals, information from manuals, ID information (such as identification numbers, order numbers, brand names, etc.) or similar the respective engineering elements be descriptive and / or identifying information.

Such description information can be determined, for example, by searching for corresponding description information within meta information on the respective engineering elements. Furthermore, in the context of designations, titles or ID information already determined in this way, it is then possible to search for further information relating to the corresponding engineering element in the data sources used.

In addition, descriptive information can also be taken from images and / or graphic representations, for example, via optical pattern recognition and / or optical character recognition. Can verifiable calculations, Konstrukti onszeichnungen, his circuit diagrams, exploded views or ver parable images or graphics settings such images and / or graphic depicting as product _Z.

A method according to the present description can furthermore comprise the following method step: g.) Identifying context information relating to the engineering elements assigned to the determined self-description data module within further data sources and storing the identified context information in the self-description data module. Process step g.) Can preferably be carried out after process step e.) Or f.) Or also after process step e.) Or f.), Further subsequent process steps. Furthermore, method step g.) Can also run in parallel to the execution of method step e.) Or f.).

In an advantageous embodiment of the invention, the identified context information can then also be stored in the self-description data module.

In this context, context information relating to a self-description data module is understood to mean information that relates to engineering elements and / or at least one functionality or component of the self-description data module. Such context information can be, for example, descriptive information, origin information, function descriptions, manuals, images, CAD data, 3D data, parts lists and / or comparable information.

The context information can be identified and set up in such a way that the context information that has been identified for a specific engineering element is stored in the self-description data module. If no context information has been identified for an engineering element, no context information is stored in the self-description data module for this engineering element either.

Further data sources can be, for example, a wide variety of data sources relating to at least one of the engineering elements assigned to the self-description data module and / or information relating to this comprise at least one engineering element. Such further data sources can be, for example, databases, design systems, programming manuals, programming guidelines, international standards (for example IEC 61131), process descriptions, process steps, standards and / or similar data sources.

In the context of the identification of the context information, context information generated via optical pattern recognition and / o optical character recognition can also be taken from images stored in the further data sources and / o from the graphic representations, for example. Such images and / or graphic representations can be, for example, product drawings, construction drawings, circuit diagrams, explosion drawings, process flow diagrams or comparable images or graphic representations.

In an advantageous embodiment of the invention, context information taken from the further data sources can be compared with the information originally stored in the self-description data module. This comparison can, for example, relate to the specific engineering elements for ordered description information or also relationship information between engineering elements. In this way, it is possible, for example, to determine whether the information that is stored in the self-description data module corresponds, for example, to corresponding standards or guidelines or also to process descriptions.

In the context of this advantageous refinement, corresponding information can then be output to a user after such indications have been determined. The identifi ed description information and / or the identified context information can advantageously be stored in the self-description data module as a semantic database.

Saving the identified descriptive information and / or the identified context information in the self-description data module leads to an advantageous self-description data module, which then forms a data module that contains, for example, a set with regard to one or more functionalities, including, for example, corresponding engineering elements including descriptions of their functions, their possible uses and other descriptive data.

In this way, for example, an encapsulated data module is created in which a wide variety of information from a wide variety of engineering sources on one or more functionalities of a device or system or one or more components of a device or system is collected, preferably including information about possible relationships between the stored information.

The use of a semantic database format for storing the information mentioned enables both the storage and the retrieval of stored information in a particularly efficient manner. This is particularly the case when a large number of different data types and relationships between engineering data are stored in the self-description data module. Such a storage of such a large number of data types in a "normal" relational database can be very complex and memory-intensive, possibly even impossible. A semantic database can, for example, be a database in which the stored information can be determined by means of semantic search operations. The semantic database can be present, for example, in a so-called NoSQL database format or also in the so-called knowledge graph data format. Different parts of the semantic database can also be stored in different of the formats mentioned above. Furthermore, the semantic database can also include further parts that are not present in any of the database formats mentioned above.

A NoSQL database can be set up and designed in accordance with the present description. It can be used, for example, as a document-oriented database, a graph-oriented database, a knowledge graph, a distributed ACID database, a key-value database, an attribute-value pair-oriented database, a multivalue database, an object-oriented database and / or as a column-oriented database or a combination or further development of such databases can be set up and designed.

In the semantic database, the stored information or parts of the stored information can also be used as a NoSQL database, one or more knowledge graphs, a non-relational database, an OWL database, an RDF database and / or a SPARQL as a query be stored using the database or the semantic database can include databases of this type.

A method according to the present description can furthermore be designed and set up in such a way that the Self-description data module is stored in a storage device of the device or system, and / or that the self-description data module is stored in an engineering system for mechanical, electrical and / or automation engineering.

An automation engineering system can be designed and set up, for example, as a computer system with suitable software that is designed and set up to generate automation engineering data for a specific machine or production plant. Such automation engineering data are, for example, data such as are created and / or provided for the automation and / or control of the production plant or machine. This includes, for example, using such an automation engineering system to create appropriate control programs, for example, and to parameterize the components of the production plant or machine and the corresponding controls accordingly. An example of such an engineering system is, for example, a computer system on which the software available on the market with the product name "TIA Portal" is installed.

The self-description data module can be stored in the engineering system, for example, in a memory of a computer or a control device which is part of the engineering system or on which the engineering system or parts thereof are installed and / or implemented. The above-mentioned object is also achieved by a self-description data module which was created using a method in accordance with the present description.

The above-mentioned object is also achieved by a computer-readable storage medium comprising a self-description data module according to the present description.

The above-mentioned object is also achieved by a device or system with a memory device which comprises a self-description data module according to the present description.

A device or system designed and set up in this way is able to communicate information about its functionalities and / or components to external devices, such as other devices, systems, computers and / or corresponding input and / or output devices, with reduced additional effort . In this way, it can be made possible, for example, for such external devices to access such information and / or functionalities in a targeted manner and thus, for example, to use the device or system or at least one of its functionalities in a simplified manner.

In an advantageous embodiment, the device or system with the self-description data module can be designed and set up in such a way that the self-description data module includes a content description file according to the present description and / or that the device or system for generating a In the description of contents file is designed and set up in accordance with the present description. Furthermore, such a device or system can be designed and set up for communicating the content description file to an external device. Such a device or system for receiving a description element from the content description file with regard to the functionality of the device or system and, if necessary, can then correspond to a call, an output of corresponding information with regard to the functionality or component and / or a call or execution of the the functionality must be designed and set up.

In this way, it is made possible that the device or system is automatically or at least partially automated in a position to transfer information regarding its one or more functionalities and / or components to external devices, such as another device or system, a web server, an OPC Server, a display unit, a control system and / or a comparable device to output.

Furthermore, an activity related to the engineering element can be triggered, for example, by selecting a specific description element characteristic of an engineering element. For example, one or more items of information assigned to the engineering element can be output or a functionality assigned to the engineering element can be called up or triggered.

In this way, a correspondingly configured device or system can be used advantageously in the context of a modular production system, for example in the context of a so-called cyber-physical production system (CPPS). Furthermore, in this way so-called “skills” can be or will be implemented within the device or system, which can then also be communicated or communicated to other devices, devices or systems as required, for example to enable these devices or systems to work together in the To enable or simplify the framework of a production.

The above-mentioned object is also achieved by an automation engineering system with a memory device, the memory device comprising a self-description data module according to the present description.

The automation engineering system can be designed and set up in accordance with the present description.

An automation engineering system configured in this way allows simplified engineering of a further device or system. Such engineering is simplified in particular if the further device or system has at least partially the same or similar functionalities as the device or system according to the present description and / or at least partially has the same components.

In this case, when creating automation applications for the automation of the further device or system, engineering data created in the past for corresponding functionalities or components can be used. This simplifies and / or accelerates the engineering of the further device or system.

The automation engineering system can, for example, continue to be designed and set up in such a way that that it comprises a content description file with regard to the self-description data module and / or is designed and set up to generate such a content description file. The automation engineering system can then, for example, also be designed and set up in such a way that contents of the content description file can be output to a user of the automation engineering system, for example, and by selecting one or more description elements of the content description file, which are each assigned to one or more engineering elements, the associated engineering elements can be taken over, for example, for the engineering of the automation of the further device or system.

Further advantageous refinements can be found in the subclaims.

The present invention is explained in more detail below by way of example with reference to the accompanying figures.

Show it:

FIG. 1: Exemplary representation of a process sequence for creating engineering data;

FIG. 2: Exemplary list of engineering data and relationship data;

Figure 3: Exemplary sequence for creating a multi graph and skill data module

FIG. 1 shows schematically an exemplary sequence for creating a self-description data module according to the present description from corresponding engineering data. In a first step 110, engineering data 100 are made available. The engineering data 100 are an example of a data collection comprising engineering elements according to the present description. The engine ering data 100 and the engineering elements contained therein will be discussed in more detail in the context of the description relating to FIG.

In a next process step 120, related information 150 between individual engineering elements contained in the engineering data 100 is determined for this engineering data 100. The corresponding relationship information 150 and its determination are also discussed in greater detail in connection with the explanations relating to FIG.

In a subsequent work step 130, a multigraph 200 is then created from engineering elements of the engineering data 100 and corresponding to the information 150 relating to this engineering data 100. The selected engineering elements are selected as nodes in this multigraph 200 and the corresponding relationship information 150 as a connection between the respective nodes. The multigraph 200 can be created and saved as a graphic representation or a correspondingly adapted mathematical or other representation of the multigraph structure.

An exemplary creation of such a multigraph 200 is explained in more detail in the context of the explanations relating to FIG.

Then, in a clustering step 140, the multigraph 200 is broken down into sub-graphs 280, 290, the clustering being designed and set up in such a way that the identified sub-graphs 280, 290 correspond, for example, to certain functionalities or components of an underlying installation or device. The clustering step 140 is also explained in more detail by way of example in the context of the explanations relating to FIG.

After clustering 140, a selection step 150 then takes place in which one of the sub-graphs 280, 290 identified in clustering step 140 is selected for the creation of a corresponding self-description data module 380, 390.

In a final work step 160, the self-description data module 380, 390 is then created. Such a creation of a self-description data module 380, 390 is also explained in more detail by way of example with reference to the explanations relating to FIG.

FIG. 2 shows a listing of engineering data 100 for a device or system according to the present description. The engineering data 100 include automation engineering data 110, mechanical CAD data (MCAD) 120 and electrical CAD data (ECAD) 130.

The automation engineering data 110 include data which are required or used in the context of an automation of the device or system, for example using appropriate controllers or a programmable logic controller. Such data are, for example, a variable list and / or what is known as a “tag” list of the variables or tags used in the context of controlling the device or system within such a controller. A "day" is used as part of the automation Engineering is understood, for example, as a variable which is identified for display or input in an operating and monitoring system (SCADA system) or a graphical user interface (HMI: Human Machine Interface).

Furthermore, the automation engineering data 110 include function blocks, data blocks, other so-called "Program Oranizational Units" (POU) or the code of a corresponding control program for controlling the device or system by a corresponding controller or a system used in the context of controlling the device or system corresponding programmable logic controller.

The automation engineering data 110 also include a list of user-defined data formats (so-called “UDT” s (User Defined Type)) that were created or set up as part of the creation of the automation engineering data 110.

Furthermore, the automation engineering data 110 includes a list of information relating to hardware components used in the device or system. This information can include, for example, component names, component ID information (for example serial numbers, order numbers, or the like), component type designations, component description information, a list of parameters used in each case and / or corresponding Parameter limit values, geometric information on corresponding hardware components and / or additional, background or support information on the corresponding hardware components.

Call structures for function blocks, data blocks and / or other POUs are also part of the automation Engineering data 110. Such structures represent which of the modules call and / or reference which other modules. For example, chain-like structures, so-called call chains, or tree-like structures can arise here.

The mechanical CAD data (MCA data) 120 include a parts list of the components of the device or system, 3D information on the components of the device or system and on the device or system itself. Furthermore, the MCAD data 120 include kinematics information relating to individual components that of the device or system, the device or system as a whole and between various of the components of the device or system. Furthermore, the MCAD data also include point-cloud information with regard to individual components of the device or installation and that of the device or installation as a whole.

Relationship information between parts of the device or installation is also part of the MCAD data 120. Such relationship information can, for example, be information about which components of the device or installation adjoin or are connected to which other components. The type of connection between two components can also be part of the relationship information. The connection between two components can be, for example, a spatial or mechanical connection or also a functional connection.

The electrical CAD data (ECAD data) 130 include circuit diagrams of the device or system and its components, function plans thereof, function diagrams, function lists, location information relating to electrical modules and components of the device or system and the device or the like - that of the system as a whole. The ECAD data 130 includes Furthermore, a parts list of the electrical and electronic components used, a corresponding product identification list and images of such components and corresponding circuits in which, for example, these components are used.

The above-mentioned examples for automation engineering data 110, MCAD data 120 and ECAD data 130 are examples of engineering elements according to the present description.

Furthermore, FIG. 2 shows a data collection of relationship data 150, which are examples of relationship information according to the present description. The relationship data contain relationships between different function blocks and / or data blocks that can be or were derived, for example, from the above-mentioned call structures for such blocks. Furthermore, the relationship data 150 include information about the relationship between various data, which can be obtained, for example, from information relating to tags or variables.

Furthermore, the relationship data 150 include information about which program modules, function modules, data modules or generally the so-called "POUs" are assigned to which components and / or parts of the device or system. Such information can be obtained from comments or other meta-information, for example Relationships between electrical, mechanical and software objects are also part of the relationship data 150. Such relationships can be obtained, for example, from 3D information or CAD data, comments, parts lists and other meta-information These data sources can also be used, for example, to determine information about mechanical connections between various components and / or parts of the device or system, which are also part of the relationship data 150.

Information obtained from wiring plans with regard to, for example, electrical, communication or data connections of various electrical or electromechanical components is also part of the relationship data 150.

FIG. 3 shows an exemplary example for the process of generating two skill data modules 380, 390 starting from a multigraph 200. For the sake of clarity, only a section of an entire multigraph is shown for this illustration, which is explained on the basis of the in FIG terten engineering data 100 can be created.

The multigraph 200 shown in FIG. 3 is based on some function modules 210, 220, 240, 250 and a data module 230 from the automation engineering data 110 according to FIG Used information for data modules is taken from the relationship data 150 (see FIG. 2).

The multigraph 200 shown at the top left in FIG. 3 is an example of a result of the first three method steps 110, 120, 130 according to FIG. 1.

The multigraph was set up in such a way that nodes of the multigraph 200 were assigned to the four function blocks 210, 220, 240, 250, which are labeled “FBI”, “FB 2”, “FB3”, “FB4” in FIG . Furthermore, a node in the multigraph 200 was also assigned to the data module 230. Furthermore, it can be seen from the call structures for function blocks within the relationship data 150 that the function block “FBI” 210 calls the second function block “FB2” 220 three times during its course. This is implemented in the multigraph 200 in such a way that a directional connection 212 is set up three times from the first function module 210 to the second function module 220, where the category “calls” is still assigned to these connections 212.

Furthermore, the data module 230 is referenced once by the first function module 210, which is represented by a directional connection 214 between these two nodes 210, 230 in the multigraph 200. This connection 214 is assigned the property “referenced”. The second function module 220 also references the data module 230, the second function module 220 referencing the data module 230 twice as part of its sequence and the data block 230 implemented in the multigraph 200.

In a corresponding manner, it is created in the multigraph 200 that the fourth function block “FB4” 250 calls the first function block “FBI” 210 by creating a correspondingly directed connection 254 between the corresponding nodes 250, 210 with the category “calls” In the same way, it is created in the multigraph 200 that the third function block “FB3” 240 is called three times during the course of the fourth function block “FB4” 250, which in turn takes the form of three parallel connections 252 between the corresponding nodes 240, 250 is implemented in the Multigra phen 200. These directed connections The category “calls” is again assigned to 252 in a corresponding manner.

In the case of the connections 212, 214, 222, 252, 254 between the respective nodes 210, 220, 230, 240, 350) in the multigraph 200 shown in FIG. 3, not all of the connections are always provided with the corresponding reference symbols for reasons of clarity.

In the upper right part of FIG. 3, a clustered multigraph 202 is shown, which is made up of the multigraph 200 shown at the top left after execution of a clustering step 140 (see FIG. 1; symbolized in FIG. 3 by a

Arrow 140) emerges according to the present description.

In the present case, the clustering was designed and set up, for example, in such a way that a logical or resulting connection between two nodes of the multigraph 200 was weighted more heavily the more connections exist between these two nodes. As already mentioned elsewhere in the context of the present description, such a clustering procedure preferably produces clusters that can be assigned to special functionalities of a device or system.

As a result of the clustering step 140, which is symbolized in FIG. 3 with an arrow 140 between the multigraph 200 and the clustered multigraph 202, two clusters 280, 290 were identified in the clustered multigraph 202, which in FIG 280 and are indicated by corresponding dashed frames.

Furthermore, two skill data modules 380, 390 are shown in FIG. 3 at the bottom right, each of the skill data modules 380, 390 each being the result of an application of the final two method steps 150, 160 according to FIG. This is symbolized in FIG. 3 by an arrow labeled “150 + 160”. In the context of these two process steps 150, 160, one of the subgraphs 280, 290 of the clustered multigraph 202 is selected in each case (process step “Select sub-graph "150) and the corresponding skill data module 380, 390 is generated therefrom (method step" Create self-description data module "160), which is an example of a self-description data module according to the present description.

As part of the generation of the first skill data module 380 from the first cluster 290 labeled “Skill 1”, a skill description file 382 was generated for the first skill data module 380. This skill description 382 contains a description of a functionality that corresponds to the first Skill data module 380 is assigned. Such a skill description can, for example, be generated automatically or also partially automatically. This can be done by adding, for example, comments, descriptions or further meta-information to the function and data blocks 210, 220, 230 and / or to the corresponding relationship information 212, 214, 222 in the first skill data module 380. This meta information is searched, for example, for terms, descriptions and / or references, for example, a certain functionality and / or a certain component can be assigned.

A skill description 382 for the first skill data module 380 can then be generated automatically, for example, from such matching description or meta information. Furthermore, in an alternative, partially automated mode, appropriate suggestions for such a skill description 382 can be output to a user. This can then subsequently select one of the suggestions, for example, after which a corresponding skill description 382 is then generated. Furthermore, a user can also manually generate the skill description 382.

The first skill data module 380 furthermore includes an additional information file 384 with regard to the engineering elements 210, 220, 230 contained in the first skill data module 380 and the related information 212, 214, 222 assigned to them. Such information can, for example, be descriptions genes, comments, instructions or comparable meta-information or meta-information sources for the correspondingly named elements. The additional information file 384 can be designed and set up, for example, as a database in accordance with the present description. Both the skill description file 382 and the additional information file 384 of the first skill data module 380 can be part of a content description file according to the present description or form such a content description file.

In a comparable manner, the second skill data module 390 is also assigned a corresponding skill description file 392 and a corresponding additional information file 394. The files mentioned can be generated, for example, analogously to the above description with regard to the skill description file 382 and the additional information file 384 of the first skill data module 380. The skill description file 392 and / or the additional information file 394 can also be part of a content description file in accordance with the present description or each or together form such a file. For example, the skill description files 382, 392 can include a unique identifier for the respective skill data module 380, 390, on the basis of which, for example, a skill data module 380, 390 can be called up and / or selected. For example, in the case in which a skill data module is generally designed and set up as executable program code and / or comprises such executable program code, this program code can be called up using a unique identifier assigned to this skill data module and / or a Expiry of this program codes are triggered. Furthermore, on the basis of the unique identifier, a corresponding skill data module, to which this identifier is assigned, can be called up from a database and loaded into an engineering project, for example.

Such skill description files, such as the skill description files 382, 392 shown in FIG. 3, can furthermore include parameters and / or parameter descriptions which are required, for example, to run a functionality assigned to the corresponding skill data module. Such parameter descriptions and / or parameters can, for example, also include physical units of such parameters and / or parameter limit values for the corresponding parameters. For example, a skill data module designed and set up as executable program code can still be called up by transmitting the assigned unique identifier and the parameters required for the execution.

Using the additional information files 384, 394, further information on the engineering elements contained in the respective skill data module 380, 390 can be made accessible to a user of the corresponding skill data module 380, 390, for example. Such additional information can For example, they can be used to integrate a corresponding skill data module as simply as possible into a corresponding engineering project or also to modify, change or adapt a corresponding skill data module.

The skill data modules 380, 390 generated in the example shown in FIG. 3 can then be stored, for example, in a storage device of a device or system assigned to the assigned engineering data 100. Furthermore, the skill data modules 380, 390 can also be stored in a storage device of an engineering system or a corresponding database, for example when creating a new engineering project or automation program for a further device or Plant to be used. A

They can be used, for example, directly in the stored version, or the respective skill data module 380, 390 can also be adapted before integration into a new automation project or automation program.

Claims

1.) A method for generating a self-description data module (380, 390) each with respect to at least one functionality and / or at least one component, a device or system, wherein a data collection (100) comprising engineering elements from at least one of the There are three data sources listed below:

- A first data source with automation engineering data (110) relating to an automation and / or automation planning of the system or device or parts of it,

- A second data source with MCAD data (120) with regard to a mechanical and / or spatial planning of the device or system or parts thereof, and / or with regard to a mechanical and / or spatial configuration of the device or system or parts thereof,

- A third data source with ECAD data (130) relating to an electrical planning and / or circuit planning of the device or system or parts thereof, and / or relating to an electrical configuration and / or implemented current flow planning of the device or system or parts thereof, The method comprises the following method steps: a.) Determination of related information (150) which are respectively assigned to engineering elements of the data collection (100), b.) Generation of a multigraph (200) comprising nodes (210, 220, 230, 240, 250) and connections (212, 214, 222, 252, 254) between nodes, the nodes each being assigned to engineering elements of the data collection and the connections being assigned to the relationship information (150) determined in accordance with method step a.), c.) applying a clustering method to the multigraph (200) to determine at least one sub-graph (280, 290) within the multigraph (200), d.) selecting a sub-graph (280, 290) from the in Method step c.) Determined at least one sub-graph (280,290), e.) Creation of a self-description data module (380,

390) with respect to a component and / or a functionality of the device or system, the self-description data module (380, 390) comprising the selected sub-graph (280, 290) and / or information contained in the sub-graph (280, 290) .

2.) The method according to claim 1, characterized in that in the context of method step e.) A content description file (382, 384, 392, 394) is generated which comprises at least one description element for the functionality and / or component, to which the sub-graph data stored in the self-description data module (380, 390) relates.

3.) The method according to any one of claims 1 and 2, characterized in that the self-description data module (380, 390) generated as part of method step e.) As a skill data module (380, 390) with respect to a functionality of the device o- the system is trained and set up.

4.) Method according to one of the preceding claims, characterized in that the method further comprises the following method step: f.) Identifying description information relating to the engineering elements assigned to the determined self-description data module (380, 390) within the data collection (100) and within the first, second and / or third data source (110, 120, 130) and storing the identified ones Description information in the self-description data module (380, 390).

5.) The method according to any one of the preceding claims, characterized in that the method further comprises the following method step: g.) Identifying context information relating to the determined self-description data module (380, 390) related to engineering elements within further Data sources and storing the identified context information in the self-description data module (380, 390).

6.) The method according to claim 4 or 5, characterized in that the storage of the identified descriptive information and / or the identified context information in the self-description data module (380, 390) takes place as a semantic database.

7.) The method according to any one of the preceding claims, characterized in that the self-description data module (380, 390) is stored in a storage device of the device or system, and / or that the self-description data module (380, 390) in an engineering system for mechanical, electrical and / or automation engineering is stored.

8.) Self-description data module for a device or system, characterized in that the self-description data module (380, 390) was created using a method according to one of the preceding claims.

9.) Computer-readable storage medium comprising a self-writing data module (380, 390) according to one of the preceding claims.

10.) Device or system with a memory device, wherein the memory device comprises a self-description data module (380, 390) according to one of claims 1 to 8.

11.) Device or system according to claim 10, characterized in that the self-description data module (380, 390) comprises a content description file (382, 384, 392, 394) according to claim 2 and / or the device or system for generating a content description file (382, 384, 392, 394) is designed and set up according to claim 2, and that the device or system for communicating the content description file (382, 384, 392, 394) to an external device is also designed and set up is set up, and / or that the device or system to receive a descriptive element from the content description file (382, 384, 392, 394) with regard to the functionality of the device or system and subsequently a call, an output of corresponding information with regard to the Functionality or component and / or a call or an execution of the corresponding functionality is designed and set up.

12.) Automation engineering system with a memory device, wherein the memory device comprises a self-description data module (380, 390) according to one of claims 1 to 8.