A knowledge graph-based intelligent configuration design method for complex equipment

Abstract

The application discloses a kind of complex equipment intelligent configuration design methods based on knowledge graph.The following steps are included: constructing product family configuration design knowledge graph;Product family configuration design knowledge graph is represented learning;The technical specification of product to be designed is extracted automatically;The integrity of each module requirement is checked;DBOM leaf node parts are recommended based on graph calculation;The module marked for decision is recommended for decision.The application establishes complex equipment configuration design knowledge graph and requirement item extraction model based on deep learning, realizes a kind of knowledge-driven intelligent configuration design scheme, can effectively assist designer to complete the configuration design of early stage, improves design efficiency.

Description

Technical Field

[0001] This invention relates to an intelligent configuration design method for complex equipment, specifically disclosing an intelligent configuration design method for complex equipment based on knowledge graphs. Background Technology

[0002] Complex equipment, such as high-speed trains, tunnel boring machines, and nuclear power equipment, consists of tens of thousands of parts arranged in intricate relationships. Configuration design, starting from requirements, is the process of combining candidate modules according to certain rules, standards, or constraints, and is an effective means of achieving rapid product design. Currently, configuration design methods for complex equipment mainly focus on recommended configurations based on requirement similarity, which requires reasonable setting of weights between requirement items and modules, making implementation difficult. No intelligent configuration methods based on product family configuration design knowledge graphs have been found.

[0003] For the design of complex equipment, designers have formed a large number of design examples based on their knowledge and experience. Based on knowledge graphs and deep learning models, these examples are used to learn the relationships between hidden part requirements and design feature attributes. First, deep learning models help designers automatically extract requirements. Then, the requirement values ​​are mapped to each module to form module requirements. Inputting the knowledge graph represents the learning model to calculate and match the configuration schemes of each part, which is of great value in improving the efficiency of complex equipment configuration design. Summary of the Invention

[0004] To achieve the above-mentioned objectives, the present invention provides the following technical solution: A knowledge graph-based intelligent configuration design method for complex equipment includes the following steps: Step S1: Construct a knowledge graph for product family configuration design; Step S2: Perform representation learning on the product family configuration design knowledge graph; Step S3: Automatically extract requirements from the technical specifications of the product to be designed; Step S4: Perform integrity verification on the requirements of each module; Step S5: Perform recommendation calculations for the leaf node parts of the DBOM based on the graph; Step S6: Make decision recommendations for modules marked as pending decisions; Specifically, step S5 includes S51-S54; Step S51 is: Query the DBOM first-level node to calculate the number of subsystems SN; Step S52 is: Define the set of modules to be decided to be tobetest[] = null; Step S53 is as follows: For each subsystem i, query its leaf node modules; for each module, input the requirements into the knowledge graph for embedding learning, and calculate the recommended module instance list. Step S54 is: i = i + 1, go to S53, until all subsystem recommendations are completed; Step S53 includes S531-S538: Step S531 is: Initialize module pointer j = 1; Step S532 is: Obtain all leaf nodes Model[] under subsystem i; Step S533 is: for each module Model[j], obtain the required value processed by S4 integrity verification; Step S534 is as follows: Input the demand value into the product family configuration design embedding learning model, calculate the theoretical attribute vector through reasoning, calculate the similarity between the theoretical attribute vector and the instance attribute vector corresponding to the meta-module, and output the recommended module instance list ExModelj [] with similarity exceeding the threshold, sorted in ascending order of deviation; Step S535 is: query the assembly rule set rules[] of the corresponding meta-module; Step S536 is: Determine whether rules[] is empty. If it is empty, it means that there is no assembly constraint with other parts. Take the first recommended instance in ExModelj[] and assign it a value to complete the recommendation of this module. If it is not empty, it means that there is an assembly constraint with other parts. Mark the module as a decision module to be recommended and add it to the decision module set tobetest[]. Step S537 is: j = j + 1, go to S532, until all modules have completed the recommended calculation; Step S6 includes steps S61-S66; Step S61 is: Query the set of modules marked as pending decisions, tobetest[]. Step S62 is: Define and initialize the conflict module set variable tobedecision[] = null; Step S63 is as follows: For each module in the tobetest[] set, take the first recommended instance in its corresponding recommended instance list ExModeil[], and bring the attribute value of the recommended instance into the assembly constraint rule to perform conflict detection; Step S64 is: Use the set operation tobetest[]-tobedecision[] to obtain a set of non-conflicting modules. For each module, take the first recommended instance of its corresponding tobetestEX[] to complete the recommendation of the module and delete the pending decision mark of the module. Step S65 is: For each module in tobedecision[], calculate its conflict complexity. Step S66 is: Construct a conflict structure tree with the module with the highest conflict complexity as the root node; Specifically, step S63 includes S631-S635: Step S631 is: Query the conflict rule set of the product family GBOM; Step S632 is: Initialize the rule pointer i = 1; Step S633 is: for each Rule[i], query the module corresponding to Rule[i] and calculate by substituting the instance attribute value; Step S634 is: determine whether there is a conflict with the rule, and if there is a conflict, add the corresponding module to tobedecision[]. Step S635 is: i = i + 1, point to the next rule, go to S633, until all rules have been checked; Step S65 includes S651-S655: Step S651 is: Calculate the length len of tobedecision[]. Step S652 is: Initialize module pointer i = 1; Step S653 is: for module Model[i], query the conflict rule set, obtain the conflict attribute set Attri[] in which it participates and the module set conflicttsij[] associated with each attribute; Step S654 is: Calculate the conflict complexity of Model[i]:

[0005] in: This indicates the length of the module set conflictsij[], i.e., the number of modules associated with the attribute Attri[j]; Attri.longth indicates the number of conflicting attributes involved in module Model[i]. Indicates the conflict complexity of module Model[i]; Step S655 is: i = i + 1, go to S653, until the complexity calculation of all modules of tobedecision[] is completed; S66 includes S661-S665: Step S661 is: Obtain the module Model[M] with the highest conflict complexity; Step S662 is as follows: with Model[M] as the root node, query the conflict association module in tobedecision[], add the node to the structure tree and establish conflict edges, and then use the branch node to query the conflict association module in tobedecision[] to recursively construct the conflict structure tree; Step S663 is: for each node, check from top to bottom by bringing the recommended instance attributes of the conflicting nodes in the conflict structure tree into the conflict rules to find the non-conflicting path solution Tree[]. Step S664 is as follows: If the conflict structure tree solution path = 1, each module is assigned a value according to the instance corresponding to each node of the path; if the conflict structure tree solution path > 1, the sum of deviations corresponding to each instance of the path node is calculated, and the module is assigned a value according to the instance corresponding to the path with the smallest sum of deviations. Step S665 is: Remove each module of the structure tree from tobedecision[]. Step S666 is: obtain the set of modules in tobedecision[] that did not participate in conflict detection. If it is not empty, go to S661 until tobedecision[] is empty.

