Part big data optimization production design method based on semantic understanding

Abstract

The application relates to the technical field of semantic understanding, and discloses a part big data optimization production design method based on semantic understanding. The method acquires design files, process routes, inspection rules, quality anomaly records, production parameter records and design change records, extracts design intentions, structural features, process conditions, quality determinations and anomaly reason entities through semantic understanding, constructs a design production semantic constraint graph according to limitation, dependence, conflict, cause and correction relations, and connects production parameters and quality inspection results; after analyzing the requirements of parts to be optimized, constraint propagation is carried out, conflict or invalid parameter combinations are deleted, and a production design feasible region and production design data are generated. The method reduces sample misuse caused by similar fields but different semantic constraints, retains constraints with different expressions but consistent technical meanings, and improves traceability and constraint consistency.

Description

Technical Field

[0001] This invention relates to the field of semantic understanding technology, and discloses a method for optimizing production design based on big data of component manufacturing based on semantic understanding. Background Technology

[0002] Current component manufacturing design typically relies on historical data from design data management systems, process management systems, quality inspection systems, and production execution systems for decision support. Conventional approaches generally use structured fields such as component codes, material names, specifications, material grades, process numbers, inspection items, and quality grades as search entry points. They first extract historical design schemes, process routes, and production parameters for identical or similar components from the database, and then determine new production design parameters based on historical pass rates, rework records, or parameter distribution ranges. For textual content in design specifications, process notes, inspection rules, and anomaly analysis reports, existing approaches often use keyword matching, manual tagging, or fixed templates to organize the text, converting information such as materials, dimensions, tolerances, processing methods, and defect names into queryable fields for use by statistical or optimization models. While this approach meets the requirements for complete fields, standardized expression, and stable component families in production data retrieval, it lacks sufficient expression of semantic relationships, constraint sources, version changes, and anomaly causes.

[0003] In the most conventional technical solutions, the optimization of component production design typically involves data cleaning, sample screening, parameter modeling, and result recommendation. The system first archives historical data by component code, process code, and inspection item, deleting records with many missing fields or abnormal formats. Then, it filters samples based on similar components, materials, or processing procedures. Subsequently, it calculates recommended processing parameters, process routes, or inspection control ranges using regression models, clustering models, rule bases, or multi-objective optimization models. For unstructured text, keywords are usually converted into tags for screening, or manually maintained disabling rules are used as post-validation conditions. The core of this solution remains field association and numerical correlation analysis; textual semantics serve only as auxiliary retrieval conditions and cannot express the limiting relationship between design intent and structural features, nor the causal constraints between process conditions, quality judgments, and causes of anomalies. When the same constraint is expressed differently in different documents, or different constraints use the same field name, the system struggles to distinguish their true technical meaning.

[0004] The main technical problem with existing technologies is that during the optimization of component production design, numerous constraints in design documents, process routes, inspection rules, quality anomaly records, and design change records exist in the form of natural language, notes, cause descriptions, or version descriptions. Traditional field matching and numerical modeling cannot establish a propagable and verifiable association between these semantic constraints and structured production parameters and quality inspection results. Due to the lack of a constraint graph based on semantic understanding, when the system calls historical big data, it is easy to include samples with similar fields but different design constraints in the optimization, and it is also easy to miss constraints with different textual expressions but consistent technical meanings. As a result, candidate production design parameters may appear to conform to the historical data distribution during the calculation stage, but may conflict with material compatibility, dimensional chain relationships, processing sequence, inspection rules, or existing anomaly causes. The resulting production design data lacks a unified semantic boundary, making it difficult to ensure that candidate solutions are within the feasible range under manufacturing and quality constraints. Summary of the Invention

[0005] The purpose of this invention is to provide a component big data optimization production design method based on semantic understanding, which can solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A big data optimization production design method for parts based on semantic understanding includes: acquiring parts design documents, process routes, inspection rules, quality anomaly records, production parameter records, and design change records; Semantic understanding is performed on the design documents, process routes, inspection rules, quality anomaly records, and design change records to extract entities such as design intent, structural features, process conditions, quality judgment, and anomaly causes. Construct a semantic constraint graph for design and production based on limiting relationships, dependency relationships, conflict relationships, causal relationships, and modifying relationships; The production parameter records and quality inspection results are linked to the design and production semantic constraint graph. The semantic analysis of the requirements for the components to be optimized is performed and the constraints are propagated in the design and production semantic constraint graph to generate a feasible domain for production design. Component production design data is generated within the feasible domain of the production design.

[0007] Preferably, the extraction of design intent entities, structural feature entities, process condition entities, quality judgment entities, and anomaly cause entities includes: establishing semantic segments according to component families, design versions, and data sources; For each semantic segment, the functional description, dimensional tolerance description, material processing description, machining process description, and defect description are labeled with entity types. Entities with the same technical meaning but different textual expressions are merged into canonical semantic entities; Configure semantic relationship identifiers for canonical semantic entities that have hierarchical, parallel, substitution, and exclusionary relationships; Based on the semantic relationship identifiers, an entity set is formed for constructing the design and production semantic constraint graph.

[0008] Preferably, the construction of the design and production semantic constraint graph based on the limiting relationship, dependency relationship, conflict relationship, causal relationship and correction relationship includes: using the design intent entity, the structural feature entity, the process condition entity, the quality judgment entity and the anomaly cause entity as graph nodes; Transform the dimensional chain constraints, material adaptation constraints, processing sequence constraints, inspection judgment constraints, and anomaly repair constraints within the same part family into directed relation edges; Write the source file identifier, design version identifier, applicable component family identifier, and constraint status identifier for the directed relation edge; The constraint status identifier is used to distinguish between valid constraints, alternative constraints, and invalid constraints.

[0009] Preferably, linking the production parameter records and quality inspection results to the design-production semantic constraint graph includes: establishing a structured data mapping key based on the component code, process identifier, inspection item identifier, and design version identifier; Bind the processing parameters, process inspection values, final inspection results, rework records and scrap reasons to the corresponding process condition entities, quality judgment entities and abnormality reason entities respectively; When the structured data mapping key is missing or conflicting, candidate attachment paths are determined based on the semantics of adjacent processes, the semantics of inspection items, and the semantics of abnormal causes. After performing consistency verification on the candidate attachment paths, they are written into the design and production semantic constraint graph.

[0010] Preferably, merging entities with the same technical meaning but different textual expressions into a standardized semantic entity includes: extracting the pre-qualifiers, post-constraints, associated numerical fields, and adjacent process words of each entity in its semantic segment; An entity context signature is formed based on the pre-qualifier, the post-constraint, the associated numerical field, and the adjacent process word; Merge entities with similar text and consistent entity context signatures into the same canonical semantic entity; Entities with similar text but inconsistent entity context signatures are retained as entities with different canonical semantics and written into an exclusion relation identifier for subsequent constraint propagation.

