A complex equipment modular configuration design knowledge graph construction method

Abstract

The present application relates to the field of complex equipment design, and specifically relates to a complex equipment modular configuration design knowledge graph construction method, comprising: constructing configuration design module meta-knowledge ontology, proposing a configuration design event class knowledge multi-element representation method and a constraint rule class constraint expression and design parameter strong association knowledge representation method, and designing a constraint rule expression and design meta-parameter matching fusion algorithm to integrate module meta-knowledge into the configuration design knowledge graph. With the help of shape constraint language, an algorithm for automatically converting constraint rules into entity path constraints and design parameter attribute value constraints is designed to generate a constraint resource description architecture diagram; all project configuration design instances are extracted and converted into project resource description architecture diagrams; the constraint resource description architecture diagram is used for integrity checking of the project resource description architecture diagram, and the project configuration design instances that pass the checking are integrated into the knowledge graph to realize the integration of project instance knowledge and module meta-knowledge.

Description

TECHNICAL FIELD

[0001] The application relates to the field of complex equipment design, and in particular to a complex equipment modular configuration design knowledge graph construction method. BACKGROUND

[0002] To cope with market demand for multiple varieties and small batches, complex equipment mostly adopts a modular configuration design method to improve design efficiency, and the complex equipment is split into independent modules or components, and demand element parameters and design element parameters are configured for each module. In the configuration process, existing module instances are referenced or changed according to actual project requirements, and how to effectively represent and manage module element knowledge is the basis for improving the configuration design efficiency.

[0003] The configuration design knowledge graph has significant advantages in knowledge representation, reasoning visualization and knowledge association indexing. However, there are many challenges in the application of the configuration design knowledge graph in the field of complex equipment design and manufacturing. The main problems are as follows: industrial applications have high requirements for the accuracy of knowledge, but the knowledge in the field of complex equipment is closely related to product structure and business processes, and there are a large number of implicit relationships and complex constraints between the knowledge, which are difficult to effectively express, thereby affecting the accuracy of the knowledge. SUMMARY

[0004] The purpose of the present application is to solve the problem that the relationship between modules, the relationship between modules and demand element parameters, and the relationship between modules and design element parameters in the modularization process of complex equipment are difficult to effectively represent. The present application provides the following technical solutions:

[0005] A complex equipment modular configuration design knowledge graph construction method, comprising the following steps:

[0006] S1: constructing a configuration design ontology model according to the relationship between configuration design module element knowledge and project configuration design instance knowledge, and then mapping the module element knowledge into a graph structure and storing it in the configuration design knowledge graph;

[0007] S2: constructing constraint rule type knowledge, and storing it in the configuration design knowledge graph after integrity verification, wherein the constraint rule type knowledge is a parameter value constraint relationship between modules;

[0008] S3: constructing a first association model according to the mapping relationship of module element knowledge to project configuration design instance knowledge and module instance reference and change;

[0009] S4: converting the constraint rule type knowledge into inter-entity path constraints and design parameter attribute value constraints associated with the same project configuration design event using a shape constraint language, and generating a constraint resource description architecture graph;

[0010] S5: extracting project configuration design instance data from the first association model, converting into project resource description architecture diagram; using tool library to perform integrity check on the project resource description architecture diagram according to the constraint resource description architecture diagram, storing the project resource description architecture diagram passing the check into the configuration design knowledge graph, and completing establishment of the configuration design knowledge graph.

[0011] Further, the step S1 of constructing the configuration design knowledge ontology model comprises:

[0012] S11: constructing configuration design module meta-knowledge ontology;

[0013] S12: sorting module meta-knowledge data of complex equipment configuration design according to relationships between module entities in the configuration design module meta-knowledge ontology.

[0014] Further, the step S2 of constructing the constraint rule class knowledge comprises:

[0015] S21: constructing constraint rule entity concept, the constraint rule entity concept comprising rule name and rule expression; the rule expression comprising check parameter set, comparison operator and factor parameter set; the check parameter set and the factor parameter set must belong to the design element parameter set;

[0016] S22: sorting all the design element parameters between the modules;

[0017] S23: checking integrity of all constraint rule expressions according to the design element parameters; if the check passes, a relationship between the corresponding constraint rule and the design element parameter needs to be completed; if the design element parameter is missing in the constraint rule, the user needs to be prompted to check and modify, and then recheck.

[0018] Further, the step S3 of constructing the first association model comprises:

[0019] S31: constructing module instance entity based on configuration design event according to the module meta-knowledge ontology;

[0020] S32: constructing instantiation relationship between the module instance entity and the module entity;

[0021] S33: constructing relationship between the module instance entities;

[0022] S34: constructing relationship between the configuration design event and the module instance entity;

