A computer aided engineering simulation result generation method and apparatus

Abstract

The embodiment of the application provides a computer-aided engineering simulation result generation method and device, an application programming interface for realizing hot plug functions of a business plug-in and a third-party business plug-in is constructed; when a user determines a target vertical field type, a target business plug-in and / or a target third-party business plug-in are determined based on the target vertical field type; the target business plug-in and / or the target third-party business plug-in is called based on the application programming interface, and a computer-aided engineering simulation result is generated. Through determining field requirements and generating diversified plug-ins, a unified hot plug API interface is constructed to realize complete module decoupling and open integration, finally, the user can flexibly select and call function modules to generate simulation results on demand, and the openness, expansibility and field adaptation capability of the CAE software are significantly improved.

Description

Technical Field

[0001] This invention relates to the field of computer-aided engineering simulation result generation technology, and in particular to a method for generating computer-aided engineering simulation results, a device for generating computer-aided engineering simulation results, an electronic device, and a computer-readable storage medium. Background Technology

[0002] CAE is an abbreviation for Computer-Aided Engineering. It is a class of tools and techniques that use computer software to simulate, analyze, and optimize the performance of product designs and engineering.

[0003] The core of CAE software lies in simulating real-world physical phenomena on a computer by establishing mathematical models and applying numerical methods (such as the Finite Element Method (FEM), Finite Volume Method (FVM), and Boundary Element Method (BEM). Through CAE software, engineers can perform virtual testing and iterative optimization before product manufacturing, thereby significantly shortening development cycles, reducing physical prototype testing costs, and improving product performance and reliability. It is widely used in almost all engineering fields, including aerospace, automotive, mechanical, electronics, energy, and biomedicine.

[0004] Currently, the software architecture of computer-aided engineering (CAE) technologies generally adopts a monolithic design pattern based on C++. Internal modules are often deeply coupled through C++ code or Python scripts. This tight binding mechanism severely limits the reusability of the same architecture across different vertical simulation domains. Furthermore, existing architectures generally rely on fixed internal system standards (e.g., the proprietary module systems of commercial software like Abaqus), resulting in poor compatibility and openness. This not only significantly restricts secondary development and functional expansion but also makes it difficult to flexibly and efficiently adapt to the increasingly diverse specific business needs of different industries and professional fields. Summary of the Invention

[0005] The present invention provides a method, apparatus, electronic device, and computer-readable storage medium for generating computer-aided engineering simulation results, in order to overcome or at least partially solve the above-mentioned problems.

[0006] This invention discloses a method for generating computer-aided engineering simulation results. The method is applied to a computer-aided engineering simulation result generation system for computer-aided engineering simulation software, which includes multiple core layers, including:

[0007] Determine the vertical domain type and the target business type of the vertical domain type;

[0008] The core layer is used to generate business plugins for implementing the target business type;

[0009] Acquire third-party computer-aided engineering software and third-party business plugins to implement other business types;

[0010] Construct an application programming interface for implementing the hot-plug functionality of the business plugin and the third-party business plugin;

[0011] When a user determines a target vertical domain type, a target business plugin and / or a target third-party business plugin are determined based on the target vertical domain type.

[0012] The target business plugin and / or the target third-party business plugin are invoked based on the application programming interface to generate computer-aided engineering simulation results.

[0013] Optionally, before the step of generating the business plugin for implementing the target business type in the core layer, the method further includes:

[0014] Determine the shelf system logical structure used to express the hierarchical relationship of the business plugins in the core layer;

[0015] The vertical domain configuration pattern information DataSchema, which is used to characterize the logical structure of the shelf system for the target business type, is stored in a preset database to generate a manageable data model.

[0016] Optionally, the step of generating the business plugin for implementing the target business type in the core layer includes:

[0017] Read the vertical domain configuration schema information (DataSchema) from the database to obtain the target business type;

[0018] Determine the custom business execution logic for the target business type;

[0019] According to the preset unified plugin interface specification, the submodule that executes the custom business execution logic is encapsulated as the business plugin.

[0020] Optionally, the step of constructing an application programming interface for implementing the hot-pluggable functionality of the business plugin and the third-party business plugin includes:

[0021] Determine a common communication protocol for the business plugin and the third-party business plugin;

[0022] Determine the module name for the target sub-module used to execute the target business type and the other business types, as well as the vertical domain name corresponding to the target sub-module;

[0023] A Uniform Resource Locator is generated using the general communication protocol, the module name, and the vertical domain name;

[0024] The Uniform Resource Locator is used to construct an application programming interface for implementing the hot-plug functionality of the business plugin and the third-party business plugin.

[0025] Optionally, it also includes:

[0026] Determine the correspondence between the application programming interface and the target submodule, and register the application programming interface to the database based on the correspondence.

[0027] Optionally, the generation system includes a graphical user interface (GUI) for displaying the business plugin and / or the third-party business plugin. When the user determines a target vertical domain type, the system determines the target business plugin based on that target vertical domain type, and / or the target third-party business plugin includes:

[0028] In response to the detection of a selection operation for the business plugin and / or the third-party business plugin, the business plugin and / or the third-party business plugin are identified as the target business plugin and / or the target third-party business plugin.

[0029] Optionally, the step of generating computer-aided engineering simulation results by calling the target business plugin based on the application programming interface, and / or the target third-party business plugin, includes:

[0030] Using the application programming interface, determine the target business plugin, and / or the call sequence of the target third-party business plugin;

[0031] The target business plugin and / or the target third-party business plugin are added to the simulation process based on the call sequence.

[0032] The simulation process is executed, and computer-aided engineering simulation results are generated.

[0033] This invention also discloses a computer-aided engineering simulation result generation device. The device is applied to a computer-aided engineering simulation result generation system for computer-aided engineering simulation software, the computer-aided engineering simulation software comprising multiple core layers, including:

[0034] The target business type determination module is used to determine the vertical domain type and the target business type of the vertical domain type;

[0035] A business plugin generation module is used to generate business plugins for the core layer to implement the target business type;

[0036] The third-party business plugin acquisition module is used to acquire third-party computer-aided engineering software for implementing other business types.

[0037] An application programming interface (API) building module is used to build application programming interfaces for implementing the hot-plug functionality of the business plugin and the third-party business plugin.

[0038] The plugin determination module is used to determine the target business plugin and / or the target third-party business plugin based on the target vertical domain type when the user determines the target vertical domain type.

[0039] The computer-aided engineering simulation result generation module is used to call the target business plugin and / or the target third-party business plugin based on the application programming interface to generate computer-aided engineering simulation results.

[0040] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0041] The memory is used to store computer programs;

[0042] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0043] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0044] The embodiments of the present invention have the following advantages:

[0045] This invention, through the following embodiments, involves: determining a vertical domain type and a target business type within that vertical domain; generating a core layer of business plugins to implement the target business type; acquiring third-party computer-aided engineering software to implement third-party business plugins for other business types; constructing an application programming interface (API) to implement the hot-swappable functionality of the business plugins and the third-party business plugins; when a user determines a target vertical domain type, determining the target business plugin and / or the target third-party business plugin based on that target vertical domain type; and calling the target business plugin and / or the target third-party business plugin based on the API to generate computer-aided engineering simulation results. This achieves thorough module decoupling and open integration by determining domain requirements and generating diverse plugins, thereby constructing a unified hot-swappable API interface. Ultimately, this allows users to flexibly select and call functional modules to generate simulation results on demand, significantly improving the openness, scalability, and domain adaptability of CAE software.

[0046] Furthermore, addressing the issues of closed systems, low scalability, and difficulty in domain adaptation caused by the monolithic architecture and strong module binding of traditional CAE software, this invention solves these problems by identifying vertical domains and generating / acquiring diverse business plugins. It then constructs a unified hot-swappable API to achieve module decoupling and open integration, ultimately enabling users to flexibly determine and call plugins based on specific domain requirements to generate simulation results on demand. This completely resolves the aforementioned pain points and significantly improves the openness, scalability, and domain adaptation capabilities of CAE software. Attached Figure Description

[0047] Figure 1 This is a flowchart of the steps of a computer-aided engineering simulation result generation method provided in this embodiment of the invention;

[0048] Figure 2 This is a flowchart illustrating a method for generating computer-aided engineering simulation results provided in an embodiment of the present invention;

[0049] Figure 3 This is a structural block diagram of a computer-aided engineering simulation result generation device provided in an embodiment of the present invention;

[0050] Figure 4 This is a hardware structure block diagram of an electronic device provided in an embodiment of the present invention;

[0051] Figure 5 This is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. Detailed Implementation

[0052] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0053] Currently, traditional Computer-Aided Engineering (CAE) software architectures generally adopt a monolithic C++-based architecture, with internal modules often deeply coupled through C++ code or Python scripts. This tight binding mechanism severely limits the reusability of the same architecture across different vertical simulation domains. Furthermore, existing architectures generally rely on fixed internal system standards (e.g., the proprietary module systems of commercial software like Abaqus), resulting in poor compatibility and openness. This not only significantly restricts secondary development and functional expansion but also makes it difficult to flexibly and efficiently adapt to the increasingly diverse specific business needs of different industries and professional fields. Therefore, there is an urgent need for a CAE software architecture system that can standardize the organization of functional modules and support rapid integration and configuration.

[0054] To address the aforementioned challenges, existing technologies have the following specific problems:

[0055] 1.1 Closed Architecture: Traditional CAE software (such as Abaqus and ANSYS) typically adopts a tightly coupled monolithic architecture, with functional modules interacting through hard-coded internal private APIs or scripts. This design solidifies the dependencies between modules, making it difficult to achieve cross-domain functional reuse and limiting the effective integration of third-party tools.