[0011] Preferably, distinguishing between valid constraints, alternative constraints, and invalid constraints based on the constraint status identifier includes: establishing a version chain for directed relation edges of the same constraint object according to the design version identifier; Compare the limiting objects, applicable component families, process conditions, and inspection and judgment contents of adjacent directed relation edges in the version chain; When a subsequently described directed relation edge covers all the bounded objects of a preceding directed relation edge, the preceding directed relation edge is marked as a replacement constraint. When a subsequent directed relation edge only covers a portion of the bounded object of a preceding directed relation edge, the covered portion is split into alternative constraints and the uncovered portion is retained as a valid constraint; When the source file corresponding to the directed relation edge is revoked, the directed relation edge is marked as an invalid constraint.

[0012] Preferably, the candidate connection path is written into the design and production semantic constraint graph after consistency verification, including: obtaining the process condition entity, quality judgment entity and abnormal cause entity connected to the candidate connection path; Check whether the processing sequence corresponding to the process condition entity is consistent with the time sequence of the production parameter records; Check whether the inspection items corresponding to the quality judgment entity cover the item identifier of the quality inspection result; Check whether the entity representing the cause of the anomaly matches a semantic fragment in the rework record or scrap reason; When the above check results are met simultaneously, production data relationship edges are generated and written into the design production semantic constraint graph.

[0013] Preferably, the step of semantically parsing the requirements of the parts to be optimized and propagating constraints in the design and production semantic constraint graph to generate a feasible domain for production design includes: parsing the requirements of the parts to be optimized into a target design intent entity, a target structural feature entity, and a target quality judgment entity; Retrieve starting nodes in the design and production semantic constraint graph that match the target design intent entity, the target structural feature entity, and the target quality judgment entity; Expand the candidate parameter set along the constraint, dependency, and modification relationships; Delete candidate parameter combinations along conflict relationships and failure constraint identifiers; The set of retained candidate parameters is written into the production design feasibility domain.

[0014] Preferably, the expansion of the candidate parameter set along the constraint relationship, dependency relationship, and modification relationship includes: establishing a constraint propagation queue with the starting node as the root node; Read the directed relation edges in the order from the design intent entity to the structural feature entity, from the structural feature entity to the process condition entity, and from the process condition entity to the quality judgment entity. When reading the aforementioned constraint relationship, the corresponding dimensional tolerances, material processing methods, and inspection items are written into the candidate parameter set; When reading the dependencies, the interrelated processing steps and parameters of the preceding and following steps are written together into the candidate parameter set; When reading the modified relationship, the process conditions marked as alternative constraints in the version chain are replaced with the modified process conditions.

[0015] Preferably, the step of deleting candidate parameter combinations along conflict relationships and failure constraint identifiers includes: reading the structural feature entity, process condition entity, and quality judgment entity corresponding to each parameter combination in the candidate parameter set; Retrieve conflict relationship edges in the design and production semantic constraint graph that are connected to the structural feature entity, the process condition entity, or the quality judgment entity; When any combination of parameters simultaneously hits the entities at both ends of the conflicting relationship edge, delete the corresponding combination of parameters; When any parameter combination depends on a directed relation edge that has a failure constraint flag, delete the corresponding parameter combination. Write the remaining parameter combinations into the production design feasibility domain according to the design version identifier and the applicable component family identifier.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. By semantically understanding component design documents, process routes, inspection rules, quality anomaly records, production parameter records, and design change records, entities representing design intent, structural features, process conditions, quality judgments, and anomaly causes are extracted. Based on constraint relationships, dependencies, conflicts, causal relationships, and correction relationships, a design-production semantic constraint graph is constructed. This unifies production design constraints, originally scattered across text and structured data, into a single data organization space. After production parameter records and quality inspection results are linked to their corresponding semantic entities, historical parameters are no longer isolated values ​​but are associated with their source processes, applicable component families, quality judgments, and anomaly causes. After semantic parsing, the requirements for components to be optimized are propagated within the design-production semantic constraint graph. This expands the candidate parameter set along constraint relationships, dependencies, and correction relationships, and removes parameter combinations that do not meet semantic constraints along conflict relationships and failure constraint identifiers. The resulting feasible production design domain is simultaneously constrained by design semantics, process semantics, and quality semantics, resolving issues of sample misuse and semantic constraint omissions caused by field similarity.

[0017] 2. Beyond the aforementioned key technical effects, by establishing semantic segments based on component families, design versions, and data sources, and merging entities with the same technical meaning but different textual expressions into standardized semantic entities, redundant constraints and scattered retrieval caused by synonymous expressions can be reduced. Distinguishing entities with similar text but different constraint content through entity context signatures can reduce the probability of erroneous merging. By writing source file identifiers, design version identifiers, applicable component family identifiers, and constraint status identifiers to directed relation edges, and distinguishing between valid constraints, alternative constraints, and invalid constraints based on version chains, old constraints that have been overridden or revoked by subsequent design changes can be prevented from continuing to participate in parameter generation. By establishing structured data mapping keys through component codes, process identifiers, inspection item identifiers, and design version identifiers, and combining adjacent process semantics, inspection item semantics, and anomaly cause semantics to verify candidate attachment paths, the associated positions of production parameters, inspection results, rework records, and scrap causes in the graph can be made more stable, facilitating subsequent production design data traceability. Attached Figure Description

[0018] Figure 1 This is an overall flowchart of the semantic understanding-based big data optimization production design method for parts according to the present invention. Figure 2 This is a flowchart illustrating the semantic segmentation, entity annotation, and standardized semantic entity generation process of this invention. Figure 3 A flowchart for semantic constraint graph construction and version status maintenance is designed for this invention. Figure 4 This is a flowchart illustrating the production data connection, constraint propagation, and production design feasible domain generation process of this invention. Detailed Implementation

[0019] In one embodiment, reference Figure 1A method for optimizing production design of components based on semantic understanding big data includes: acquiring component design documents, process routes, inspection rules, quality anomaly records, production parameter records, and design change records; performing semantic understanding on the design documents, process routes, inspection rules, quality anomaly records, and design change records to extract design intent entities, structural feature entities, process condition entities, quality judgment entities, and anomaly cause entities; constructing a design-production semantic constraint graph based on constraint relationships, dependency relationships, conflict relationships, causal relationships, and correction relationships; linking the production parameter records and quality inspection results to the design-production semantic constraint graph; performing semantic parsing on the requirements of the components to be optimized and propagating constraints in the design-production semantic constraint graph to generate a feasible production design domain; generating component production design data within the feasible production design domain. Specifically, the component design documents include component name, design purpose, functional boundaries, key dimensions, tolerance limits, material limits, and assembly parameters. The data includes textual or semi-structured content such as constraints. The process route includes process name, process sequence, processing conditions, processing method, and process remarks. The inspection rules include inspection items, judgment basis, acceptable range, and non-conformance judgment statements. The quality anomaly record includes anomaly phenomenon, anomaly cause, rework disposal, and scrap reason. The production parameter record includes parameter items, parameter values, process identifier, batch identifier, and component family identifier from the historical processing. The design change record includes pre-change constraints, post-change constraints, version identifier, and applicable scope. This embodiment converts the above data into a semantic processing object containing data source, component family, design version, and statement position through a unified data access format. Then, it uses semantic understanding methods to identify expressions corresponding to the same technical meaning in different files, avoiding rough matching based solely on field names or text keywords. This embodiment can incorporate scattered design constraints, process constraints, and quality constraints into the same computable semantic space, providing a complete data foundation for the subsequent generation of the production design feasible domain.