[0006] Step S4 includes steps S41-S46; Step S41 is: Obtain the product family and product name of the product to be designed, and generate DBOM by instantiating and copying based on GBOM; Step S42 is: Query the DBOM to obtain the leaf node module set Models[]; Step S43 is: Initialize module pointer i = 1; Step S44 is as follows: For each module Model[i], extract the original requirement value and match it with the requirement items in the module requirement meta-model, perform unit verification and conversion on the value, and select the value range according to the rules; Step S45 is: to perform an integrity check on the requirement item values ​​in the requirement meta-model of each module; Step S46 is: i = i + 1, point to the next module, go to S44, until all modules in Models[] have been processed.

[0007] S44 includes S441-S443; Step S441 is: Obtain the original requirement value Rqij[] of module Model[n]; Step S442 is: Calculate the count of the required items in Rqij[]. Step S443 is: for each original demand value Rqij[Count], perform value verification and conversion; S443 includes S4431-S44310; Step S4431 is: Obtain the name of the required item Rqij[Count].Name; Step S4432 is: Obtain the dictionary item name RQDictij[] corresponding to module Model[n]; Step S4433 is: calculate the similarity between Rqij[count].Name and RQDictij[], and take the highest similarity RQDictij[k] that exceeds the threshold; Step S4434 is: Determine whether RQDictij[k] = NULL is true. If it is true, store Rqij[count] as a new requirement item in the candidate requirement item library and go to S44310. If it is not true, no processing is required. Step S4435 is: Obtain the unit of the required item value Rqij[count].Unit; Step S4436 is: Query the dictionary item unit RQDictij[k].Unit; Step S4437 is: Determine whether RQDictij[k].Unit = Rqij[count].Unit is true. If they are not equal, convert the unit of Rqij[count]. If they are equal, no processing is required. Step S4438 is: Determine whether the value of Rqij[count] is a value range type. The determination is based on whether the required value contains an upper limit value, a lower limit value, or an upper deviation or a lower deviation. If so, query the rules and take the upper limit value, the middle value, or the lower limit value according to the rules. Otherwise, do not process it. Step S4439 is: Assign the value to RQDictij[k]; Step S44310 is: count = count - 1, pointing to the previous demand item in the queue, then go to S4431, until the demand item values ​​of this module have been processed.

[0008] S45 includes S451-S454; Step S451 is: query the module requirement meta-model and calculate the number of items RK in RQDictij[]. Step S452 is: Obtain the value of the extraction and transformation requirement item RQDictij[RK].value; Step S453 is as follows: Determine whether RQDictij[RK].value=null is true. If true, calculate the mean of the instance values ​​of the module requirement items and assign the mean value. If false, further check whether RQDictij[RK].value is an outlier using the quartile method. If it is an outlier, assign the mean value. If it is not an outlier, no processing is required. Step S454 is: RK=RK-1, pointing to the next requirement item, go to S452, until all items of RQDictij[] have been processed.

[0009] Step S1 includes steps S11-S14; Step S11 is: Create a product requirement dictionary; create a triplet of <requirement dictionary item - belongs to - function category>, and the requirement dictionary item data is manually organized; Step S12 is as follows: Establish a dictionary of meta-module feature attributes; configure design feature attributes for each meta-module, construct a module attribute dictionary, and the triplet form is <design feature attribute item-description-meta-module>. The module feature attribute data is manually organized. Step S13 is: Establish a product family configuration design knowledge ontology based on meta-module associations. Step S14 is to organize the data corresponding to various meta-concepts, instance concepts, and relationships, and store the data in the native graph database Neo4j according to the ontology triple data structure to form a product family configuration design knowledge graph.

[0010] S13 specifically includes steps S131-S135; Step S131 is as follows: For the product family, select and configure meta-modules to construct the GBOM tree; establish triple <meta-module-assembly-meta-module> to describe the GBOM, and establish triple <meta-module-conflict rule-meta-module> to describe the conflict rules between modules; In step S131, a knowledge graph ontology modeling tool is used to establish the concept of meta-modules, and self-associations of assembly and self-associations of conflict rules are established on the concept of meta-modules in the form of directed connection lines. Step S132 is as follows: Establish the mapping between GBOM tree nodes and the dictionary of requirements and the instances of requirements values; establish the triple <Module Requirements Meta-Model - Belongs to - Meta-Module> to describe the relationship between the meta-module and the requirement feature vector; establish <Requirement Dictionary Item - Composition - Module Requirements Meta-Model> to describe the features of the module requirements meta-model; establish <Requirement Dictionary Item - Belongs to - Functional Classification> to describe the classification features of the requirements. In step S132, based on the ontology modeling tool, on the basis of S131, a module requirement meta-model, a requirement item dictionary, and a functional classification are added. The belonging relationship between the module requirement meta-model and the meta-module concept, the composition relationship between the requirement dictionary item and the module requirement meta-model concept, and the belonging relationship between the requirement dictionary item and the functional classification concept are added in the form of directed connection lines. Step S133 is: establishing a mapping between GBOM tree nodes and parameter feature value instances; the ontology triplet is in the form of <design feature attribute item-description-meta-module>; In step S133, based on the ontology modeling tool, the concept of design feature attribute items is added on the basis of S132, and the descriptive relationship between the design feature attribute items and the meta-module concept is added in the form of directed connection lines. Step S134 is as follows: Establish the mapping between product module instances and meta-modules; establish the ontology triple <module instance-instance-meta-module> to describe the instantiation relationship between module instances and meta-modules; establish <module instance-assembly-module instance> to describe the product DBOM; establish <attribute value-description-module instance> to map module design features; and establish <attribute value-instance-design feature attribute> to describe the instantiation relationship of attribute features. The construction method used in step S134 is as follows: Based on the ontology modeling tool, on the basis of S133, add module instances, attribute values ​​and design feature attribute items, and add instance relationships between module instances and meta-module concepts, assembly self-relationships of module instance concepts, descriptive relationships between attribute values ​​and module instance concepts, and instance relationships between attribute values ​​and design feature attribute item concepts in the form of directed connection lines. Step S135 is as follows: Establish the mapping between product module requirement instances, module instances, and meta-modules; establish ontology triples <requirement item value - extracted from - product requirement> to describe the structured mapping of requirements; establish <requirement item value - mapping - requirement dictionary item> to describe the value checking and instance relationship between requirement item values ​​and requirement dictionary items; establish <requirement item value - composition - module requirement instance> to realize the mapping from a single requirement item to the module requirement feature space; establish <module requirement instance - instance - module requirement meta-model> to realize the instantiation relationship description; and establish <module requirement instance - mapping - module instance> to describe the mapping from the requirement space to the module design solution space. The construction method used in step S135 is as follows: Based on the ontology modeling tool, on the basis of S134, add requirement item values, product requirements, and module requirement instances, and add extraction relationships between requirement item values ​​and product requirement concepts, mapping relationships between requirement item values ​​and requirement dictionary item concepts, composition relationships between requirement item values ​​and module requirement instance concepts, and mapping relationships between module requirement instances and module instances in the form of directed connection lines.