[0056] 1.2 Low scalability: The functional expansion of traditional architectures relies heavily on in-depth secondary development. Developers need to thoroughly understand the complex internal structure of the software and a large number of private interfaces, resulting in long development cycles and difficulty in ensuring compatibility, which seriously hinders the rapid iteration and deployment of new functions and algorithms.

[0057] 1.3 Difficulty in Domain Adaptation: Existing CAE software often requires customized toolchains to meet the specific simulation needs of different vertical fields, such as automotive crash testing and aerospace thermal analysis. The lack of a unified architectural framework to support flexible configuration and dynamic combination leads to high costs of repetitive development and maintenance, making it difficult to efficiently meet the personalized needs of niche markets.

[0058] The closed nature of traditional CAE software stems from the strong coupling of modules and the restriction of private APIs under its monolithic architecture.

[0059] 2.1 Overcoming the problem of closed architecture:

[0060] To address the core issues of traditional CAE software architectures, such as their closed nature, low scalability, and difficulty in domain adaptation, this invention proposes a software architecture with a shelf-like logical structure. This architecture aims to achieve open integration, efficient scalability, and flexible domain adaptation. Through a layered decoupling architecture and standardized interface design, this software architecture achieves fundamental open integration.

[0061] 2.1.1 Module Decoupling and Interface Standardization: Complex CAE functions are meticulously broken down into independent and cohesive modules such as preprocessing, solvers, and post-processing. These modules interact through a unified REST-style application programming interface (API), eliminating the hard-coded dependencies of traditional C++ or Python scripts. For example, the "Bevel Cleaning API" of the geometry cleanup module uses JSON format to define input and output parameters, ensuring the universality and readability of communication between modules. This standardized design allows third-party tools to seamlessly integrate through standardized interfaces. For instance, a self-developed lightweight mesh generation tool can be registered with the software system containing the shelving system's logical structure via the API, enabling collaborative work with mainstream solvers.

[0062] 2.1.2 Plug-in Integration Mechanism: The business plug-in layer adopts a unified plug-in interface specification and supports the dynamic loading and management of third-party CAE tool plug-ins through a plug-in registry center. Taking the structural mechanics solver plug-in as an example, plug-ins developed based on ABAQUS only need to follow the preset interface protocols for initialization, data reception, and function execution to be integrated as independent components into the software system containing the racking system's logical structure. This plug-and-play mechanism completely breaks the closed nature of the proprietary module systems of software such as Abaqus, promotes the flexible combination of tools from different sources, and thus builds an open CAE ecosystem.

[0063] 2.2 Improve system scalability:

[0064] To address the difficulty of extending the functionality of traditional architectures, the software system of this invention achieves rapid iteration and continuous evolution of system functions through an innovative layered architecture and low-code orchestration strategy.

[0065] 2.2.1 Layered and Scalable Architecture: The entire system is divided into multiple core layers (such as preprocessing, solver, and post-processing), each supporting modular expansion. When new functions are needed, such as adding composite material fatigue analysis functionality in the aerospace field, only a composite material modeling submodule needs to be added to the preprocessing layer, and a fatigue analysis solver submodule needs to be added to the solver layer. Through the clear definition of standardized APIs, new modules can be quickly integrated into the existing system without modifying the code of other modules, significantly reducing development complexity and potential compatibility issues.

[0066] 2.2.2 Low-code Task Orchestration: The task orchestration layer provides an intuitive, visual low-code platform, allowing users to quickly build complex simulation workflows by dragging and dropping module components and defining data flow through connections. This platform supports advanced logic configurations such as conditional branches and loop structures. For example, in automotive crash simulation, users can quickly configure multi-condition crash simulation workflows through a graphical interface. This approach transforms traditional feature expansion from cumbersome code development to efficient graphical configuration, significantly shortening the development cycle and effectively improving the overall scalability of the system and user productivity.

[0067] 2.3 Enhance domain adaptability:

[0068] To address the challenge of adapting to different vertical domains, the software architecture of this invention employs a strategy that combines domain customization with dynamic adaptation, ensuring that the system can accurately and flexibly meet the specific needs of various industries.

[0069] 2.3.1 Vertical Domain Customization: Based on the DataSchema configuration pattern information of a specific vertical domain, a dedicated functional "shelf system logical structure" is customized for that domain. Taking the field of automotive fluid dynamics simulation as an example, by deeply analyzing the needs of this field for handling complex geometric models and turbulence simulation, the flow channel geometry repair module can be strengthened at the preprocessing layer, and a turbulence model solving submodule suitable for automotive operating conditions can be configured at the solver layer. Simultaneously, dedicated APIs are customized to meet the specific needs of this field. For example, interfaces for setting parameters such as vehicle driving wind speed and direction can be added to the boundary condition definition API, achieving precise adaptation of functions and business requirements.

[0070] 2.3.2 Dynamic Adaptation Mechanism: The plugin adaptation layer achieves dynamic and flexible adaptation between the interface layer and underlying business plugins by integrating visual orchestration tools and script development. For data format differences between tools in different domains (such as the IGES format commonly used in aerospace tools and the STEP format commonly used in the automotive field), the system can use pre-built data format conversion components for automated processing. For more complex domain-specific data mapping requirements, the system supports writing custom adaptation logic via Python scripts. This dynamic adaptation mechanism ensures that different plugins for different domains can efficiently and flexibly adapt to the simulation requirements of different domains within the same shelf-based system logic structure, avoiding the need to repeatedly develop independent toolchains for each new domain, significantly improving the system's versatility and cost-effectiveness.

[0071] Reference Figure 1 The diagram illustrates a flowchart of a method for generating computer-aided engineering simulation results according to an embodiment of the present invention, which may specifically include the following steps:

[0072] Step 101: Determine the vertical domain type and the target business type of the vertical domain type;

[0073] Step 102: Generate the core layer to implement the business plugins for the target business type;

[0074] Step 103: Obtain third-party business plugins from third-party computer-aided engineering software to implement other business types;

[0075] Step 104: Construct an application programming interface for implementing the hot-swappable functionality of the business plugin and the third-party business plugin;

[0076] Step 105: When the user determines the target vertical domain type, determine the target business plugin and / or the target third-party business plugin based on the target vertical domain type;

[0077] Step 106: Based on the application programming interface, call the target business plugin and / or the target third-party business plugin to generate computer-aided engineering simulation results.

[0078] In a specific implementation, the embodiments of the present invention are applied to a computer-aided engineering simulation result generation system for computer-aided engineering simulation software, hereinafter referred to as "the system", wherein the computer-aided engineering simulation software includes multiple core layers.

[0079] For example, the core layer includes a preprocessing layer, a solver layer, and a postprocessing layer.

[0080] 1. Pre-processing Layer:

[0081] Purpose: To prepare the input data required for simulation. This is the process of transforming real-world engineering problems into mathematical models that CAE software can recognize and process.

[0082] Core functions:

[0083] Geometric Modeling and Import: Import geometric models (such as .step and .iges files) from CAD software, or create geometric shapes directly in CAE software.

[0084] Geometry cleanup and repair: Clean up defects in the imported model (such as holes, slits, and overlapping surfaces), and perform simplification operations such as chamfering and filleting to improve mesh generation efficiency and quality.