[0023] S35: Extracting a plurality of project configuration design instances from the module meta-knowledge data according to the configuration design ontology constructed in S31-S34, to obtain a first data set.

[0024] Further, the step of converting the constraint rule class knowledge into inter-entity path constraints and design parameter attribute value constraints in step S4 includes:

[0025] S41: Defining shape constraints on the project entity class, the module instance entity class, and the requirement parameter entity class, and ensuring that they are associated with the configuration design event class;

[0026] S42: Defining shape constraints on the design parameter entity class, and ensuring that they belong to the module instance entity;

[0027] S43: Defining constraint positions to specify the path of the applied constraints;

[0028] S44: Defining allowed parameter names;

[0029] S45: Converting the rule expression set in the constraint rule class knowledge into value constraints between the design parameter entities using the SPARQL-based constraint component;

[0030] S46: Saving the syntax formed by S41-S45 to the constraint resource description architecture diagram.

[0031] Further, the completeness verification step of the project resource description architecture diagram includes:

[0032] S51: Converting the first data set into the project resource description architecture diagram;

[0033] S52: Loading the data graph and the shape constraint language graph from the project resource description architecture diagram and the constraint resource description architecture diagram using the parsing program in the tool library;

[0034] S53: Performing shape constraint language verification using the verification program in the remaining database; if the verification fails, recording an error log and prompting the user to check; if successful, storing the project resource description architecture diagram into the configuration design knowledge graph.

[0035] Further, the completeness verification step for all rule expressions includes:

[0036] S231: Parsing the left-side verification parameter expression, extracting the verification parameter set through regular expressions, and matching with the design meta-parameter of the configuration design knowledge graph;

[0037] S232: Parsing the right-side factor parameter expression, extracting the factor parameter set through regular expressions, and matching with the design parameter of the configuration design knowledge graph;

[0038] S233: If S231 and S232 match successfully, it is also necessary to complete the relationship edge between the rule expression and the check parameter set and the factor parameter set, store it into the configuration design knowledge graph, and remove the rule from the to-be-verified rules; if the matching fails, record error information and delete the rule expression.

[0039] Further, the structure of the configuration design module meta-knowledge ontology comprises:

[0040] S111: Module entity, the attributes of the module entity comprising: module name, code.

[0041] S112: Demand meta-parameter entity, the attributes of the demand meta-parameter entity comprising: name, data type and unit.

[0042] S113: Design meta-parameter entity, the attributes of the design meta-parameter entity comprising: name, data type and unit.

[0043] S114: Connection between entities, comprising: demand mapping relationship between module and demand meta-parameter, assembly relationship between modules, and feature relationship between module and design parameter.

[0044] Further, the structure of the module meta-knowledge data comprises:

[0045] S121: Module meta-knowledge data, constructing attribute triple sets of <module, module name, name value> and <module, code, code value>.

[0046] S122: Demand parameter meta-knowledge data, constructing attribute triple sets of <demand meta-parameter, name, name value>, <demand meta-parameter, data type, type value> and <demand meta-parameter, unit, unit value>.

[0047] S123: Design parameter meta-knowledge data, constructing attribute triple sets of <design meta-parameter, name, name value>, <design meta-parameter, data type, type value> and <design meta-parameter, unit, unit value>.

[0048] S124: Mapping relationship between module and demand meta-parameter, constructing relationship triple set of <module, demand mapping, demand meta-parameter>.

[0049] S125: Description relationship between module and design meta-parameter, constructing relationship triple set of <module, feature, design meta-parameter>.

[0050] S126: Assembly relationship between modules, constructing relationship triple set of <first module, assembly, second module>.

[0051] Further, the structure of the module instance entity includes:

[0052] S311: Establish a project entity concept, and the attributes include: name, code, and application scenario.

[0053] S312: Establish a requirement parameter entity concept, and the attributes include: requirement value.

[0054] S313: Establish a module instance entity concept, and the attributes include: code, model, drawing, and time.

[0055] S314: Establish a design parameter entity concept, and the attributes include: parameter value.

[0056] S315: Establish a designer entity concept, and the attributes include: work number, name, and title.

[0057] S316: Establish a configuration design event concept, and the attributes include: design time.

[0058] Compared with the prior art, the present application has the following beneficial effects:

[0059] 1. The inventor found in practice that, in order to meet the market demand for multiple varieties and small batches, complex equipment mostly adopts modular configuration design to improve design efficiency, and the complex equipment is divided into independent modules or components, requirement parameters and design parameters are designed for each module, and existing module instances are matched or changed in the configuration design process according to the actual requirements of the project, and effective representation and management of module meta-knowledge is the basis for improving the configuration design efficiency. Therefore, a module knowledge meta-model for configuration design is proposed, which maps the module meta-knowledge into a project resource description architecture diagram and stores it in a knowledge graph through knowledge representation of modules, requirement meta-parameters, design meta-parameters, and meta-assembly relationships between modules, mapping relationships between modules and requirement meta-parameters, and description relationships between modules and design meta-parameters, so as to facilitate the search and question-answering services of module general knowledge.

