Standardized module library construction and dynamic calling method and system for engineering design intelligent generation

Abstract

The invention discloses a standardized module library construction and dynamic calling method for engineering design intelligent generation, which comprises the following steps of: extracting standardized modules, storing the extracted standardized modules in a standardized module library, and creating a parameterized driving model for each standardized module; performing bidirectional association mapping on each standardized module in the standardized module library and an entity in the engineering design domain knowledge graph; receiving a parameterized instruction set, accessing the engineering design domain knowledge graph to obtain the design context of the current project, and verifying and confirming the matching and compliance of a standardized module in the parameterized instruction set and the design context based on the established association mapping; and according to the verified parameterized instruction set, driving a parameterized driving model to run, generating design contents which meet the requirements of the parameterized instruction set and meet the requirements of the current project, and carrying out combination and conflict detection on the generated design contents to form a complete design scheme section.

Description

Technical Field

[0001] This application relates to the intersection of artificial intelligence and computer-aided design technology, and in particular to a method and system for constructing and dynamically calling a standardized module library for intelligent generation of engineering designs. Background Technology

[0002] In the field of engineering design, especially in the design of complex systems such as power distribution, buildings, and technological processes, there are numerous reusable typical design schemes and modules. Currently, these design experiences exist mostly in the form of scattered drawings, documents, or CAD blocks, lacking a unified, structured, parametric management and intelligent retrieval mechanism. When undertaking new projects, designers mainly rely on manually searching, referencing, and modifying historical schemes, which is inefficient and prone to errors.

[0003] While existing technologies have proposed engineering design generation frameworks that combine knowledge graphs in the engineering design domain with Retrieval Enhanced Generation (RAG) technology, they have not yet provided an optimal implementation path for efficiently transforming scattered historical design experience into parameterized design units (standardized design modules) that can be directly executed and invoked by computers. Although various standard parts libraries or module libraries exist in existing technologies, most are merely static, non-intelligent model collections, lacking deep semantic connections with the design knowledge system. They cannot perform matching verification, adaptive generation, or conflict resolution based on design context and parameter constraints. More importantly, existing technologies lack a "parameterized driven model" that deeply encapsulates business rules and parameterized generation capabilities and semantically integrates them with the engineering design domain knowledge graph, resulting in limited intelligence and automation levels for the modules.

[0004] Furthermore, existing technologies lack an intelligent module library system that can operate independently and achieve self-verification capabilities by associating with knowledge graphs in the engineering design field. Such a system would provide plug-and-play standardized design component generation services for various design environments.

[0005] Therefore, there is an urgent need for a specialized, standardized module library construction and invocation method that can deeply parametrically encapsulate and semantically associate design experience, transforming historical design experience into "intelligent design assets" that can be directly understood, driven, combined, and verified by artificial intelligence systems. This would provide reliable and efficient core material support for the intelligent generation of higher-level engineering designs, breaking through the technical bottleneck of intelligent design in the "last mile." Summary of the Invention

[0006] The technical problem that the invention aims to solve

[0007] This application provides a method and system for constructing and dynamically calling a standardized module library for intelligent generation of engineering design. It can run independently and not only solves the technical problem of insufficient parameterized encapsulation and automated reuse of design experience in the field of engineering design, realizing the intelligent reuse of design experience, but also solves the problems of static, non-intelligent and lacking self-verification capabilities of existing module libraries.

[0008] Technical means to solve technical problems

[0009] According to one aspect of this application, a method for constructing and dynamically calling a standardized module library for intelligent generation of engineering designs is provided, wherein the method includes: a standardized module library construction step S10: based on historical engineering design results, standardized modules are extracted and stored in a standardized module library. Each standardized module is provided with a functional interface, a set of key design parameters and constraints, and is assigned a unique module identifier. Based on the set of key design parameters, a parameterized driving model is created for each standardized module. The parameterized driving model can execute logical decisions according to input parameters and drive scripts to generate or adjust the design content of the standardized module; a module-domain knowledge graph association mapping step S20: each standardized module in the standardized module library is bidirectionally associated and mapped with entities in an engineering design domain knowledge graph; and a module instruction receiving and matching verification step S3. 0: Receive a parameterized instruction set, access the engineering design domain knowledge graph to obtain the design context of the current project, wherein the parameterized instruction set contains module identifiers of one or more standardized modules to be called and input parameters corresponding to the standardized modules, and verifies and confirms the matching and compliance of the standardized modules in the parameterized instruction set with the design context based on the association mapping established in step S20; and the standardized module dynamic calling and combination step S40: According to the parameterized instruction set verified in step S30, input the parameters in the parameterized instruction set into the parameterized driving model of the standardized module specified in the parameterized instruction set, drive the parameterized driving model to run, generate design content that meets the requirements of the parameterized instruction set and satisfies the needs of the current project, and combine and detect conflicts in the generated design content to form a complete design scheme segment.

[0010] Furthermore, creating a parameterized driven model for each standardized module includes: deeply querying and utilizing the engineering design domain knowledge graph to analyze historical success cases, design specifications, and domain expert experience, and extracting the design decision logic into a logical expression including "IF-THEN" rules; transforming structured business rules into executable algorithmic flows; writing parameterized drawing, modeling, document generation, or data processing scripts for different types of design outputs, and developing scripts or program modules that can dynamically generate or adjust content based on input parameters; and integrating the rules, algorithms, and scripts into the parameterized driven model, and setting input and output interfaces for the parameterized driven model.

[0011] Furthermore, the bidirectional association mapping includes: associating the standardized module with the functional entities representing the function of the standardized module, the equipment entities constituting the standardized module, and the normative entities followed by the standardized module in the engineering design domain knowledge graph.

[0012] Furthermore, verifying and confirming the matching and compliance of the standardized modules in the parameterized instruction set with the design context includes: verifying the existence of the module identifier of the standardized module; verifying whether the input parameters meet the key design parameter set and constraints of the standardized module; and performing a semantic-based deep verification of whether the standardized module is applicable to the design context based on the key design parameter set and constraints, according to the associated entities in the engineering design domain knowledge graph through the bidirectional association mapping.

[0013] Furthermore, the conflict detection includes one or more of the following: geometric conflict detection, logical conflict detection, and specification compliance detection.

[0014] Furthermore, the method further includes: when a conflict is detected, performing one or more of the following processes: a) generating a detailed conflict report and identifying the conflict type, location, and severity; b) providing a solution to the detected conflict, the solution including a parameter adjustment scheme or a module replacement scheme; c) performing parameter optimization to eliminate the detected conflict; d) marking the detected conflict status and pausing the combination, awaiting intervention.

[0015] Furthermore, based on historical engineering design results, the standardized modules are extracted as follows: by analyzing drawings, models and documents in historical projects, design scheme units that are recurring, functionally complete and mature in design are identified and summarized; and the design scheme units are summarized and abstracted into reusable standardized modules through automated analysis tools.

[0016] Furthermore, the design content includes one or more of the following: two-dimensional drawing fragments, three-dimensional model components, equipment bill of materials, or calculation instructions.

[0017] Furthermore, the method also includes: during execution or after the design content is generated, the parameterized driving model updates the metadata of the standardized module to the corresponding entity attributes in the engineering design domain knowledge graph.

[0018] Furthermore, the method also includes storing the design context of the current project into the engineering design domain knowledge graph, wherein the design context includes project type, design stage, geographical location, environmental data, technical specifications, and applicable mandatory standards.

