CAE preprocessing cloud rendering method and system based on Web

Abstract

The invention discloses a CAE (Computer Aided Engineering) preprocessing cloud rendering method and system based on Web, and the method comprises the steps: generating a connection request sent to an intermediate coordination layer when a click operation for a connection button of a Web front-end interface layer is detected, and calling an API (Application Program Interface) under Kubernetes by the intermediate coordination layer to start a special container instance; and when a click operation for a loading model button of the Web front-end interface layer is detected, the intermediate coordination layer sends a task creation request to the special container instance. The special container instance analyzes the task creation request, obtains a model file address and a task operation command, loads a corresponding basic model file from the OSS object storage layer, carries out cloud rendering processing on the basic model file, stores a processed target model file in the OSS object storage layer, and stores the target model file in the OSS object storage layer; and returning the target file address of the target model file and the unique task identifier to the Web front-end interface layer. According to the invention, CAE pre-processing cloud rendering can be realized by using a layered architecture, and the problems of low rendering efficiency and poor cross-platform compatibility are solved.

Description

Technical Field

[0001] This invention relates to the field of computer-aided engineering technology, specifically to a web-based CAE preprocessing cloud rendering method, system, electronic device, and medium. Background Technology

[0002] In the field of Computer-Aided Engineering (CAE), CAE software such as ANSYS, Siemens NX, ABAQUS, and SolidWorks Simulation play a crucial role in engineering design and analysis. Existing software in this category often relies on local computing resources, resulting in low rendering efficiency and difficulty in meeting the rapid visualization needs of large-scale CAE models. While ANSYS's Cloudburst platform and Siemens' MindSphere enhance computing power through cloud resources, they still suffer from insufficient rendering performance and limited real-time collaboration capabilities. Furthermore, these CAE software programs often have poor cross-platform compatibility. When users need to switch between different operating systems and devices, reinstallation and configuration are required, leading to complexity and increased costs.

[0003] Based on the above problems, the applicant proposes the technical solution of this application. Summary of the Invention

[0004] The purpose of this invention is to provide a method, system, electronic device, and medium that can...

[0005] To achieve the above objectives, this invention discloses a web-based CAE preprocessing cloud rendering method, comprising the following steps: When a click operation is detected on the connection button of the Web front-end interface layer, a connection request is generated and sent to the intermediate coordination layer. In response to the connection request, the intermediate coordination layer calls the API interface under Kubernetes to start a dedicated container instance and deploys the Python and SDK development environment in the dedicated container instance. When a click operation is detected on the loading model button of the Web front-end interface layer, the intermediate coordination layer triggers a task creation request and sends the task creation request to the dedicated container instance. The task creation request includes user-inputted task parameter information and a randomly generated unique task identifier. The dedicated container instance parses the task creation request, obtains the model file address and task operation command, and loads the corresponding basic model file from the OSS object storage layer according to the model file address. The basic model file is pre-transmitted to the OSS object storage layer by the Web front-end interface layer. The dedicated container instance performs cloud rendering processing on the basic model file according to the task operation command, stores the processed target model file in the OSS object storage layer, and returns the target file address and task unique identifier of the target model file to the Web front-end interface layer.

[0006] Preferably, bidirectional communication between the Web front-end interface layer and the intermediate coordination layer, between the intermediate coordination layer and the OSS object storage layer, and between the OSS object storage layer and the Web front-end interface layer is achieved through Socket.IO.

[0007] Preferably, the intermediate coordination layer allocates a corresponding dedicated container instance as an isolation container for each task creation request, and deploys data processing services within the isolation container.

[0008] Preferably, the data processing service obtains task parameter information from the task creation request, and the task parameter information includes the model file address, geometry processing type, and mesh generation accuracy.

[0009] Preferably, the intermediate coordination layer is equipped with a resource allocation service and a data processing service. The resource allocation service is used to respond to task creation requests sent by the Web front-end interface layer and allocate isolation containers for user interaction operations. The data processing service is used to perform geometric processing and mesh generation.

[0010] Preferably, the data processing service generates standardized JSON data after processing the CAE model data.