[0020] In this embodiment, when performing semantic understanding on the design documents, process routes, inspection rules, quality anomaly records, and design change records, a parsing record containing lexical sequences, field sources, paragraph positions, and association numbers is first established for each text. Then, a combination of domain dictionary matching and contextual dependency analysis is used to identify design intent entities, structural feature entities, process condition entities, quality judgment entities, and anomaly cause entities. Among them, design intent entities are used to characterize the load-bearing function, assembly purpose, or working boundary of components, and structural feature entities are used to characterize design objects such as holes, slots, surfaces, steps, threads, mating surfaces, datum surfaces, and dimensional chain nodes. The process condition entity is used to characterize the processing steps, heat treatment methods, surface treatment methods, processing sequence, and process control conditions. The quality judgment entity is used to characterize the inspection items, judgment rules, acceptance range, and quality grade. The abnormal cause entity is used to characterize the sources of quality problems such as dimensional deviation, surface defects, assembly interference, material processing abnormalities, and process deviations. During the semantic understanding process, negative words, limiting words, conditional words, and version words are independently labeled and limited connections are established with the entities to prevent the identification of "not allowed to use a certain process" and "using a certain process" as the same process condition. This embodiment can transform the constraint meaning in the natural language description into entities and relationships that can participate in graph reasoning.

[0021] In this embodiment, when constructing a design-production semantic constraint graph based on constraint relationships, dependency relationships, conflict relationships, causal relationships, and modification relationships, the extracted entities are used as graph nodes, and the technical relationships explicitly stated in the file or determined by the context are used as directed relationship edges. Constraint relationships are used to represent the constraints of a design intent on structural features, tolerance ranges, material handling, or inspection conditions. Dependency relationships are used to represent that a certain process condition must be established on the previous process, previous structural feature, or previous inspection item. Conflict relationships are used to represent that two parameter combinations or two process conditions cannot be applied simultaneously. Causal relationships are used to represent the association between a structural feature, process condition, or parameter state and the cause of quality anomalies. Modification relationships are used to represent that old constraints in the design change record are replaced or partially covered by new constraints. Each relationship edge in the design-production semantic constraint graph is configured with a source file, version identifier, component family, applicable state, and evidence fragment. After the graph is constructed, the constraint propagation path is limited by the direction of the relationship edges, so that the requirements of the component to be optimized can only be extended along the relationships consistent with the current design intent, structural features, and quality judgment. This embodiment can transform constraints that were originally scattered in different data sources into a traceable, verifiable, and propagable data structure.

[0022] ; in, The constraint confidence weight represents the strength of a semantic relation in production design reasoning. Indicates the credibility of the source document. Indicates the degree of design version matching. This indicates the consistency of the corresponding quality results. Indicates contextual consistency. , , , This represents the weight coefficients of each item, and their sum is 1. For example, when a process's disabled constraint originates from the official process route, the design version is consistent with the requirement to be optimized, historical anomaly records repeatedly point to the same anomaly cause, and the context contains explicit negative constraints, this is considered a disabled constraint. , , , All values ​​are taken as higher. As the constraint propagation process improves, candidate parameter combinations that conflict with the edge of the relation are preferentially eliminated; when a relation originates only from the old version of the comments and does not correspond consistently with the quality results, and Take the lower value. As the constraint on the candidate parameter set decreases, the constraint strength also decreases.

[0023] In this embodiment, when the production parameter records and quality inspection results are linked to the design-production semantic constraint graph, the component codes, process identifiers, inspection item identifiers, and design version identifiers in the production parameter records are combined into a structured mapping key. The mapping key is matched with the process condition entities, quality judgment entities, and abnormal cause entities in the graph. If the structured mapping key is complete and consistent with the graph node identifier, the corresponding parameter value, inspection value, final inspection judgment result, rework record, and scrap reason are directly written into the attribute set of the graph node or relation edge. If the mapping key is missing, has a conflicting name, or is inconsistent in version, candidate linking paths are generated based on the semantics of adjacent processes, inspection items, and abnormal causes. The process sequence relationship, inspection item coverage relationship, and abnormal cause matching relationship in the candidate linking paths are checked. Only candidate linking paths that pass the consistency check are written into the graph. The linked production parameters no longer exist in isolation but are associated with the design intent, structural features, process conditions, and quality judgment. This embodiment can reduce the mislinking of historical production data caused by missing fields or inconsistent naming.

[0024] In this embodiment, when performing semantic parsing on the requirements for the parts to be optimized, the functional description, structural description, material description, inspection description, and version description in the requirements to be optimized are parsed into target design intent entities, target structural feature entities, target process constraint entities, and target quality judgment entities, respectively. Starting nodes matching the target entities are retrieved in the design-production semantic constraint graph. During the matching process, text meaning, entity context, part families, and design versions are considered simultaneously to avoid selecting incorrect starting nodes simply because of similar names. After determining the starting node, candidate process conditions, candidate processing parameters, candidate inspection items, and candidate quality boundaries are read along constraint relationships, dependency relationships, and correction relationships. Candidate parameter combinations that cannot be simultaneously satisfied are then deleted along conflict relationships, failure constraint identifiers, and abnormal reasons. The retained parameter combinations constitute the production design feasible domain. The production design feasible domain is jointly defined by part families, design versions, structural features, process paths, quality judgments, and parameter ranges. This embodiment enables the production design data generation process to be controlled by semantic constraints, reducing the probability of data with similar fields but different constraints entering the design results.

[0025] In a preferred embodiment, reference Figure 2 Semantic segments are established according to component families, design versions, and data sources. For each semantic segment, the functional description, dimensional tolerance description, material handling description, processing procedure description, and defect description are labeled with entity types. Entities with the same technical meaning but different textual expressions are merged into standardized semantic entities. Semantic relationship identifiers are configured for standardized semantic entities with hierarchical, parallel, substitution, and exclusionary relationships. Based on these semantic relationship identifiers, an entity set is formed to construct the design and production semantic constraint graph. In specific implementation, semantic segments are not divided by fixed text length, but rather by component families, version numbers, document sources, process segments, and inspection... The verification segment generates data fragments at the boundary, enabling entities within the same semantic segment to share a common production design context. When annotating entity types, basic nouns are identified through a domain dictionary, the constraint relationship between qualifiers and entities is determined through dependency syntax, and the semantics of entities belonging to the design, process, or quality end are determined through document source. This embodiment also performs technical meaning comparison on entities that may have synonyms or near-synonyms, such as reference holes, positioning holes, and assembly holes, and distinguishes entities with similar texts but different defect mechanisms, such as surface scratches and surface pressure marks. This embodiment can provide a stable semantic foundation for graph nodes and reduce the impact of synonym splitting and heteronymous merging on subsequent reasoning.