[0019] According to another aspect of this application, a system for constructing and dynamically calling a standardized module library for intelligent generation of engineering designs is provided. The system includes: a module builder that extracts standardized modules based on historical engineering design results. Each standardized module has a functional interface, a set of key design parameters, and constraints, and is assigned a unique module identifier. The module builder creates a parameterized driving model for each standardized module based on the set of key design parameters. The parameterized driving model can execute logical decisions based on input parameters and drive scripts to generate or adjust the design content of the standardized module. A graph association mechanism that bidirectionally maps each standardized module in the standardized module library to entities in an engineering design domain knowledge graph. A module matching engine that receives a parameterized instruction set and accesses the engineering design domain knowledge graph to obtain the current project. The design context includes: a parameterized instruction set containing module identifiers and corresponding input parameters of one or more standardized modules to be invoked; a module execution engine that, based on the association mapping established by the graph correlator, verifies and confirms the matching and compliance of the standardized modules in the parameterized instruction set with the design context; a module execution engine that, according to the parameterized instruction set verified by the module matching engine, inputs the parameters in the parameterized instruction set into the parameterized driving model of the standardized module specified in the parameterized instruction set, drives the parameterized driving model to run, generates design content that meets the requirements of the parameterized instruction set and satisfies the needs of the current project, and performs combination and conflict detection on the generated design content to form a complete design scheme segment; and a standardized module library for storing the standardized modules and parameterized driving models constructed by the module builder.

[0020] Furthermore, the system also includes a standardized service interface for receiving call requests and parameterized instruction sets from external systems.

[0021] According to another aspect of this application, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the steps of the method described above for constructing and dynamically calling a standardized module library for intelligent generation of engineering design.

[0022] According to another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method for constructing and dynamically invoking a standardized module library for intelligent generation of engineering design described above.

[0023] Beneficial effects

[0024] This application constructs a standardized module library with a parameterized driving model and deeply associates it with a knowledge graph in the field of engineering design. This enables intelligent dynamic calling and quality self-verification of modules, solving the problems of static, non-intelligent, and lacking self-verification capabilities in existing module libraries.

[0025] This application, by creating a parameterized driven model deeply integrated with business rules and generation scripts, systematically extracts and encapsulates abstract and scattered design experience into fine-grained, parameterized standardized modules that can be directly executed and invoked by computers. Furthermore, this standardized module, equipped with a parameterized driven model, possesses logical decision-making and adaptive generation capabilities, forming the "intelligent kernel" of the standardized module and realizing a leap from design knowledge "data" to "executable capability." Moreover, the standardized module with the parameterized driven model enables advanced reuse of design knowledge, thereby achieving intelligent encapsulation of design experience.

[0026] In this application, through deep bidirectional association with a knowledge graph in the engineering design domain, standardized modules are no longer isolated information silos. This association enables external systems to intelligently perceive and semantically retrieve modules, shifting from "passive search" to "proactive, precise recommendation." Furthermore, it provides a semantic foundation for deep verification, ensuring that the invoked modules are highly compatible with the current design context in terms of function, equipment, and specifications. This comprehensive knowledge collaboration significantly improves design efficiency and decision-making quality. Moreover, it achieves intelligent invocation and deep knowledge collaboration.

[0027] The standardized modules in this application are derived from mature experience, and the calling process undergoes parametric verification and automated conflict detection based on a knowledge graph in the engineering design domain, ensuring the quality and compliance of the output solution from the source. Simultaneously, through a standardized parametric instruction set interface, decoupling from external design systems is achieved, clarifying system boundaries, avoiding functional redundancy, and improving the synergy of the entire intelligent generation system, as well as the independence and reusability of the system modules. Therefore, this application ensures that the quality of intelligent engineering design generation is controllable and the interface is clear.

[0028] Providing a high-quality, structured, and executable "material library" for the intelligent generation system of upper-level engineering design is a key foundational component for its efficient and accurate generation. Through a dynamic invocation mechanism, the intelligent generation process of the system, which uses a standardized module library for intelligent engineering design generation, can be based on precise and verified standardized modules, greatly improving the reliability and usability of the generated results. By receiving a standardized parameterized instruction set, a clear and efficient interface is formed with the upper-level intelligent generation system of engineering design, further enhancing system synergy and module reusability. This application, through a comprehensive scheme of construction and dynamic invocation, realizes the intelligent reuse of design experience, providing core support for external design systems.

[0029] The system described in this application does not depend on a specific external design system. It can be deployed and run independently, or it can be flexibly integrated into various design environments, providing core support for the intelligent upgrade of traditional design software. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 This illustration schematically shows a flowchart of a method for constructing and dynamically invoking a standardized module library for intelligent generation of engineering designs according to an embodiment of this application;

[0032] Figure 2 This illustration schematically shows a working principle diagram of a parameterized driving model according to an embodiment of this application;

[0033] Figure 3 The process of creating a parameterized driven model according to an embodiment of this application is illustrated schematically;

[0034] Figure 4 A schematic diagram illustrating the bidirectional association mapping between standardized modules and knowledge graphs in the engineering design field according to embodiments of this application is shown.

[0035] Figure 5 A timing diagram illustrating the dynamic invocation and combination of standardized modules according to embodiments of this application is shown; and

[0036] Figure 6 A schematic diagram of the structure of a system for constructing and dynamically calling a standardized module library for intelligent generation of engineering design, according to an embodiment of this application, is shown. Detailed Implementation

[0037] The present application will now be described in further detail with reference to the accompanying drawings and embodiments, but these descriptions are not intended to limit the present application.

[0038] It should be clarified that the system provided in this application operates as an independent system, receiving design requests and calling instructions from various external systems (including but not limited to manual operation interfaces, traditional design software, or other intelligent generation systems) through standardized service interfaces.

[0039] In this application, "design entity" is a broad concept, referring to any core element in engineering design. Specifically, it manifests as physical equipment (such as switchgear, circuit breakers, pumps, beams and columns), logical modules (such as software function blocks and control loops), structural components, materials, processes, or service interfaces. The engineering design domain knowledge graph describes these "design entities" and the functional, parameter, and constraint relationships between them, thus forming a general framework for representing engineering knowledge.

[0040] Figure 1 The flowchart illustrating the method for constructing and dynamically invoking a standardized module library for intelligent generation of engineering designs according to an embodiment of this application is shown.

[0041] like Figure 1 As shown, the method for constructing and dynamically invoking a standardized module library for intelligent generation of engineering designs includes a standardized module library construction step S10, a module-domain knowledge graph association mapping step S20, a module instruction receiving and matching verification step S30, and a standardized module dynamic invoking and combination step S40. The following describes each step in detail according to embodiments of this application.

[0042] Standardized module library construction steps S10

[0043] In step S10, based on the historical engineering design results, standardized modules are extracted and stored in the standardized module library. Each standardized module is set with functional interfaces, key design parameter sets and constraints, and is assigned a unique module identifier. Based on the key design parameter sets, a parameterized driving model is created for each standardized module. The parameterized driving model can execute logical decisions according to the input parameters and drive the script to generate or adjust the design content of the standardized module.

[0044] According to embodiments of this application, by analyzing drawings, models, and documents from historical projects, recurring, functionally complete, and mature design scheme units are identified and summarized. These units are then summarized and abstracted into reusable templates—standardized modules—using automated analysis tools or with the assistance of domain experts. Standardized modules can be extracted through this method.

[0045] In this application, a globally unique module identifier is assigned to each standardized module. This module identifier serves as a key index for accurately locating, retrieving, and calling a specific standardized module in the standardized module library.

[0046] According to embodiments of this application, the parameterized driven model includes a set of logics integrating a business rule engine based on domain knowledge, parameterized drawing or modeling scripts, which are used to transform implicit design experience into explicit, computer-executable logic, and this process is deeply coordinated with an engineering design domain knowledge graph.