[0011] This invention also discloses a web-based CAE preprocessing cloud rendering system, comprising a web front-end interface layer, an intermediate coordination layer, and an OSS object storage layer. The web front-end interface layer is used to implement user interaction operations based on a standard browser. The intermediate coordination layer deploys a resource allocation service and a data processing service. The resource allocation service is used to respond to task creation requests sent by the web front-end interface layer, allocate isolation containers for user interaction operations, and deploy data processing services within the isolation containers. The data processing service is used to process CAE model data and generate standardized JSON data. The OSS object storage layer is used to store model data, intermediate rendering results, and various historical versions of model data through OSS objects.

[0012] Preferably, the web-based CAE preprocessing cloud rendering system executes the above-described web-based CAE preprocessing cloud rendering method.

[0013] The present invention also discloses an electronic device, including one or more processors, a memory, and a computer program, which, when executed by the processor, is used to implement the above-described Web-based CAE preprocessing cloud rendering method.

[0014] The present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the above-described Web-based CAE preprocessing cloud rendering method.

[0015] Compared with the prior art, the present invention has the following beneficial effects: The web-based CAE preprocessing cloud rendering method and system provided in this invention achieves CAE preprocessing cloud rendering through a layered architecture consisting of a front-end layer, a middleware coordination layer, a data processing layer, and a storage layer, solving the problems of low rendering efficiency and poor cross-platform compatibility. Front-end interaction is achieved through a web browser, eliminating the need for users to install local CAE software or high-performance graphics workstations; they can complete preprocessing operations such as geometric modeling and mesh generation using only a standard browser, significantly reducing the barrier to entry and hardware dependence for CAE rendering.

[0016] The following will further explain the concept, specific structure, and technical effects of the present invention in conjunction with the accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the Web-based CAE preprocessing cloud rendering method of this invention.

[0018] Figure 2 This is a schematic diagram of the data flow in the Web-based CAE preprocessing cloud rendering method of this invention.

[0019] Figure 3 This is a schematic diagram of model rendering for the Web-based CAE preprocessing cloud rendering method in this invention. Detailed Implementation

[0020] To make the technical means, inventive features, objectives, and effects of the invention readily understandable, the invention is further illustrated below with reference to specific figures. However, the invention is not limited to the embodiments described below.

[0021] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings of this specification are only used to complement the content disclosed in the specification for those skilled in the art to understand and read, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0022] To address the issues of low rendering efficiency in traditional CAE software and poor cross-platform compatibility and limited real-time collaboration capabilities in cloud-based rendering software, this invention proposes a web-based CAE preprocessing cloud rendering method and system. Through a layered architecture, it achieves collaboration between lightweight interaction on the browser side and high-performance rendering in the cloud, significantly improving the visualization efficiency of large-scale CAE models and the ability to handle concurrent multi-user processing.

[0023] The first embodiment of the present invention provides a web-based CAE preprocessing cloud rendering method, such as... Figure 1 As shown, the method includes the following steps: Step S1: When a click operation is detected on the connection button of the Web front-end interface layer, a connection request is generated and sent to the intermediate coordination layer. In response to the connection request, the intermediate coordination layer calls the API interface under Kubernetes to start a dedicated container instance and deploys the Python and SDK development environment in the dedicated container instance.

[0024] Specifically, the web front-end interface layer is implemented based on a browser, using TypeScript to build the user interface. The user interface allows users to set various configuration parameters for model rendering, such as parameters related to mesh display, cloud map display, vector map display, and parameters related to slicing and cross-sectioning. Users can freely interact with and configure these parameters in the browser to determine the rendering needs of the CAE model. Before performing cloud rendering, users first need to initiate a connection in the browser, which includes a connection button. Clicking this button generates an HTTP-style connection request. The web front-end interface layer establishes a persistent connection with the intermediate coordination layer via Socket communication, receiving user commands in real time, and transmitting connection requests to the intermediate coordination layer through the persistent connection.

[0025] The middle coordination layer responds to the connection request by calling the Kubernetes API to start a dedicated container instance. The middle coordination layer is implemented using TypeScript and the kubernetes-client library. First, the @kubernetes / client-node library is installed, kubeconfig is configured, and the container instance is created using the Kubernetes API. This container instance can perform CAE computing, data processing, or other specialized tasks. Then, Python and SDK development environments are deployed in the dedicated container instance to facilitate task execution.