[0060] 2. The inventor found in practice that, in the configuration design process of complex equipment components, there are complex constraint relationships between the attribute values of modules, and the variable parameters in these constraint relationships must belong to the design meta-parameter set. Therefore, a constraint rule checking algorithm is designed to extract variables in the constraint rule expression, check the integrity of the constraint rule by matching with the module design meta-parameters, and complete the relationship between the constraint rule that meets the integrity and the design meta-parameters.

[0061] 3. The inventors discovered in practice that the process of complex equipment configuration design involves decomposing project requirements into modules and matching similar module instances with these module requirements as input. Specifically, it involves mapping module meta-knowledge to project instance knowledge and referencing and modifying module instances. Traditional knowledge triple structures are insufficient to effectively represent the constraint rules involving multiple entities in this process. Therefore, a project module configuration design event association model is proposed. This model uses configuration design event classes to connect projects, modules, module instances, requirement parameters, and designer entities in a role-based manner, thus representing the semantic relationships in the project module configuration design process.

[0062] 4. In practice, the inventors discovered that the constraint rules represented and stored at the module meta-knowledge layer are merely static rule knowledge. During the instantiation configuration design process, it is necessary to verify whether the design parameters of the module instance meet the constraints to ensure, from a global perspective, that there are no design conflicts between components. Therefore, an algorithm is proposed to automatically convert constraint rules into the attribute values ​​of design parameters of project module instances. This algorithm automatically converts constraint rules into path constraints between entities associated with the same project configuration design event and constraints between design parameter attribute values, generating a shape constraint resource description architecture diagram for project module instances.

[0063] 5. In practice, the inventors discovered that existing configuration design instance knowledge for a project must satisfy all constraint rules between entities associated with the same project configuration design event and between design parameter attribute values ​​before it can be stored in the knowledge graph, thus ensuring the integrity of project configuration data in the knowledge graph. Therefore, the project configuration design instance dataset is extracted and converted into a project resource description architecture diagram. The project resource description architecture diagram and the shape constraint resource description architecture diagram are used as parameters to call the pySHACL package for integrity verification. The verified project configuration design instances are then integrated into the knowledge graph, realizing the fusion of project instance knowledge and module meta-knowledge. Attached Figure Description

[0064] Figure 1 A flowchart illustrating the configuration of a knowledge graph;

[0065] Figure 2 Example diagram illustrating the configuration of a knowledge graph;

[0066] Figure 3 A flowchart illustrating the knowledge verification and fusion algorithm for constraint rule expressions;

[0067] Figure 4 A schematic diagram illustrating the architecture structure for constraining resources. Detailed Implementation

[0068] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments of the present application.

[0069] Therefore, the following detailed description of the embodiments of the present application is not intended to limit the scope of the claimed application, but merely represents some embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0070] It should be noted that the embodiments in the present application and the features and technical solutions in the embodiments can be combined with each other without conflict.

[0071] In the description of the present application, it should be noted that the positions or location relationships indicated by the terms "upper", "lower" and the like are based on the positions or location relationships shown in the drawings, or the positions or location relationships commonly placed when the product of the present application is used, or the positions or location relationships commonly understood by those skilled in the art. Such terms are only for the convenience of describing the present application and simplifying the description, and are not intended to indicate or imply that the indicated device or element must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application. In addition, the terms "first", "second" and the like are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0072] Embodiment one: refer to Figure 1 as shown,

[0073] The complex equipment modular configuration design knowledge graph construction method provided in the embodiment includes the following steps:

[0074] S1: as shown, collate the design requirements of the complex equipment configuration design process module and the design parameters representing the module design results, construct a configuration design knowledge ontology model according to the relationship between the configuration design module element knowledge and the project configuration design instance knowledge, and then map the module element knowledge into a graph structure and store it in the configuration design knowledge graph. Figure 2 S2: construct constraint rule type knowledge and store it in the configuration design knowledge graph, wherein the constraint rule type knowledge is the parameter value constraint relationship between the modules. For example, the assembly constraint between the design parameters "internal space" of the gear box and "gear width" of the gear is calculated as follows:

[0075]

[0076] ;

[0077] ​where Inside is the internal space dimension, W1 is the gearbox width, and W2 is the gear width.