[0047] Upon receiving input parameters, the parametric-driven model's business rule engine first performs logical decisions, then drives the execution of corresponding parametric scripts, ultimately automatically generating specific design content. This design content includes, but is not limited to, one or more of the following: 2D drawing fragments, 3D model components, equipment and material lists, and calculation specifications.

[0048] Figure 3 The illustration schematically depicts the process of creating a parameterized driven model according to an embodiment of this application. For example... Figure 3 As shown, the method for creating a parameterized driven model includes the following steps: business rule extraction and structuring based on domain knowledge graph, logical algorithm design and implementation, parameterized generation script development, and model integration and encapsulation.

[0049] The steps for extracting and structuring business rules based on domain knowledge graphs are as follows: Through in-depth querying and utilization of the engineering design domain knowledge graph using tools such as automated analysis, historical successful cases, design specifications, and domain expert experience are analyzed to extract the design decision logic into explicit logical expressions including "IF-THEN" rules. The specification entities, equipment entities, and their attributes in the engineering design domain knowledge graph provide authoritative evidence for the correctness and completeness of the rules.

[0050] The logical algorithm design and implementation steps involve transforming structured business rules into an executable algorithm flow, including parameter validation, logical branch judgment, and intermediate result calculation. During this process, the algorithm design considers future dynamic interactions with the knowledge graph of the engineering design domain, such as reserving interfaces for real-time querying of the latest constraints or updating entity states in the graph during model execution.

[0051] Parametric generation script development steps: For different types of design output (such as graphics, 3D models, text, and data), write parametric drawing, modeling, document generation, or data processing scripts, and develop scripts or program modules that can dynamically generate or adjust content based on input parameters. For example: for the output of graphics / 2D drawings, drawing scripts based on CAD platforms (such as AutoCAD) can be developed; for the output of 3D models, parametric modeling scripts based on BIM platforms (such as Revit) can be developed; for the output of text content, document generation scripts based on template engines or natural language generation technology can be developed; for the output of data / lists, data processing scripts based on general programming languages ​​(such as Python) can be developed.

[0052] The development of all scripts must strictly adhere to the business rules, drafting specifications, and documentation standards defined in the engineering design domain knowledge graph to ensure the technical compliance of the output content.

[0053] Model integration and encapsulation steps: Integrate the above rules, algorithms and scripts into a unified software unit that can be called and executed by the system (i.e., parameterized driven model), and set input and output interfaces for it.

[0054] The methods for refining standardized modules and creating parameterized driven models are flexible, allowing for both automated implementation using analysis tools and experience-based assistance from domain experts. Automated analysis tools can automatically identify design patterns, extract business rules, establish parameter relationships, and generate executable code from historical engineering design outcomes. These tools include, but are not limited to, design pattern recognition tools, business rule extraction tools, parameter relationship modeling tools, and code generation tools. The application of these tools significantly improves the efficiency, standardization, and traceability of refining standardized modules and creating parameterized driven models.

[0055] It should be noted that this application aims to provide a complete technical solution. The auxiliary participation of the aforementioned "domain experts" is only reflected in the initial construction or subsequent optimization stages of the standard module library, and its purpose is to verify and improve the quality of the results produced by the automated tools. In this application, after the standardized module library is constructed, the association mapping, instruction verification, dynamic invocation, and combination processes in steps S20 to S40 are fully automated and do not rely on any human intervention. The aforementioned automated analysis tools demonstrate that the entire process from construction to invocation can be intelligently completed by the computer system.

[0056] Figure 2 The schematic diagram illustrates the working principle of the parameterized driving model according to an embodiment of this application. For example... Figure 2As shown, the parameterized driven model can make logical decisions based on the input parameters (such as In, Ics, W) and the business rule engine of the internal logic of the parameterized driven model. For example, it can make logical decisions based on predefined logic (such as the "IF-THEN" rule), and execute rules and logical judgments through algorithms / logic judgments, thereby driving the execution of the corresponding parameterized generation scripts, and finally automatically generating or adjusting the specific design content of the standardized module.

[0057] Module-Domain Knowledge Graph Association Mapping Step S20

[0058] In step S20, each standardized module in the standardized module library constructed in step S10 is bidirectionally associated and mapped with entities in the knowledge graph of the engineering design domain.

[0059] Figure 4 A schematic diagram illustrating the bidirectional association mapping between standardized modules and a knowledge graph in the engineering design domain, according to an embodiment of this application, is shown. Figure 4 As shown, the above bidirectional association mapping includes: associating the standardized module with the functional entities representing the module's function in the knowledge graph of the engineering design domain, associating it with the equipment entities constituting the module, and associating it with the normative entities followed by the module.

[0060] The deep integration and association mapping established as described above provides a semantic basis for the intelligent positioning of standardized modules in the knowledge graph of engineering design and for deep contextual verification in step S30, which will be described later, through rich semantic associations (such as "module instantiated in", "module contains device", "module meets specification"), rather than simple keyword matching.

[0061] The "design context" mentioned in this application refers to the background information of the current design project obtained by accessing the engineering design domain knowledge graph, which includes, but is not limited to, project type, design stage, geographical location, environmental data, technical specifications, and applicable mandatory standards. The "design context," as the background environment for verification, is primarily stored in the engineering design domain knowledge graph and dynamically maintained.

[0062] When retrieving and calling standardized modules in an external design system, the rich semantic relationships established in step S20 can be used to understand and reason from multiple dimensions such as design intent, functional logic, equipment attributes and specification constraints, so as to accurately retrieve and recommend the module most suitable for the current design context.

[0063] In the module matching verification process of this application, upon receiving an instruction containing a module identifier, the system utilizes the rich semantic relationships established in step S20 to perform in-depth and comprehensive compliance and design context matching verification on the specified standardized module. This ensures that the invoked standardized module is highly compatible with the current design requirements in terms of functionality, equipment, and specifications.

[0064] As mentioned above, this application differs fundamentally from traditional retrieval methods that rely solely on keyword matching in module names or descriptions. It achieves a leap from "string matching" to "concept and logic matching," demonstrating the semantic understanding advantages based on knowledge graphs in the engineering design field.

[0065] Furthermore, this deeply integrated associative mapping enables entities in the engineering design domain's knowledge graph to "perceive" the specific modules that can instantiate them, while modules can also "understand" their semantic position within a larger knowledge system. This lays a solid foundation for subsequent semantic-based intelligent retrieval of external design systems and semantic-based deep verification in step S30, which will be described later.

[0066] The "semantic-based intelligent retrieval" described in this application is fundamentally based on leveraging the semantic understanding and reasoning capabilities of knowledge graphs in the engineering design domain, which is entirely different from traditional retrieval methods based on keyword matching or general text vector similarity. Specifically, its "semantics" originates from explicitly defined entities, attributes, and the rich semantic relationships between them (such as a network composed of "function-equipment-specification") within the engineering design domain knowledge graph. This retrieval process includes, but is not limited to, one or more of the following levels:

[0067] (1) Functional semantic understanding: The natural language description in user requirements is mapped to a well-defined functional entity in the knowledge graph of engineering design (such as mapping “outgoing line cabinet” to “outgoing line protection” function), thereby achieving accurate matching at the conceptual level rather than superficial text matching.

[0068] (2) Parameter semantic constraints: The design parameters (such as values ​​and ranges) are understood as the screening conditions for entity attributes in the knowledge graph of the engineering design field (such as "short circuit current 25kA" means screening equipment entities with "short circuit breaking current" attribute ≥ 25kA) and logical verification is performed.

[0069] (3) Relationship path reasoning: By traversing multiple relationship paths between entities in the knowledge graph of engineering design, we can discover implicit and deep semantic connections (for example, by reasoning the “Class II lightning protection” function required by the “chemical warehouse” through the path of “engineering type → special requirements → measures to be taken → functional entity”).