[0026] Furthermore, in the aforementioned semantic segmentation, a layered annotation mechanism is adopted for entity annotation of functional description, dimensional tolerance description, material processing description, machining process description, and defect description. The bottom layer annotates the entity name, the middle layer annotates the qualifiers and semantic roles, and the top layer annotates the constraint type and applicable scope of the entity. For example, the load-bearing positioning seal in the functional description is annotated as the functional role of the design intent entity; the roundness, coaxiality, and flatness in the dimensional tolerance description are annotated as the cross-limitation of the structural feature entity and the quality judgment entity; the inspection after rough machining, heat treatment, and surface treatment before processing in the machining process description is annotated as the sequential dependency between process condition entities; and the deformation after heat treatment that still exceeds the tolerance after rework in the defect description is annotated as the causal relationship between the abnormal cause entity and the process condition entity. After annotation, local consistency checks are performed on entities within the same semantic segment, and similar entities appearing across segments are globally merged or retained. This embodiment can retain the context information required for constraint generation during the entity extraction stage.

[0027] ; in, This represents the semantic merging judgment value between entity i and entity j, indicating the degree of confidence that the two entities are merged into the same canonical semantic entity. and Let i and j represent the values ​​of entity i and entity j in the k-th semantic dimension, respectively, and n represent the number of semantic dimensions. This represents the context constraint consistency coefficient; for example, when the positioning datum hole and the assembly positioning hole have similar values ​​in terms of functional role, structural object, adjacent process, and inspection item, and the context all points to the same assembly datum, Take the higher value. If the merging conditions are met, the two entities are merged into a canonical semantic entity; when external pressure marks and surface scratches are similar in text vectors but have different causes and rework procedures. Take the lower value. If the merging conditions are not met, the two entities are retained as entities with different canonical semantics.

[0028] In a preferred embodiment, reference Figure 3When constructing the semantic constraint graph for design and production, the design intent entity, structural feature entity, process condition entity, quality judgment entity, and anomaly cause entity are used as graph nodes. Dimension chain constraints, material adaptation constraints, processing sequence constraints, inspection judgment constraints, and anomaly repair constraints within the same component family are transformed into directed relation edges. Source file identifiers, design version identifiers, applicable component family identifiers, and constraint status identifiers are written to these directed relation edges. Based on the constraint status identifiers, valid constraints, alternative constraints, and failed constraints are distinguished. In specific implementation, dimensional chain constraints point from the structural feature entity to the associated dimension or tolerance judgment entity; material adaptation constraints point from the material processing semantics to the available process condition entity; processing sequence constraints point from the preceding process condition entity to the following process condition entity; inspection judgment constraints point from the structural feature entity or process condition entity to the quality judgment entity; and anomaly repair constraints point from the anomaly cause entity to the corrected process condition entity or inspection rule entity. The relation edge direction is used to determine the reading order of constraint propagation, and the relation edge attributes are used to determine the source and status of the constraint. This embodiment enables the graph relations to simultaneously possess technical meaning, version boundaries, and propagation direction.

[0029] In this embodiment, the generation of directed relation edges adopts an evidence fragment-driven approach. The system extracts statement fragments that can support relation generation from design documents, process routes, inspection rules, quality anomaly records, and design change records, and binds the evidence fragments to the relation edges. After the relation edges are generated, same-source verification and heterogeneous-source verification are performed. Same-source verification is used to check whether there are contradictory constraint descriptions in the same file. Heterogeneous-source verification is used to check whether the descriptions of the same constraint object by the design end, process end, and quality end are consistent. If the same structural feature requires a certain process condition in the design end, but the quality end anomaly record shows that the process condition causes a specific defect, the system does not directly delete any relation. Instead, it adds a cause relation between the process condition entity and the anomaly cause entity, and uses it as the basis for conflict analysis when generating candidate parameters. If the design change record provides subsequent corrections to the same constraint object, a correction relation is established between the old relation edge and the new relation edge. This embodiment can retain historical conflict information and allow it to participate in subsequent feasible domain screening.

[0030] In a preferred embodiment, reference Figure 4When linking production parameter records and quality inspection results to the design-production semantic constraint graph, a structured data mapping key is established based on the component code, process identifier, inspection item identifier, and design version identifier. Processing parameters, process inspection values, final inspection results, rework records, and scrap reasons are respectively bound to the corresponding process condition entity, quality judgment entity, and anomaly cause entity. When the structured data mapping key is missing or conflicting, candidate linking paths are determined based on the semantics of adjacent processes, inspection items, and anomaly causes. After consistency verification of the candidate linking paths, they are written into the design-production semantic constraint graph. In practical implementation, the structured data mapping key uses the component code to determine the basic object, the process identifier to determine the process location, the inspection item identifier to determine the quality semantic location, and the design version identifier to determine the applicable constraint range. If the production parameter record lacks the inspection item identifier, the candidate quality judgment entity is matched by the process inspection statement after the process and the item name in the quality inspection result. If the rework record lacks the process identifier, the abnormal cause entity is matched by the abnormal semantic in the rework reason and the defect semantic in the scrap reason. This embodiment can maintain the correct association between production data and semantic constraints even when the structured fields are incomplete.

[0031] In this embodiment, the consistency verification of candidate attachment paths includes process sequence verification, inspection item coverage verification, anomaly cause matching verification, and version range verification. Process sequence verification is used to determine whether the time sequence of production parameter records is consistent with the processing sequence constraints in the graph. Inspection item coverage verification is used to determine whether the item identifier in the quality inspection result is covered by the inspection item corresponding to the quality judgment entity. Anomaly cause matching verification is used to determine whether the semantic fragment in the rework record or scrap cause can form a synonym, hierarchical, or causal relationship with the anomaly cause entity. Version range verification is used to determine whether the design version to which the production parameter record belongs falls within the applicable range of the relation edge. If any verification is not satisfied, the candidate attachment path is reserved as pending verification and does not participate in the calculation of the production design feasible domain. If all verifications are satisfied, production data relation edges are generated and written into the graph. This embodiment can avoid erroneous production records from affecting the generation of candidate parameters.

[0032] Table 1 below is a table showing the correspondence between data object graph processing.

[0033] Table 1. Correspondence Table for Data Object Mapping Processing Table 1 illustrates the correspondence between different data objects in semantic understanding, graph linking, and consistency verification. All types of data objects in the table are related to constraint generation or parameter linking in the component production design process. In specific implementation, a data processing template can be established according to the correspondence in the table, or similar fields can be extended according to component families and file formats. However, the extended fields still need to be included in the design intent entity, structural feature entity, process condition entity, quality judgment entity, abnormal cause entity, or corresponding relationship edge.