[0078] S3: According to the module meta-knowledge, a mapping relationship between the project configuration design instance knowledge and the module instance reference and change is configured, and a first association model is constructed; the first association model is a project module configuration design event association model. The mapping relationship is that a design personnel obtains a module actual demand value, matches a similar module instance according to the demand value, and establishes a reference relationship, then obtains a model and design parameters of the module instance, and completes a complex equipment configuration design process; for a design that needs to be changed, a new module instance and design parameter value are formed by changing on the basis of the model.

[0079] S4: The constraint rule class knowledge is converted into an entity path constraint and a design parameter attribute value constraint associated with the same project configuration design event using a shape constraint language, and a constraint resource description architecture diagram is generated.

[0080] S5: Project configuration design instance data is extracted from the first association model and converted into a project resource description architecture diagram; a tool library is used to perform integrity checking on the project resource description architecture diagram according to the constraint resource description architecture diagram, and the project resource description architecture diagram that passes the checking is stored in a configuration design knowledge graph, and the establishment of the configuration design knowledge graph is completed.

[0081] Further, the step S1 of constructing the configuration design knowledge ontology model comprises the following steps.

[0082] S11: A configuration design module meta-knowledge ontology is constructed, specifically comprising the following steps.

[0083] S111: A module entity concept is established, and attributes include a module name and a code.

[0084] S112: A demand meta-parameter entity concept is established, and attributes include a name, a data type, and a unit.

[0085] S113: A design meta-parameter entity concept is established, and attributes include a name, a data type, and a unit.

[0086] S114: A relationship between entities is established, including a demand mapping relationship between the module and the demand meta-parameter, an assembly relationship between a first module and a second module, and a description relationship between the module and the design meta-parameter.

[0087] S12: According to the relationship between the module entities in the configuration design module meta-knowledge ontology, module meta-knowledge data of complex equipment configuration design is sorted. Specifically, the following steps are included.

[0088] S121: The module meta-knowledge data is sorted according to the module entity, and a <module, module name, name value> and <module, code, code value> attribute triple set is constructed.

[0089] S122: The requirement parameter meta-knowledge data is sorted according to the requirement parameter entity, and a <requirement parameter, name, name value>, <requirement parameter, data type, type value> and <requirement parameter, unit, unit value> attribute triple set is constructed.

[0090] S123: The design parameter meta-knowledge data is sorted according to the design parameter entity, and a <design parameter, name, name value>, <design parameter, data type, type value> and <design parameter, unit, unit value> attribute triple set is constructed.

[0091] S124: According to the mapping relationship between the module and the requirement parameter, a <module, requirement mapping, requirement parameter> relationship triple set is constructed.

[0092] S125: According to the description relationship between the module and the design parameter, a <module, feature, design parameter> relationship triple set is constructed.

[0093] S126: According to the assembly relationship between the modules, a <module, assembly, module> relationship triple set is constructed.

[0094] Most complex equipment adopts modular configuration design method to improve design efficiency, and the complex equipment is divided into independent modules or components, and the requirement parameters and design parameters of each module are designed, and in the configuration design process, the existing instance reference or change is matched according to the actual requirement of the project, and the effective representation and management of the module meta-knowledge is the basis for improving the configuration design efficiency. The present application proposes a module knowledge element model for configuration design, which represents the relationship between the project configuration design instance and the module meta-knowledge through event multi-element, and then converts the module meta-knowledge into a graph structure after the resource description architecture diagram, and stores the module meta-knowledge into the knowledge graph, so as to facilitate the search and question and answer services of the module general knowledge.

[0095] Further, the step S2 of constructing the constraint rule class knowledge comprises:

[0096] S21: A constraint rule entity concept is constructed, and the constraint rule entity concept comprises a rule name and a rule expression; the rule expression comprises a verification parameter set, a comparison operator and a factor parameter set in sequence from left to right; and the verification parameter set and the factor parameter set must belong to the design parameter set.

[0097] S22: All the design parameter constraint rules between the modules are sorted.

[0098] S23: Verify the integrity of all constraint rule expressions according to the design element parameters; if the verification is passed, the relationship between the corresponding constraint rule and the design element parameter needs to be completed; if the design element parameter is missing in the constraint rule, the verification cannot be passed, the current rule and the corresponding mismatch information are written into the error log, then the user is prompted to check and modify, and then step S23 is returned to re-verify.

[0099] In the configuration design process of complex equipment parts, there are complex constraint relationships between module attributes and values. The variable parameters in these constraint rule expressions must belong to the design element parameter set. The constraint rule expression checking algorithm is designed, the variables in the constraint rule expression are extracted, and the integrity of the constraint rule is checked by matching with the module design element parameters; for the constraint rules that pass the verification, the relationship between them and the design element parameters is also completed, which is convenient for constraint rule class knowledge search and question and answer services.