[0011] Step S2 includes steps S21-S22; Step S21 is: convert the module configuration design process into a knowledge graph recommendation process; the configuration design process of the knowledge graph recommendation module is as follows: given the head entity module requirement instance and relation mapping, calculate the tail entity theoretical module attribute vector, and then calculate the similarity between the theoretical module attribute vector and the instance module attribute feature vector corresponding to the original module to recommend similar instances; Step S22 is: learning the triple representation of module requirement instance-mapping-module instance; based on the n:1 mapping relationship between module requirement instance and module instance, the TransR model is used to perform triple embedding learning of module requirement instance-mapping-module instance to obtain the product family configuration design knowledge embedding learning model.

[0012] Step S3 includes steps S31-S34; Step S31 is: organize the technical tender requirements corpus, and annotate the corpus based on the meta-modules and requirement item dictionary in the ontology; Step S32 is: build a runtime environment for the Named Entity Recognition Deep Learning Model BERT-BILSTM-CRF based on the PyTorch platform, and train the model using the labeled required dataset; Step S33 is: Read the technical tender document uploaded by the user; Step S34 is as follows: Decompose the tender document into paragraphs from top to bottom and obtain the number of paragraphs; for each paragraph, extract the requirements.

[0013] S34 includes steps S341-S347; Step S341 is: Initialize paragraph marker i=1; Step S342 is: input the paragraph text into the BERT-BILSTM-CRF demand extraction model; Step S343 is: Obtain the named entity set and the requirement-requirement-value domain relationship set; Step S344 is: Query the knowledge graph to obtain the set of meta-module names; Step S345 is: calculate the similarity between the named entity set and the meta-module name set, and return the meta-module name Modepi with the highest matching degree; Step S346 is: Determine whether Modepi=null is true. If it is true, it means that the meta-module corresponding to the requirement item is the same as the previous paragraph. Continue to write the requirement item-requirement-value domain relationship set into the meta-module node corresponding to the previous paragraph. If it is not true, write the requirement item-requirement-value domain relationship set into the Modepi meta-module node. Step S347 is: i = i + 1, go to S342, until all paragraphs are processed.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) The inventors discovered in practice that complex equipment products have obvious personalized needs, and the needs of each piece of equipment are not exactly the same. Existing configuration examples contain the designer's knowledge, and effective mining and utilization can assist in intelligent configuration. This invention establishes a knowledge graph for the configuration design of complex equipment product families, and transforms the configuration design process of modules into: given the head entity "module requirement instance" and the relation "mapping", calculate the tail entity "theoretical module attribute vector", and then calculate the similarity between the "theoretical module attribute vector" and the instance module attribute feature vector corresponding to the original module, and recommend similar module instances.

[0015] (2) In practice, the inventors discovered that the design process of complex equipment configuration involves many types of knowledge, and clarifying the relationship between these knowledge is the key to intelligent configuration recommendation. At present, no knowledge graph for intelligent configuration design of complex equipment has been found. This invention proposes an ontology model for intelligent configuration design of complex equipment. It constructs product family GBOM and configuration design meta-knowledge through the association mapping between meta-modules, design feature attributes, and requirement item dictionaries. It constructs product instance design knowledge through the association mapping between product module design instances, design attribute values, and design requirements. It establishes a knowledge graph describing the design configuration through the association mapping between instance knowledge and meta-knowledge.

[0016] (3) The inventors have found in practice that most of the requirements of complex equipment suppliers are currently in the form of unstructured text (such as technical tender documents). The description of technical indicators is in the form of natural language description and lacks standardization. At present, most of them are manually extracted by designers to match the requirement values ​​with the modules to be designed or reused experience values. The present invention designs a deep learning model for automatic extraction of requirement items based on product family meta-modules and requirement item dictionaries. First, the document is divided into paragraphs from top to bottom, and the paragraph titles are extracted and matched with the meta-module names. Then, for each module, the model is called to extract the requirement item values ​​of each module of the product to be designed.

[0017] (4) In practice, the inventors found that the requirement item values ​​extracted from the technical tender documents have problems such as non-standard naming of requirement items, inconsistent units, and missing values ​​for some requirement items, making them difficult to use directly for solving. This invention designs a module requirement item integrity verification algorithm, which matches the original requirement values ​​of the module extracted from the technical tender documents with the requirement items in the module requirement meta-model, performs unit verification and conversion on the values, selects values ​​for the value range according to rules, queries all requirement instances of the module for the requirement item value and calculates the mean, and assigns the mean value to requirement items with empty requirement item values ​​or those detected as outliers by the quartile method.

[0018] (5) The inventors discovered in practice that there are assembly constraints in the assembly process of each module of complex equipment. Therefore, learning only from the representation of the module requirements themselves and taking the optimal recommendation for each module may cause assembly conflicts. The present invention designs to embed the module requirements that have passed the requirement item integrity verification into the product family configuration design into the learning model, and calculates the recommended module instance list (instance encoding and deviation) with the similarity of the output instance vectors exceeding the threshold through reasoning. Then, based on the assembly rule detection, the module without assembly constraints is assigned the instance with the highest similarity, and the module with assembly constraints is assigned a conflict decision solution.

[0019] (6) The inventors discovered in practice that modules with assembly constraints have complex multi-level relationships, which increases the complexity of the solution process. This invention designs an algorithm that constructs an assembly conflict structure tree based on the module assembly complexity, solves non-conflict paths according to the conflict structure tree and the recommended instance set of modules, calculates the sum of deviations of each module instance in the solution path, and assigns module recommendation values ​​to the instance corresponding to the path with the smallest sum of deviations, so that the output recommended configuration satisfies the assembly constraints. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the intelligent configuration process for products based on knowledge graphs. Figure 2 A schematic diagram of a knowledge graph ontology model for configuring product families; Figure 3 A schematic diagram of a deep learning-based algorithm for automatically extracting product requirements. Figure 4 A schematic diagram of the module requirement integrity verification algorithm; Figure 5 A schematic diagram of the decision recommendation algorithm for the assembly constraint module. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0022] Therefore, the following detailed description of embodiments of the present invention is not intended to limit the scope of the claimed invention, but merely illustrates some embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0023] It should be noted that, unless otherwise specified, the embodiments and features and technical solutions in the present invention can be combined with each other.