[0070] Using the methods described above, the semantic retrieval implemented by the module matching and verification process of the external design system or this system can accurately understand the semantic connotation of the design intent, ensure that the retrieval results are highly relevant to the engineering logic, and lay a solid foundation for subsequent intelligent generation.

[0071] Module instruction reception and matching verification step S30

[0072] In step S30, a parameterized instruction set is received, and an engineering design domain knowledge graph is accessed to obtain a design context. The parameterized instruction set contains module identifiers of one or more standardized modules to be invoked and their corresponding input parameters. Based on the association mapping established in step S20, the matching and compliance of the standardized modules in the parameterized instruction set with the obtained design context are verified and confirmed.

[0073] Parametric instruction sets can be generated by external design systems. Verifying and confirming the compatibility and compliance of standardized modules within the parametric instruction set with the design context can include: verifying the existence of module identifiers; verifying whether input parameters meet the key design parameter set and constraints defined by the standardized module; and performing a semantic-based deep verification of the standardized module's applicability to the current design context based on the complete key design parameter set and constraints, using bidirectional mapping of associated entities in the engineering design domain knowledge graph. Through the association between standardized modules and the engineering design domain knowledge graph, relevant specifications and equipment parameters can be obtained, thereby verifying the module's suitability for the current design context.

[0074] This step verifies and confirms the compatibility and compliance of the standardized modules in the parameterized instruction set with the design context. This ensures that the called standardized modules and their parameterized execution processes conform to the rules and constraints defined in the knowledge graph of the engineering design domain, thus guaranteeing the quality and compliance of the generated content from the source.

[0075] It should be noted that the matching and verification process in step S30 aims to establish an independent and reliable self-verification mechanism for this system. By forcibly verifying all calling instructions using the authoritative knowledge source of the engineering design domain knowledge graph, this system can: ensure the quality of generated content from the source without relying on external systems; ensure that design instructions from different external systems conform to unified latest standards and specifications, maintaining the consistency of design results; and act as a highly autonomous intelligent service, providing "plug-and-play" reliability guarantees to external systems, thereby achieving decoupling and specialized division of labor between systems. This design is a key feature that distinguishes this system from ordinary module libraries or simple script executors. This verification mechanism realizes a fundamental shift from passive execution that "depends on the correctness of external systems" to proactive assurance that "the system itself has the right to veto quality," thus ensuring the reliability of the output results at the architectural level.

[0076] The effective execution of the method described in this invention relies on the maintenance of the "design context" information of the current project in the engineering design domain knowledge graph, such as project type, design stage, geographical location, environmental data, technical specifications, and applicable mandatory standards. This information should be synchronized to the engineering design domain knowledge graph by the external system during project creation and management. The advantage of this design is that it establishes an authoritative verification benchmark independent of instantaneous instructions. Even if the project information changes after the upstream system generates instructions (e.g., applicable mandatory standards are updated), as long as the domain knowledge graph is updated in a timely manner, this system can detect this change in step S30 by querying the domain knowledge graph and determine that the previously issued instructions are no longer applicable. This prevents the generation of designs that do not conform to the latest context from the source, ensuring the timeliness and compliance of the design. Therefore, ensuring the completeness and real-time nature of the "design context" in the engineering design domain knowledge graph is the preferred method to maximize the benefits of this invention.

[0077] Standardized module dynamic calling and combination steps S40

[0078] In this step, based on the parameterized instruction set verified in step S30, the parameters in the parameterized instruction set are input into the parameterized driving model of the standardized module specified in the parameterized instruction set, driving the parameterized driving model to run, generating design content that meets the requirements of the parameterized instruction set, and combining and conflict-detecting the generated design content to form a complete design scheme segment.

[0079] Figure 5 The module dynamic calling and combination timing diagram provided in this application shows the complete workflow and detailed timing interaction process between system components from the input parameters to the final output design scheme segment, highlighting the interaction sequence of module calling, content generation and conflict detection.

[0080] The following will refer to Figure 5 Please provide a detailed explanation.

[0081] (a) Model invocation: Based on the module identifier verified in step S30, locate and invoke the corresponding parameterized driving model from the standardized module library, and pass the verified project parameters to the parameterized driving model.

[0082] (b) Rule and script execution: The parameterized driving model runs its embedded business rule engine and parameterized generation script to start generating instantiated design content.

[0083] (c) Updating the Engineering Design Domain Knowledge Graph: During execution or after generating design content, the parametric-driven model can send information to the engineering design domain knowledge graph to update the status or attributes of relevant entities (e.g., marking the selected equipment entity status as "adopted" or recording the generated design parameters). The metadata of the standardized module (including functional interfaces, key parameter sets, and constraints) is synchronously updated to the corresponding entity attributes in the engineering design domain knowledge graph. The mapping relationship is as follows: the functional interface information of the standardized module is updated to the attributes of the relevant functional entities in the engineering design domain knowledge graph; the key design parameter sets of the standardized module are updated to the attributes of the relevant equipment entities; and the constraints of the standardized module are updated to the attributes of the relevant specification entities. This step enables "bidirectional association" and dynamic collaboration between the module and the engineering design domain knowledge graph.

[0084] (d) Confirmation of update: After the knowledge graph in the engineering design domain completes the update of attributes or status, it returns a confirmation signal to the parameterized driving model.

[0085] (e) Return results: The parameterized driven model returns the specific design content (such as equipment list, drawing data, model files, etc.) generated during the run to the module execution engine used to execute step S40.

[0086] (f) Combination and Conflict Detection: The module execution engine automatically combines the design content returned by multiple standardized modules and performs conflict detection. When a conflict is detected, the system executes one or more of the following processing flows:

[0087] a) Generate detailed conflict reports, including but not limited to identifying the type, location, and severity of the conflict;

[0088] b) Provide conflict resolution suggestions, including but not limited to parameter adjustment schemes or module replacement schemes;

[0089] c) Optimize parameters to eliminate detected conflicts;

[0090] d) Mark the detected conflict state and pause the above combination process, waiting for user intervention.

[0091] (g) Output scheme: The system outputs a complete design scheme segment that has undergone combination and conflict detection, thus completing this dynamic call.

[0092] Through the aforementioned sequence of steps, this application, based on successful verification in S30, achieves precise execution and knowledge feedback of standardized modules through steps (a)-(e), and ensures the quality of the final integrated solution through steps (f)-(g). This "execution as feedback" mechanism enables the continuous evolution of the knowledge graph in the engineering design field, providing a dynamically updated, high-quality knowledge base for subsequent design iterations and conflict detection. The method described in this application is significantly different from the static module library calling method.

[0093] The conflict detection in this application not only identifies problems, but more importantly, provides complete solutions. According to embodiments of this application, the aforementioned conflicts can be categorized as follows: for example, severe conflicts, which violate mandatory specifications or cause the system to malfunction and must be resolved; warning conflicts, which indicate violations of recommended specifications or provide performance optimization suggestions and can be ignored; and informational conflicts, which remind designers of design consistency for their reference.

[0094] The system can handle conflicts through automatic repair, suggested repair, forced intervention, and learning from past experiences. For simple conflicts that can be resolved by parameter adjustments, the system automatically attempts to optimize the solution, thus achieving automatic repair. The system can also provide multiple feasible solutions for users to choose from based on conflict classification and severity. For severe conflicts, the system will intervene, for example, by pausing the process and requiring user confirmation. The system records all conflicts and solutions for optimizing subsequent designs.