[0034] In a preferred embodiment, when merging entities with the same technical meaning but different textual expressions into a standardized semantic entity, the pre-qualifier, post-constraint, associated numerical field, and adjacent process words of each entity in its semantic segment are extracted; an entity context signature is formed based on the pre-qualifier, post-constraint, associated numerical field, and adjacent process words; entities with similar text and consistent entity context signatures are merged into the same standardized semantic entity; entities with similar text but inconsistent entity context signatures are retained as different standardized semantic entities and written with an exclusion relationship identifier for subsequent constraint propagation. Specifically, the pre-qualifier includes words used to define objects, materials, locations, or applicable conditions; the post-constraint includes words used to define tolerances, processes, judgment methods, or abnormal states; the associated numerical field includes dimensions, acceptable ranges, process sequence numbers, and quality grades associated with the entity in the same sentence, paragraph, or table; and the adjacent process words include the names or processing methods of processes associated with the entity before and after it. This embodiment can introduce contextual constraints in addition to semantic similarity to avoid the erroneous merging of entities with similar text but different technical meanings.

[0035] In this embodiment, the entity context signature is composed of the entity name, entity type, set of pre-qualifying words, set of post-constraining words, set of associated numerical fields, set of adjacent process words, and document source identifier. Before merging entities, the system compares the entity types. If the entity types are different, the merging process is not initiated. If the entity types are the same, the text similarity value and the context signature consistency value are calculated. Only when both meet the merging conditions is a canonical semantic entity generated. The canonical semantic entity retains all source expressions and evidence fragments, and a traceable number is configured for the source expressions. For entities with similar text but inconsistent context signatures, the system generates an exclusion relationship identifier and records the exclusion reason, such as different qualifying objects, different process positions, different inspection items, or different reasons for abnormality. This exclusion relationship identifier serves as the basis for deleting candidate parameter combinations during constraint propagation. This embodiment can simultaneously support synonym merging and heteronym isolation.

[0036] In a preferred embodiment, when distinguishing between valid constraints, alternative constraints, and invalid constraints based on constraint status identifiers, a version chain is established for directed relation edges of the same constraint object according to the design version identifier. The limiting objects, applicable component families, process conditions, and inspection judgment contents of adjacent directed relation edges in the version chain are compared. When a subsequent directed relation edge covers all the limiting objects of a previous directed relation edge, the previous directed relation edge is marked as an alternative constraint. When a subsequent directed relation edge only covers part of the limiting objects of a previous directed relation edge, the covered part is split into alternative constraints, and the uncovered part is retained as a valid constraint. When the source file corresponding to a directed relation edge is revoked, the directed relation edge is marked as an invalid constraint. In specific implementation, the version chain uses the same structural feature, the same process condition, or the same quality judgment entity as the constraint object, arranged according to the order of design versions. The coverage relationship between subsequent relation edges and previous relation edges is determined by the inclusion relationship between the set of limiting objects and the set of applicable component families. When there is partial coverage, the relation edge is split and its respective evidence fragments are retained. This embodiment can prevent old version constraints and new version constraints from being mixed into the same feasible domain.

[0037] ; in, This represents the coverage determination value between the preceding directed relation edge 'a' and the subsequent directed relation edge 'b'. Its physical meaning is the degree to which the subsequent constraint covers the content limited by the preceding constraint. and These represent the sets of objects that define the two relation edges. and Let each of the two relation edges represent the set of applicable component families. and These represent the sets of process conditions or inspection criteria for the two relation edges, respectively. For example, when a subsequent version replaces all the process conditions and inspection criteria for a certain structural feature and applies the same part families, the intersection is close to the union. The higher value is taken, and the preceding directed relation edge is marked as a replacement constraint; when a subsequent version modifies only one process condition while retaining the others. When the value is in the middle, the system splits the directed relation edges, marking the covered part as a substitute constraint and the uncovered part as a valid constraint.

[0038] In this embodiment, after the version chain processing is completed, the constraint status identifier is written into the design-production semantic constraint graph along with the relation edges. When generating the feasible domain of production design, only valid constraints and correction relations matching the current version are allowed to participate in the forward expansion. Substitute constraints are used to trace the source of historical design and to determine whether old production parameters can be reused. Failure constraints cannot be used as the basis for generating candidate parameters. When a production parameter record can only be attached to the process condition entity corresponding to the failure constraint, the production parameter record is marked as historical reference data and does not enter the current candidate parameter set. When a production parameter record is attached to an entity covered by both substitute constraints and valid constraints, the system determines its applicable scope according to the version identifier and the applicable component family identifier. This embodiment can keep the production design data generation process consistent with the design change.

[0039] In a preferred embodiment, when writing the candidate connection path into the design-production semantic constraint graph after performing consistency verification, the process condition entity, quality judgment entity, and anomaly cause entity connected to the candidate connection path are obtained; it is checked whether the processing sequence corresponding to the process condition entity is consistent with the time sequence of the production parameter records; it is checked whether the inspection item corresponding to the quality judgment entity covers the item identifier of the quality inspection result; it is checked whether the anomaly cause entity matches the semantic fragment in the rework record or scrap reason; when the above check results are satisfied simultaneously, a production data relationship edge is generated and written into the design-production semantic constraint graph. In specific implementation, the candidate connection path starts from the production parameter record, matches the process condition entity through the process identifier, matches the quality judgment entity through the inspection item identifier or inspection semantic, and matches the anomaly cause entity through the rework record or scrap reason. The production data relationship edge records the parameter value, inspection value, judgment result, batch identifier, and data source. This embodiment enables the three types of data, namely parameters, inspection, and anomalies, to form a closed association in the graph.

[0040] In this embodiment, if a production parameter record has multiple candidate attachment paths, the system calculates the process consistency value, inspection consistency value, anomaly consistency value, and version consistency value for each path. The process consistency value is determined by the relative position of the production parameter time sequence and the process sequence in the graph. The inspection consistency value is determined by the quality inspection item identifier and the coverage of the quality judgment entity. The anomaly consistency value is determined by the semantic matching relationship between the rework record, scrap reason, and anomaly reason entity. The version consistency value is determined by the production record version and the version applicable to the relation edge. The system selects candidate attachment paths that meet all basic consistency conditions and have a higher comprehensive path value to write into the graph. For paths with similar comprehensive path values ​​that all meet the basic consistency conditions, the multi-path relationship is retained, but they are screened again based on the requirements of the parts to be optimized when the production design feasible domain is generated. This embodiment can handle common situations in historical data such as missing fields, shared inspection items for multiple processes, and inconsistent expression of anomaly records.

[0041] ; in, This represents the comprehensive path value of the candidate attachment path p, indicating the reliability of attaching production parameter records to the graph entity via the candidate path. Indicates the consistency value of the process. Indicates the consistency value. Indicates an abnormally consistent value. Indicates version consistency value. , , , This indicates the corresponding coefficient, and its sum is 1. For example, if the time sequence of a certain processing parameter is after the corresponding process and the quality inspection item covers the output of that process, the abnormal semantics in the rework record are consistent with the abnormal cause entity in the graph, and the production record version falls within the applicable version range of the relation edge, then... , , , All values ​​are taken as higher. The write conditions are met; if the item names are the same but the corresponding process order is different, then... If the value is low, the candidate mount path will not be included in the write operation.