[0085] Material property definition: Define the material properties of each component in the model (such as elastic modulus, Poisson's ratio, density, thermal conductivity, etc.).

[0086] Boundary conditions and load definitions: Define the constraints (such as fixation, displacement) and loads (such as force, pressure, temperature, fluid inlet / outlet conditions) that the model will be subjected to during the simulation, as well as the initial conditions.

[0087] Meshing: Discretizing a continuous geometric model into a finite number of non-overlapping elements and nodes to form a computational model (such as tetrahedral meshes, hexahedral meshes, shell elements, etc.). This step is crucial for simulation accuracy and computational efficiency.

[0088] Example module (plugin):

[0089] Geometry repair plugins (such as custom repair modules based on Parasolid or OpenCASCADE);

[0090] Advanced mesh generation plugin (can be integrated with HyperMesh or ANSYS Meshing functionality);

[0091] Load and boundary condition definition plugin (user interface and data interface).

[0092] 2. Solver Layer:

[0093] Function: Performs numerical calculations, solves a set of physical equations based on the model, materials, and loads defined in the preprocessing, and obtains simulation results.

[0094] Core functions:

[0095] Select the solution algorithm: Choose the appropriate numerical algorithm based on the simulation type (such as linear static, nonlinear dynamic, steady-state / transient fluid, multiphysics coupling, etc.).

[0096] Equation solving: The core algorithm is run to iteratively solve the discretized system of equations and generate intermediate results.

[0097] Results storage: The original data obtained from the solution (such as the displacement of each node, the stress of each element, the flow velocity, the temperature field, etc.) are stored in the results file.

[0098] Example module (plugin):

[0099] Structural mechanics solver plugin (can integrate Abaqus Standard / Explicit or LS-Dyna functionality);

[0100] Computational Fluid Dynamics (CFD) solver plugin (integrates functionality with ANSYS Fluent or OpenFOAM);

[0101] Thermal analysis solver plugin (custom heat conduction solver or integrated COMSOL);

[0102] 3. Post-processing Layer:

[0103] Function: To visualize, analyze, and interpret the large amounts of raw data generated by the solver, so that engineers can understand the simulation results and evaluate product performance.

[0104] Core functions:

[0105] Results loading and display: Reads the result file generated by the solver and displays it in a three-dimensional visualization in the graphical interface (such as model deformation diagram, stress cloud diagram, temperature distribution diagram, streamline diagram, etc.).

[0106] Data query and extraction: Allows users to query data of specific nodes or cells, extract maximum / minimum values, and generate XY curves, cross-sectional diagrams, etc.

[0107] Animation and Report Generation: Create animations of the simulation process or generate automated simulation reports containing charts, tables, and text.

[0108] Results Comparison and Evaluation: Compare the results under different simulation conditions to evaluate the merits of the design scheme.

[0109] Example module (plugin):

[0110] Results visualization plugin (can integrate visualization capabilities of ParaView or EnSight);

[0111] Data extraction and curve generation plugin (for generating time-displacement curves, force-deformation curves, etc.);

[0112] Automated report generation plugin (automatically generates Word / PDF reports based on templates).

[0113] These three core layers form the skeleton of any CAE simulation process. This invention can standardize the functions of these core layers and allow for the flexible insertion and combination of custom or third-party "business plugins" to ultimately produce the desired CAE simulation results.

[0114] In a specific implementation, embodiments of the present invention can determine the vertical domain type and the target business type of the vertical domain type;

[0115] Vertical domain type: refers to the specific sub-sectors or engineering fields in which CAE technology is applied and served, such as automotive crash simulation, aerospace structural analysis, ship fluid dynamics, and electronic heat dissipation analysis.

[0116] Target business type: refers to the specific engineering problems that need to be solved or the specific tasks that need to be achieved through CAE simulation in this vertical field, such as predicting vehicle collision deformation, evaluating wing flutter characteristics, optimizing the flow field of engine cooling system, and analyzing the heat distribution of electronic components.

[0117] This invention, through determining the vertical domain type and the target business type of that vertical domain, defines the application boundaries and focus, ensuring that subsequent system design, functional module development, and integration accurately serve the actual needs of a specific industry. It provides fundamental input for building a domain-specific "shelf system," guides the planning and definition of functional modules, and achieves the following beneficial effects:

[0118] This ensures that the entire CAE simulation result generation system has a high degree of domain specificity and professionalism, avoiding functional generalization and resource waste.

[0119] It can more effectively capture and meet the deep and personalized simulation needs of users in specific vertical fields.

[0120] It helps to create a differentiated competitive advantage and occupy a favorable position in the market segment.

[0121] In a specific implementation, embodiments of the present invention can generate the core layer for implementing the target business type of the business plugin;

[0122] Core layer: refers to the set of basic, logically interdependent functions in the CAE simulation process, which typically include preprocessing, solver, and postprocessing.

[0123] Business plugins: These are functional modules implemented for specific target business types, conforming to a pre-defined unified interface specification, and capable of independent deployment and invocation. They are the self-developed parts of the shelf system, corresponding to third-party business plugins, which are plugins developed by third-party R&D personnel.

[0124] By independently developing solutions, we can fill the functional gaps in existing third-party CAE software or implement high-performance and customized core business logic. These customized core functions will be encapsulated in a modular and standardized manner, enabling the system to recognize and manage them, laying the foundation for subsequent dynamic combination, and achieving the following beneficial effects:

[0125] Enhance core competitiveness: Allow the system to include unique and differentiated simulation algorithms and functions.

[0126] Improved controllability: It provides complete control over core business logic, facilitating optimization, iteration, and maintenance.

[0127] Promote modular development: Break down complex functions into independent plugins to reduce development difficulty and shorten the development cycle.

[0128] In specific implementations, embodiments of the present invention can acquire third-party computer-aided engineering software to implement third-party business plugins for other business types;

[0129] Third-party computer-aided engineering software: refers to commercially available and mature CAE software (such as Abaqus, ANSYS, OpenFOAM, etc.) or open-source CAE tools.

[0130] Third-party business plugins: These refer to plugins that adapt and encapsulate specific functions of third-party CAE software to conform to the system's pre-defined unified interface specifications and can be independently called and managed by the system. They are the parts of the shelving system that "borrow / integrate what others have already done".

[0131] Other business types: These refer to business needs within the target vertical industry that can be met through mature third-party software functions, or as a supplement to custom business plugins.

[0132] This invention, by fully utilizing existing mature, high-performance, and proven CAE functionalities in the industry, avoids redundant development, thereby significantly saving development costs and time. It expands the system's functional coverage, integrates industry standards and best practices, enhances the system's comprehensiveness and reliability, and achieves the following beneficial effects:

[0133] Shorten development cycles and reduce costs: Quickly build powerful systems without having to develop all features from scratch.

[0134] Expanding system capabilities: Integrating the advantages of various professional tools to cover a wider range of simulation scenarios.

[0135] Enhanced market compatibility: Supports data and functionality interoperability with mainstream industry tools.

[0136] In a specific implementation, embodiments of the present invention can construct an application programming interface for implementing the hot-swappable functionality of the business plugin and the third-party business plugin;

[0137] Application Programming Interface (API): A set of rules and protocols that define how software components communicate and interact. Here, it specifically refers to standardized APIs, such as those based on the REST style and using JSON as the data exchange format. Standardized APIs may include, but are not limited to, initialization interfaces (for plugin initialization configuration), data receiving interfaces (for receiving input data from the task orchestration layer), function execution interfaces (for executing specific plugin functions, such as geometry cleanup, solution calculations, etc.), result return interfaces (for returning processing results to the plugin adaptation layer), and error handling interfaces (for handling errors during plugin execution and returning error messages).

[0138] Hot-swappable functionality: refers to the ability to dynamically add, remove, or update plugins during system operation without stopping or restarting the entire system.

[0139] This invention establishes a unified and standardized communication mechanism, enabling both custom-developed and integrated third-party business plugins to expose their functions in a consistent manner and be invoked by the upper-layer system. This decoupling of functional modules (plugins) ensures their independence, replaceability, and maintainability. It also provides technical support for the dynamic loading, updating, and unloading of plugins, improving system flexibility and scalability, and achieving the following beneficial effects:

[0140] Achieve system decoupling and high cohesion: Modules communicate with each other through standard APIs, reducing mutual dependencies and improving module independence and reusability.

[0141] Supports flexible expansion: New or updated features can be accessed via API without modifying the core code, significantly improving system scalability.

[0142] Improve development efficiency: Developers only need to focus on the implementation of the plugin's internal logic and API interfaces, without needing to understand the complex interaction details of the entire system.

[0143] Fostering an open ecosystem: It provides a standardized entry point for the seamless integration of third-party tools, building an open CAE ecosystem.

[0144] In a specific implementation, embodiments of the present invention can determine a target business plugin and / or a target third-party business plugin based on the target vertical domain type when the user determines the target vertical domain type.

[0145] User-defined target vertical domain type: This refers to the specific industry or professional field that the user selects on the system interface for the CAE simulation work they need to perform, such as selecting "Automotive Collision Simulation" in the graphical user interface (GUI).

[0146] Target business plugins and target third-party business plugins: These refer to specific plugins that, within a specific vertical domain, are selected by the user based on their needs or automatically recommended by the system, and that can achieve the functions required for simulation tasks of that target vertical domain type.

[0147] This invention, through its embodiments, associates a user's domain selection with functional modules (plugins) within the system. This allows users to flexibly select and configure specific functional components according to their particular simulation tasks and domain requirements, constructing personalized simulation workflows and achieving the following beneficial effects:

[0148] Improve user experience and work efficiency: Users only need to focus on issues in their own field and select functions through an intuitive interface, without needing to delve into the underlying technical details.

[0149] Customizable functionality: The system can dynamically combine plugins to provide a highly customized simulation toolchain based on different fields and user needs.

[0150] Reduce operational complexity: It hides the heterogeneity of underlying plugins and provides a unified and simplified user interface.

[0151] In a specific implementation, embodiments of the present invention can call the target business plugin and / or the target third-party business plugin based on the application programming interface to generate computer-aided engineering simulation results.

[0152] Computer-aided engineering simulation results refer to the various data, images, reports, and other outputs generated by CAE software after executing the simulation process, which are used to analyze and evaluate engineering problems.

[0153] In this embodiment of the invention, the functional combinations determined by the user at a high level (step 105) are transformed into an executable sequence of instructions. By utilizing standardized APIs and a plugin management mechanism, the actual execution of underlying functional modules (plugins) is driven, thereby completing the entire CAE simulation calculation process. Ultimately, the invention produces computer-aided engineering simulation results required by the user for analysis and decision-making, achieving the following beneficial effects:

[0154] Automated simulation process: Automates complex CAE tasks, reduces human intervention, and improves efficiency and consistency.

[0155] Ensure the accuracy of simulation results: Follow the preset call sequence and data flow to reduce human error and ensure the reliability of results.

[0156] Enable rapid iteration and optimization: By changing the combination of plug-ins or parameters, quickly perform multi-scheme simulations to accelerate product development and optimization.

[0157] Achieve "on-demand simulation": relevant plugins are only activated when actually called, improving resource utilization.

[0158] Provides complete output: ultimately generates quantitative simulation results that can be used for engineering decision-making.

[0159] This invention, through the following embodiments, involves: determining a vertical domain type and a target business type within that vertical domain; generating a core layer of business plugins to implement the target business type; acquiring third-party computer-aided engineering software to implement third-party business plugins for other business types; constructing an application programming interface (API) to implement the hot-swappable functionality of the business plugins and the third-party business plugins; when a user determines a target vertical domain type, determining the target business plugin and / or the target third-party business plugin based on that target vertical domain type; and calling the target business plugin and / or the target third-party business plugin based on the API to generate computer-aided engineering simulation results. This achieves thorough module decoupling and open integration by determining domain requirements and generating diverse plugins, thereby constructing a unified hot-swappable API interface. Ultimately, this allows users to flexibly select and call functional modules to generate simulation results on demand, significantly improving the openness, scalability, and domain adaptability of CAE software.

[0160] Furthermore, addressing the issues of closed systems, low scalability, and difficulty in domain adaptation caused by the monolithic architecture and strong module binding of traditional CAE software, this invention solves these problems by identifying vertical domains and generating / acquiring diverse business plugins. It then constructs a unified hot-swappable API to achieve module decoupling and open integration, ultimately enabling users to flexibly determine and call plugins based on specific domain requirements to generate simulation results on demand. This completely resolves the aforementioned pain points and significantly improves the openness, scalability, and domain adaptation capabilities of CAE software.

[0161] Based on the above embodiments, modified embodiments of the above embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in the modified embodiments.

[0162] In an optional embodiment of the present invention, before the step of generating the business plugin of the core layer for implementing the target business type, the method further includes:

[0163] Determine the shelf system logical structure used to express the hierarchical relationship of the business plugins in the core layer;

[0164] The vertical domain configuration pattern information DataSchema, which is used to characterize the logical structure of the shelf system for the target business type, is stored in a preset database to generate a manageable data model.

[0165] The logical structure of the shelving system: In this embodiment of the invention, it is an abstract concept used to organize and classify all available CAE functional modules (i.e., business plugins or third-party business plugins) within a specific vertical domain. It simulates the classification system of a library or the display method of a merchandise shelf, categorizing a large number of functions according to core layers such as preprocessing, solvers, and post-processing, and further subdividing each layer into more specific modules and sub-modules, forming a clear tree-like or network-like hierarchical relationship.

[0166] Its purpose is to provide a systematic and logically clear organizational framework for functional modules in a specific vertical field.

[0167] Ensure that all functional modules (whether custom or third-party) can be effectively managed, indexed, and discovered within this unified framework.

[0168] It provides a foundational blueprint for subsequent DataSchema definitions, clarifying which functionalities will be abstracted, encapsulated, and exposed.

[0169] Beneficial effects:

[0170] Enhanced feature discoverability and manageability: Engineers can clearly see all available features in a specific area, making it easier to find and select the required modules.

[0171] Promote function reuse and standardization: With a clear structure, similar functions are easier to identify and reuse, reducing redundant development.

[0172] Simplified system expansion: When adding new functions or integrating third-party tools, their position in the shelving system can be quickly determined, ensuring the orderliness of the system structure.

[0173] Supports industry-specific customization: Different vertical industries can build their own unique shelving systems to meet their professional needs.

[0174] In this embodiment of the invention, the vertical domain configuration pattern information DataSchema, which is used to characterize the logical structure of the shelf system for the target business type, can also be stored in a preset database to generate a manageable data model.

[0175] Vertical Domain Configuration Pattern Information DataSchema: This is the concrete implementation of the "shelf system logical structure," typically represented in a structured data format (such as JSON Schema). It not only defines the hierarchical relationships within the shelf system but also contains detailed metadata for each functional module (plugin), such as module name, function description, core layer, input parameters (type, constraints, default values), output parameters, API interface path, version information, and dependencies with other modules.

[0176] Database: A storage system used to persistently store this DataSchema information, ensuring data consistency, reliability, and accessibility.

[0177] Manageable data model: refers to the DataSchema stored in the database. It is no longer a simple text file, but has the ability to be structured, read, updated, queried and version controlled by programs, so that the system can dynamically manage and use these metadata.

[0178] Its purpose is:

[0179] The abstract "shelf system logical structure" is made concrete, digitized, and standardized so that it can be efficiently parsed and processed by computer programs.

[0180] It provides a unified, programmable source of metadata for CAE software generation systems, driving subsequent plugin generation, API construction, task orchestration, and user interface display.

[0181] This enables centralized management and version control of vertical domain functions and interface definitions, ensuring that all parts of the system operate based on consistent definitions.

[0182] Beneficial effects:

[0183] Implement a "metadata-driven" system: most functional logic is no longer hard-coded, but driven by configuration information in the DataSchema, which greatly improves the system's flexibility and configurability.

[0184] Supports low-code / visual orchestration: The task orchestration platform can directly read the DataSchema to dynamically generate visual components and parameter configuration interfaces, allowing users to build simulation processes without writing code.

[0185] Improved development efficiency and consistency: Developers can develop plugins and implement APIs based on the DataSchema specification, ensuring compatibility and data consistency between modules.

[0186] Facilitates system evolution and maintenance: Modifications to the DataSchema can be dynamically reflected in the system, facilitating feature updates, iterations, and maintenance without recompiling the entire core system.

[0187] Ensure data integrity and reliability: Store critical configuration information in the database and provide data persistence, backup and recovery mechanisms.

[0188] For example, modules, submodules, APIs, and message bodies required for interaction can be defined using JSON format, such as:

[0189] {

[0190] DataSchema code block

[0191] "module": "GeometricCleaning"

[0192] "api": "RemoveLogo",

[0193] "parameters": {

[0194] "filePath": "XXXX.stp",

[0195] "xxx": "xxx", / / Other parameters

[0196] }

[0197] …

[0198] }

[0199] If you need to adjust the data schema of the shelving system, you can simply adjust the data format described above. In contrast to the traditional approach, which requires modifying the code and recompiling, testing, packaging, and deploying, this solution directly modifies the data schema and uses plugin adaptation functionality for mapping.

[0200] In an optional embodiment of the present invention, the step of generating the business plugin of the core layer for implementing the target business type includes:

[0201] Read the vertical domain configuration schema information (DataSchema) from the database to obtain the target business type;

[0202] Determine the custom business execution logic for the target business type;

[0203] According to the preset unified plugin interface specification, the submodule that executes the custom business execution logic is encapsulated as the business plugin.

[0204] This invention can read the vertical domain configuration pattern information (DataSchema) from the database to obtain the target business type, using this as the first step in generating a custom business plugin. This ensures that plugin development is based on clear and standardized requirements. By reading the DataSchema, it obtains the precise definition and requirements of the required business plugin, including the functions it should implement, the names of the API interfaces it provides, the required input parameters, and the expected output format. This allows the plugin generation process to be automatically or semi-automatically adjusted according to the latest definition in the DataSchema, achieving the following:

[0205] Beneficial effects:

[0206] Ensure the accuracy of development direction: Ensure that the developed business plugins are highly consistent with the logical structure of the corresponding shelf system and the domain requirements of the corresponding vertical domain type.

[0207] Improve development efficiency: Developers do not need to design interfaces from scratch; they can directly refer to the specifications defined in the DataSchema.

[0208] Enhance system consistency: Ensure that all custom business plugins follow a unified definition standard, facilitating integration and management.

[0209] Conditions for achieving automated code generation: In some cases, it is even possible to automatically generate the framework code or interface definition of plugins based on the DataSchema.

[0210] This invention can also determine custom business execution logic for the target business type;

[0211] Custom business execution logic: refers to the execution logic designed to achieve a specific target business type (this function can be defined by DataSchema). Custom business execution logic corresponds to the execution logic designed by a third party. If the execution logic designed by a third party is regarded as the execution logic of a third-party business plugin made by others based on other CAE software, then the custom business execution logic can be the execution logic designed by the user for the target business type.

[0212] According to the embodiments of the present invention, sub-modules that execute custom business execution logic can be encapsulated as business plugins based on a preset unified plugin interface specification.

[0213] The pre-defined unified plugin interface specification refers to a set of standards predefined by the system to guide the development, encapsulation, and registration of all plugins (including business plugins and third-party business plugins). This includes conventions on plugin lifecycle management (initialization, operation, and destruction), data input / output formats, error handling mechanisms, and how to expose APIs.

[0214] Submodule: refers to an independent code unit or functional component that implements specific custom business execution logic.

[0215] Business plugins: Custom functional modules that are encapsulated and can be dynamically loaded and invoked by the system.

[0216] Its purpose is:

[0217] Custom-developed business execution logic is converted into standard components that the system can recognize, manage, and hot-swap.

[0218] Ensure that all custom plugins follow a unified external interface and behavior pattern to achieve plugin interoperability and versatility.

[0219] It provides a unified entry point for the plugin registry and task orchestration layer, hiding the complexity of the underlying implementation.

[0220] Beneficial effects:

[0221] Achieve true "hot-swappability": plugins can be dynamically loaded, unloaded, and updated at runtime without stopping the entire system.

[0222] Improve module reusability: The encapsulated plugins can be reused in different simulation processes, reducing development and maintenance costs.

[0223] Simplify system integration: The plugin provides a unified interface, making system integration simple and efficient.

[0224] Promote team collaboration: Different teams can develop compliant plugins in parallel, improving overall development efficiency.

[0225] Enhanced system stability: The isolation of plugins reduces the impact of a single plugin failure on the entire system.

[0226] In an optional embodiment of the present invention, the step of constructing an application programming interface for implementing the hot-pluggable functionality of the business plugin and the third-party business plugin includes:

[0227] Determine a common communication protocol for the business plugin and the third-party business plugin;

[0228] Determine the module name for the target sub-module used to execute the target business type and the other business types, as well as the vertical domain name corresponding to the target sub-module;

[0229] A Uniform Resource Locator is generated using the general communication protocol, the module name, and the vertical domain name;

[0230] The Uniform Resource Locator is used to construct an application programming interface for implementing the hot-plug functionality of the business plugin and the third-party business plugin.

[0231] This invention can determine a common communication protocol for the business plugin and the third-party business plugin;

[0232] A general communication protocol refers to the unified rules and standards followed throughout the system for data exchange and message passing between different modules (especially API consumers and plugin providers). It specifies how data is transmitted over the network, how it is formatted, and how it is parsed. Common protocols include HTTP / HTTPS (used for web services, the foundation of RESTful APIs), gRPC (a high-performance, HTTP / 2-based RPC framework), or custom protocols like rs: / / .

[0233] As mentioned above, business plugins / third-party business plugins refer to custom-developed functional modules and functional modules adapted to third-party CAE software, respectively.

[0234] Its purpose is:

[0235] Unified communication foundation: Ensure that all plugins, regardless of their underlying implementation language or technology stack, can communicate in the same way to achieve cross-language and cross-platform service calls.

[0236] Ensure interoperability: Establish a common language so that different components within the system can "understand" and "respond" to each other's requests.

[0237] Simplify network communication management: Abstract complex network details so that developers only need to focus on business logic and API interface definitions.

[0238] Beneficial effects:

[0239] Achieve system-level compatibility: Plugins from different sources can work together under a unified protocol.

[0240] Improved development efficiency: Developers do not need to design independent communication mechanisms for each plugin, and can reuse a common protocol stack.

[0241] Easier maintenance and troubleshooting: A unified communication mode makes system behavior more predictable and makes it easier to locate and resolve communication-related problems.

[0242] Supports horizontal scaling: Universal protocols facilitate the deployment of distributed services and improve system performance and availability through load balancing and other methods.

[0243] In this embodiment of the invention, the module name of the target sub-module used to execute the target business type and the other business types, and the vertical domain name corresponding to the target sub-module can be determined;

[0244] In practical applications, a "plugin" can be an encapsulation of a submodule used to execute business logic for a target business type or to execute business logic for other business types.

[0245] Target submodule: refers to the functional submodule in the business plugin or third-party business plugin that is generated or obtained in S102 and S103 and specifically implements a certain function.

[0246] Module name: refers to the unique identifier or function name of each target submodule (plugin), such as "geometry cleanup", "structural solver", "stress cloud visualization", etc.

[0247] Vertical domain name: refers to the specific industry or application field to which this module belongs, such as "automotive collision", "aerospace", "electronic heat dissipation", etc.

[0248] Its purpose is:

[0249] Build semantic paths for APIs: Provide each API with a clear, identifiable logical address that can be accurately mapped to a specific function and domain.

[0250] Implement hierarchical resource location: Incorporate module names and vertical domain names as important components of the URL path to form a logically clear API hierarchy structure, facilitating management and invocation.

[0251] Supports multi-tenant / multi-domain isolation (optional): Logical isolation and management of different domain functions can be achieved to a certain extent by using vertical domain names.

[0252] Beneficial effects:

[0253] Improve the semantic clarity of APIs: The URL structure of an API intuitively reflects its function and domain, making it easy to understand and use.

[0254] Facilitates API management and expansion: APIs can be categorized and organized by domain and module, making it easier to add, modify, and version control them later.

[0255] Supports automated API documentation generation: Based on standardized naming, it is easier to generate readable API documentation.

[0256] In this embodiment of the invention, a Uniform Resource Locator (URL) can be generated using the general communication protocol, the module name, and the vertical domain name.

[0257] Uniform Resource Locator (URL): refers to the unique access address of an API.

[0258] A URL (Uniform Resource Locator) is a standard way to uniquely identify and locate any resource on the Internet (or any network).

[0259] In this embodiment of the invention, when various CAE functions (whether custom-developed business plugins or adapted third-party business plugins) are encapsulated and provided to the outside world through a standardized application programming interface (API), each callable API must have a unique "network address", which is its URL.

[0260] A URL is like a network address for an API: when a module in a system (such as the task orchestration layer) needs to call a function provided by another module (such as the geometry cleanup plugin), it needs to know where to find and access that function. The URL is the precise network address of that function. It tells the caller where to find the function.

[0261] URL uniqueness and addressability:

[0262] Uniqueness: Every API must have a unique URL across the entire system. Two different APIs cannot share the same URL; otherwise, the system will be unable to distinguish which function to call.

[0263] Addressability: As long as the URL of the API is known, theoretically any authorized client or system component can make a request through this URL to access or trigger the functionality behind the API.

[0264] In this embodiment of the invention, the function of the URL includes:

[0265] The cornerstone of service discovery: During the establishment of the plugin registration mechanism and the definition of its management API, plugins register their URL information with the registry center. When a user needs to call a function (of a plugin) through the system's task orchestration layer, the task orchestration layer queries the registry center for the URL of the corresponding function and then directly initiates the call through that URL.

[0266] Achieving module decoupling: The caller only needs to know the API URL and request construction method, without needing to delve into the internal implementation details of the called plugin (e.g., whether its underlying code is C++ or a wrapper around Abaqus functionality, and its specific deployment location, etc.). This API-oriented rather than implementation-oriented model is key to achieving module decoupling.

[0267] Hot-swappable: As long as a plugin's functionality and exposed API (i.e., URL) remain unchanged, its underlying implementation can be replaced, or even deployed to different servers, without the upper-level caller being aware of these changes and still calling it through the same URL. This enables plugins to be "hot-swappable".

[0268] Optionally, embodiments of the present invention can also support a distributed architecture: different plugin services can be deployed on different servers, and each service has its own URL. Through load balancing and routing mechanisms, the URL can point to the most suitable instance, thereby supporting the evolution of the CAE system towards a distributed, microservice architecture and improving performance and reliability.

[0269] The purpose of generating a Uniform Resource Locator is:

[0270] Provide a unique identifier for each plugin's API: ensure that every callable function in the system has a clear and unambiguous network address.

[0271] Standardized API access point: This allows all plugins to be discovered and invoked through a unified and standardized URL pattern.

[0272] Implement dynamic addressability for plugins: The system can dynamically construct and parse these URLs based on the information in the DataSchema, thereby accessing the corresponding plugin services.

[0273] Beneficial effects:

[0274] Enables remote invocation and distributed deployment of plugins: URLs, as network addresses, allow plugin services to be deployed on different servers and invoked over the network.

[0275] Improve system flexibility: As long as the URL remains unchanged, the underlying implementation or deployment location of the plugin can be dynamically adjusted without affecting the API caller.

[0276] Simplify the service discovery process: The task orchestration layer can directly invoke the service by querying the plugin registry to obtain the URL, without needing to know the physical location of the plugin.

[0277] Supports RESTful architecture: The design of the URL is a core component of the RESTful API and conforms to the best practices of modern web services.

[0278] This invention can utilize the Uniform Resource Locator (URL) to construct an application programming interface (API) for implementing the hot-pluggable functionality of the business plugins and third-party business plugins. This concretizes the URL into a usable service interface, ensuring that the generated URL is not merely an address, but a callable service entry point that actually connects to the functionality. This allows all business plugins and third-party business plugins to have their functions accessed and used by external systems through a unified API interface, providing a stable and accessible interface layer for the dynamic loading, replacement, and upgrading of plugins, and achieving the following beneficial effects:

[0279] This achieves true decoupling of plugins: the caller only faces the API (URL) and does not care about the specific implementation and deployment details of the plugin, thus achieving a high degree of modularity and independence.

[0280] Supports hot-swapping of plugins: As long as the API (URL) remains unchanged, the underlying plugins can be freely replaced or updated without affecting the upper-level callers.

[0281] Promote microservice architecture: Each plugin provides services independently through APIs, which facilitates the evolution of the system towards a microservice architecture and improves scalability and elasticity.

[0282] Enhancing the overall openness of the system: Standardized APIs are key to achieving seamless integration between the system and external tools and platforms, forming a broader CAE ecosystem.

[0283] For example, the application programming interface (API) is generated in the following way:

[0284] Based on the functional module definitions in DataSchema, design a standardized application programming interface specification;

[0285] Based on the definitions of all functional modules in the DataSchema (including those provided by business plugins and third-party business plugins) and their required input / output message bodies, design a unified, RESTful style application programming interface (API) specification. For example, use rs: / / as the communication protocol, JSON as the parameter and return data format, and clearly define the structure and meaning of each API's URL, request method, input parameters (message body), and output parameters (message body), as well as the error handling mechanism.

[0286] Establish a plugin registry and define its management application programming interface;

[0287] Build a centralized plugin registry center that provides standardized API interfaces (such as registration, deregistration, update, query, etc.) for business plugins and third-party business plugins to register and manage their metadata; this center is the foundation of the task orchestration layer and service discovery, ensuring that the system can dynamically discover and manage all available plugins.

[0288] Implement a plugin adaptation layer to bridge different data formats and interfaces;

[0289] A plugin adaptation layer is developed, which acts as a bridge between the standardized API interface and the underlying specific plugins (whether business plugins or third-party business plugins). This layer includes built-in data type / format conversion components and supports defining complex mapping rules through visual orchestration or custom scripts (such as Python scripts). It converts the request data from the standardized API into the format required by the plugin and converts the data returned by the plugin into the format required by the API, thereby achieving seamless "hot-plugging" of all plugins.

[0290] Taking the collection cleanup interface as an example:

[0291]

[0292]

[0293] In an optional embodiment of the invention, it further includes:

[0294] Determine the correspondence between the application programming interface and the target submodule, and register the application programming interface to the database based on the correspondence.

[0295] Mapping relationship: This refers to the mapping relationship between an API (usually its URL, request method, parameters, etc.) and the underlying target submodule it represents (including its ID, name, version, deployment location, and other metadata). This relationship enables the system to find and invoke the correct underlying function through the API.

[0296] The mapping information between these APIs and submodules is registered and stored in a pre-defined database in a structured data format. This database acts as a plugin registry or service registry, and its purpose is to:

[0297] Establish a unified service discovery mechanism: provide a centralized, queryable service directory for the entire system. Any module that needs to call a certain function (such as the task orchestration layer or user interface) can find the corresponding API address and related information by querying this database, without needing to hardcode the deployment location or calling method of the plugin.

[0298] Dynamic management of plugins: By registering and managing the correspondence between APIs and plugins in the database, the system can dynamically discover, load, update, or uninstall plugins without modifying or restarting the caller code.

[0299] Ensure system consistency and reliability: Ensure that all API definitions and their associated underlying plugin information are up-to-date and consistent to avoid call failures due to information mismatch.

[0300] Supports elastic scaling and load balancing: Registration information can include multiple instance addresses and health statuses of the plugin, providing a data foundation for subsequent load balancing and fault tolerance mechanisms.

[0301] Beneficial effects:

[0302] Improve system availability and robustness: When a plugin instance fails or needs to be updated, the registry center can dynamically update its status or switch to other available instances to ensure uninterrupted service.

[0303] Enhanced system scalability: When adding a new plugin instance, it can be recognized and used by the system simply by registering it, without the need to modify the calling logic, which facilitates horizontal expansion.

[0304] Simplified service invocation and orchestration: The task orchestration layer only needs to query the registry center based on the logical name defined in the DataSchema to obtain available API information, which greatly simplifies the construction and execution of the simulation process.

[0305] Achieve true "plug and play": newly developed or adapted plugins can be immediately recognized and their functions invoked by the system as long as they are registered in the database, without the need for complex configuration.

[0306] Facilitates monitoring and governance: The registry center stores the metadata and status of all services, which facilitates the monitoring, management and governance of the system.

[0307] Promote the development of the API ecosystem: As a unified API entry point and management platform, we encourage the development and integration of more plugins to form a virtuous cycle ecosystem.

[0308] In an optional embodiment of the present invention, the generation system includes a graphical user interface for displaying the business plugin and / or the third-party business plugin, wherein when the user determines a target vertical domain type, a target business plugin is determined based on the target vertical domain type, and / or the target third-party business plugin includes:

[0309] In response to the detection of a selection operation for the business plugin and / or the third-party business plugin, the business plugin and / or the third-party business plugin are identified as the target business plugin and / or the target third-party business plugin.

[0310] Graphical User Interface (GUI): This refers to the visual interface through which users interact with a computer system. It typically includes graphical elements such as windows, icons, buttons, and menus, allowing users to control the software through intuitive operations like clicking and dragging. All available, standardized, and encapsulated business plugins and third-party business plugins in the system are presented to the user in a graphical format (such as icons, lists, cards, etc.), usually categorized according to their respective vertical domains and core layers (preprocessing, solver, post-processing).

[0311] Its purpose is:

[0312] Provide an intuitive user interaction interface: abstract complex backend functions into visual elements that are easy to understand and operate, reducing the barrier to entry for users.

[0313] Visualize the "shelf system": Present the shelf system defined in the DataSchema and its various plugins in a user-friendly way, making it easy for users to browse and select.

[0314] Supports low-code / no-code orchestration: Provides a foundation for users to build simulation processes through drag-and-drop, clicking, etc., and achieves a "what you see is what you get" operating experience.

[0315] Beneficial effects:

[0316] Significantly enhances the user experience: Say goodbye to command lines or complex script operations, allowing engineers to focus on simulation logic rather than technical details.

[0317] Reduce learning costs: Intuitive graphical operation reduces the learning curve for new users.

[0318] Improve work efficiency: Users can quickly find the functions they need and combine them to accelerate the construction of simulation processes.

[0319] Enhance system accessibility: Enable non-professional programmers to effectively utilize the powerful features of the CAE system.

[0320] Take dragging an icon as an example:

[0321] Selection operation: refers to the user selecting one or more displayed business plugins or third-party business plugins through specific interactive behaviors (such as mouse click, drag, keyboard shortcuts, etc.) on the GUI.

[0322] Response to Listening: This refers to the GUI system continuously monitoring user input events (such as mouse press, move, and release), and triggering corresponding internal logic processing when a specific event matching the "selected operation" is detected.

[0323] Identifying as a target business plugin / target third-party business plugin: This refers to the system recognizing and confirming the specific plugins selected by the user. These selected plugins will become the objects of subsequent simulation process construction and execution.

[0324] Example of dragging an icon:

[0325] A visual task orchestration canvas with a library of available plugins on the left (such as preprocessing module icons, solver module icons, and postprocessing module icons).

[0326] When a user clicks and holds down a business plugin icon representing the "Geometry Cleanup" function, this is called "Listening to Selected Operation".

[0327] When the user "drags" the icon onto the arrangement canvas and "releases" it, the system "determines" that the "Geometric Cleanup" business plugin is one of the target business plugins in the current simulation process.

[0328] Purpose:

[0329] Enable user interaction with system functions: accurately convey the user's intent (selecting a function) to the system.

[0330] Build personalized simulation workflows: Allow users to flexibly select and combine different plugins according to the needs of specific simulation tasks, forming a unique simulation workflow.

[0331] Supports visual task orchestration: Users can define complex simulation logic and data flow through graphical drag-and-drop without writing code, greatly simplifying process construction.

[0332] Beneficial effects:

[0333] Extremely high flexibility and customization: Users can freely combine any available plugins to quickly build simulation processes that meet specific needs, which solves the problem of traditional CAE software "lacking a unified framework to support flexible configuration".

[0334] Accelerate simulation workflow construction: Compared to writing scripts or code, drag-and-drop operation is more efficient and significantly shortens the simulation workflow setup time.

[0335] Reduced error rate: The graphical interface and explicit connection methods reduce process problems caused by manual coding or configuration errors.

[0336] Intuitive presentation of process logic: The flowchart created by dragging and dropping clearly shows the simulation steps and data flow, making it easy to understand, modify and collaborate on.

[0337] Of course, the selected operation is not unique, and those skilled in the art can use any other means to implement the user's selected operation. In this regard, the embodiments of the present invention do not limit it.

[0338] In an optional embodiment of the present invention, the step of generating computer-aided engineering simulation results by calling the target business plugin based on the application programming interface, and / or the target third-party business plugin, includes:

[0339] Using the application programming interface, determine the target business plugin, and / or the call sequence of the target third-party business plugin;

[0340] The target business plugin and / or the target third-party business plugin are added to the simulation process based on the call sequence.

[0341] The simulation process is executed, and computer-aided engineering simulation results are generated.

[0342] Call sequence: refers to the logical order and interdependencies of these selected plugins during the entire simulation process. This is not just a simple linear sequence, but may include complex logic such as conditional branches (execute B if result A satisfies a certain condition, otherwise execute C), loops (repeatedly execute a step until a condition is met), and parallel execution, like a complete programming script or flowchart, but in the form of a data structure.

[0343] This invention transforms the abstract simulation logic defined by the user through a visual interface (such as dragging and dropping lines) into a specific sequence of instructions that the system can understand and execute. This ensures that the functions of each plugin are triggered in the correct logical order to achieve the expected simulation goal, provides precise action guidelines for the subsequent simulation process, and ensures that data flows and is processed correctly between different plugins.

[0344] Beneficial effects:

[0345] To automate and standardize the simulation process: transform complex manual operations into automatically executed sequences, reduce human intervention, and improve efficiency.

[0346] Ensure the consistency and reproducibility of simulation results: Each execution follows the same call sequence to ensure the stability and repeatability of the results.

[0347] Reduce the complexity of process construction: Users only need to define the process through a graphical interface, and the system will automatically parse and determine the call sequence, eliminating the need to manually write complex call code.

[0348] Supports complex simulation scenarios: It can flexibly define simulation processes that include complex logic such as conditions and loops.

[0349] Simulation process: refers to a complete, executable simulation task definition, which consists of a series of target business plugins and / or third-party business plugins organized according to a specific call sequence. This "process" is a job unit actually constructed by the system based on the call sequence and ready for execution. It may be an internal task scheduling graph, an execution queue, or a script that can be parsed by the task execution engine.

[0350] The embodiments of the present invention can configure each plugin and its parameters defined in the call sequence into the execution environment of the simulation process, making it ready to be called by the scheduler or execution engine, and achieving the following beneficial effects:

[0351] Improve task execution efficiency: All execution elements are predefined in the process, avoiding the overhead of dynamic parsing at runtime.

[0352] Facilitates task scheduling and management: As an independent entity, the simulation process can be effectively scheduled onto computing resources and managed in a unified manner.

[0353] Supports parallel computing and distributed execution: If the simulation process includes plugins that can be executed in parallel, the system can perform parallel scheduling according to the definition.

[0354] Ensure optimized resource allocation: When building a process, the system can estimate the required resources and allocate them reasonably.

[0355] Computer-aided engineering simulation results: These refer to all data, files, and reports ultimately produced by the collaborative work of various plugins after the entire simulation process is completed. This includes, but is not limited to:

[0356] Numerical results: matrix or vector data of physical quantities such as displacement, stress, temperature, flow velocity, and pressure.

[0357] Graphical results: such as cloud maps, line graphs, vector graphics, animations, and other visual data files.

[0358] Text report: Includes simulation settings, process logs, key result statistics, analysis conclusions, etc.

[0359] Intermediate files: Various temporary files, mesh files, solver input / output files, etc. generated during the simulation process.

[0360] The purpose of generating computer-aided engineering simulation results is:

[0361] The ultimate value of simulation methods lies in transforming all previous definitions, preparations, and orchestration into actual engineering calculations and data outputs.

[0362] Obtain a basis for engineering decisions: Produce reliable simulation results for engineers to analyze, evaluate, optimize, and make decisions.

[0363] Verify the design scheme: Evaluate the performance and safety of the product design under different operating conditions through simulation results.

[0364] Beneficial effects:

[0365] Efficiently acquire simulation data: Automated execution process quickly produces the required CAE simulation results, significantly improving efficiency.

[0366] Supporting Engineering Decisions: Providing quantitative and visualized data support to help engineers make more scientific and reliable design decisions.

[0367] Reduce physical testing costs: Virtual simulation can identify and resolve issues early in the design process, reducing the need for expensive physical prototype testing.

[0368] Accelerate product development cycles: Rapidly iterate through simulation-design-optimization cycles to shorten time to market.

[0369] Improve product performance and reliability: Through repeated simulation and optimization, improve various performance indicators and mitigate risks.

[0370] Taking a specific simulation task of "predicting the fatigue life of automotive parts" as an example, we will explain in detail the simulation process and computer-aided engineering simulation results.

[0371] Example scenario: fatigue life prediction of automotive brake calipers. Suppose an automaker wants to predict whether its newly designed brake calipers will fail due to fatigue under long-term use and optimize its structure to extend its life.

[0372] 1. Simulation Workflow:

[0373] In the system, users will build a complete "brake caliper fatigue life prediction" simulation process by dragging and connecting plug-in icons through the graphical user interface.

[0374] Key components of the simulation process (target business component or third-party business component):

[0375] The geometry import and cleanup plugin (preprocessing core layer, which may be a custom business plugin or adapted to HyperMesh, etc.) is used to import the CAD model of the brake caliper and perform necessary geometry repair and simplification.

[0376] Position in the process: The starting point of the process, receiving the original CAD file (such as .step or .iges).

[0377] The meshing plugin (preprocessing core layer, possibly a third-party business plugin adapted to HyperMesh or ANSYS Meshing) is used to discretize the cleaned brake caliper geometry model into a finite element mesh, preparing it for subsequent structural analysis.

[0378] Position in the process: After geometry cleanup, output mesh files (such as .fem or .msh).

[0379] The material property definition plugin (pre-processing core layer, custom business plugin) is used to define the material properties of the brake caliper (such as the elastic modulus, yield strength, and fatigue curve data of steel).

[0380] Its position in the process: independent of grid division, but its results must be associated with the grid.

[0381] The load and boundary condition application plugin (preprocessing core layer, custom business plugin) is used to simulate the stress conditions (such as braking force, temperature changes) and constraint conditions (such as fixed mounting points) of the brake caliper in actual operation.

[0382] Position in the process: parallel to or after mesh and material definition.

[0383] The structural static / transient analysis solver plugin (solver core layer, possibly a third-party business plugin adapted to Abaqus Standard / Explicit) is used to calculate the stress, strain, and displacement distribution of the brake caliper under single or multiple load conditions based on the mesh, material, load, and boundary conditions.

[0384] Its position in the process: Receive all preprocessing results and perform core calculations.

[0385] The fatigue life calculation plugin (post-processing core layer, which may be a custom business plugin or adapted to third-party tools such as Fatigue-Lab) is used to calculate fatigue damage and life prediction at various locations of the brake caliper based on the stress history obtained from structural analysis and the fatigue characteristic curve of the material.

[0386] Position in the process: after the structural analysis solver.

[0387] The results visualization and report generation plugin (post-processing core layer, custom business plugin or adapted to ParaView / EnSight) is used to graphically display fatigue analysis results (such as fatigue life cloud map, fatigue hotspots) and generate reports containing key data and analysis conclusions.

[0388] Position in the process: The end point of the process, where all calculation results are received.

[0389] An example of a “simulation process”:

[0390] code snippet

[0391] graph TD

[0392] A [Brake Caliper CAD File Import] --> B (Geometry Import and Cleanup Plugin)

[0393] B --> C (Mesh Generation Plugin)

[0394] C --> D (Material Property Definition Plugin)

[0395] C --> E (Load and Boundary Condition Application Plugin)

[0396] D --> F (Structural Static / Transient Analysis Solver Plugin)

[0397] E->F

[0398] F --> G (Fatigue Life Calculation Plugin)

[0399] G->H (Results Visualization and Report Generation Plugin)

[0400] In this process, each box and rounded corner box represents a "target plugin" called via API. Arrows indicate the data flow and call sequence. The system will call the API of each plugin sequentially according to this graphically defined sequence to execute the corresponding function.

[0401] 2. Computer-Aided Engineering Simulation Results (CAE Simulation Results): After the above "Brake Caliper Fatigue Life Prediction" simulation process is successfully completed, the system will generate a series of computer-aided engineering simulation results. These results are the key basis for engineers to conduct design evaluation and decision-making.

[0402] Through these diverse simulation results, engineers can gain a comprehensive understanding of the performance bottlenecks of brake calipers, guide structural optimization, and ensure that products meet design requirements and are competitive in the market.

[0403] To enable those skilled in the art to better understand the embodiments of the present invention, an example is used below to illustrate the embodiments of the present invention.

[0404] refer to Figure 2 , Figure 2 This is a flowchart illustrating a method for generating computer-aided engineering simulation results provided in an embodiment of the present invention;

[0405] S1, Vertical Domain Shelving System Definition Layer:

[0406] 1. Domain Requirements Analysis: For specific vertical domains (such as aerospace structural simulation, automotive fluid dynamics simulation, etc.), collect simulation standards and specifications, commonly used CAE software tools, typical simulation processes, and special requirements for that domain. For example, the aerospace structural simulation field has high requirements for model accuracy and computational efficiency, and often uses solvers such as Nastran; the automotive fluid dynamics simulation field focuses on handling complex geometric models and turbulence simulation, and often uses software such as Fluent.

[0407] 2. Hierarchical Structure Definition: Based on domain requirements, adjust and refine the module division according to the core hierarchy of the shelving system. For example, in the field of aerospace structural simulation:

[0408] The preprocessing layer can add a composite material modeling submodule to define properties such as the layup direction and thickness of composite materials;

[0409] The solver layer can be specially set up with a fatigue analysis solver submodule.

[0410] Determine the hierarchical relationships and dependencies between modules, and construct the hierarchical structure tree of the shelving system in this vertical field.

[0411] A shelf system is an analogy in CAE simulation software architecture, used to systematically categorize and organize the various functional modules, components, and tools of the software, much like shelves in a supermarket. Its core idea is to divide the functionality of CAE simulation software into different levels, modules, or functional blocks, thus forming a clear and standardized framework. This allows developers to "place" their developed modules or functional components in specific shelf locations, enabling tight integration with other components to build a complete and scalable simulation software system. Essentially, a shelf system is a software functional architecture.

[0412] 3. API Customization: Extending and customizing the general API to meet the specific needs of vertical industries. For example, in the field of automotive crash simulation, the boundary condition definition API of the physical modeling module needs to add an interface for defining collision loads, supporting the setting of parameters such as collision speed and collision angle; the data extraction API of the post-processing layer needs to add the function of extracting the acceleration and stress-time curves of key components during the collision process.

[0413] S2, Vertical Domain Application Layer:

[0414] 1. Application Scenario Analysis: Identify typical application scenarios in this vertical field, such as static strength analysis of airfoil structures in the aerospace industry and flow field analysis of engine cooling systems in the automotive industry. For each application scenario, determine the required rack system modules and APIs.

[0415] 2. Application Function Construction: Based on the modules and APIs provided by the shelving system, and combined with the needs of the application scenarios, specific application functions are constructed. For example, in the static strength analysis scenario of the wing structure, the geometry processing module of the preprocessing layer is called to import and clean the model, the mesh generation module generates a high-quality finite element mesh, and the physical modeling module defines material properties and boundary conditions (such as displacement constraints at the wing root and aerodynamic loads); the solver layer calls the structural mechanics statics solver to perform calculations; the post-processing layer calls the result visualization module to display stress and displacement contour maps, and the data extraction module extracts the location and value of the maximum stress.

[0416] 3. User Interface Design:

[0417] Design a user-friendly interface based on the operating habits and needs of users in the vertical industry. The interface should intuitively display application functions, facilitating user operations such as model import, parameter setting, simulation submission, and result viewing. For example, in an automotive fluid dynamics simulation application interface, a dedicated geometry model preprocessing panel, a mesh generation parameter configuration dialog box, and a flow field visualization result display window should be provided.

[0418] S3, Task Orchestration Layer:

[0419] 1. Low-code platform design:

[0420] a. Visual Process Editing: Provides a canvas-style operation area where users can drag and drop modular components (such as preprocessing components, solver components, and postprocessing components) from the shelving system onto the canvas, and define data transfer and process sequence between components by connecting them. Supports operations such as copying, deleting, and editing properties of components.

[0421] b. Parameter Configuration: Each task node (module component) provides a parameter configuration interface, allowing users to set the required input parameters for that component (such as the chamfer size threshold for geometry cleanup, the mesh size for mesh generation, etc.), and specify the storage location and format of the output parameters. For task nodes that require specifying CAE software tools, a drop-down menu selection list is provided, displaying the registered and available tools.

[0422] c. Process control: Supports complex process control logic such as conditional branching (e.g., selecting different post-processing processes based on whether the simulation results meet a certain condition) and loop structures (e.g., performing loop simulations on multiple operating conditions), which can be configured visually.

[0423] d. Process Management: Enables saving, loading, and version management of processes. Users can save designed simulation processes as templates for easy and quick access in similar projects later. It also supports viewing historical versions and modification records of processes.

[0424] 2. Task orchestration implementation:

[0425] Once the user completes the process design and parameter configuration, the task orchestration layer parses the process into an executable sequence of tasks. For each task, it generates corresponding task invocation instructions based on the specified CAE software tool and passes the required input data. During task execution, the system monitors the task status in real time (e.g., running, successful, failed) and provides error messages and retry mechanisms in case of task failure.

[0426] S4, Interface Definition Layer:

[0427] 1. REST API Specification:

[0428] a. URL Design: Use a unified URL format, such as rs:vertical-domain module operation, where rs represents a custom communication protocol, vertical-domain represents the vertical domain name, module represents the module name, and operation represents the specific operation (such as geometry cleanup, mesh generation, etc.).

[0429] b. Request method: Select the appropriate communication protocol request method according to the operation type. For example, GET is used to obtain data (such as obtaining geometric model information), POST is used to submit data (such as submitting a geometry cleanup request), PUT is used to update data, and DELETE is used to delete data.

[0430] c. Parameter Format: Both request and return parameters use common formats such as JSON to ensure data readability and cross-platform compatibility. Define a unified parameter structure, including fields such as request identifier, input data, and configuration parameters.

[0431] d. Return value format: Successful responses include a status code (e.g., 200 for success), returned data, and a message description; failure responses include a status code (e.g., 400 for parameter error, 500 for internal server error), an error code, and an error message, facilitating error handling by the client.

[0432] Interface example:

[0433] Taking the collection cleanup interface as an example:

[0434]

[0435]

[0436] S5, Plugin Adaptation Layer:

[0437] 1. Visual Orchestration Tool: Provides a visual interface for designing adaptation processes. Users can drag and drop pre-built adaptation components (such as data type conversion components, data format conversion components, and logic judgment components) to define the conversion logic between the interface definition layer and the capability interfaces of the business plugin layer. The adaptation process can be saved as an adaptation template for easy reuse.

[0438] 2. Pre-built adaptation logic;

[0439] 3. Data Type Conversion: Supports automatic conversion between common data types, such as integers and floating-point numbers, strings and numbers, and conversions between different enumeration types. For example, it can convert floating-point grid size parameters in the interface definition layer into integer parameters required by the business plugin layer (unit conversion).

[0440] 4. Data Format Conversion: Enables conversion between different data formats, such as JSON to XML, and STL to STEP geometric file formats. Provides a general format conversion engine and supports custom format conversion rules.

[0441] 5. Data Structure Mapping: This addresses inconsistencies between the data structures of the interface definition layer and the business plugin layer. By configuring mapping relationships, fields in the source data structure are mapped to corresponding fields in the target data structure. For example, the "material_properties" field in the interface definition layer can be mapped to the various properties of the "material" object in the business plugin layer.

[0442] 6. Script Adaptation Development: For scenarios requiring in-depth logic code for adaptation, a Python script development environment is provided. Users can write Python scripts to implement complex adaptation logic, such as processing data according to specific business rules or calling external libraries for special calculations. The script development environment supports code editing, debugging, running, and version management. Scripts can be combined with visual orchestration-based adaptation processes to achieve flexible adaptation functionality.

[0443] S6, Service Plug-in Layer:

[0444] 7. Plugin Interface Specification: Define a unified plugin interface, including an initialization interface (for plugin initialization configuration), a data receiving interface (for receiving input data passed from the task orchestration layer), a function execution interface (for executing the specific functions of the plugin, such as geometry cleanup, solution calculation, etc.), a result return interface (for returning the processing results to the plugin adaptation layer), and an error handling interface (for handling errors during plugin execution and returning error information).

[0445] 8. Plugin Registration Mechanism: A plugin registry center is established. Plugin developers need to register their developed plugins in the registry center, providing basic information such as plugin name, domain, supported functions, dependent environments, etc., interface description, and invocation method. When the task orchestration layer specifies a CAE software tool for a task, it retrieves a list of available plugins from the registry center.

[0446] 9. Plugin Communication Method: Plugins and the framework interact through a unified communication protocol, supporting network-based remote communication (such as HTTP and TCP) and local inter-process communication (such as shared memory and pipes). This ensures the independence and portability of plugins, facilitating the encapsulation of CAE software tools and kernel modules from different sources into plugins for integration into the framework.

[0447] 10. Plugin example, taking a structural mechanics solver plugin as an example:

[0448] 11. Plugin Basic Information: Named "StructuralSolverPlugin", it belongs to the field of structural mechanics simulation, supports static and dynamic analysis functions, and depends on the ABAQUS solver environment.

[0449] 12. Data receiving interface: Receives JSON format data containing information such as mesh data, material properties, and boundary conditions.

[0450] 13. Function execution interface: Calls the ABAQUS solver to perform calculations based on the input data and generates a solution result file.

[0451] The result return interface converts the stress, displacement, and other data in the solution results into a unified format defined by the framework and returns it to the plugin adaptation layer.

[0452] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0453] Reference Figure 3 The diagram shows a structural block diagram of a computer-aided engineering simulation result generation device provided in an embodiment of the present invention, which may specifically include the following modules:

[0454] The target business type determination module 301 is used to determine the vertical domain type and the target business type of the vertical domain type;

[0455] The business plugin generation module 302 is used to generate business plugins in the core layer for implementing the target business type.

[0456] The third-party business plugin acquisition module 303 is used to acquire third-party computer-aided engineering software for implementing other business types.

[0457] Application Programming Interface (API) building module 304 is used to build an API for implementing the hot-plug functionality of the business plugin and the third-party business plugin.

[0458] The plugin determination module 305 is used to determine the target business plugin and / or the target third-party business plugin based on the target vertical domain type when the user determines the target vertical domain type.

[0459] The computer-aided engineering simulation result generation module 306 is used to call the target business plugin and / or the target third-party business plugin based on the application programming interface to generate computer-aided engineering simulation results.

[0460] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0461] In addition, embodiments of the present invention also provide an electronic device, such as... Figure 4 As shown, it includes a processor 401, a communication interface 402, a memory 403, and a communication bus 404, wherein the processor 401, the communication interface 402, and the memory 403 communicate with each other through the communication bus 404.

[0462] Memory 403 is used to store computer programs;

[0463] When the processor 401 executes the program stored in the memory 403, it implements the computer-aided engineering simulation result generation method described in any of the above embodiments:

[0464] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0465] The communication interface is used for communication between the aforementioned terminal and other devices.