[0095] According to another embodiment of this application, a system for constructing and dynamically calling a standardized module library for intelligent generation of engineering designs is provided. Figure 6 A schematic diagram of the structure of a system for constructing and dynamically calling a standardized module library for intelligent generation of engineering design, according to an embodiment of this application, is shown.

[0096] like Figure 6 As shown, the system includes: a module builder for performing step S10, a graph correlator for performing step S20, a module matching engine for performing step S30, a module execution engine for performing step S40, and a standardized module library for all standardized design modules and their parameterized driving models.

[0097] The module builder provides a graphical interface for users to build standardized modules and their parameterized driving logic. It can define modules and assist in the digitization of business rules, the design of logical algorithms, and the development of generated scripts in the parameterized driving model.

[0098] The graph correlator is used to manage the bidirectional association mapping between standardized modules and knowledge graph entities in the engineering design domain, and to maintain the bidirectional synchronization of metadata.

[0099] The module matching engine is responsible for receiving parameterized instructions, accessing the engineering design domain knowledge graph to obtain the design context of the current project, and performing matching and compliance verification based on the association mapping with the engineering design domain knowledge graph.

[0100] The module execution engine is responsible for driving the parametric model to run, combining results, and detecting conflicts.

[0101] According to embodiments of this application, the system further includes a standardized service interface for receiving call requests and parameterized instruction sets from external systems. Through this standardized service interface, various external design systems can call the system according to this application. External design systems include, but are not limited to, intelligent generation systems, traditional CAD software, and project management platforms. This system receives design requests and parameterized instructions from external systems, completes module matching, verification, and content generation, and returns the results to the caller.

[0102] The system based on this application can be implemented independently, and its application scenarios include, but are not limited to:

[0103] (1) As an independent design resource platform: Designers can directly query and call standardized modules through its web interface to quickly generate design components.

[0104] (2) As a plug-in for traditional design software: embed it into existing CAD / BIM and other software through API interface to enhance its intelligent module calling capability.

[0105] (3) As a design quality verification service platform: perform compliance pre-verification of design instructions from any source based on the knowledge graph of the engineering design field.

[0106] The following will describe in detail, through embodiments in different fields, the method and system for constructing and dynamically calling a standardized module library for intelligent generation of engineering design according to this application.

[0107] The method described in this application has broad applicability and typically works in conjunction with a knowledge graph in the engineering design domain constructed by an intelligent engineering design generation system. The following example of substation design illustrates the method according to this application.

[0108] Assume there exists an externally constructed knowledge graph for the engineering design domain, containing entities such as substation equipment, functions, and specifications, along with their relationships. This embodiment primarily demonstrates how to build a standardized module library based on this graph and how to call upon it.

[0109] The following combination Figure 1 Taking the invocation of the switchgear module in the intelligent design of a substation as an example (hereinafter referred to as the first embodiment), each step is explained in detail.

[0110] Based on historical engineering design results, a mature "10kV outgoing line cabinet solution" from a historical project is extracted into a standardized design module M-FEED-01 using automated analysis tools. The extraction results can be reviewed by domain experts, and a module identifier is ultimately assigned. For example... Figure 2 As shown, based on the working principle of the parameterized driven model, the following definitions are made:

[0111] Functional interfaces: outgoing line protection, metering.

[0112] Key design parameters: rated current (In), short-circuit breaking current (Ics), cabinet width (W).

[0113] According to the method of this application, a parameterized driving model is created through steps (1)-(4).

[0114] (1) Extract and structure business rules based on knowledge graphs in the field of engineering design.

[0115] Clustering algorithms can be used to analyze historical substation design schemes, automatically identifying common outgoing switch configuration patterns, and extracting equipment selection rules based on association rule mining technology. By analyzing dozens of historical design schemes and equipment selection manuals, and deeply querying the knowledge graph of engineering design fields for equipment entities (such as various circuit breakers and transformers) and their attributes (rated parameters, breaking capacity), and standard entities (such as GB50060) and their clauses, key business rules can be summarized, such as: "IF Ics > 25kA THEN Recommended circuit breaker model = VD4-12 / 1250-31.5"; "IF 630A ≤ In ≤ 1250A THEN Recommended busbar specification is TMY-60x10".

[0116] (2) Design and implement the logical algorithm.

[0117] The above rules are encoded into algorithmic logic. This algorithm takes In and Ics as input, determines the circuit breaker model based on the Ics value through conditional judgment, and determines the busbar specifications based on the In value. Based on the determined circuit breaker model and the number of instrument transformers (which can be derived from rules or obtained through input), the cabinet width W is dynamically calculated using an internally integrated cabinet layout algorithm based on industry standards and equipment installation dimensions. This calculation process is not a simple table lookup, but a parameterized calculation logic W=f(circuit breaker model, number of instrument transformers) based on component physical dimensions and safety clearances, implemented through the following (a)-(c).

[0118] (a) Mapping the width of the device unit

[0119] The system maintains a physical dimension library associated with equipment entities in the engineering design domain knowledge graph. Based on the selected circuit breaker model (e.g., VD4-12 / 1250-31.5), its standard installation width W_cb is mapped. Based on the number of current transformers (e.g., 2 LZZBJ9-10), the standard installation width W_ct of a single current transformer is mapped, and its total width is calculated.

[0120] (b) Calculate the width of the structural unit

[0121] The cabinet structure is broken down into standard units such as the width of the circuit breaker compartment and the width of the instrument transformer compartment. The width of each unit is composed of the width of the equipment it houses, plus a fixed mounting plate thickness, wiring space, and safety clearances. For example, the width of the instrument transformer compartment W_ct_bay = n*W_ct + (n-1)*Δ_spacing + 2*Δ_margin, where n is the number of instrument transformers, Δ_spacing is the minimum spacing between instrument transformers, and Δ_margin is the edge safety margin.

[0122] (c) Total width of the composite cabinet

[0123] The total width W of the cabinet is obtained by adding up the width of all structural units, the thickness of the partitions between units, and the thickness of the cabinet frame, that is, W=Σ(width of each unit)+Σ(thickness of partition)+2*(thickness of frame column).

[0124] This computational model (i.e., the specific implementation of the function W=f(circuit breaker model, number of transformers)) is encapsulated in the business rule engine of the parameterized driving model. The key parameters on which its calculation depends (such as W_cb, W_ct, Δ_spacing, etc.) are all derived from the attributes of relevant equipment entities and specification entities in the knowledge graph of the engineering design field, thereby ensuring the standardization and compliance of the design.

[0125] In the algorithm design, an interface was reserved for "updating the device selection status" to the knowledge graph of the engineering design domain during subsequent execution.

[0126] (3) Develop parameterized generation scripts.

[0127] A series of scripts were developed, such as an equipment list generation script that automatically fills in standard table templates based on equipment models output by the algorithm; an electrical schematic generation script that automatically connects predefined wiring diagrams and symbols based on defined functional intent and component models to generate DWG format drawings; and a cabinet layout generation script that adjusts the cabinet's dimensional parameters in the 3D model based on the calculated cabinet width W. All scripts adhere to the drafting standards consistent with the "Drafting Standards" entity in the engineering design domain knowledge graph.

[0128] In the first embodiment, the parameterized driving model mainly includes an electrical drawing generation script based on the AutoCAD platform and an equipment list generation script based on Python, corresponding to two design output types: graphics and data, respectively.

[0129] (4) Integrate and encapsulate the parameterized driving model.

[0130] The aforementioned business rules (in code form), logical algorithms (control flow code), and parameterized scripts (plotting and tabulation scripts) are integrated into a single execution framework. This framework ensures that upon input of parameters (In, Ics), logical judgments are executed sequentially, corresponding scripts are called, and a final packaged design solution containing an equipment list, system diagram, schematic diagram, and cabinet dimension drawings is output.