[0026] Step S2: When a click operation is detected on the loading model button of the Web front-end interface layer, the intermediate coordination layer triggers a task creation request and sends the task creation request to the dedicated container instance. The task creation request includes user-inputted task parameter information and a randomly generated unique task identifier.

[0027] Specifically, if CAE model cloud rendering is required, the CAE model needs to be loaded after connection. At this point, the user needs to click the "Load Model" button in the web front-end interface layer. The web front-end interface layer receives user input to form task parameter information and randomly generates a unique task identifier ID that can uniquely identify the task. The middle coordination layer responds to the click event of the "Load Model" button, triggers a task creation request, and sends the task creation request to a dedicated container instance.

[0028] To support multi-user collaborative processing, the intermediate coordination layer creates and allocates a corresponding dedicated container instance as an isolation container for each task request, and deploys data processing services within the isolation container. Task parameter information includes various configuration information such as model file path, geometry processing type, and mesh generation accuracy, which is transmitted in real-time to the Python service running in the container via a persistent connection.

[0029] In one example, the middle coordination layer deploys a resource allocation service and a data processing service. The resource allocation service responds to task creation requests sent by the web front-end interface layer, allocating isolated containers for user interaction. The data processing service performs geometric processing and mesh generation. The resource allocation service is the scheduling hub, receiving resource request requests from the front-end, calling the underlying container orchestration Kubernetes API, and allocating or starting an isolated container for the task. The data processing service is deployed within the container. The data processing service handles business requirements such as mesh and boundary conditions for CAE model data, and then generates standardized JSON data for subsequent data transmission.

[0030] Step S3: The dedicated container instance parses the task creation request, obtains the model file address and task operation command, and loads the corresponding basic model file from the OSS object storage layer according to the model file address. The basic model file is pre-transmitted to the OSS object storage layer by the Web front-end interface layer.

[0031] Specifically, the web frontend sends task parameters and a task ID to the data processing service via the socket protocol. The dedicated container instance parses the task parameters and unique task identifier ID from the task creation request using the deployed data processing service. The Python service within the dedicated container instance receives the task request from the frontend and loads the corresponding basic model file from the OSS object storage layer based on the task's unique identifier ID. This basic model file is uploaded by the frontend and stored in the OSS object storage layer. The dedicated container instance locates the target file based on the task's unique identifier ID and downloads it to a local temporary directory within the container for processing via the API.

[0032] Step S4: The dedicated container instance performs cloud rendering processing on the basic model file according to the task operation command, stores the processed target model file in the OSS object storage layer, and returns the target file address and task unique identifier of the target model file to the Web front-end interface layer.

[0033] Specifically, a dedicated instance container performs cloud rendering on the base model file, using a built-in API to call Python service scripts to execute specific geometric processing or mesh generation commands. After processing, the result file is formatted into a target model file and sent to the OSS object storage layer along with the task ID. The storage address and task ID are then returned to the web frontend. The standard format result file includes processed mesh data, log information, intermediate process files, etc., all saved in a structured manner for easy download, analysis, or secondary processing.

[0034] In one example, such as Figure 2 The data flow diagram shows that the web front-end interface layer requests a connection to the engine service to reach the resource allocation service for resource allocation, scheduling, and monitoring. The resource allocation service is the resource allocation service of the intermediate coordination layer. The resource allocation service calls the Kubernetes API to allocate or create engine services. The Kubernetes API is the API interface under Kubernetes, and the engine service is the dedicated container instance launched based on the connection request from the front-end. The resource allocation service monitors the workload status through Kubernetes. This workload deploys a Python and SDK development environment, which is a dedicated container instance launched based on the connection request from the front-end. The engine service is the data processing service, handling geometric processing and mesh generation commands. The processed model files and intermediate processing files are stored in the OSS object storage layer.

[0035] like Figure 3 In the model rendering process shown, the user requests a connection to the engine through the browser, calls the Kubernetes API to start the container, and then clicks to load the model through the browser, generating a task ID. The front end sends the partitioning task parameters via socket. The process is then handled by a Python service within the container, loading the model file from OSS and storing the standard format result file and task ID in the OSS object storage layer.