[0466] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0467] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0468] like Figure 5 As shown, in another embodiment of the present invention, a computer-readable storage medium 501 is also provided, which stores instructions that, when run on a computer, cause the computer to execute the computer-aided engineering simulation result generation method described in the above embodiment.

[0469] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

[0470] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0471] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0472] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0473] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0474] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0475] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0476] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for generating computer-aided engineering simulation results, characterized in that, The method is applied to a computer-aided engineering simulation result generation system for computer-aided engineering simulation software, which includes multiple core layers, including: Determine the vertical domain type and the target business type of the vertical domain type; The core layer is used to generate business plugins for implementing the target business type; Acquire third-party computer-aided engineering software and third-party business plugins to implement other business types; Construct an application programming interface for implementing the hot-plug functionality of the business plugin and the third-party business plugin; When a user determines a target vertical domain type, a target business plugin and / or a target third-party business plugin are determined based on the target vertical domain type. Based on the application programming interface, the target business plugin is called, and / or the target third-party business plugin, to generate computer-aided engineering simulation results; The step of constructing the application programming interface for implementing the hot-pluggable functionality of the business plugin and the third-party business plugin includes: Determine a common communication protocol for the business plugin and the third-party business plugin; Determine the module name for the target sub-module used to execute the target business type and the other business types, as well as the vertical domain name corresponding to the target sub-module; A Uniform Resource Locator is generated using the general communication protocol, the module name, and the vertical domain name; The Uniform Resource Locator is used to construct an application programming interface for implementing the hot-plug functionality of the business plugin and the third-party business plugin.