[0131] Store the standardized module M-FEED-01 into the standardized module library.

[0132] A bidirectional association mapping is established between the standardized module M-FEED-01 and multiple entities in the engineering design domain knowledge graph (see the diagram for the mapping relationship). Figure 4 ): Establish a "module instantiation with" relationship with the functional entities "outgoing line protection" and "metering"; establish a "module contains equipment" relationship with the equipment entities circuit breaker VD4-12 / 1250-31.5 and current transformer LZZBJ9-10; establish a "module meets specification" relationship with the relevant clauses of the specification entity GB50060.

[0133] At the same time, the module's metadata (such as rated current range, breaking capacity, and applicable scenarios for instantiation) is synchronously mapped to the attributes of relevant entities in the knowledge graph of the engineering design domain.

[0134] The module matching engine receives parameterized instruction sets from external systems (such as through web service interfaces, software APIs, or manual interfaces) via standardized service interfaces. The instruction explicitly specifies the call to module M-FEED-01 and passes in the parameters: { "In": 630A, "Ics": 30kA}.

[0135] The module matching engine performs matching and compliance verification on standardized modules:

[0136] (1) Perform identifier verification and location: Confirm in the standardized module library whether there is a module with the identifier M-FEED-01 and locate the module;

[0137] (2) Perform parameter compliance verification: Verify whether the input parameters (In=630A, Ics=30kA) are within the allowable range of the rated current (e.g., range 400A-1600A) and breaking capacity (e.g., range 25kA-40kA) parameters defined in the standardized module M-FEED-01;

[0138] (3) Perform design context verification (semantic deep verification): By accessing the knowledge graph of the engineering design domain, deep reasoning verification is performed based on the semantic relationship chains established as described above, such as "module instantiated in", "module contains equipment", and "module meets specifications".

[0139] By linking standardized modules with a knowledge graph of the engineering design domain, relevant specifications and equipment parameters can be obtained, thereby verifying whether the standardized module is suitable for the current design context. As mentioned above, "design context" refers to information about the current design project, including project type, design stage, geographical location, environmental data, technical regulations, and applicable mandatory standards.

[0140] By verifying the "module instantiation with" relationship, it was confirmed that module M-FEED-01 possesses the semantic function of "outgoing line protection," and that "project type = substation" is within the applicable scope of module M-FEED-01. This verification ensures that the module function matches the project type.

[0141] By leveraging the "module contains equipment" relationship, the associated equipment entity (such as circuit breaker VD4-12 / 1250-31.5) is located, and the "rated breaking capacity" attribute (value 31.5kA) of this equipment entity is queried from the engineering design domain knowledge graph to verify whether it meets the latest technical specifications for Ics≥30kA. This step goes beyond the static validation of the module's own parameter set, enabling dynamic semantic querying of associated equipment attributes.

[0142] At the same time, by using the "module meets the specification" relationship, the associated mandatory specification entity (such as GB50060) is located, and it is verified whether the current design context (such as voltage level 10kV) meets the applicable conditions of the specification entity.

[0143] Once all the above verifications are passed, the parameterized instruction is considered valid and allowed to be executed.

[0144] The entire process demonstrates that the applicability of standardized modules is jointly determined by their semantic network within the knowledge graph of the engineering design domain. This "semantic-based deep verification" is a crucial step in ensuring the quality of the generated solutions, echoing the "semantic-based intelligent retrieval" function of the external design system, together forming a complete intelligent invocation chain.

[0145] After successful verification, the system drives the parameterized driving model to run automatically according to the verified parameterized instructions, completing the entire process from logical decision-making and geometric calculation to content generation. It also achieves a design closed loop through dynamic interaction with the knowledge graph in the engineering design field, and finally combines and detects conflicts between the outputs of multiple modules.

[0146] pass Figure 5 This will illustrate the timing relationship between the dynamic invocation and combination of modules according to the first embodiment.

[0147] (a) Model Invocation: The module execution engine locates and invokes the parameterized driving model based on the module identifier M-FEED-01 that has passed the above verification, and passes the project parameters (In=630A, Ics=30kA) to the parameterized driving model.

[0148] (b) Rules and script execution:

[0149] Rule execution and logical decision-making: The parameterized driving model runs, and its business rule engine selects the circuit breaker model VD4-12 / 1250-31.5 based on the logic that Ics=30kA>25kA (the decision-making capability of the parameterized driving model).

[0150] Parameter calculation and geometry generation: The parameterized driving model triggers the cabinet layout algorithm defined above. Based on the selected circuit breaker model and the number of current transformers (e.g., 2) by default or deduced, it obtains the component reference dimensions from the physical dimension library associated with the knowledge graph of the engineering design domain. According to the standard unit synthesis logic, it dynamically calculates the accurate cabinet width W=800mm through the process of "equipment unit mapping → structural unit calculation → cabinet total width synthesis" (the parameterized driving model has the ability to automatically generate accurate geometric parameters from logical decision-making).

[0151] Script execution and content generation: Based on the above decision and calculation results (circuit breaker model, cabinet width W), the model drives parametric scripts and CAD and other design tools to generate instantiated specific design content that is completely consistent with the above decision and calculation results, such as equipment list, system diagram, schematic diagram, and cabinet layout diagram.

[0152] (c) Update the knowledge graph of the engineering design domain: The parametric-driven model takes the final parameters determined in this generation (such as the selected equipment model and the calculated cabinet width) as the design result, sends information to the knowledge graph of the engineering design domain, and updates the status and attributes of the relevant entities. Specifically, it marks the status of the equipment entity "Circuit Breaker VD4-12 / 1250-31.5" as "selected"; and records the key design parameters generated in this generation (this step completes the design closed loop from knowledge application to knowledge feedback).

[0153] (d) Confirmation of update: After the knowledge graph in the engineering design domain completes the update of attributes and status, it returns a confirmation signal to the parameterized driving model.

[0154] (e) Return results: The parameterized driven model returns the generated equipment list, system diagram, cabinet layout diagram and other specific design content to the module execution engine.

[0155] (f) Combination and Conflict Detection: The module execution engine automatically combines the design content generated by multiple standardized modules and executes a conflict detection process, such as electrical logic conflict detection (e.g., busbar capacity verification, protection coordination verification); and geometric conflict detection (e.g., cabinet spacing check, busbar tray space interference check). Since the geometric conflict detection here (e.g., cabinet spacing) directly depends on the cabinet width W accurately calculated by each standardized module, the accuracy of the detection is ensured.

[0156] During conflict detection, for example, when the system detects an electrical logic conflict indicating insufficient bus capacity, the following processing is performed:

[0157] (1) Automatically generate conflict report: Bus rated current 2000A, current total load 2150A, overload 7.5%;

[0158] (2) Provide solutions: a) Upgrade the busbar specification to 2500A; b) Adjust the load distribution of the outgoing line cabinet;

[0159] (3) Automatic optimization attempt: The system automatically recalculates and recommends the optimal bus upgrade scheme;

[0160] (4) User decision: After the designers confirm and adopt the suggestion, the system continues to execute.

[0161] The system outputs a complete substation outgoing line cabinet design scheme segment that has undergone combination and conflict detection, thus completing this dynamic call.

[0162] The method according to this application will be described below using the example of dynamically generating standard drawing frames and explanatory documents (hereinafter referred to as the second embodiment).

[0163] This application allows for the flexible use of different methods to create parameterized driven models for different types of standardized modules.