[0036] In one example, the engine service's resource scheduling is used to respond to users' engine service requests and to dynamically create and configure engine instances in a cloud-native environment. The specific steps are as follows: First, users initiate an engine service request by calling the API interface / engine / apply through the front-end interface. The interface is received by the Cloud Render Controller component, which is located in the sh-engine-controller-ns namespace and is used to handle the engine instance creation request.

[0037] Then, user requests enter the system network entry point through Traefik Ingress. Traefik Ingress, as a reverse proxy gateway, is responsible for receiving external HTTP requests and performing initial route distribution.

[0038] Traefik Ingress forwards requests to the AccessController Middleware module and performs route matching and authentication. The authentication process includes user permission verification, session verification, and access policy checks to ensure that only legitimate users can access the engine service.

[0039] AccessController Middleware queries the MySQL RDS database to verify user permissions and task quotas. The database stores metadata such as user information, task history, and resource usage records, and supports real-time status queries and policy judgments.

[0040] If authentication is successful, AccessController will forward the request to the target Engine Pod (located in the 3d-engine namespace). The Engine Pod is a service instance that actually runs the geometry processing and mesh generation logic and has processing capabilities.

[0041] The Cloud Render Controller calls the Kubernetes API to send resource configuration instructions to the Kubernetes control plane. After the controller listens for the / engine / apply request, it triggers an automated process to create new workload resources through the k8s API.

[0042] The Kubernetes control plane creates resource objects such as Deployment, Service, and IngressRoute according to instructions, deploys engine service instances, and deploys resources in the 3d-engine namespace to achieve automatic scaling, load balancing, and network exposure of services.

[0043] Finally, the Cloud Render Controller persists the metadata of this operation (such as task ID, Pod name, resource path, etc.) to MySQL RDS. The metadata is used for subsequent task tracking, status monitoring, log auditing, and resource reclamation management.

[0044] This embodiment utilizes a web browser for front-end interaction, eliminating the need for users to install local CAE software or high-performance graphics workstations. A standard browser is sufficient to complete pre-processing operations such as geometric modeling and mesh generation, significantly lowering the barrier to entry and reducing hardware dependencies for CAE rendering. The layered architecture—front-end, middleware coordination, data processing, and storage—ensures clear responsibilities and loose coupling between layers, facilitating independent development, deployment, and horizontal scaling. For real-time performance, Socket.IO enables real-time bidirectional communication, allowing front-end operations to instantly trigger back-end processing and push rendering results back to the browser in real time. This supports smooth user interaction and visual feedback, improving operational efficiency and user experience. Regarding data processing, a Python service provides unified parsing and structured processing of CAE model data (such as meshes and boundary conditions), outputting standardized JSON format for easy front-end and back-end data exchange, third-party system integration, and subsequent simulation process automation. For data storage, Object Storage Service (OSS) supports multi-version historical retention of CAE model files, ensuring data traceability and rollback, and achieving reliable data management.

[0045] A second embodiment of the present invention provides a web-based CAE preprocessing cloud rendering system, including a web front-end interface layer, an intermediate coordination layer, and an OSS object storage layer. The web front-end interface layer is used to implement user interaction operations based on a standard browser. The intermediate coordination layer deploys a resource allocation service and a data processing service. The resource allocation service is used to respond to task creation requests sent by the web front-end interface layer, allocate isolation containers for user interaction operations, and deploy data processing services within the isolation containers. The data processing service is used to process CAE model data and generate standardized JSON data. The OSS object storage layer is used to store model data, intermediate rendering results, and various historical versions of model data through OSS objects.

[0046] The Web front-end interface layer communicates bidirectionally with the intermediate coordination layer, with the intermediate coordination layer and the OSS object storage layer, and with the OSS object storage layer and the Web front-end interface layer via Socket.IO.

[0047] When a click on the "Connect" button in the web front-end interface layer is detected, a connection request is generated and sent to the intermediate coordination layer. In response to this request, the intermediate coordination layer calls the Kubernetes API to start a dedicated container instance, within which a Python and SDK development environment are deployed. When a click on the "Load Model" button in the web front-end interface layer is detected, the intermediate coordination layer triggers a task creation request and sends it to the dedicated container instance. This task creation request includes user-inputted task parameters and a randomly generated unique task identifier.