2. The method according to claim 1, characterized in that, Before the step of generating the business plugin for implementing the target business type in the core layer, the method further includes: Determine the shelf system logical structure used to express the hierarchical relationship of the business plugins in the core layer; The vertical domain configuration pattern information DataSchema, which is used to characterize the logical structure of the shelf system for the target business type, is stored in a preset database to generate a manageable data model.

3. The method according to claim 2, characterized in that, The step of generating the business plugin for the core layer to implement the target business type includes: Read the vertical domain configuration schema information (DataSchema) from the database to obtain the target business type; Determine the custom business execution logic for the target business type; According to the preset unified plugin interface specification, the submodule that executes the custom business execution logic is encapsulated as the business plugin.

4. The method according to claim 3, characterized in that, Also includes: Determine the correspondence between the application programming interface and the target submodule, and register the application programming interface to the database based on the correspondence.

5. The method according to claim 2, characterized in that, The generation system includes a graphical user interface (GUI) for displaying the business plugins and / or the third-party business plugins. When a user determines a target vertical domain type, a target business plugin is determined based on that target vertical domain type. And / or, the target third-party business plugin includes: In response to the detection of a selection operation for the business plugin and / or the third-party business plugin, the business plugin and / or the third-party business plugin are identified as the target business plugin and / or the target third-party business plugin.