[0164] Based on historical engineering design results, a mature "standard drawing frame" from historical projects, validated multiple times, was extracted into a standardized module M-DrawingFrame-01 using automated analysis tools (such as clustering algorithms), and assigned a module identifier. For example... Figure 2 As shown, based on the working principle of the parameterized driven model, the following definitions are made:

[0165] Key parameters: Project name, design stage, drawing number, scale, and list of signatories.

[0166] According to the method of this application, a parameterized driving model is created through steps (1)-(4).

[0167] (1) Extract and structure business rules based on knowledge graphs in the field of engineering design.

[0168] Query the "Drafting Standards" and "Project Information" entities in the engineering design knowledge graph to summarize drafting standards, such as different title block formats and approval processes corresponding to different design stages (schematic, preliminary design, construction drawings).

[0169] (2) Design and implement the logical algorithm.

[0170] The algorithm selects the corresponding drawing template based on the input "design stage" parameter, and queries the existing drawing entity in the engineering design domain knowledge graph based on the "drawing number" to verify its uniqueness under the project.

[0171] (3) Develop parameterized generation scripts.

[0172] Develop a CAD script that creates a new DWG file. Based on input parameters, dynamically populate all attribute blocks in the title block and signature block, and set the drawing size and scale.

[0173] (4) Integrate and encapsulate the parameterized driving model.

[0174] By integrating the verification logic with the drawing script, the M-DrawingFrame-01 standardized module was created.

[0175] Based on historical engineering design results, a mature "design specification paragraph" from a historical project applied to a chemical library is extracted into a standardized module M-DesignDesc-01 through automated analysis tools (such as clustering algorithms) or by domain experts, and assigned a module identifier. For example... Figure 2 As shown, based on the working principle of the parameterized driven model, the following definitions are made:

[0176] Key parameters: Project type, list of design specifications, key design parameters (such as load rating, fire resistance rating).

[0177] According to the method of this application, a parameterized driving model is created through steps (1)-(4).

[0178] (1) Extract and structure business rules based on knowledge graphs in the field of engineering design.

[0179] The core capabilities of this model are directly derived from the knowledge graph of the engineering design domain. During construction, it is necessary to systematically traverse and analyze the "design specifications" entities (such as GB50016) related to the "chemical library" in the knowledge graph of the engineering design domain, extract the mandatory clauses and recommended explanatory statements for different fire resistance ratings and fire hazards of stored items, and establish selection logic.

[0180] (2) Design and implement the logical algorithm.

[0181] Based on the "project type" and "key design parameters", a query is initiated into the knowledge graph of the engineering design field to retrieve the latest applicable standard clauses, and these clauses are sorted and selected according to predefined priority and combination rules.

[0182] (3) Develop parameterized generation scripts.

[0183] Develop a text synthesis script that can smoothly combine multiple terms and statements selected by the algorithm from a knowledge graph in the field of engineering design into coherent paragraphs according to a standard document structure.

[0184] (4) Integrate and encapsulate the parameterized driving model.

[0185] Create the M-DesignDesc-01 standardized module, which is deeply integrated with the knowledge graph of the engineering design domain during the construction phase. It can be regarded as an "executor" of the knowledge graph of the engineering design domain in the field of text generation.

[0186] According to this embodiment, the parametric-driven model has the ability to handle multiple output types: the M-DrawingFrame-01 module uses an AutoCAD-based drawing frame generation script to process graphic output; the M-DesignDesc-01 module uses a template engine-based design specification generation script to process text output.

[0187] The latter can extract relevant regulatory clauses from the knowledge graph of the engineering design field and automatically combine them to generate compliant design specification text according to a predefined document structure.

[0188] Store the standardized modules M-DrawingFrame-01 and M-DesignDesc-01 into the standardized module library.

[0189] Associate the standardized module M-DrawingFrame-01 with the "Drafting Standards" and "Project Information" entities in the engineering design knowledge graph. Associate the standardized module M-DesignDesc-01 with the "Design Standards" entity (such as GB50016) and the "Engineering Type" entity (see the diagram for their mapping relationship). Figure 4 Both standardized modules' parameterized driven models are associated with the engineering design domain knowledge graph, but in different ways: M-DrawingFrame-01 is associated with drafting specifications and project information to generate drawing frames; M-DesignDesc-01 is associated with design specifications and project types to generate explanatory text.

[0190] Receive, for example, parametric instructions issued by an external design system, requiring the simultaneous invocation of the standardized modules M-DrawingFrame-01 and M-DesignDesc-01, and the input of project parameters (such as project type="chemical library" and stage="construction drawing"). The project parameters include the specific values ​​required by the key parameter set of the standardized modules.

[0191] The module matching engine receives instructions and performs matching and compliance verification on the two standardized modules respectively:

[0192] (1) Perform identifier verification and module location: confirm whether the two standardized modules exist in the standardized module library. If they exist, locate the two standardized modules.

[0193] (2) Perform parameter compliance verification: Verify whether the parameters are complete (e.g., project name, drawing number are not empty), and whether the value of the "design stage" parameter is one of the enumerated values ​​defined by the standardized module (e.g., "preliminary design", "construction drawing");

[0194] (3) Perform design context verification: Through the knowledge graph of the engineering design domain, verify that the "project type" entity associated with the standardized module M-DesignDesc-01 contains the "chemical library" and that the associated "design specification" entity (such as GB50016 "Code for Fire Protection Design of Buildings") is applicable to the current project type, thereby ensuring that the generated design specification text content is compliant; and verify the standardized module M-DrawingFrame-01 to check its matching with the current "design stage" to ensure that the correct version of the drawing frame is generated.

[0195] Once the matching and compliance verification of the standardized module is passed, the instruction is forwarded to the module execution engine.

[0196] The system passes project parameters to the parameterized driven model of two standardized modules specified by module identifiers. The second embodiment outlines the timing flow of invocation, composition, and collaboration with a knowledge graph in the engineering design domain. Figure 6 As described in the first embodiment above, it will not be repeated here.

[0197] Based on the second embodiment described above, the parametric-driven model of the M-DrawingFrame-01 standardization module automatically generates a DWG format drawing frame file with a correct title block, and the parametric-driven model of the M-DesignDesc-01 standardization module automatically generates design specification text for the "Chemical Library". During or after this process, the system can update the attributes of relevant entities based on the association and mapping relationship between the standardization module and the engineering design domain knowledge graph. For example, it can mark newly generated drawing numbers as "assigned" or update the "current design stage" of the project information entity to "construction drawing". The system automatically fills the specification text into the drawing frame and performs conflict detection (such as verifying the uniqueness of the drawing number within the project scope and checking whether the specification version referenced in the specification text is the latest valid version marked in the engineering design domain knowledge graph). Finally, the system outputs a design document integrating the drawing frame and specification.

[0198] The methods and systems described in this application can be used as service components and integrated into external design systems. They can receive and execute parameterized instructions issued by external systems through module matching engines and module execution engines, providing them with modular and intelligent design material generation and management capabilities.

[0199] This application constructs a standardized module library with a parameterized driving model and deeply associates it with a knowledge graph in the field of engineering design. This enables intelligent dynamic calling and quality self-verification of modules, solving the problems of static, non-intelligent, and lacking self-verification capabilities in existing module libraries.

[0200] This application, by creating a parameterized driven model deeply integrated with business rules and generation scripts, systematically extracts and encapsulates abstract and scattered design experience into fine-grained, parameterized standardized modules that can be directly executed and invoked by computers. Furthermore, this standardized module, equipped with a parameterized driven model, possesses logical decision-making and adaptive generation capabilities, forming the "intelligent kernel" of the standardized module and realizing a leap from design knowledge "data" to "executable capability." Moreover, the standardized module with the parameterized driven model enables advanced reuse of design knowledge, thereby achieving intelligent encapsulation of design experience.