[0100] Further, the step S3 of constructing the first association model comprises:

[0101] S31: Constructing a module instance entity concept based on configuration design events according to the module element knowledge ontology. Specifically, it comprises:

[0102] S311: Project entity, attributes include: name, code, application scenario.

[0103] S312: Demand parameter entity, attributes include: demand value.

[0104] S313: Module instance entity, attributes include: code, model, drawing, time.

[0105] S314: Design parameter entity, attributes include: parameter value.

[0106] S315: Design personnel entity, attributes include: worker number, name, title.

[0107] S316: Configuration design event, attributes include: design time.

[0108] S32: Constructing the instantiation relationship between the module instance entity and the module entity; including: the instantiation relationship between the demand element parameter and the demand parameter, the instantiation relationship between the module and the module instance, and the instantiation relationship between the design element parameter and the design parameter.

[0109] S33: Constructing the relationship between the module instance entities; including: the instantiation relationship between the project and the demand parameter, the belonging relationship between the design parameter and the module instance, and the change relationship between the module instances.

[0110] S34: Construct the relationship between the configuration design event and the module instance entity; including: the event participant relationship between the configuration design event and the project, the designer, the requirement parameter, the module, and the module instance.

[0111] S35: According to the configuration design ontology constructed in S31-S34, extract a plurality of project configuration design instances from the module meta-knowledge data to obtain a first data set.

[0112] The process of complex equipment configuration design is a process of decomposing project requirements into modules, matching similar module instances with module requirements as input, which is a process of mapping module meta-knowledge to project instance knowledge and module instance reference and change design from a semantic point of view. The traditional knowledge triple structure is difficult to effectively represent the semantic constraints of multiple entity participation in this process. Therefore, a project module configuration design event association model is proposed, which connects the project, module, module instance, requirement parameter, and designer class entities in the form of roles through the configuration design event class to represent the semantic relationship of the project module configuration design process.

[0113] Further, as shown in Figure 4 , the step of converting the constraint rule class knowledge into the constraint between the path between entities and the attribute value of the design parameter using the shape constraint language SHACL includes:

[0114] S41: Create a SHACL namespace named ProjectConfigConstraints.

[0115] S42: Define a shape constraint ex:ProjectShape on the project entity class, and ensure that it is associated with the configuration design event class, as follows:

[0116] ex:ProjectShape

[0117] a sh:NodeShape;

[0118] sh:property[

[0119] sh:path ex:hasConfigurationEvent;

[0120] sh:node ex:ConfigurationEventShape;]。

[0121] S43: Define a shape constraint ex:ModuleInstanceShape on the module instance entity class, and ensure that it participates in the configuration design event class, as follows:

[0122] ex:ModuleInstanceShape

[0123] a sh:NodeShape ;

[0124] sh:property [

[0125] sh:path ex:hasConfigurationEvent;

[0126] sh:node ex:ConfigurationEventShape;].

[0127] S44: Define the shape constraint ex:RequireParaShape on the requirement parameter entity class, which ensures that it participates in the configuration design event class, as follows:

[0128] ex:RequireParaShape

[0129] a sh:NodeShape ;

[0130] sh:property [

[0131] sh:path ex:hasConfigurationEvent;

[0132] sh:node ex:ConfigurationEventShape;].

[0133] S45: Define the shape constraint ex:DesignParaShape on the design parameter entity class, which ensures that it belongs to the module instance entity and contains the parameter name and attribute value, as follows:

[0134] ex:DesignParaShape

[0135] a sh:NodeShape ;

[0136] sh:property [

[0137] sh:path ex:belongsToModuleInstance;

[0138] sh:node ex:ModuleInstanceShape ;];

[0139] sh:property [

[0140] sh:path ex:parameterName;

[0141] sh:datatype xsd:string; ];

[0142] sh:property [

[0143] sh:path ex:propertyValue;

[0144] sh:datatype xsd:decimal;].

[0145] S46: define constraint shape ex:ConstraintShape, make sure the path of applying constraint is specified by sh:property, syntax as follows:

[0146] ex:ConstraintShape

[0147] a sh:NodeShape;

[0148] sh:property[

[0149] sh:path

[0150] ex:hasConfigurationEvent / ex:hasModuleInstance / ex:hasDesignParameter;

[0151] sh:node ex:ValueConstraintShape;].

[0152] S47: define allowed parameter name ex:ValueConstraintShape, syntax as follows:

[0153] ex:ValueConstraintShape

[0154] a sh:NodeShape;

[0155] sh:property[

[0156] sh:path ex:hasDesignPara;

[0157] sh:node ex:DesignParaValueShape;].