[0024] A knowledge graph-based intelligent configuration design method for complex equipment includes the following steps: Step S1: Construct a knowledge graph for product family configuration design; Step S2: Perform representation learning on the product family configuration design knowledge graph; Step S3: Automatically extract requirements from the technical specifications of the product to be designed; Step S4: Perform integrity verification on the requirements of each module; Step S5: Perform recommendation calculations for the leaf node parts of the DBOM based on the graph; Step S6: Make decision recommendations for modules marked as pending decisions.

[0025] Preferably, step S1 includes steps S11-S14.

[0026] Preferably, S11 involves: establishing a product requirement dictionary. Specifically, this involves creating a triplet of <requirement dictionary item - belongs to - functional category>, with the requirement dictionary item data being manually compiled.

[0027] Preferably, S12 involves: establishing a dictionary of meta-module feature attributes. Specifically, design feature attributes are configured for each meta-module, and a module attribute dictionary is constructed. The triplet format is <design feature attribute item-description-meta-module>, and the module feature attribute data is manually compiled.

[0028] Preferably, S13: Establish a product family configuration design knowledge ontology based on meta-module association, specifically including steps S131-S135.

[0029] Preferably, S131 is as follows: For the product family, select meta-modules to construct the GBOM tree. Establish triples <meta-module-assembly-meta-module> to describe the GBOM, and establish triples <meta-module-conflict rule-meta-module> to describe the conflict rules between modules.

[0030] Preferred construction method: Use knowledge graph ontology modeling tools such as Protégé to establish meta-module concepts, and establish assembly self-connections and conflict rule self-connections on the meta-module concepts in the form of directed connection lines.

[0031] Preferably, S132 involves: establishing a mapping between GBOM tree nodes and the requirement item dictionary and requirement item value instances; establishing a triple <Module Requirement Meta-Model - Belongs to - Meta-Module> to describe the relationship between meta-modules and requirement feature vectors; establishing <Requirement Dictionary Item - Composition - Module Requirement Meta-Model> to describe the features of the module requirement meta-model; and establishing <Requirement Dictionary Item - Belongs to - Functional Classification> to describe the classification features of requirement items.

[0032] Preferred construction method: Based on ontology modeling tools, add three concepts to S131: module requirement meta-model, requirement item dictionary, and functional category. Add the belonging relationship between the module requirement meta-model and the meta-module concept, the composition relationship between the requirement dictionary item and the module requirement meta-model concept, and the belonging relationship between the requirement dictionary item and the functional category concept in the form of directed connection lines.

[0033] Preferably, S133 involves: establishing a mapping between GBOM tree nodes and parameter feature value instances. The ontology triplet is in the form of <design feature attribute item-description-meta-module>.

[0034] Preferred construction method: Based on ontology modeling tools, add the concept of design feature attribute items on the basis of S132, and add the descriptive relationship between the design feature attribute items and the meta-module concept in the form of directed connection lines.

[0035] Preferably, S134 is: establishing a mapping between product module instances and meta-modules. This involves establishing an ontology triple <module instance-instance-meta-module> describing the instantiation relationship between module instances and meta-modules, establishing <module instance-assembly-module instance> describing the product DBOM, establishing <attribute value-description-module instance> mapping module design features, and establishing <attribute value-instance-design feature attribute> describing the instantiation relationship of attribute features.

[0036] Preferred construction method: Based on ontology modeling tools, add three concepts: module instance, attribute value, and design feature attribute item on the basis of S133. Add instance relationships between module instances and meta-module concepts, assembly self-relationships of module instance concepts, descriptive relationships between attribute values ​​and module instance concepts, and instance relationships between attribute values ​​and design feature attribute item concepts in the form of directed connection lines.

[0037] Preferably, S135 involves: establishing a mapping between product module requirement instances, module instances, and meta-modules. This includes establishing an ontology triple <Requirement Item Value - Extracted from - Product Requirement> to describe the structured mapping of requirements; establishing <Requirement Item Value - Mapping - Requirement Dictionary Item> to describe the value checking and instance relationship between requirement item values ​​and requirement dictionary items; establishing <Requirement Item Value - Composition - Module Requirement Instance> to realize the mapping from a single requirement item to the module requirement feature space; establishing <Module Requirement Instance - Instance - Module Requirement Meta-Model> to realize the instantiation relationship description; and establishing <Module Requirement Instance - Mapping - Module Instance> to describe the mapping from the requirement space to the module design solution space.

[0038] Preferred construction method: Based on ontology modeling tools, add three concepts: requirement item value, product requirement, and module requirement instance on the basis of S134. Add extraction relationships between requirement item value and product requirement concepts, mapping relationships between requirement item value and requirement dictionary item concepts, composition relationships between requirement item value and module requirement instance concepts, and mapping relationships between module requirement instances and module instances in the form of directed connection lines.

[0039] Preferably, S14 is: organizing the data corresponding to the above-mentioned meta-concepts, instance concepts and relationships, storing the data into the native graph database Neo4j according to the ontology triple data structure, and forming a product family configuration design knowledge graph.

[0040] Given the diverse knowledge types involved in the design process of complex equipment configurations, clarifying the relationships between these knowledge points is crucial for intelligent configuration recommendation. Currently, no knowledge graph for intelligent configuration design of complex equipment has been discovered. This invention proposes an ontology model for intelligent configuration design of complex equipment. It constructs a product family GBOM and configuration design meta-knowledge through the association mapping between meta-modules, design feature attributes, and requirement item dictionaries. It constructs product instance design knowledge through the association mapping between product module design instances, design attribute values, and design requirements. Finally, it establishes a knowledge graph describing the design configuration through the association mapping between instance knowledge and meta-knowledge.

[0041] Preferably, step S2 includes steps S21-S22.

[0042] Preferably, S21 involves converting the module configuration design process into a knowledge graph recommendation process. The module configuration design process based on knowledge graph recommendation is as follows: given the head entity "module requirement instance" and the relation "mapping", calculate the tail entity "theoretical module attribute vector", then calculate the similarity between the "theoretical module attribute vector" and the instance module attribute feature vector corresponding to the original module, and recommend similar instances.

[0043] Preferably, S22 is the learning of the "module requirement instance-mapping-module instance" triple representation. Based on the n:1 mapping relationship between module requirement instances and module instances, the TransR model is used to perform "module requirement instance-mapping-module instance" triple embedding learning to obtain the product family configuration design knowledge embedding learning model.