[0042] In a preferred embodiment, when semantically parsing the requirements of the component to be optimized and propagating constraints in the design-production semantic constraint graph to generate the production design feasible domain, the requirements of the component to be optimized are parsed into a target design intent entity, a target structural feature entity, and a target quality judgment entity. Starting nodes matching the target design intent entity, the target structural feature entity, and the target quality judgment entity are retrieved in the design-production semantic constraint graph. The candidate parameter set is expanded along limiting relations, dependency relations, and modification relations. Candidate parameter combinations are deleted along conflict relations and failure constraint identifiers. The retained candidate parameter set is written into the production design feasible domain. In specific implementation, the target design intent entity determines the functional boundaries to be satisfied, the target structural feature entity determines the matching component families and structural objects, and the target quality judgment entity determines the inspection items that the candidate parameters must be associated with. The starting node retrieval uses both the standard semantic entity and the entity context signature for matching, and the constraint propagation uses the direction of the relation edges to control the expansion range. This embodiment enables the candidate parameter set to be continuously constrained by the target requirement semantics during the generation process.

[0043] In this embodiment, the candidate parameter set is composed of process conditions, processing parameter ranges, inspection items, applicable versions, component families, and anomaly restrictions. When expanding along the limiting relationship, the system reads the limitations of the design intent entity on the structural feature entity and the limitations of the structural feature entity on the quality judgment entity, and writes the corresponding dimensional tolerances, material processing methods, and inspection items into the candidate parameter set. When expanding along the dependency relationship, the system reads the sequential relationship between process condition entities and treats the parameters of the preceding and subsequent processes as the same parameter combination. When expanding along the correction relationship, the system reads the corrected process conditions and inspection judgments under the current version and replaces the old conditions marked as alternative constraints. When deleting along the conflict relationship, the system checks whether the parameter combination hits both ends of the conflict relationship edge. When deleting along the failure constraint identifier, the system checks the state of the relationship edge that the parameter combination depends on. This embodiment can ensure that the feasible domain includes both the necessary candidate space and excludes combinations that violate semantic constraints.

[0044] In a preferred embodiment, when expanding the candidate parameter set along the limiting relationship, dependency relationship, and modification relationship, a constraint propagation queue is established with the starting node as the root node; directed relationship edges are read in the order of design intent entity to structural feature entity, structural feature entity to process condition entity, and process condition entity to quality judgment entity; when reading the limiting relationship, the corresponding dimensional tolerance, material processing method, and inspection item are written into the candidate parameter set; when reading the dependency relationship, the interrelated processing steps and parameters of the preceding and following steps are written into the candidate parameter set; when reading the modification relationship, the modified process conditions are used to replace the process conditions marked as alternative constraints in the version chain. In specific implementation, each item in the constraint propagation queue includes the current node, source relationship edge, propagation depth, applicable version, and cumulative constraint weight. The system starts reading the relevant structural feature entity from the target design intent entity, then reads the process condition entity from the structural feature entity, and then reads the quality judgment entity from the process condition entity. If a modification relationship is encountered in the middle, the reading of the old process conditions corresponding to the replaced constraint is stopped. This embodiment can generate a parameter set according to the technical dependency direction of the production design.

[0045] In this embodiment, the constraint propagation queue uses a set of visited nodes and a set of visited relation edges to avoid circular propagation. When there are multiple source relation edges for the same node, the system determines the propagation order based on the design version, applicable component family, and constraint credibility weight, and retains candidate parameter combinations generated by different paths until unified screening at the conflict deletion stage. During the propagation process, a path evidence chain is established for each parameter combination. The path evidence chain includes the target requirement entity, the starting node, the directed relation edges traversed, the related production data relation edges, the source file, and the version status. When generating component production design data later, the production design data contains the corresponding parameter combination and path evidence chain, which makes it easy to identify which design constraint, process constraint, or quality constraint each parameter comes from. This embodiment enables the candidate parameter generation process to have a traceable data link.

[0046] In a preferred embodiment, when deleting candidate parameter combinations along conflict relationships and failure constraint identifiers, the system reads the structural feature entity, process condition entity, and quality judgment entity corresponding to each parameter combination in the candidate parameter set; it retrieves conflict relationship edges connected to the structural feature entity, process condition entity, or quality judgment entity in the design and production semantic constraint graph; when any parameter combination simultaneously hits the entities at both ends of a conflict relationship edge, the corresponding parameter combination is deleted; when any parameter combination depends on a directed relationship edge with a failure constraint identifier, the corresponding parameter combination is deleted; the remaining parameter combinations are written into the production design feasible domain according to the design version identifier and the applicable component family identifier. In specific implementation, conflict relationship edges can originate from process prohibition instructions, inspection rejection rules, abnormal reason records, or design change records. The system does not use equality of a single field as a deletion condition, but judges whether a conflict is hit based on the status of the entities and relationship edges connected to the parameter combination. This embodiment can transform text constraints and historical abnormal constraints into candidate parameter deletion conditions.

[0047] ; in, This represents the feasibility decision value of the candidate parameter combination r, indicating whether the candidate parameter combination can be written into the production design feasibility domain, and m represents the number of constraints associated with the candidate parameter combination. This represents the flag indicating whether the candidate parameter combination r satisfies the g-th necessary constraint; it is set to 1 if satisfied and 0 if not satisfied. This indicates whether the candidate parameter combination r matches a conflicting relationship or a failed constraint; a value of 1 indicates a match, and a value of 0 indicates a failure. This represents the version compatibility flag for candidate parameter combination r, set to 1 for compatibility and 0 for incompatibility. For example, if a parameter combination satisfies the necessary constraints corresponding to the design intent, structural features, process conditions, and quality judgment, and does not hit any conflicting relationships or failure constraints, and the current design version is also compatible, then all... Take 1, Take 0, Take 1, Set the value to 1 and write it into the feasible region; if the parameter combination depends on the old version of the failed relation edge, then Take 1, It is 0 and deleted.

[0048] In this embodiment, when the remaining parameter combinations are written into the production design feasible domain, the system establishes feasible domain partitions according to the design version identifier and the applicable component family identifier. Parameter combinations within the same feasible domain partition have consistent target design intent, structural features, and quality judgment boundaries. Version status and component family identifiers must not be mixed between different feasible domain partitions. If the component requirements to be optimized involve multiple structural features, the system generates local feasible domains for each structural feature, and then merges them into an overall feasible domain based on dimensional chain dependencies, process dependencies, and quality judgment dependencies. During merging, conflict relationship and failure constraint checks are performed again to prevent parameter combinations that are satisfied locally but conflict overall from entering the final production design data. This embodiment can ensure that the production design results of components with multiple structural features maintain overall semantic consistency.