[0048] The dedicated container instance parses the task creation request, obtains the model file address and task operation command, and loads the corresponding basic model file from the OSS object storage layer based on the model file address. This basic model file is pre-transmitted to the OSS object storage layer by the web front-end interface layer. The dedicated container instance performs cloud rendering processing on the basic model file according to the task operation command, stores the processed target model file in the OSS object storage layer, and returns the target file address and unique task identifier of the target model file to the web front-end interface layer.

[0049] Since the first embodiment corresponds to this embodiment, this embodiment can be implemented in conjunction with the first embodiment. The relevant technical details mentioned in the first embodiment remain valid in this embodiment, and the technical effects achievable in the first embodiment can also be achieved in this embodiment. To reduce repetition, they will not be repeated here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the first embodiment.

[0050] A third embodiment of the present invention provides an electronic device, including a processor, a memory, and a computer program, wherein the computer program, when executed by the processor, is used to implement the method described in the first embodiment.

[0051] A fourth embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the method described in the first embodiment.

[0052] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A Web-based CAE preprocessing cloud rendering method, characterized in that, Includes the following steps: When a click operation on the connection button of the Web front-end interface layer is detected, a connection request is generated and sent to the intermediate coordination layer. In response to the connection request, the intermediate coordination layer calls the API interface under Kubernetes to start a dedicated container instance and deploys the Python and SDK development environment in the dedicated container instance. When a click operation is detected on the loading model button of the Web front-end interface layer, the intermediate coordination layer triggers a task creation request and sends the task creation request to the dedicated container instance. The task creation request includes user-inputted task parameter information and a randomly generated unique task identifier. The dedicated container instance parses the task creation request, obtains the model file address and task operation command, and loads the corresponding basic model file from the OSS object storage layer according to the model file address. The basic model file is pre-transmitted to the OSS object storage layer by the Web front-end interface layer. The dedicated container instance performs cloud rendering processing on the basic model file according to the task operation command, stores the processed target model file in the OSS object storage layer, and returns the target file address and task unique identifier of the target model file to the Web front-end interface layer.

2. The Web-based CAE preprocessing cloud rendering method according to claim 1, characterized in that, The Web front-end interface layer communicates bidirectionally with the intermediate coordination layer, with the intermediate coordination layer and the OSS object storage layer, and with the OSS object storage layer and the Web front-end interface layer via Socket.IO.

3. The Web-based CAE preprocessing cloud rendering method according to claim 1, characterized in that, The intermediate coordination layer creates a request for each task and assigns a corresponding dedicated container instance as an isolation container, within which data processing services are deployed.

4. The Web-based CAE preprocessing cloud rendering method according to claim 3, characterized in that, The data processing service obtains task parameter information from the task creation request, which includes the model file address, geometry processing type, and mesh generation accuracy.

5. The Web-based CAE preprocessing cloud rendering method according to claim 1, characterized in that, The intermediate coordination layer deploys a resource allocation service and a data processing service. The resource allocation service is used to respond to task creation requests sent by the Web front-end interface layer and allocate isolation containers for user interaction operations. The data processing service is used to perform geometric processing and mesh generation.

6. The Web-based CAE preprocessing cloud rendering method according to claim 5, characterized in that, The data processing service processes the CAE model data and generates standardized JSON data.

7. A Web-based CAE preprocessing cloud rendering system, characterized in that, It includes a web front-end interface layer, a middleware coordination layer, and an OSS object storage layer. The web front-end interface layer is used to implement user interaction operations based on a standard browser. The middleware coordination layer deploys resource allocation services and data processing services. The resource allocation service is used to respond to task creation requests sent by the web front-end interface layer, allocate isolation containers for user interaction operations, and deploy data processing services within the isolation containers. The data processing service is used to process CAE model data and generate standardized JSON data. The OSS object storage layer is used to store model data, rendering intermediate results, and various historical versions of model data through OSS objects.

8. The Web-based CAE preprocessing cloud rendering system according to claim 7, characterized in that, Perform the Web-based CAE preprocessing cloud rendering method as described in any one of claims 1 to 6.

9. An electronic device comprising one or more processors, a memory, and a computer program, wherein the computer program, when executed by the processor, is used to implement the Web-based CAE preprocessing cloud rendering method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, is used to implement the Web-based CAE preprocessing cloud rendering method as described in any one of claims 1 to 6.

Images