[0044] Given the significant personalized requirements of complex equipment products, with each piece of equipment having unique needs, existing configuration examples contain the designer's knowledge. This invention effectively mines and utilizes this knowledge to assist in intelligent configuration. It establishes a knowledge graph for the configuration design of complex equipment product families, transforming the module configuration design process into: knowing the head entity "module requirement instance" and the relation "mapping," calculating the tail entity "theoretical module attribute vector," and then calculating the similarity between the "theoretical module attribute vector" and the corresponding instance module attribute feature vector, recommending similar module instances.

[0045] Preferably, step S3 includes steps S31-S34.

[0046] Preferably, S31 is: organizing the technical tender requirements corpus and annotating the corpus based on the meta-modules and requirement item dictionary in the ontology.

[0047] Preferably, S32 is: building a runtime environment for the named entity recognition deep learning model BERT-BILSTM-CRF based on the PyTorch platform, and training the model using the labeled required dataset.

[0048] Preferably, S33 is: reading the technical tender document uploaded by the user.

[0049] Preferably, step S34 involves: breaking down the tender document into paragraphs from top to bottom and obtaining the number of paragraphs. For each paragraph, the requirements are extracted, specifically including steps S341-S347.

[0050] Preferably, S341 is: initialize paragraph marker i=1.

[0051] Preferably, S342 is: inputting the paragraph text into the BERT-BILSTM-CRF demand extraction model.

[0052] Preferably, S343 is: obtaining the named entity set and the requirement-requirement-value domain relationship set.

[0053] Preferably, S344 is: query the knowledge graph to obtain the set of meta-module names.

[0054] Preferably, S345 is: calculate the similarity between the named entity set and the meta-module name set, and return the meta-module name Modepi with the highest matching degree.

[0055] Preferably, S346 is: determine whether Modepi=null is true. If it is true, it means that the meta-module corresponding to the requirement item is the same as the previous paragraph. Continue to write the requirement item-requirement-value domain relationship set into the meta-module node corresponding to the previous paragraph. If it is not true, write the requirement item-requirement-value domain relationship set into the Modepi meta-module node.

[0056] Preferably, S347 is: i = i + 1, go to S342, until all paragraphs are processed.

[0057] Given that most supplier requirements for complex equipment currently exist in unstructured text (such as technical tender documents), and their descriptions of technical indicators are in natural language and lack standardization, designers often manually extract the requirement values ​​corresponding to the modules to be designed or reuse empirical values. This invention designs a deep learning model for automatic requirement item extraction based on product family meta-modules and a requirement item dictionary. First, the document is divided into paragraphs from top to bottom, and paragraph titles are matched with meta-module names. Then, for each module, the model is invoked to extract requirement item values ​​from the paragraph content, calculating the requirement item values ​​for each module of the product to be designed.

[0058] Preferably, step S4 includes steps S41-S46.

[0059] Preferably, S41 is: obtain the product family and product name of the product to be designed, and generate DBOM by instantiating and copying based on GBOM.

[0060] Preferably, S42 is: query the DBOM to obtain the leaf node module set Models[].

[0061] Preferably, S43 is: initialize module pointer i=1.

[0062] Preferably, S44 is as follows: for each module Model[i], extract the original requirement value and match it with the requirement items in the module requirement meta-model, perform unit verification and conversion on the value, and select the value range according to the rules. S44 specifically includes S441-S443.

[0063] Preferably, S441: Obtain the original requirement value Rqij[] of module Model[i].

[0064] Preferably, S442: Calculate the number of required items count for Rqij[].

[0065] Preferably, S443: For each original demand value Rqij[Count], perform value verification and transformation. S443 specifically includes S4431-S44310.

[0066] Preferably, S4431 is: obtain the required item name Rqij[Count].Name.

[0067] Preferably, S4432 is: obtain the name of the meta-module requirement dictionary item RQDictij[] corresponding to module Model[i].

[0068] Preferably, S4433 is: calculate the similarity between Rqij[count].Name and RQDictij[], and take the highest similarity RQDictij[k] that exceeds the threshold.

[0069] Preferably, S4434 is: determine whether RQDictij[k]=NULL is true. If it is true, store Rqij[count] as a new requirement item in the candidate requirement item library and go to S44310. If it is not true, no processing is required.

[0070] Preferably, S4435: Obtain the unit of the required item value Rqij[count].Unit.

[0071] Preferably, S4436: Query dictionary item unit RQDictij[k].Unit.

[0072] Preferably, S4437: Determine whether RQDictij[k].Unit = Rqij[count].Unit is true. If they are not equal, convert the unit of Rqij[count]. If they are equal, no processing is required.

[0073] Preferably, S4438: Determine whether the value of Rqij[count] is a value range type. The determination is based on whether the required value includes an upper limit value, a lower limit value, or an upper deviation or a lower deviation. If so, query the rule and take the upper limit value, median value, or lower limit value according to the rule. Otherwise, do not process it.

[0074] Preferably, S4439: Assign the value to RQDictij[k].

[0075] Preferably, S44310: count=count-1, pointing to the previous demand item in the queue, then proceed to S4431 until the demand item value of this module has been processed.

[0076] Preferably, S45: Perform an integrity check on the requirement item values ​​in the requirement meta-model of each module, specifically including S451-S454.

[0077] Preferably, S451: query module requirement meta-model, calculate the number of items RK of RQDictij[].

[0078] Preferably, S452: Obtain the value of the extraction and transformation requirement item RQDictij[RK].value.

[0079] Preferably, S453: Determine whether RQDictij[RK].value=null is true. If true, calculate the mean of the instance values ​​of the query module requirement items and assign the mean value. If false, further check whether RQDictij[RK].value is an outlier using the quartile method. If it is an outlier, assign the mean value. If it is not an outlier, no processing is required.

[0080] Preferably, S454: RK=RK-1, pointing to the next requirement item, go to S452, until all items of RQDictij[] have been processed.

[0081] Preferably, S46: i=i+1, point to the next module, go to S44, until all modules in Models[] have been processed.

[0082] Given that the requirement item values ​​extracted from technical tenders suffer from issues such as non-standard naming, inconsistent units, and missing values ​​for some requirements, they are difficult to use directly for solving problems. This invention designs a module requirement item integrity verification algorithm. This algorithm matches the original requirement values ​​of the module extracted from the technical tender with the requirement items in the module requirement meta-model. It performs unit verification and conversion on the values, assigns values ​​to the value range according to rules, queries all requirement instances of the requirement item for the module, calculates the mean, and assigns the mean value to requirement items with empty values ​​or those detected as outliers using the quartile method.

[0083] Preferably, step S5 specifically includes S51-S54.

[0084] Preferably, S51: Query the number of subsystems SN of the DBOM first-level node calculation.