[0158] S48: for the rule expression set in the constraint rule class knowledge, use SPARQL-based constraint component to convert it into value constraint between design parameter entities, specifically including:

[0159] S481: Obtain each constraint rule rulei, define the rule constraint, until all rules are defined, the syntax is as follows:

[0160] <ex:ruleshape 资源描述架构图:about="#Rulei">

[0161] <sh:property>

[0162] <sh:path 资源描述架构图:resource="ex:expression" / >

[0163] <sh:datatype 资源描述架图:resource="xsd:string">rulei< / sh:datatype>

[0164] < / sh:property>

[0165] < / ex:ruleshape>

[0166] Wherein: the ex:expression attribute stores the expression of the constraint rule rulei.

[0167] S482: Define the query constraint shape ex:QueryConstraintShape, check the constraints in rules, the syntax is as follows:

[0168] <ex:queryconstraintshape 资源描述架构图:about="#QueryConstraint">

[0169] <sh:property>

[0170] <sh:path 资源描述架构图:resource="ex:computedValue" / >

[0171] <sh:sparql>

[0172] <![CDATA[SELECT?this?constraintResult {

[0173] ?this ex:expression?rulei.

[0174] BIND (xsd:boolean(?rulei) AS?constraintResult)}]]>

[0175] < / sh:sparql>

[0176] < / sh:property>

[0177] < / ex:queryconstraintshape>

[0178] S49: Save the syntax of the above steps to the constraint resource description architecture diagram.

[0179] The constraint rules represented and stored in the module meta-knowledge layer are only static rule knowledge. In the instantiation configuration design process, it is necessary to check whether the design parameters of the module instance meet the constraints to ensure that there is no design conflict between parts from a global perspective. Therefore, an algorithm for automatically converting constraint rules into attribute values between design parameters of project module instances is proposed. The constraint rules are automatically converted into path constraints between entities associated with the same project configuration design event and constraints between design parameter attribute values, and a project module instance shape constraint resource description architecture diagram is generated. The constraint rules between the design parameters of the configuration design module instance are defined by SHACL, which ensures the integrity and consistency of the modular configuration design knowledge of complex equipment.

[0180] Further, the integrity checking step of the project resource description architecture diagram using the python verification program pySHACL package includes:

[0181] S51: Determine whether the first data set is empty. If not, obtain the first project instance, otherwise go to S56.

[0182] S52: Convert the project instance data into a project resource description architecture diagram.

[0183] S53: Load the data graph and SHACL graph from the two resource description architecture diagram files of the project resource description architecture diagram and the constraint resource description architecture diagram using data_graph.parse.

[0184] S54: SHACL validation is performed using the pyshacl.validate function, returning a Boolean value conforms indicating whether the SHACL constraints are met, a results_graph containing the validation results, and a readable validation report results_text. If conforms is false, the following steps are performed:

[0185] S55: It is determined whether conforms is false. If so, results_text is written to the error log and the project resource description schema graph file is stored. Otherwise, the project resource description schema data is stored in the configuration design knowledge graph.

[0186] S55: The project data is removed from the first data set, and S51 is reached.

[0187] S56: It is determined whether the error log is empty. If not, the contents of the error log and the corresponding project resource description schema file are displayed to the user for inspection.

[0188] The existing configuration design instance knowledge of a project must satisfy the path constraints between entities associated with the same project configuration design event and all constraint rules between design parameter attribute values in order to be stored in the knowledge graph, thereby ensuring the integrity of the project configuration data in the knowledge graph. Therefore, the first data set is converted into a project resource description schema graph; the project resource description schema graph and the shape constraint resource description schema graph are used as parameters to call the pySHACL package for integrity checking, and the project configuration design instance that passes the checking is integrated into the knowledge graph, realizing the fusion of project instance knowledge and module meta-knowledge.

[0189] Further, as shown in Figure 3 the integrity checking steps for all rule expressions include:

[0190] S231: Read each constraint rule expression in the set of constraint rule expressions to be verified.

[0191] S232: Parse the check parameter expression of the rule expression, extract the set of check parameters by regular expression, and match them with the design meta-parameters of the configuration design knowledge graph. If there are unmatched parameters, go to S235.

[0192] S233: Parse the sub-parameter expression of the rule expression factor, extract the set of factor parameters by regular expression, and match them with the design parameters of the configuration design knowledge graph. If there are unmatched parameters, go to S235.

[0193] S234: Complete the relationship edge between the rule expression knowledge and the verification parameter set and the factor parameter set, store it into the configuration design knowledge graph, and remove the rule expression from the to-be-verified rule.

[0194] S235: Write the rule expression and the mismatch information into an error log, and remove the rule expression from the to-be-verified rule.