[0049] In this embodiment, when generating component production design data within the feasible domain of production design, the system reads candidate parameter combinations that satisfy the target design intent, target structural features, and target quality judgment from the feasible domain, and forms a production design data package based on the dependency relationships between process condition entities. The production design data package includes processing conditions corresponding to structural features, process sequence relationships, parameter ranges, inspection items, version identifiers, applicable component family identifiers, and path evidence chains. During the generation process, relation edges that have been marked as invalid constraints are no longer called, production parameter records that are incompatible with the current design version are no longer referenced, and parameter combinations of entities at both ends of conflicting relation edges are no longer written into the data package. If there are multiple feasible parameter combinations for the same target requirement, the system sorts them according to constraint credibility weight, comprehensive path value, and feasibility judgment value, and retains the sorting criteria. This embodiment can output component production design data that is semantically constrained and traceable in origin.

[0050] In this embodiment, the design and production semantic constraint graph can be implemented using a graph database, a graph extension structure of a relational database, or an object-oriented data structure. The node table stores entity identifiers, entity types, standard semantic names, source expressions, component families, and version identifiers. The relation table stores relation types, starting entities, ending entities, constraint states, source files, evidence fragments, and constraint credibility weights. The production data table stores production parameter records, quality inspection results, rework records, scrap reasons, and attachment path identifiers. During queries, constraint propagation is completed through starting node retrieval, relation edge traversal, status identifier filtering, and version partition reading. The storage method is not limited to a specific database product, but the data structure needs to be able to express nodes, edges, attributes, and version states. This embodiment can reproduce the same semantic constraint processing logic in different data platforms.

[0051] In this embodiment, for cases where historical data is continuously added, the system uses an incremental update method to maintain the design and production semantic constraint graph. Newly added design files, process routes, inspection rules, quality anomaly records, production parameter records, and design change records are first parsed into entities and relationships to be added to the database. Then, they are compared with existing standardized semantic entities, entity context signatures, version chains, and production data relationship edges. If the entity to be added to the database meets the merging conditions with existing standardized semantic entities, source expressions and evidence fragments are added. If the relationship to be added to the database and the existing relationship edge point to the same entity but have different version identifiers, a version chain overwrite judgment is entered. If the candidate attachment path corresponding to the newly added production parameter record conflicts with an existing attachment path, a consistency check is entered and the check status is retained. This embodiment enables the graph to maintain a consistent constraint state as production design data is updated.

[0052] In this embodiment, the processing of historical anomaly records adopts a joint expression method of anomaly cause entities and causal relationship edges. The defect phenomena in the anomaly records are not directly equivalent to the anomaly causes, but are distinguished by semantic understanding into phenomenon description, cause description, treatment description, and judgment description. For example, larger size is considered a defect phenomenon, deformation after heat treatment is considered an anomaly cause, rework is considered a treatment semantic, and final inspection failure is considered a quality judgment semantic. In the graph, the causal relationship edge pointing from the process condition entity to the anomaly cause entity records the corresponding evidence fragment, and the correction relationship edge pointing from the anomaly cause entity to the corrected process condition entity records the constraint changes after treatment. When candidate parameters are generated, if the parameter combination triggers the causal relationship and there is no corresponding correction relationship covering it, the conflict deletion process is entered. This embodiment can transform anomaly records from text files into constraints that can participate in production design screening.

[0053] In this embodiment, the processing of inspection rules adopts a two-way verification method between quality judgment entities and structural feature entities. The dimensions, tolerances, and surface quality constraints in the design file generate a constraint relationship from the structural feature entity to the quality judgment entity. The inspection items and judgment criteria in the inspection rules generate an inspection coverage relationship from the quality judgment entity to the structural feature entity. If the requirements of the component to be optimized only provide structural features without specifying inspection items, the system can read the corresponding quality judgment entity from the structural feature entity along the constraint relationship. If the historical production data only contains inspection items without specifying structural features, the system can reverse locate the relevant structural feature entity from the quality judgment entity and complete the candidate attachment path verification. The two-way verification is still limited by the design version and the applicable component family. This embodiment can reduce the parameter attachment deviation caused by the lack of inspection fields.

[0054] In this embodiment, the processing of material processing semantics adopts the material adaptation constraint edge expression method. The material grade, heat treatment method, surface treatment method and process prohibition statement in the material description are parsed into material processing semantics. Material adaptation constraint edges or conflict relationship edges are established between the material processing semantics and the process condition entity. If the requirements of the part to be optimized contain a certain material processing limitation, only the process condition entity that is adapted to the material processing semantics is read during the constraint propagation process. If a historical production parameter record comes from different material processing semantics but has the same process name, it will not enter the candidate parameter set because the process field is the same. If the design change record changes the material processing method, the version chain will convert the raw material adaptation constraint into a replacement constraint or failure constraint. This embodiment can avoid the differences in material semantics being masked by ordinary field matching.

[0055] In this embodiment, conflicting descriptions in multiple source files are handled using a relational edge conflict merging method. If a description of a certain process condition appears in the process route, and a description of the same process condition causing a specific abnormality appears in the quality anomaly record, the system does not consider them as data errors. Instead, it establishes a conditional conflict relationship between the process condition entity, the quality judgment entity, and the anomaly cause entity. The conditional conflict relationship record applies to the component family, design version, structural features, and trigger semantics. Only when the candidate parameter combination simultaneously satisfies the trigger semantics of the conditional conflict relationship will it be deleted. If the candidate parameter combination does not involve the corresponding structural features or is not within the scope of the corresponding design version, deletion will not be triggered. This embodiment can preserve the applicable boundaries of historical process experience.

[0056] In this embodiment, the feasible domain of production design can be represented as a set of several candidate parameter combinations and their constraint evidence chains. Each candidate parameter combination includes structural feature entities, process condition entities, quality judgment entities, production data relationship edges, and version status. The boundary of the feasible domain of production design is jointly determined by the target requirement analysis results, the limiting relationships, dependency relationships, modification relationships, conflict relationships, failure constraint identifiers, and production data attachment results in the graph. Any data that fails to pass entity matching, relationship propagation, attachment consistency verification, and version adaptation verification is not written into the feasible domain. The generated production design data can be used for parameter recommendation, process path verification, and quality judgment association in the component production design process, but its essence is still data processing results rather than hardware structure modification. This embodiment can form a clear production design boundary at the software data level.

[0057] In this embodiment, a closed data logic is formed between each technical processing stage. Semantic segmentation and entity extraction provide graph nodes, relation edge construction provides constraint propagation paths, production parameters and quality inspection results provide historical production basis, version chains and constraint status identifiers provide current applicable boundaries, and the analysis of requirements to be optimized provides starting nodes and target constraints. Constraint propagation and conflict deletion generate a feasible domain for production design. Production design data generates and retains a path evidence chain within the feasible domain. Each stage revolves around semantic constraint identification and constraint feasible domain generation in component production design. This embodiment can solve the data distortion problems caused by similar fields but different semantic constraints, different textual expressions but consistent technical meanings, and old version constraints mixed into the current design task.

Claims