[0085] Preferably, S52: Define the set of modules to be decided to be to betest[] = null.

[0086] Preferably, S53: For each subsystem i, query its leaf node module; for each module, input the requirements into the knowledge graph for embedding learning, and calculate the recommended module instance list. S53 specifically includes S531-S538: Preferably, S531: Initialize module pointer j=1.

[0087] Preferably, S532: Obtain all leaf nodes Model[] under subsystem i.

[0088] Preferably, S533: For each module Model[j], obtain the required value processed by S4 integrity verification.

[0089] Preferably, S534: Input the demand value into the product family configuration design embedded learning model, calculate the theoretical attribute vector through reasoning, calculate the similarity between the theoretical attribute vector and the instance attribute vector corresponding to the meta-module, and output the recommended module instance list ExModelj [] (instance code and deviation) with similarity exceeding the threshold, sorted by deviation from smallest to largest.

[0090] Preferably, S535: Query the assembly rule set rules[] of the corresponding meta-module of this module.

[0091] Preferably, S536: Determine whether rules[] is empty. If it is empty, it means that there is no assembly constraint with other parts. Take the first recommended instance in ExModelj[] and assign it to complete the recommendation of this module. If it is not empty, it means that there is an assembly constraint with other parts. Mark the module as a decision module to be recommended and add it to the decision module set tobetest[].

[0092] Preferably, in S537: j=j+1, go to S532, until all modules have completed the recommended calculations.

[0093] Preferably, S54: i=i+1, go to S53, until all subsystems have completed the recommended calculation.

[0094] Given the assembly constraints present in the assembly process of complex equipment modules, learning solely from the module requirements themselves and selecting the optimal recommendation for each module may lead to assembly conflicts. This invention designs a model that embeds module requirements, after requirement integrity verification, into the product family configuration design. Through inference, it calculates a list of recommended module instances (instance encoding and deviation) whose instance vector similarity exceeds a threshold. Then, based on assembly rule detection, it assigns the highest similarity instance to modules without assembly constraints, and performs conflict decision-making and assignment for modules with assembly constraints.

[0095] Preferably, step S6 includes steps S61-S66.

[0096] Preferably, S61: The query is marked as the set of modules to be decided, tobetest[].

[0097] Preferably, S62: Define and initialize the conflict module set variable tobedecision[] = null.

[0098] Preferably, S63: For each module in the tobetest[] set, take the first recommended instance in its corresponding recommended instance list ExModeil[], and input the attribute value of this recommended instance into the assembly constraint rules for conflict detection. S63 specifically includes S631-S635: Preferably, S631: Query the conflict rule set Rules[] of the product family GBOM.

[0099] Preferably, S632: Initialize the rule pointer i=1.

[0100] Preferably, S633: For each Rule[i], query the module corresponding to Rule[k] and calculate by substituting the instance attribute value.

[0101] Preferably, S634: Determine whether there is a conflict with the rule, and if there is a conflict, add the corresponding module to tobedecision[].

[0102] Preferably, in S635: i = i + 1, point to the next rule, go to S633, until all rules have been checked.

[0103] Preferably, S64: Use the set operation tobetest[]-tobedecision[] to obtain a set of non-conflicting modules. For each module, take the first recommended instance of its corresponding tobetestEX[] to complete the recommendation of the module and delete the pending decision mark of the module.

[0104] Preferably, S65: For each module in tobedecision[], calculate its conflict complexity, specifically including S651-S655: Step S651 is: Calculate the length len of tobedecision[]. Step S652 is: Initialize module pointer i = 1; Step S653 is: for module Model[i], query the conflict rule set, obtain the conflict attribute set Attri[] in which it participates and the module set conflicttsij[] associated with each attribute; Step S654 is: Calculate the conflict complexity of Model[m]:

[0105] in: Attri.longth represents the length of the module set conflictsij[]; Attri.longth represents the number of conflicting attributes involved in module Model[i]. Indicates the conflict complexity of module Model[i]; Step S655 is: i = i + 1, go to S653, until the complexity calculation of all modules of tobedecision[] is completed; Preferably, S66: Using the module with the highest conflict complexity as the root node, construct a conflict structure tree, specifically including S661-S665: Preferably, S661: Obtain the module Model[M] with the highest conflict complexity.

[0106] Preferably, S662: Using Model[M] as the root node, query the conflict association module in tobedecision[], add it to the structure tree node and establish conflict edges, then use the branch node to query the conflict association module in tobedecision[], and recursively construct the conflict structure tree.

[0107] Preferably, S663: For each node, the recommended instance attributes of the conflicting nodes in the conflict structure tree are brought into the conflict rules for a top-down check to find a non-conflicting path solution Tree[].

[0108] Preferably, S664: If the conflict structure tree solution path = 1, each module is assigned a value according to the instance corresponding to each node of the path; if the conflict structure tree solution path > 1, the sum of deviations corresponding to each instance of the path node is calculated, and the module is assigned a value according to the instance corresponding to the path with the smallest sum of deviations.

[0109] Preferably, S665: Remove each module of the structure tree from tobedecision[].

[0110] Preferably, S666: Obtain the set of modules in tobedecision[] that did not participate in conflict detection. If it is not empty, go to S661 until tobedecision[] is empty.

[0111] Given the complex multi-level relationships between modules with assembly constraints, the solution process becomes complicated. This invention designs an algorithm that constructs an assembly conflict structure tree based on module assembly complexity, solves for non-conflict paths using the conflict structure tree and the recommended instance set of modules, calculates the sum of deviations of each module instance along the solution path, and assigns module recommendations to the instance corresponding to the path with the smallest sum of deviations, ensuring that the output recommended configuration satisfies the assembly constraints.

[0112] The above embodiments are only used to illustrate the present invention and are not intended to limit the technical solutions described herein. Although the present invention has been described in detail with reference to the above embodiments, the present invention is not limited to the specific embodiments described above. Therefore, any modifications or equivalent substitutions to the present invention, as well as all technical solutions and improvements that do not depart from the spirit and scope of the invention, are covered within the scope of the claims of the present invention.

Claims