[0195] According to the rule knowledge ontology, the rule knowledge is arranged, the verification element parameter and the factor element parameter in the rule expression are extracted by using a regular expression, the extracted design element parameter is matched with the design parameter entity in the configuration design element knowledge graph constructed in S1,

[0196] Further, the structure of the configuration design module element knowledge ontology comprises:

[0197] S111: Module entity, the attributes of the module entity comprise: module name, code.

[0198] S112: Requirement element parameter entity, the attributes of the requirement element parameter entity comprise: name, data type and unit.

[0199] S113: Design element parameter entity, the attributes of the design element parameter entity comprise: name, data type and unit.

[0200] S114: Connection between entities, comprising: requirement mapping relationship between module and requirement element parameter, assembly relationship between modules, and feature relationship between module and design parameter.

[0201] Further, the structure of the module element knowledge data comprises:

[0202] S121: Module element knowledge data, construct attribute triple sets of <module, module name, name value> and <module, code, code value>.

[0203] S122: Requirement parameter element knowledge data, construct attribute triple sets of <requirement element parameter, name, name value>, <requirement element parameter, data type, type value> and <requirement element parameter, unit, unit value>.

[0204] S123: Design parameter element knowledge data, construct attribute triple sets of <design element parameter, name, name value>, <design element parameter, data type, type value> and <design element parameter, unit, unit value>.

[0205] S124: Mapping relationship between module and requirement element parameter, construct relationship triple set of <module, requirement mapping, requirement element parameter>.

[0206] S125: Describing the relationship between the module and the design element parameter, and constructing a <module, feature, design element parameter> relationship triple set.

[0207] S126: Assembling the relationship between the modules, and constructing a <first module, assembly, second module> relationship triple set.

[0208] Further, the structure of the module instance entity includes:

[0209] S311: Establishing a project entity concept, and the attributes include: name, code, and application scenario.

[0210] S312: Establishing a requirement parameter entity concept, and the attributes include: requirement value.

[0211] S313: Establishing a module instance entity concept, and the attributes include: code, model, drawing, and time.

[0212] S314: Establishing a design parameter entity concept, and the attributes include: parameter value.

[0213] S315: Establishing a designer entity concept, and the attributes include: work number, name, and title.

[0214] S316: Establishing a configuration design event concept, and the attributes include: design time.

[0215] The above embodiments are only used to illustrate the present application and not to limit the technical solutions described in the present application. Although the present application has been described in detail with reference to the above embodiments, the present application is not limited to the above specific embodiments, and therefore any modification or equivalent replacement of the present application; and all technical solutions and improvements without departing from the spirit and scope of the application are covered in the scope of the claims of the present application.

Claims

1. A method for constructing a knowledge graph for modular configuration design of complex equipment, characterized in that, Including the following steps: S1: Based on the relationship between the configuration design module meta-knowledge and the project configuration design instance knowledge, construct a configuration design knowledge ontology model; then map the module meta-knowledge into a graph structure and store it in the configuration design knowledge graph; S2: Construct constraint rule knowledge, and after integrity verification, store it in the configuration design knowledge graph. The constraint rule knowledge is the parameter value constraint relationship between modules. S3: Construct the first association model based on the mapping relationship between module meta-knowledge, project configuration design instance knowledge, and module instance references and changes; the first association model is the project module configuration design event association model; S4: Use shape constraint language to convert the constraint rule class knowledge into path constraints between entities and constraints between design parameter attribute values ​​associated with the same project configuration design event, and generate a constraint resource description architecture diagram; S5: Extract project configuration design instance data from the first association model and convert it into a project resource description architecture diagram; use a tool library to perform integrity verification on the project resource description architecture diagram based on the constraint resource description architecture diagram, and store the verified project resource description architecture diagram into the configuration design knowledge graph to complete the establishment of the configuration design knowledge graph; The step of constructing the first association model in step S3 includes: S31: Construct a module instance entity based on the configuration design event according to the module meta-knowledge ontology; S32: Construct the instantiation relationship between the module instance entity and the module entity; S33: Construct the relationships between the module instance entities; S34: Establish the relationship between the configuration design event and the module instance entity; S35: Based on the configuration design ontology constructed in S31-S34, extract multiple project configuration design instances from the module meta-knowledge data to obtain the first dataset; The step S4, which converts the constraint rule knowledge into inter-entity path constraints and design parameter attribute value constraints, includes: S41: Define shape constraints on the project entity class, module instance entity class, and requirement parameter entity class to ensure that they are associated with the configuration design event class; S42: Define shape constraints on the design parameter entity class to ensure that it belongs to the module instance entity; S43: Defines the constraint location, specifying the path where the constraint is applied; S44: Define the allowed parameter names; S45: Using a SPARQL-based constraint component, the set of rule expressions in the constraint rule class knowledge is converted into value constraints between the design parameter entities; S46: Save the syntax formed by S41 - S45 to the constraint resource description architecture diagram.