6. The method according to claim 5, characterized in that, The step of generating computer-aided engineering simulation results by calling the target business plugin based on the application programming interface, and / or the target third-party business plugin, includes: Using the application programming interface, determine the target business plugin, and / or the call sequence of the target third-party business plugin; The target business plugin and / or the target third-party business plugin are added to the simulation process based on the call sequence. The simulation process is executed, and computer-aided engineering simulation results are generated.

7. A computer-aided engineering simulation result generation device, characterized in that, The device is applied to a computer-aided engineering simulation result generation system for computer-aided engineering simulation software, the computer-aided engineering simulation software comprising multiple core layers, including: The target business type determination module is used to determine the vertical domain type and the target business type of the vertical domain type; A business plugin generation module is used to generate business plugins for the core layer to implement the target business type; The third-party business plugin acquisition module is used to acquire third-party computer-aided engineering software for implementing other business types. An application programming interface (API) building module is used to build application programming interfaces for implementing the hot-plug functionality of the business plugin and the third-party business plugin. The plugin determination module is used to determine the target business plugin and / or the target third-party business plugin based on the target vertical domain type when the user determines the target vertical domain type. The computer-aided engineering simulation result generation module is used to call the target business plugin and / or the target third-party business plugin based on the application programming interface to generate computer-aided engineering simulation results; The application programming interface construction module is specifically used for: Determine a common communication protocol for the business plugin and the third-party business plugin; Determine the module name for the target sub-module used to execute the target business type and the other business types, as well as the vertical domain name corresponding to the target sub-module; A Uniform Resource Locator is generated using the general communication protocol, the module name, and the vertical domain name; The Uniform Resource Locator is used to construct an application programming interface for implementing the hot-plug functionality of the business plugin and the third-party business plugin.

8. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-6.

9. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-6.

Images