1. A method for intelligent configuration design of complex equipment based on knowledge graphs, characterized in that: Includes the following steps: Step S1: Construct a knowledge graph for product family configuration design; Step S2: Perform representation learning on the product family configuration design knowledge graph; Step S3: Automatically extract requirements from the technical specifications of the product to be designed; Step S4: Perform integrity verification on the requirements of each module; Step S5: Perform recommendation calculations for the leaf node parts of the DBOM based on the graph; Step S6: Make decision recommendations for modules marked as pending decisions; Specifically, step S5 includes S51-S54; Step S51 is: Query the DBOM first-level node to calculate the number of subsystems SN; Step S52 is: Define the set of modules to be decided to be tobetest[] = null; Step S53 is as follows: For each subsystem i, query its leaf node modules; for each module, input the requirements into the knowledge graph for embedding learning, and calculate the recommended module instance list. Step S54 is: i = i + 1, go to S53, until all subsystem recommendations are completed; Step S53 includes S531-S538: Step S531 is: Initialize module pointer j = 1; Step S532 is: Obtain all leaf nodes Model[] under subsystem i; Step S533 is: for each module Model[j], obtain the required value processed by S4 integrity verification; Step S534 is as follows: Input the demand value into the product family configuration design embedding learning model, calculate the theoretical attribute vector through reasoning, calculate the similarity between the theoretical attribute vector and the instance attribute vector corresponding to the meta module, and output the recommended module instance list ExModelj [] with similarity exceeding the threshold, sorted in ascending order of deviation; Step S535 is: query the assembly rule set rules[] of the corresponding meta-module; Step S536 is: Determine whether rules[] is empty. If it is empty, it means that there is no assembly constraint with other parts. Take the first recommended instance in ExModelj[] and assign it a value to complete the recommendation of this module. If it is not empty, it means that there is an assembly constraint with other parts. Mark the module as a decision module to be recommended and add it to the decision module set tobetest[]. Step S537 is: j = j + 1, go to S532, until all modules have completed the recommended calculation; Step S6 includes steps S61-S66; Step S61 is: Query the set of modules marked as pending decisions, tobetest[]. Step S62 is: Define and initialize the conflict module set variable tobedecision[] = null; Step S63 is as follows: For each module in the tobetest[] set, take the first recommended instance in its corresponding recommended instance list ExModeil[], and bring the attribute value of the recommended instance into the assembly constraint rule to perform conflict detection; Step S64 is: Use the set operation tobetest[]-tobedecision[] to obtain a set of non-conflicting modules. For each module, take the first recommended instance of its corresponding ExModeil[] to complete the recommendation of the module and delete the pending decision mark of the module. Step S65 is: For each module in tobedecision[], calculate its conflict complexity. Step S66 is: Construct a conflict structure tree with the module with the highest conflict complexity as the root node; Specifically, step S63 includes S631-S635: Step S631 is: Query the conflict rule set of the product family GBOM; Step S632 is: Initialize the rule pointer i = 1; Step S633 is: for each Rule[i], query the module corresponding to Rule[i] and calculate by substituting the instance attribute value; Step S634 is: determine whether there is a conflict with the rule, and if there is a conflict, add the corresponding module to tobedecision[]. Step S635 is: i = i + 1, point to the next rule, go to S633, until all rules have been checked; Step S65 includes S651-S655: Step S651 is: Calculate the length len of tobedecision[]. Step S652 is: Initialize module pointer i = 1; Step S653 is: for module Model[i], query the conflict rule set, obtain the conflict attribute set Attri[] in which it participates and the module set conflicttsij[] associated with each attribute; Step S654 is: Calculate the conflict complexity of Model[i]: ， in: This indicates the length of the module set conflictsij[], i.e., the number of modules associated with the attribute Attri[j]; Attri.longth indicates the number of conflicting attributes involved in module Model[i]. Indicates the conflict complexity of module Model[i]; Step S655 is: i = i + 1, go to S653, until the complexity calculation of all modules of tobedecision[] is completed; S66 includes S661-S665: Step S661 is: Obtain the module Model[M] with the highest conflict complexity; Step S662 is as follows: with Model[M] as the root node, query the conflict association module in tobedecision[], add the node to the structure tree and establish conflict edges, and then use the branch node to query the conflict association module in tobedecision[] to recursively construct the conflict structure tree; Step S663 is: for each node, check from top to bottom by bringing the recommended instance attributes of the conflicting nodes in the conflict structure tree into the conflict rules to find the non-conflicting path solution Tree[]. Step S664 is as follows: If the conflict structure tree solution path = 1, each module is assigned a value according to the instance corresponding to each node of the path; if the conflict structure tree solution path > 1, the sum of deviations corresponding to each instance of the path node is calculated, and the module is assigned a value according to the instance corresponding to the path with the smallest sum of deviations. Step S665 is: Remove each module of the structure tree from tobedecision[]. Step S666 is: obtain the set of modules in tobedecision[] that did not participate in conflict detection. If it is not empty, go to S661 until tobedecision[] is empty.

2. The intelligent configuration design method for complex equipment based on knowledge graphs as described in claim 1, characterized in that: Step S4 includes steps S41-S46; Step S41 is: Obtain the product family and product name of the product to be designed, and generate DBOM by instantiating and copying based on GBOM; Step S42 is: Query the DBOM to obtain the leaf node module set Models[]; Step S43 is: Initialize module pointer i = 1; Step S44 is as follows: For each module Model[i], extract the original requirement value and match it with the requirement items in the module requirement meta-model, perform unit verification and conversion on the value, and select the value range according to the rules; Step S45 is: to perform an integrity check on the requirement item values ​​in the requirement meta-model of each module; Step S46 is: i = i + 1, point to the next module, go to S44, until all modules in Models[] have been processed.

3. The intelligent configuration design method for complex equipment based on knowledge graphs as described in claim 2, characterized in that: S44 includes S441-S443; Step S441 is: Obtain the original requirement value Rqij[] of module Model[n]; Step S442 is: Calculate the count of the required items in Rqij[]. Step S443 is: for each original demand value Rqij[Count], perform value verification and conversion; S443 includes S4431-S44310; Step S4431 is: Obtain the name of the required item Rqij[Count].Name; Step S4432 is: Obtain the dictionary item name RQDictij[] corresponding to module Model[n]; Step S4433 is: calculate the similarity between Rqij[count].Name and RQDictij[], and take the highest similarity RQDictij[k] that exceeds the threshold; Step S4434 is: Determine whether RQDictij[k] = NULL is true. If it is true, store Rqij[count] as a new requirement item in the candidate requirement item library and go to S44310. If it is not true, no processing is required. Step S4435 is: Obtain the unit of the required item value Rqij[count].Unit; Step S4436 is: Query the dictionary item unit RQDictij[k].Unit; Step S4437 is: Determine whether RQDictij[k].Unit = Rqij[count].Unit is true. If they are not equal, convert the unit of Rqij[count]. If they are equal, no processing is required. Step S4438 is: Determine whether the value of Rqij[count] is a value range type. The determination is based on whether the required value contains an upper limit value, a lower limit value, or an upper deviation or a lower deviation. If so, query the rules and take the upper limit value, the middle value, or the lower limit value according to the rules. Otherwise, do not process it. Step S4439 is: Assign the value to RQDictij[k]; Step S44310 is: count = count - 1, pointing to the previous demand item in the queue, then go to S4431, until the demand item values ​​of this module have been processed.