2. The method for constructing a knowledge graph for modular configuration design of complex equipment as described in claim 1, characterized in that, The steps in step S1 of constructing the configuration design knowledge ontology model include: S11: Construct the meta-knowledge ontology of the configuration design module; S12: Organize the module meta-knowledge data of complex equipment configuration design according to the relationships between module entities in the configuration design module meta-knowledge ontology.

3. The method for constructing a knowledge graph for modular configuration design of complex equipment as described in claim 1, characterized in that, The steps for constructing the constraint rule class knowledge in step S2 include: S21: Construct a constraint rule entity concept, which includes a rule name and a rule expression; the rule expression includes a set of verification parameters, a comparison operator, and a set of factor parameters; the set of verification parameters and the set of factor parameters must belong to the design meta-parameter set. S22: Review all the design meta-parameter constraint rules between the modules; S23: Verify the completeness of all constraint rule expressions based on the design meta-parameters; if the verification passes, complete the relationship between the corresponding constraint rules and design meta-parameters; if the design meta-parameters are missing from the constraint rules, prompt the user to check and modify them, and then re-verify.

4. The method for constructing a knowledge graph for modular configuration design of complex equipment as described in claim 1, characterized in that, The integrity verification steps for the project resource description architecture diagram include: S51: Convert the first dataset into the project resource description architecture diagram; S52: Use the parser in the tool library to load the data diagram and shape constraint language diagram from the project resource description architecture diagram and the constraint resource description architecture diagram; S53: Use the validation program in the remaining database to perform shape constraint language validation; if the validation fails, log the error and prompt the user to check; if successful, store the project resource description architecture diagram in the relevant configuration design knowledge graph.

5. The method for constructing a knowledge graph for modular configuration design of complex equipment as described in claim 1, characterized in that, The integrity verification steps for the rule expression include: S231: Parse the left-side validation parameter expression, extract the validation parameter set through regular expressions, and match it with the design meta-parameters of the configuration design knowledge graph; S232: Parse the right-hand factor parameter expression, extract the factor parameter set through regular expressions, and match it with the design parameters of the configuration design knowledge graph; S233: If S231 and S232 match successfully, it is also necessary to complete the relationship edges between the rule expression and the verification parameter set and factor parameter set, store them in the configuration design knowledge graph, and remove the rule expression from the rule expressions to be verified; if the match fails, record the error information and delete the rule expression.

6. The method for constructing a knowledge graph for modular configuration design of complex equipment as described in claim 2, characterized in that, The structure of the configuration design module meta-knowledge ontology includes: S111: Module entity, the attributes of which include: module name and code; S112: Demand meta-parameter entity, the attributes of which include: name, data type and unit; S113: Design meta-parameter entity, the attributes of which include: name, data type and unit; S114: Relationships between entities, including: the requirement mapping relationship between modules and requirement meta-parameters, the assembly relationship between modules, and the characteristic relationship between modules and design parameters.

7. The method for constructing a knowledge graph for modular configuration design of complex equipment as described in claim 2, characterized in that, The structure of the module meta-knowledge data includes: S121: Module meta-knowledge data, constructing a set of attribute triples <module, module name, name value> and <module, code, code value>; S122: Demand parameter meta-knowledge data, constructing a set of attribute triples of <demand meta-parameter, name, name value>, <demand meta-parameter, data type, type value>, and <demand meta-parameter, unit, unit value>. S123: Design parameter meta-knowledge data, constructing a set of attribute triples: <design meta-parameter, name, name value>, <design meta-parameter, data type, type value>, and <design meta-parameter, unit, unit value>; S124: The mapping relationship between modules and requirement meta-parameters, constructing a set of <module, requirement mapping, requirement meta-parameter> relationship triples; S125: Describe the relationship between modules and design meta-parameters, and construct a set of <module, feature, design meta-parameter> relationship triples; S126: Assembly relationships between modules, construct a set of triples of the relationship <first module, assembly, second module>.

8. The method for constructing a knowledge graph for modular configuration design of complex equipment as described in claim 1, characterized in that, The structure of the module instance entity includes: S311: Establish the project entity concept, with attributes including: name, code, and application scenario; S312: Establish the concept of requirement parameter entity, with attributes including: requirement value; S313: Establish the concept of module instance entities, with attributes including: code, model, drawing, and time; S314: Establish the entity concept of design parameters, with attributes including: parameter values; S315: Establish the entity concept of designers, with attributes including: employee ID, name, and job title. S316: Establish the concept of configuration design events, with attributes including: design time.

Images