1. A method for optimizing production design of parts based on semantic understanding big data, characterized in that, include: Obtain component design documents, process routes, inspection rules, quality anomaly records, production parameter records, and design change records; Semantic understanding is performed on the design documents, process routes, inspection rules, quality anomaly records, and design change records to extract entities such as design intent, structural features, process conditions, quality judgment, and anomaly causes. Construct a semantic constraint graph for design and production based on limiting relationships, dependency relationships, conflict relationships, causal relationships, and modifying relationships; The production parameter records and quality inspection results are linked to the design and production semantic constraint graph. The semantic analysis of the requirements for the components to be optimized is performed and the constraints are propagated in the design and production semantic constraint graph to generate a feasible domain for production design. Component production design data is generated within the feasible domain of the production design.

2. The component big data optimization production design method based on semantic understanding according to claim 1, characterized in that, The extraction of design intent entities, structural feature entities, process condition entities, quality judgment entities, and abnormality cause entities includes: establishing semantic segments according to component families, design versions, and data sources; For each semantic segment, the functional description, dimensional tolerance description, material processing description, machining process description, and defect description are labeled with entity types. Entities with the same technical meaning but different textual expressions are merged into canonical semantic entities; Configure semantic relationship identifiers for canonical semantic entities that have hierarchical, parallel, substitution, and exclusionary relationships; Based on the semantic relationship identifiers, an entity set is formed for constructing the design and production semantic constraint graph.

3. The component big data optimization production design method based on semantic understanding according to claim 1, characterized in that, The construction of the design and production semantic constraint graph based on the limiting relationship, dependency relationship, conflict relationship, causal relationship and modification relationship includes: using the design intent entity, the structural feature entity, the process condition entity, the quality judgment entity and the abnormal cause entity as graph nodes; Transform the dimensional chain constraints, material adaptation constraints, processing sequence constraints, inspection judgment constraints, and anomaly repair constraints within the same part family into directed relation edges; Write the source file identifier, design version identifier, applicable component family identifier, and constraint status identifier for the directed relation edge; The constraint status identifier is used to distinguish between valid constraints, alternative constraints, and invalid constraints.

4. The component big data optimization production design method based on semantic understanding according to claim 1, characterized in that, The step of linking the production parameter records and quality inspection results to the design and production semantic constraint graph includes: establishing a structured data mapping key based on the component code, process identifier, inspection item identifier, and design version identifier; Bind the processing parameters, process inspection values, final inspection results, rework records and scrap reasons to the corresponding process condition entities, quality judgment entities and abnormality reason entities respectively; When the structured data mapping key is missing or conflicting, candidate attachment paths are determined based on the semantics of adjacent processes, the semantics of inspection items, and the semantics of abnormal causes. After performing consistency verification on the candidate attachment paths, they are written into the design and production semantic constraint graph.

5. The component big data optimization production design method based on semantic understanding according to claim 2, characterized in that, The process of merging entities with the same technical meaning but different textual expressions into standardized semantic entities includes: extracting the pre-qualifiers, post-constraints, associated numerical fields, and adjacent process words of each entity in its semantic segment; An entity context signature is formed based on the pre-qualifier, the post-constraint, the associated numerical field, and the adjacent process word; Merge entities with similar text and consistent entity context signatures into the same canonical semantic entity; Entities with similar text but inconsistent entity context signatures are retained as entities with different canonical semantics and written into an exclusion relation identifier for subsequent constraint propagation.

6. The component big data optimization production design method based on semantic understanding according to claim 3, characterized in that, Distinguishing between valid constraints, alternative constraints, and invalid constraints based on the constraint status identifier includes: establishing a version chain for directed relational edges of the same constraint object according to the design version identifier; Compare the limiting objects, applicable component families, process conditions, and inspection and judgment contents of adjacent directed relation edges in the version chain; When a subsequently described directed relation edge covers all the bounded objects of a preceding directed relation edge, the preceding directed relation edge is marked as a replacement constraint. When a subsequent directed relation edge only covers a portion of the bounded object of a preceding directed relation edge, the covered portion is split into alternative constraints and the uncovered portion is retained as a valid constraint; When the source file corresponding to the directed relation edge is revoked, the directed relation edge is marked as an invalid constraint.

7. The component big data optimization production design method based on semantic understanding according to claim 4, characterized in that, After performing consistency verification on the candidate connection paths, they are written into the design and production semantic constraint graph, including: obtaining the process condition entity, quality judgment entity, and abnormal cause entity connected to the candidate connection paths; Check whether the processing sequence corresponding to the process condition entity is consistent with the time sequence of the production parameter records; Check whether the inspection items corresponding to the quality judgment entity cover the item identifier of the quality inspection result; Check whether the entity representing the cause of the anomaly matches a semantic fragment in the rework record or scrap reason; When the above check results are met simultaneously, production data relationship edges are generated and written into the design production semantic constraint graph.

8. The component big data optimization production design method based on semantic understanding according to claim 6, characterized in that, The step of performing semantic parsing of the requirements for the parts to be optimized and propagating constraints in the design and production semantic constraint graph to generate a feasible domain for production design includes: parsing the requirements for the parts to be optimized into target design intent entities, target structural feature entities, and target quality judgment entities; Retrieve starting nodes in the design and production semantic constraint graph that match the target design intent entity, the target structural feature entity, and the target quality judgment entity; Expand the candidate parameter set along the constraint, dependency, and modification relationships; Delete candidate parameter combinations along conflict relationships and failure constraint identifiers; The set of retained candidate parameters is written into the production design feasibility domain.

9. The component big data optimization production design method based on semantic understanding according to claim 8, characterized in that, The expansion of the candidate parameter set along the constraint relationship, dependency relationship, and modification relationship includes: establishing a constraint propagation queue with the starting node as the root node; Read the directed relation edges in the order from the design intent entity to the structural feature entity, from the structural feature entity to the process condition entity, and from the process condition entity to the quality judgment entity. When reading the aforementioned constraint relationship, the corresponding dimensional tolerances, material processing methods, and inspection items are written into the candidate parameter set; When reading the dependencies, the interrelated processing steps and parameters of the preceding and following steps are written together into the candidate parameter set; When reading the modified relationship, the process conditions marked as alternative constraints in the version chain are replaced with the modified process conditions.

10. The component big data optimization production design method based on semantic understanding according to claim 8, characterized in that, The step of deleting candidate parameter combinations along conflict relationships and failure constraint identifiers includes: reading the structural feature entity, process condition entity, and quality judgment entity corresponding to each parameter combination in the candidate parameter set; Retrieve conflict relationship edges in the design and production semantic constraint graph that are connected to the structural feature entity, the process condition entity, or the quality judgment entity; When any combination of parameters simultaneously hits the entities at both ends of the conflicting relationship edge, delete the corresponding combination of parameters; When any parameter combination depends on a directed relation edge that has a failure constraint flag, delete the corresponding parameter combination. Write the remaining parameter combinations into the production design feasibility domain according to the design version identifier and the applicable component family identifier.

Images