4. The intelligent configuration design method for complex equipment based on knowledge graphs as described in claim 3, characterized in that: S45 includes S451-S454; Step S451 is: query the module requirement meta-model and calculate the number of items RK in RQDictij[]. Step S452 is: Obtain the value of the extraction and transformation requirement item RQDictij[RK].value; Step S453 is as follows: Determine whether RQDictij[RK].value=null is true. If true, calculate the mean of the instance values ​​of the module requirement items and assign the mean value. If false, further check whether RQDictij[RK].value is an outlier using the quartile method. If it is an outlier, assign the mean value. If it is not an outlier, no processing is required. Step S454 is: RK=RK-1, pointing to the next requirement item, go to S452, until all items of RQDictij[] have been processed.

5. The intelligent configuration design method for complex equipment based on knowledge graphs as described in claim 4, characterized in that: Step S1 includes steps S11-S14; Step S11 is: Create a product requirement dictionary; create a triplet of <requirement dictionary item - belongs to - function category>, and the requirement dictionary item data is manually organized; Step S12 is: Establish a dictionary of meta-module feature attributes; Configure design feature attributes for each meta-module and construct a module attribute dictionary. The triplet format is <design feature attribute item-description-meta-module>. The module feature attribute data is manually compiled. Step S13 is: Establish a product family configuration design knowledge ontology based on meta-module associations. Step S14 is to organize the data corresponding to various meta-concepts, instance concepts, and relationships, and store the data in the native graph database Neo4j according to the ontology triple data structure to form a product family configuration design knowledge graph.

6. The intelligent configuration design method for complex equipment based on knowledge graphs as described in claim 5, characterized in that: S13 specifically includes steps S131-S135; Step S131 is as follows: For the product family, select and configure meta-modules to construct the GBOM tree; establish triple <meta-module-assembly-meta-module> to describe the GBOM, and establish triple <meta-module-conflict rule-meta-module> to describe the conflict rules between modules; In step S131, a knowledge graph ontology modeling tool is used to establish the concept of meta-modules, and self-associations of assembly and self-associations of conflict rules are established on the concept of meta-modules in the form of directed connection lines. Step S132 is as follows: Establish the mapping between GBOM tree nodes and the dictionary of requirements and the instances of requirements values; establish the triple <Module Requirements Meta-Model - Belongs to - Meta-Module> to describe the relationship between the meta-module and the requirement feature vector; establish <Requirement Dictionary Item - Composition - Module Requirements Meta-Model> to describe the features of the module requirements meta-model; establish <Requirement Dictionary Item - Belongs to - Functional Classification> to describe the classification features of the requirements. In step S132, based on the ontology modeling tool, on the basis of S131, a module requirement meta-model, a requirement item dictionary, and a functional classification are added. The belonging relationship between the module requirement meta-model and the meta-module concept, the composition relationship between the requirement dictionary item and the module requirement meta-model concept, and the belonging relationship between the requirement dictionary item and the functional classification concept are added in the form of directed connection lines. Step S133 is: establishing a mapping between GBOM tree nodes and parameter feature value instances; the ontology triplet is in the form of <design feature attribute item-description-meta-module>; In step S133, based on the ontology modeling tool, the concept of design feature attribute items is added on the basis of S132, and the descriptive relationship between the design feature attribute items and the meta-module concept is added in the form of directed connection lines. Step S134 is as follows: Establish the mapping between product module instances and meta-modules; establish the ontology triple <module instance-instance-meta-module> to describe the instantiation relationship between module instances and meta-modules; establish <module instance-assembly-module instance> to describe the product DBOM; establish <attribute value-description-module instance> to map module design features; and establish <attribute value-instance-design feature attribute> to describe the instantiation relationship of attribute features. The construction method used in step S134 is as follows: Based on the ontology modeling tool, on the basis of S133, add module instances, attribute values ​​and design feature attribute items, and add instance relationships between module instances and meta-module concepts, assembly self-relationships of module instance concepts, descriptive relationships between attribute values ​​and module instance concepts, and instance relationships between attribute values ​​and design feature attribute item concepts in the form of directed connection lines. Step S135 is as follows: Establish the mapping between product module requirement instances, module instances, and meta-modules; establish ontology triples <requirement item value - extracted from - product requirement> to describe the structured mapping of requirements; establish <requirement item value - mapping - requirement dictionary item> to describe the value checking and instance relationship between requirement item values ​​and requirement dictionary items; establish <requirement item value - composition - module requirement instance> to realize the mapping from a single requirement item to the module requirement feature space; establish <module requirement instance - instance - module requirement meta-model> to realize the instantiation relationship description; and establish <module requirement instance - mapping - module instance> to describe the mapping from the requirement space to the module design solution space. The construction method used in step S135 is as follows: Based on the ontology modeling tool, on the basis of S134, add requirement item values, product requirements, and module requirement instances, and add extraction relationships between requirement item values ​​and product requirement concepts, mapping relationships between requirement item values ​​and requirement dictionary item concepts, composition relationships between requirement item values ​​and module requirement instance concepts, and mapping relationships between module requirement instances and module instances in the form of directed connection lines.

7. The intelligent configuration design method for complex equipment based on knowledge graphs as described in claim 6, characterized in that: Step S2 includes steps S21-S22; Step S21 is: convert the module configuration design process into a knowledge graph recommendation process; the configuration design process of the knowledge graph recommendation module is as follows: given the head entity module requirement instance and relation mapping, calculate the tail entity theoretical module attribute vector, and then calculate the similarity between the theoretical module attribute vector and the instance module attribute feature vector corresponding to the original module to recommend similar instances; Step S22 is: learning the triple representation of module requirement instance-mapping-module instance; based on the n:1 mapping relationship between module requirement instance and module instance, the TransR model is used to perform triple embedding learning of module requirement instance-mapping-module instance to obtain the product family configuration design knowledge embedding learning model.

8. The intelligent configuration design method for complex equipment based on knowledge graphs as described in claim 7, characterized in that: Step S3 includes steps S31-S34; Step S31 is: organize the technical tender requirements corpus, and annotate the corpus based on the meta-modules and requirement item dictionary in the ontology; Step S32 is: build a runtime environment for the Named Entity Recognition Deep Learning Model BERT-BILSTM-CRF based on the PyTorch platform, and train the model using the labeled required dataset; Step S33 is: Read the technical tender document uploaded by the user; Step S34 is as follows: Decompose the tender document into paragraphs from top to bottom and obtain the number of paragraphs; for each paragraph, extract the requirements.

Images