[0201] In this application, through deep bidirectional association with a knowledge graph in the engineering design domain, standardized modules are no longer isolated information silos. This association enables external systems to intelligently perceive and semantically retrieve modules, shifting from "passive search" to "proactive, precise recommendation." Furthermore, it provides a semantic foundation for deep verification, ensuring that the invoked modules are highly compatible with the current design context in terms of function, equipment, and specifications. This comprehensive knowledge collaboration significantly improves design efficiency and decision-making quality. Moreover, it achieves intelligent invocation and deep knowledge collaboration.

[0202] The standardized modules in this application are derived from mature experience, and the calling process undergoes parametric verification and automated conflict detection based on a knowledge graph in the engineering design domain, ensuring the quality and compliance of the output solutions from the source. Simultaneously, through a standardized parametric instruction set interface, decoupling from external design systems is achieved, clarifying system boundaries, avoiding functional redundancy, and improving the synergy of the entire intelligent generation system as well as the independence and reusability of the system modules. Therefore, this application ensures that the quality of intelligent engineering design generation is controllable and the interfaces are clear.

[0203] Providing a high-quality, structured, and executable "material library" for the intelligent generation system of upper-level engineering design is a key foundational component for its efficient and accurate generation. Through a dynamic invocation mechanism, the intelligent generation process of the system, which uses a standardized module library for intelligent engineering design generation, can be based on precise and verified standardized modules, greatly improving the reliability and usability of the generated results. By receiving a standardized parameterized instruction set, a clear and efficient interface is formed with the upper-level intelligent generation system of engineering design, further enhancing system synergy and module reusability. This application, through a comprehensive scheme of construction and dynamic invocation, realizes the intelligent reuse of design experience, providing core support for external design systems.

[0204] The system described in this application does not depend on a specific external design system. It can be deployed and run independently, or it can be flexibly integrated into various design environments, providing core support for the intelligent upgrade of traditional design software.

[0205] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for constructing and dynamically calling a standardized module library for intelligent generation of engineering designs, characterized in that, The method includes: Standardized module library construction step S10: Based on historical engineering design results, standardized modules are extracted and stored in the standardized module library. Each standardized module is set with functional interfaces, key design parameter sets and constraints, and is assigned a unique module identifier. Based on the key design parameter sets, a parameterized driving model is created for each standardized module. The parameterized driving model can execute logical decisions according to the input parameters and drive the script to generate or adjust the design content of the standardized module. Module-Domain Knowledge Graph Association Mapping Step S20: Perform bidirectional association mapping between each standardized module in the standardized module library and an entity in the engineering design domain knowledge graph; Module instruction reception and matching verification step S30: Receive a parameterized instruction set, access the engineering design domain knowledge graph to obtain the design context of the current project, wherein the parameterized instruction set contains module identifiers of one or more standardized modules to be invoked and the input parameters corresponding to the standardized modules, and based on the association mapping established in step S20, verify and confirm the matching and compliance of the standardized modules in the parameterized instruction set with the design context; and Standardized module dynamic calling and combination step S40: According to the parameterized instruction set verified in step S30, the parameters in the parameterized instruction set are input into the parameterized driving model of the standardized module specified in the parameterized instruction set, driving the parameterized driving model to run, generating design content that meets the requirements of the parameterized instruction set and satisfies the needs of the current project, and combining and conflict detecting the generated design content to form a complete design scheme segment.

2. The method according to claim 1, wherein, Creating a parameterized driving model for each of the standardized modules includes: By deeply querying and utilizing the knowledge graph in the engineering design field, analyzing historical successful cases, design specifications and domain expert experience, the design decision logic is extracted into a logical expression including "IF-THEN" rules. Transform structured business rules into executable algorithmic processes; For different types of design outputs, write parametric drawing, modeling, document generation, or data processing scripts, and develop scripts or program modules that can dynamically generate or adjust content based on input parameters; and The rules, the algorithm, and the script are integrated into the parameterized driving model, and input and output interfaces are set for the parameterized driving model.

3. The method according to claim 1, wherein, The bidirectional association mapping includes: The standardization module is associated with the functional entities that represent the function of the standardization module, the equipment entities that constitute the standardization module, and the normative entities that the standardization module follows in the knowledge graph of the engineering design domain.

4. The method according to claim 3, wherein, Verifying and confirming the compatibility and compliance of the standardized modules in the parameterized instruction set with the design context includes: Verify whether the module identifier of the standardized module exists; Verify whether the input parameters meet the key design parameter set and constraints of the standardized module; Based on the associated entities in the knowledge graph of the engineering design domain through the bidirectional association mapping, and based on the key design parameter set and the constraints, a semantic-based deep verification is performed to determine whether the standardized module is applicable to the design context.

5. The method according to claim 1, wherein, The conflict detection includes one or more of the following: geometric conflict detection, logical conflict detection, and specification compliance detection.

6. The method according to claim 5, wherein, The method further includes: when a conflict is detected, performing one or more of the following processes: a) to d). a) Generate a detailed conflict report, identifying the conflict type, location, and severity; b) Provide solutions to the detected conflicts, including parameter adjustment solutions or module replacement solutions; c) Optimize parameters to eliminate detected conflicts; d) Mark the detected conflict state and pause the combination, awaiting intervention.

7. The method according to claim 1, wherein, Based on historical engineering design results, the standardized modules extracted include: By analyzing drawings, models, and documents from historical projects, we identified and summarized recurring, fully functional, and mature design scheme units; and The design scheme units are summarized and abstracted into reusable standardized modules through automated analysis tools.

8. The method according to claim 1, wherein, The design content includes one or more of the following: two-dimensional drawing fragments, three-dimensional model components, equipment material lists, or calculation instructions.

9. The method according to claim 1, wherein, The method further includes: during the operation of the parameterized driving model or after the design content is generated, updating the metadata of the standardized module to the corresponding entity attributes in the engineering design domain knowledge graph.

10. The method according to claim 1, wherein, The method also includes storing the design context of the current project into the engineering design domain knowledge graph, wherein the design context includes project type, design stage, geographical location, environmental data, technical specifications, and applicable mandatory standards.

11. A system for constructing and dynamically calling a standardized module library for intelligent generation of engineering designs, wherein, The system includes: The module builder extracts standardized modules based on historical engineering design results. Each standardized module is provided with a functional interface, a set of key design parameters and constraints, and is assigned a unique module identifier. The module builder creates a parameterized driving model for each standardized module based on the set of key design parameters. The parameterized driving model can execute logical decisions based on the input parameters and drive scripts to generate or adjust the design content of the standardized module. The graph association tool performs bidirectional association mapping between each standardized module in the standardized module library and entities in the knowledge graph of the engineering design domain. The module matching engine receives a parameterized instruction set, accesses the engineering design domain knowledge graph to obtain the design context of the current project, wherein the parameterized instruction set contains module identifiers of one or more standardized modules to be called and their corresponding input parameters, and verifies and confirms the matching and compliance of the standardized modules in the parameterized instruction set with the design context based on the association mapping established by the graph association. The module execution engine, based on the parameterized instruction set verified by the module matching engine, inputs the parameters from the parameterized instruction set into the parameterized driving model of the standardized module specified in the parameterized instruction set, drives the parameterized driving model to run, generates design content that conforms to the requirements of the parameterized instruction set and meets the needs of the current project, and performs combination and conflict detection on the generated design content to form a complete design scheme segment; and A standardized module library is used to store the standardized modules and the parameterized driving model constructed by the module builder.

12. The system according to claim 11, wherein, The system also includes a standardized service interface for receiving call requests and parameterized instruction sets from external systems.

13. A computer device, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images