Vehicle simulation method and device based on containerization technology and medium

Abstract

The invention provides a containerization technology-based vehicle simulation method and device and a medium, and the method comprises the steps: responding to an initial operation instruction from a terminal, sending a container group creation request to a container management platform, calling a container platform interface to create a container group, loading a vehicle simulation resource, and obtaining a generated initial state parameter, if the container group is successfully created, establishing a persistent connection channel with the terminal, generating first state response data based on the initial state parameters, sending the first state response data to the terminal through the persistent connection channel to create and render a vehicle three-dimensional model, receiving a user operation instruction and forwarding the user operation instruction to a simulation engine in a target container group, receiving dynamic state response data generated by the simulation engine, and sending the dynamic state response data to the terminal to update the rendering state of the vehicle three-dimensional model; according to the method, addition of a new vehicle type or functions can be supported without front-end code modification, and the flexibility and expansibility of a simulation system are improved.

Description

Technical Field

[0001] The present invention relates to the field of simulation technology, and in particular to a vehicle simulation method, device, and medium based on containerization technology. Background Art

[0002] Existing vehicle simulation systems typically rely on static, prefabricated 3D model interfaces that lack real-time interaction with back-end services. Users cannot obtain instant dynamic feedback or update vehicle component status through simple operational commands. Furthermore, adding new models or features often requires upgrading and revising the front-end code, which not only increases development and maintenance costs but also reduces the flexibility and scalability of the simulation system.

[0003] Traditional solutions lack effective container management mechanisms, resulting in irrational resource allocation and difficulty achieving efficient isolation. This leads to significant performance degradation when handling concurrent requests. Therefore, a new solution is urgently needed to overcome these issues in existing technologies. Summary of the Invention

[0004] The present invention provides a vehicle simulation method, device and medium based on containerization technology to solve the technical problems of existing vehicle simulation systems such as lack of real-time interaction capabilities, the need to upgrade front-end code for adding new models or functions, and performance bottlenecks caused by unreasonable resource allocation.

[0005] The present invention provides a vehicle simulation method based on containerization technology, which is executed on the cloud and includes: sending a container group creation request to a container management platform in response to an initial operation instruction from a terminal; calling the container management platform to create a target container group and load vehicle simulation resources, and obtaining initial state parameters generated by the vehicle simulation resources, wherein the initial state parameters include default configuration parameters of vehicle components; if the container group is successfully created, establishing a persistent connection channel with the terminal, and generating first state response data based on the initial state parameters; sending the first state response data to the terminal based on the persistent connection channel, so that the terminal creates and renders a three-dimensional vehicle model according to the default configuration parameters; receiving an update operation instruction sent by the terminal, forwarding the update operation instruction to a simulation engine in the target container group, and receiving dynamic state response data generated by the simulation engine based on the update operation instruction, wherein the dynamic state response data includes a change result to the initial state parameters; sending the dynamic state response data to the terminal based on the persistent connection channel to update the rendering state of the three-dimensional vehicle model.

[0006] In one embodiment of the present invention, loading vehicle simulation resources includes: obtaining a simulation resource file of a target vehicle model and loading the simulation resource file into a shared storage space of a container group; calling an initialization interface in the simulation resource file to generate the initial state parameters, and the initial state parameters serve as the only data source for the first state response data, and are used to drive the initial rendering of the vehicle three-dimensional model.

[0007] In one embodiment of the present invention, forwarding an update operation instruction to a simulation engine in a target container group includes: forwarding the update operation instruction to the simulation engine in the target container group, including: extracting an action identifier and a parameter value contained in the update operation instruction as instruction parameters; parsing a container group identifier and a service identifier in the update operation instruction, wherein the service identifier is derived from registration information in a vehicle simulation resource; locating a target container group according to the container group identifier, and determining a target simulation engine running in the target container group; encapsulating the service identifier and the instruction parameters into a message body that complies with an inter-container communication protocol, and forwarding the message body to the target simulation engine based on the inter-container communication protocol to generate dynamic state response data.

[0008] In one embodiment of the present invention, generating dynamic state response data includes: a simulation engine calling a dynamic link library in a container according to a service identifier; executing the dynamic link library to generate state change data, wherein the state change data includes a correction value for the initial state parameter; and combining the state change data with the container group identifier and the service identifier into dynamic state response data for updating the rendering state of the vehicle three-dimensional model.

[0009] In one embodiment of the present invention, after sending dynamic status response data to the terminal, it also includes: in response to the resource update notification issued by the image repository, stopping the operation of the simulation engine in the target container group; replacing the current vehicle simulation resource with an updated simulation resource file, wherein the updated simulation resource file includes a new version of the initialization interface and a dynamic link library; calling the new version of the initialization interface to generate new initial state parameters, wherein the new initial state parameters overwrite the default configuration values ​​of the original initial state parameters; generating update response data based on the new initial state parameters, and sending the update response data to the terminal based on the persistent connection channel to trigger the resetting of the vehicle three-dimensional model rendering state.

[0010] The present invention also provides a vehicle simulation method based on containerization technology, which is executed based on a terminal and includes: sending a container group creation request to the cloud in response to an initial operation instruction; receiving the container group status and initial state parameters returned by the cloud, wherein the initial state parameters include the default configuration values ​​of the vehicle components; if the container group is successfully created, establishing a persistent connection channel with the cloud; receiving first state response data based on the persistent connection channel, and triggering the initial rendering of the vehicle three-dimensional model based on the first state response data; sending an update operation instruction to the cloud based on the persistent connection channel, and receiving dynamic state response data, wherein the dynamic state response data includes the change result of the initial state parameters; and updating the rendering state of the vehicle three-dimensional model according to the dynamic state response data.

[0011] In one embodiment of the present invention, the sending of the update operation instruction includes: capturing the interaction event type and event parameters in response to an operation event triggered by a user on an interactive component of a three-dimensional vehicle model; generating a target action identifier based on a preset mapping relationship between the interaction event type and the action identifier; extracting the parameter value to be modified of the target vehicle component from the event parameters, and encapsulating the target action identifier, the actual parameter value to be modified and the current container group identifier into a structured operation instruction, wherein the current container group identifier is derived from the received container group status information; sending the structured operation instruction to the cloud based on the persistent connection channel to drive the cloud to call the simulation engine of the target container group according to the target action identifier, execute the state change based on the parameter value to be modified, and generate dynamic state response data containing the state change result.

[0012] In one embodiment of the present invention, after receiving the dynamic state response data, it also includes: receiving the update response data sent by the cloud based on the persistent connection channel, the update response data is generated by the cloud after responding to the resource update notification, based on the new initial state parameters generated by the new version of the simulation resource; parsing the update response data to obtain the new initial state parameters, the new initial state parameters overwriting the original initial state parameters stored in the terminal; resetting the vehicle three-dimensional model rendering state based on the new initial state parameters, and clearing the historical operation instruction cache associated with the target container group, the historical operation instruction cache containing the sent action identification sequence.

[0013] Beneficial effects of the present invention: The vehicle simulation method, device and medium based on containerization technology proposed in the present invention realize comprehensive support for vehicle simulation through cloud execution. New models or functions can be added without modifying the front-end code, which greatly improves the flexibility and scalability of the simulation system. Secondly, the container management platform is used to create container groups and load vehicle simulation resources, which ensures the effective isolation and efficient utilization of resources and reduces the performance bottleneck caused by concurrent requests. Furthermore, real-time two-way communication is achieved with the help of persistent connection channels, so that users can instantly obtain the results of changes in vehicle status and dynamically update the rendering status of the three-dimensional model, enhancing interactivity and realism. Ultimately, this method not only simplifies the simulation system architecture and reduces maintenance costs, but also provides users with a smoother and more realistic vehicle simulation experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be derived from these drawings without inventive effort.

[0015] In the attached figure: Figure 1 A schematic diagram of an implementation environment for a vehicle simulation method based on containerization technology provided by an embodiment of the present invention; Figure 2 This is a diagram of the overall system architecture of a vehicle simulation method based on containerization technology provided in one embodiment of the present invention; Figure 3 This is a flow chart of a vehicle simulation method based on containerization technology provided in one embodiment of the present invention implemented on the cloud; Figure 4 This is a flow chart of a vehicle simulation method based on containerization technology provided in one embodiment of the present invention implemented on a terminal; Figure 5 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0016] The following describes the embodiments of the present invention through specific examples. Those skilled in the art will readily understand the other advantages and benefits of the present invention from the disclosure herein. The present invention may also be implemented or applied through various other specific embodiments. The details in this specification may be modified or altered based on different viewpoints and applications without departing from the spirit of the present invention. The following embodiments and features therein may be combined with one another without conflict.

[0017] It should be noted that the illustrations provided in the following embodiments are merely schematic illustrations of the basic concept of the present invention. The drawings only show components related to the present invention and are not drawn according to the number, shape, and size of components in actual implementation. In actual implementation, the type, quantity, and proportion of each component may be changed arbitrarily, and the component layout may also be more complex.

[0018] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present invention. However, it will be apparent to those skilled in the art that the embodiments of the present invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring the embodiments of the present invention.

[0019] See Figure 1 , Figure 1 A schematic diagram of the implementation environment of a vehicle simulation method based on containerization technology provided in one embodiment of the present invention.

[0020] like Figure 1 As shown, the implementation environment of the containerized vehicle simulation method proposed in this application includes a cloud 101 and a terminal 102. Cloud 101 serves as the core computing and control center, responsible for container management, simulation resource loading, and real-time data interaction. Specifically, cloud 101 dynamically creates and manages container groups using the Kubernetes container management platform (K8s). Each container group encapsulates independent simulation model resources. When a user initiates a simulation request, the cloud calls the K8s interface to generate a container group and loads preconfigured simulation resources. It then transmits initial state information to the terminal via a real-time communication protocol, driving the initial rendering of the 3D model. The simulation engine runs within the container group, executes user commands through local library calls, and transmits dynamically generated response data back to the cloud in real time. It is ultimately transmitted to the terminal via a persistent communication link. Simulation model resources include, but are not limited to, vehicle component configuration, execution engine, vehicle model default state parameters, and other related information. Initial state information includes, but is not limited to, door closing status and default light brightness. User commands include, but are not limited to, door opening and closing, and light switching. These parameters can be determined based on actual simulation requirements, and this application does not impose any specific restrictions on the specific types and data of these parameters.

[0021] Terminal 102 serves as an interactive entry point and is mainly responsible for 3D model rendering, user operation input and real-time communication functions. It has a built-in 3D rendering engine that drives the real-time visual display of the vehicle model based on the initial state parameters and dynamically updated data provided by the cloud 101. The user triggers the operation command through the graphical interface and establishes a two-way persistent connection with the cloud through the WebSocket protocol to achieve low-latency command transmission and feedback. After the cloud receives the command from the terminal, it parses the target service identifier and operation parameters and accurately forwards the command to the corresponding container group internal service. After the simulation engine in the container group executes the command, it generates response data containing the state change result, which is transmitted back to the terminal through the same communication link to further update the 3D model state or display the operation log. Among them, the response data of the state change result includes but is not limited to information related to the door switch status log light, and this application does not impose any specific restrictions on it.

[0022] The aforementioned vehicle simulation process leverages containerization technology to dynamically load and isolate simulation resources. Combined with a microservices architecture to support multi-module collaboration, this ensures the simulation system possesses high flexibility, scalability, and resource utilization. Real-time collaboration between the cloud and the terminal enables vehicle simulation to rapidly respond to user actions and supports dynamic updates of vehicle models and features, enabling the deployment and iteration of new scenarios without relying on front-end code modifications.

[0023] Figure 2 This is a diagram of the overall system architecture of a vehicle simulation method based on containerization technology provided in one embodiment of the present invention.

[0024] In one embodiment of the present application, Figure 2 As shown in Figure 1, the implementation process of the vehicle simulation method based on containerization technology involves information interaction between the terminal, the cloud, and the container management platform. The interaction process is as follows: First, the terminal sends a user operation instruction to the cloud. After receiving the instruction, the cloud calls the interface of the container management platform to send a container creation request. After processing the request, the container management platform returns a successful creation response and synchronously provides the initial state parameters to the cloud. The cloud encapsulates these parameters into the first state response data and forwards it to the terminal to drive the initial rendering of the 3D model.

[0025] In addition, a persistent connection channel (such as WebSocket) is established between the cloud and the container management platform for subsequent real-time communication. When the terminal sends a new operation instruction, the cloud forwards the instruction to the container management platform. The container management platform performs the simulation operation according to the instruction and generates dynamic state response data. Finally, this dynamic state response data is transmitted back to the terminal through the cloud to update the rendering status of the 3D model or display the operation log.

[0026] It can be understood that the above information interaction process realizes the dynamic creation, status synchronization and real-time operation functions of the container through the interaction between the cloud-coordinated terminal and the container management platform, ensuring that users can intuitively control and observe the status changes of the simulation model through the terminal.

[0027] Figure 3 This is a flowchart of a cloud-based implementation of a vehicle simulation method based on containerization technology provided in one embodiment of the present invention.

[0028] like Figure 3 As shown, in an exemplary embodiment, the vehicle simulation method based on containerization technology includes at least steps S310 to S360, which are described in detail as follows: Step S310 : In response to the initial operation instruction from the terminal, a container group creation request is sent to the container management platform.

[0029] In one embodiment of the present application, a user performs a specific operation on a web page, and the front-end interface encapsulates the operation instruction as an API (Application Programming Interface) request and sends it to the cloud service via the HTTP / HTTPS protocol. The request typically contains the vehicle model identification, simulation scenario parameters, and user authentication information. After receiving the API request, the cloud service first verifies the user's permissions and the legitimacy of the request parameters. If the verification is successful, the service internally calls the Kubernetes API interface and sends a container group creation instruction to the container management platform (K8s). The instruction contains key information such as container configuration, service dependencies, and network policies: In a specific embodiment of the present application, when the user selects the target vehicle model and clicks the "New Simulation Model" button, the client encapsulates the user's operation into an API request and sends it to the cloud service via HTTP or HTTPS protocol. The request contains content such as vehicle model identification, simulation scenario parameters, and user identity authentication information. After receiving the request, the cloud service first verifies the user's permissions and the legitimacy of the parameters. After confirming that they are correct, it calls the Kubernetes interface and sends an instruction to the container management platform to create a container group. The instruction contains necessary information such as container image version, resource configuration, environment variables, and network policy.

[0030] Step S320 : calling the container management platform to create a target container group and load the vehicle simulation resources, and obtaining the initial state parameters generated by the vehicle simulation resources. The initial state parameters include the default configuration parameters of the vehicle components.

[0031] In one embodiment of this application, "dynamically creating and managing container groups using the Kubernetes container management platform (K8s)" is used as an example. After receiving a creation request, the Kubernetes cluster deploys the container group based on a predefined orchestration strategy. During the creation process, K8s monitors the container status in real time and notifies the cloud service of any status changes via an event bus. The cloud service encapsulates the container group's creation progress and final status as structured data and sends it back to the endpoint via an HTTP response or WebSocket channel.

[0032] In a specific embodiment of the present application, the container management platform dynamically schedules node resources according to a preset orchestration strategy, pulls the corresponding simulation image, and starts the container group. During this process, the platform continuously monitors changes in container status and feeds back status updates to the cloud service in real time through an event mechanism. The cloud service thus grasps the progress of container group creation and encapsulates the operating status and initial state parameters of the container group as structured data, which is returned to the user terminal via an HTTP response or WebSocket channel. Its initial state parameters include but are not limited to basic configuration values ​​of vehicle components such as the default door angle and lighting status, which are used to drive the initial rendering of the three-dimensional model.

[0033] Step S330: If the container group is successfully created, a persistent connection channel is established with the terminal, and initial status response data is generated based on the initial status parameters.

[0034] In one embodiment of the present application, after the container group is successfully created, the cloud service further calls the service interface within the container to extract the initial state parameters of the vehicle model from the simulation engine. These parameters are transmitted to the terminal using a standardized message format to drive the initial rendering of the 3D model. In addition, if the container creation fails, the cloud service will log the error details to the log system and return a readable error message to the terminal. At the same time, the automatic recovery mechanism of K8s is used to attempt to repair the problem and ensure service stability.

[0035] In a specific embodiment of the present application, after the container group is successfully created, the cloud service further establishes communication with the simulation engine inside the container and calls the service interface provided by it, such as obtaining the initial state information of the vehicle model through a standard HTTP GET request. This information includes but is not limited to key parameters such as the default closing angle of the car door and the initial brightness value of the light, which are used for the subsequent initialization rendering of the 3D model. The cloud encapsulates these parameters in a unified message format and transmits them to the user terminal, enabling the terminal to quickly load and display the 3D model based on the actual state of the simulation resource.

[0036] Furthermore, if an exception occurs during container group creation, such as an image pull failure or insufficient computing resources, preventing the container from starting properly, the cloud service will log the specific error type in the system log and return an easy-to-understand prompt to the user terminal, such as "Insufficient resources, please try again later" or "Image loading failed." Simultaneously, the simulation system utilizes the automatic recovery mechanism provided by the Kubernetes platform to attempt to repair failed container instances, such as restarting the corresponding pod or rescheduling it to another available node, thereby improving overall service availability and stability.

[0037] It can be understood that the method proposed in the above embodiment achieves efficient collaboration between user operations and the container management platform through deep integration of standardized APIs and Kubernetes, ensuring dynamic allocation and status transparency of simulation resources.

[0038] Step S340: Sending initial status response data to the terminal based on the persistent connection channel, so that the terminal creates and renders the vehicle three-dimensional model according to default configuration parameters.

[0039] In one embodiment of the present application, when a user selects a target vehicle model and clicks the "Start Simulation" button, the cloud service invokes the Kubernetes container management platform (K8s) interface to dynamically create a container group containing the vehicle simulation resources. Once the container group is started, the internal simulation engine proactively reports the initial state parameters of the vehicle model, such as default configuration values ​​for door closing angles and lighting brightness. The cloud encapsulates these parameters into structured initial status response data and pushes it to the terminal via an established WebSocket channel.

[0040] After receiving the initial status response, the terminal's 3D rendering engine initializes the vehicle model based on the service identifier and parameter values ​​in the initial status response. For example, it analyzes information such as door angle and lighting status to render the 3D model in a manner consistent with the default configuration. After model initialization is complete, users can perform subsequent operations through the web interface, generating update instructions. The front-end converts these instructions into messages containing the target service ID, method ID, and operation parameters, and sends them to the cloud in real time via a WebSocket channel.

[0041] Step S350: receiving the update operation instruction sent by the terminal, forwarding the update operation instruction to the simulation engine in the target container group, and receiving dynamic state response data generated by the simulation engine based on the update operation instruction, the dynamic state response data including the change result of the initial state parameter.

[0042] In one embodiment of the present application, after receiving an update operation instruction, the cloud forwards it to the corresponding container group's internal service, where the simulation engine calls the model execution module to complete the actual operation. After the container group completes the execution, the simulation engine generates dynamic response data containing the state change results and transmits it back to the terminal via the WebSocket channel.

[0043] Step S360: Send dynamic status response data to the terminal based on the persistent connection channel to update the rendering status of the vehicle three-dimensional model.

[0044] In one embodiment of the present application, the cloud transmits data back to the terminal through the WebSocket channel, and the terminal's 3D rendering engine updates the model display effect based on the received dynamic status data, such as adjusting the model angle or lighting the lights when the car door is opened. At the same time, the user interface can synchronously display the operation log to enhance the intuitiveness of the operation feedback. Throughout the process, the WebSocket persistent connection channel continues to maintain low-latency communication to ensure real-time synchronization between user operations and model status. If new models or functions need to be expanded, the cloud can dynamically replace container resources through the Kubernetes image update mechanism without interrupting existing connections or modifying front-end code, thereby achieving flexible expansion and rapid iteration of the simulation system.

[0045] In one embodiment of the present application, loading vehicle simulation resources includes: loading vehicle simulation resources, including: obtaining a simulation resource file of a target vehicle model, and loading the simulation resource file into a shared storage space of a container group; calling an initialization interface in the simulation resource file to generate initial state parameters, the initial state parameters serving as the only data source for the first state response data, and being used to drive the initial rendering of the vehicle three-dimensional model.

[0046] In a specific embodiment of the present application, the loading process of vehicle simulation resources is implemented through the collaboration of the cloud and the container group. When the user initiates a simulation request, the cloud service first obtains the simulation resource files of the target vehicle model from the pre-configured resource library. These files usually include the geometric data of the vehicle's three-dimensional model, physical property description files, and initialization configuration files. The resource files are distributed to the node where the container group is located through container images or remote storage, and loaded into the shared storage space of the container group. The shared storage space is supported by Kubernetes' persistent volumes or temporary shared volumes to ensure that all service components in the container group can access unified resource data. Among them, remote storage includes but is not limited to object storage services, and service components in the container group include but are not limited to model engines, rendering services, etc. This application does not impose any specific restrictions on them.

[0047] After the resource file is loaded, the simulation engine service in the container group calls the initialization interface in the resource file to perform parsing and verification of the simulation resources. For example, the engine will read the default parameters in the configuration file and complete the initialization logic in conjunction with the local library file. By calling the initialization interface, the simulation system generates the initial state parameters of the vehicle components. These parameters include service identifiers, method identifiers, and default configuration values ​​of the components. As the only data source for the first state response data, the initial state parameters are directly used to drive the initial rendering of the terminal's three-dimensional model to ensure that the model display is consistent with the definition in the configuration file. Among them, the local library file trove is not limited to the simulation engine dynamic link library, and the default configuration values ​​also include but are not limited to the door closing angle, etc. This application does not impose any specific restrictions on them.

[0048] It's understandable that the aforementioned vehicle simulation resource file loading process leverages Kubernetes' container orchestration capabilities to achieve dynamic resource allocation and isolation, while also supporting the rapid deployment of new models or features. If simulation resources need to be updated, the cloud can replace resource files through image upgrades or shared storage hot-update mechanisms, completing dynamic resource loading without rebuilding the container group. This process ensures efficient simulation resource management and accurate model initialization, laying the foundation for subsequent real-time interaction and dynamic operation.

[0049] In one embodiment of the present application, an update operation instruction is forwarded to a simulation engine in a target container group, including: extracting an action identifier and a parameter value contained in the update operation instruction as instruction parameters; parsing the container group identifier and the service identifier in the update operation instruction, where the service identifier is derived from registration information in a vehicle simulation resource; locating the target container group according to the container group identifier, and determining the target simulation engine running in the target container group; encapsulating the service identifier and the instruction parameters into a message body that complies with an inter-container communication protocol, and forwarding the message body to the target simulation engine based on the inter-container communication protocol to generate dynamic state response data.

[0050] In one specific embodiment of the present application, an update operation instruction sent by a terminal is parsed and forwarded by a cloud service to trigger the execution of the simulation engine within the target container group. The cloud service first extracts the action identifier and parameter value from the instruction and parses it to obtain the target container group identifier (e.g., container group name or tag) and service identifier (e.g., serviceId:0xAD04). This service identifier is derived from pre-registered service information in the vehicle simulation resource (e.g., a configuration file or service registry) and is used to locate the specific service component within the container group. Update operation instructions include, but are not limited to, door control and light switching. Correspondingly, the action identifier includes, but is not limited to, door opening and closing type, and the parameter value includes, but is not limited to, door ID and target angle. It is understood that the action identifier and parameter value correspond to their corresponding update operation instructions. Different operation instructions require different types and values ​​of action identifiers and parameter values. The specific correspondence is determined by actual simulation requirements and is not limited in this application.

[0051] Based on the target container group ID, the cloud service uses Kubernetes' service discovery mechanism to determine the location of the target container group and further maps it to the simulation engine running within the container group. The cloud service then encapsulates the extracted service ID and instruction parameters according to the format requirements of the inter-container communication protocol, generating a standardized message body. This message body contains the service ID, operation method ID, and parameter values, for example, as a JSON-formatted request body via HTTP or as a structured request object via gRPC.

[0052] After encapsulation, the cloud service sends the message body to the simulation engine in the target container group via the selected communication protocol. Upon receiving the message, the simulation engine invokes the corresponding execution logic based on the service identifier and dynamically adjusts the model state based on the parameter values. This entire forwarding process is implemented using Kubernetes' dynamic scheduling capabilities and standardized communication protocols, ensuring that user commands are accurately delivered to the simulation engine in the target container group, generating dynamic state response data that is fed back to the terminal.

[0053] In one embodiment of the present application, generating dynamic state response data includes: a simulation engine calling a dynamic link library in a container according to a service identifier; executing the dynamic link library to generate state change data, wherein the state change data includes a correction value for an initial state parameter; and combining the state change data with a container group identifier and a service identifier into dynamic state response data for updating the rendering state of a vehicle three-dimensional model.

[0054] In one specific embodiment of this application, the generation of dynamic state response data is performed by a simulation engine within the target container group. When a user operation command is forwarded to the target container group via a cloud service, the simulation engine invokes a preloaded dynamic link library within the container based on the service identifier in the command and executes the model state change logic. The dynamic link library adjusts the state of vehicle components based on the operation parameters and returns state change data, such as the actual door angle value or the on / off status of a light.

[0055] The simulation engine combines the state change data returned by the dynamic link library with the container group ID and service ID to generate standardized dynamic state response data. This data is returned to the cloud service via the inter-container communication protocol and ultimately pushed to the terminal. For example, if a door angle is adjusted from the default 90 degrees to 0 degrees, the dynamic state response data will include the container group ID, serial number, service ID, and the corrected state value, indicating the actual open or closed state of the door. This process ensures that the results of user operation commands are accurately fed back to the terminal, driving real-time updates of the 3D model.

[0056] In one embodiment of the present application, after sending the dynamic status response data to the terminal, it also includes: in response to the resource update notification issued by the image repository, stopping the simulation engine in the target container group; replacing the current vehicle simulation resource with an updated simulation resource file, the updated simulation resource file includes a new version of the initialization interface and a dynamic link library; calling the new version of the initialization interface to generate new initial state parameters, the new initial state parameters overwrite the default configuration values ​​of the original initial state parameters; generating update response data based on the new initial state parameters, and sending the update response data to the terminal based on the persistent connection channel to trigger the reset of the vehicle three-dimensional model rendering state.

[0057] In a specific embodiment of the present application, when the image repository issues a resource update notification, the dynamic replacement and status synchronization of the container group are achieved through the rolling update mechanism of Kubernetes. After the cloud service receives the update notification, it first sends an elegant termination instruction to the target container group to gradually stop the currently running simulation engine service. Kubernetes uses a rolling update strategy to ensure that the old container group starts a new container group while releasing resources to avoid service interruption. The new container group pulls the updated simulation resource file from the image repository, including the new version of the initialization interface configuration and dynamic link library to support new functions or fix problems. Among them, the resource update notification includes but is not limited to the upgrade of the configuration file or dynamic link library version, which is determined based on the specific simulation requirements, and this application does not impose specific restrictions on it.

[0058] After the new container group is started, the simulation engine calls the new version initialization interface and generates new initial state parameters based on the updated resource file. For example, if the new configuration adjusts the default door closing angle or adds a new lighting mode, the new initial state parameters will overwrite the original configuration values ​​and serve as the benchmark for 3D model rendering. The cloud service encapsulates the new initial state parameters as update response data and pushes it to the terminal through a persistent connection channel (such as WebSocket). This data contains the container group identifier, serial number, and new version configuration value, which is used to drive the 3D model to perform a rendering state reset. After the terminal receives the update response data, the 3D rendering engine parses the new version parameters and adjusts the model state, while displaying an update prompt on the interface to ensure that the user is aware of the model changes.

[0059] It is understandable that the implementation process of the above embodiment achieves a seamless upgrade of simulation resources through the automated orchestration capabilities of Kubernetes and the dynamic replacement of container resources. If the new version of the resource causes an exception, it can be restored to the old version through the image rollback mechanism, and the stability of the new container group can be ensured through health checks. The terminal always displays the vehicle model based on the latest resource file, which ensures the flexibility and real-time performance of the simulation system and is suitable for multi-model version iteration and function expansion scenarios. Among them, exceptions include but are not limited to configuration conflicts, data transmission errors, etc.

[0060] Figure 4 This is a flowchart of a vehicle simulation method based on containerization technology provided in one embodiment of the present invention implemented on a terminal.

[0061] like Figure 4 As shown, in an exemplary embodiment, the vehicle simulation method based on containerization technology includes at least steps S410 to S460, which are described in detail as follows: Step S410: In response to the initial operation instruction, a container group creation request is sent to the cloud.

[0062] In one embodiment of the present application, after the user performs an operation through the Web interface, the front end encapsulates the operation instruction into an API request and sends it to the cloud service through the HTTP / HTTPS protocol. After the cloud service verifies the user's permissions and the legitimacy of the parameters, it calls the Kubernetes API interface and sends a container group creation instruction to the container management platform, specifying the container image version, resource limits, and environment variables. The Kubernetes cluster dynamically creates a container group according to the instructions and loads the pre-configured simulation resource file. After successful creation, the cloud encapsulates the container group identifier and initial state parameters as response data, returns it to the terminal through the HTTP or WebSocket channel, and drives the initial rendering of the three-dimensional model. If the creation fails, the cloud will synchronously return an error prompt and try to repair it through the K8s automatic recovery mechanism.

[0063] Step S420: Receive the container group status and initial status parameters returned by the cloud, where the initial status parameters include default configuration values ​​of vehicle components.

[0064] In one embodiment of the present application, the terminal receives the container group status and initial state parameters returned by the cloud via a persistent connection channel. Once the cloud completes container group creation, it encapsulates the container group's operating status and the default configuration values ​​for vehicle components into structured data and sends it to the terminal. After parsing the data, the terminal extracts the container group status to verify service availability and passes the initial state parameters to the 3D rendering engine, driving the vehicle model to initialize and display according to the default configuration values. If reception fails, the terminal requests the cloud to resend the data through a connection retry mechanism, or prompts the user to check the connection status.

[0065] Step S430: If the container group is created successfully, a persistent connection channel with the cloud is established.

[0066] In one embodiment of the present application, after a container group is successfully created, the terminal proactively initiates a request to establish a persistent connection channel with the cloud service. This channel uses the WebSocket protocol to transmit user operation instructions and simulation status feedback in real time. After the connection is established, the cloud service verifies user permissions and maintains the channel's active state, monitoring the connection's health through heartbeat packets. If the channel is disconnected, the terminal triggers an automatic reconnection mechanism to ensure the continuity of operation instructions and status synchronization.

[0067] Step S440: receiving initial status response data based on the persistent connection channel, and triggering initial rendering of the vehicle three-dimensional model based on the initial status response data.

[0068] In one embodiment of the present application, the terminal receives the initial status response data returned by the cloud service through a persistent connection channel. This data contains the default configuration values ​​of the vehicle components and the service identifier. After parsing the data, the terminal passes the configuration values ​​to the 3D rendering engine, driving the vehicle model to complete the initial display according to the default state. It should be noted that this process does not require manual user operation and is automatically triggered by the simulation system to ensure that the 3D model is consistent with the simulation state within the container group.

[0069] Step S450: Send an update operation instruction to the cloud based on the persistent connection channel, and receive dynamic state response data, where the dynamic state response data includes the change result of the initial state parameters.

[0070] In one embodiment of the present application, a terminal sends update operation instructions to the cloud via a persistent connection channel. The cloud then forwards the instructions to the simulation engine within the target container group for execution. After the container group completes the execution, it returns dynamic state response data via the same channel, containing the changes to the initial state parameters. After parsing the response data, the terminal drives the 3D rendering engine to update the vehicle model state, achieving real-time synchronization between the operation instructions and the model state.

[0071] Step S460: updating the rendering state of the vehicle three-dimensional model according to the dynamic state response data.

[0072] In one embodiment of the present application, after the terminal receives the dynamic state response data, the 3D rendering engine parses the service identifier and parameter value in the data and drives the real-time update of the vehicle model. For example: if the response data indicates that the door angle changes from 90 degrees to 0 degrees, the rendering engine adjusts the door model position to the open state; if the light state changes from off to on, the rendering engine updates the brightness and display effect of the light component. It can be understood that the simulation system ensures that the model state is synchronized with the data returned by the cloud through a frame-by-frame refresh mechanism, and adopts an incremental update strategy to optimize performance. If the data is abnormal, the rendering engine falls back to the most recent valid state or prompts the user to check the connection to ensure the accuracy and stability of the model display. Among them, data anomalies include but are not limited to garbled data, data misalignment, data loss, etc., and this application does not impose specific restrictions on them.

[0073] In one embodiment of the present application, sending an update operation instruction includes: responding to an operation event triggered by a user on an interactive component of a vehicle three-dimensional model, capturing the interaction event type and event parameters; generating a target action identifier based on a preset mapping relationship between the interaction event type and the action identifier; extracting the parameter value to be modified of the target vehicle component from the event parameter, and encapsulating the target action identifier, the actual parameter value to be modified and the current container group identifier into a structured operation instruction, wherein the current container group identifier is derived from the received container group status information; sending the structured operation instruction to the cloud based on a persistent connection channel to drive the cloud to call the simulation engine of the target container group according to the target action identifier, execute the state change based on the parameter value to be modified, and generate dynamic state response data containing the state change result.

[0074] In one specific embodiment of the present application, when a user interacts with interactive components of a 3D model through a web interface, the simulation system generates and issues operational instructions through the following process: When a user triggers an operational event, the terminal's front-end module captures the interactive event type and event parameters in real time. The front-end then converts the event type into a corresponding action identifier based on a pre-defined mapping table of interactive event types and action identifiers. For example, if a user clicks a door button, the event type "click" is mapped to the action identifier "setDoorAngle," while the drag event of a slider is mapped to the action identifier "adjustDoorPosition."

[0075] The front-end then extracts the parameter value to be modified for the target vehicle component from the event parameters and encapsulates it into a structured operation instruction based on the current container group identifier. This container group identifier is derived from the container group status information previously received by the terminal. The structured operation instruction contains the action identifier, the parameter value to be modified, and the container group identifier.

[0076] The encapsulated command is sent to the cloud service via a persistent connection. After parsing the command, the cloud service locates the target container group based on the containerId and calls the corresponding method in the simulation engine based on the actionId. The simulation engine executes the state change and generates dynamic state response data containing the state change results, which is returned to the terminal via the same channel.

[0077] If the event parameter is missing or the actionId is not defined in the mapping table, the frontend will trigger a local prompt. If the cloud detects that the target container group has terminated, the frontend will prompt the user "The current simulation has been closed, please restart it."

[0078] In a specific embodiment of the present application, It can be understood that the implementation process of this embodiment ensures that user operations accurately drive the real-time update of the three-dimensional model status through closed-loop interaction of event capture, action mapping, instruction encapsulation and cloud processing, and is suitable for vehicle simulation applications in highly interactive scenarios.

[0079] In one embodiment of the present application, after receiving the dynamic state response data, it also includes: receiving the update response data sent by the cloud based on the persistent connection channel, the update response data is generated by the cloud after the response resource update notification is generated based on the new initial state parameters generated by the new version of the simulation resource; parsing the update response data to obtain the new initial state parameters, the new initial state parameters overwriting the original initial state parameters stored in the terminal; resetting the vehicle three-dimensional model rendering state based on the new initial state parameters, and clearing the historical operation instruction cache associated with the target container group, the historical operation instruction cache containing the action identification sequence that has been sent.

[0080] In a specific embodiment of the present application, after the cloud completes the simulation resource update, the terminal receives the update response data pushed by the cloud through a persistent connection channel. The data contains new initial state parameters generated based on the new version of the simulation resources, which are used to overwrite the old configuration stored locally. After the terminal parses the update response data, the 3D rendering engine drives the rendering state of the vehicle model to reset according to the new initial state parameters, such as adjusting the door angle from 90 degrees in the old version to 85 degrees in the new version, or adding new functions synchronously. At the same time, the simulation system clears the historical operation instruction cache associated with the target container group, including the action identification sequence and execution parameters that have been sent, to ensure that subsequent operations are executed based on the new version of the configuration. If the parsing fails or the cache clearing is blocked, the terminal ensures state consistency through an alarm prompt or a forced refresh mechanism, thereby achieving seamless switching of the model and operation state after the resource update.

[0081] It's important to emphasize that the containerized vehicle simulation method proposed in this application enables real-time communication between user terminals and cloud services through a persistent connection channel. Operational commands can be issued to the target container group in real time, and dynamic state response data drives precise updates of the 3D model, ensuring synchronization between user operations and model display. When cloud resources are updated, the simulation system replaces the container group resources through the Kubernetes rolling update mechanism and generates new initial state parameters based on the new version of the initialization interface. The user terminal overwrites the old local configuration and triggers a model rendering reset. The historical operation cache is also cleared to avoid version conflicts. Containerization technology enables on-demand resource loading, elastic scalability, and isolated operation, supporting concurrent simulation of multiple vehicle models. New features can be rapidly deployed through shared storage and image hot update mechanisms. The simulation system also integrates a multi-level fault-tolerance strategy: automatic reconnection to recover from communication interruptions, state rollback to ensure model consistency, and image rollback to address resource anomalies, ensuring high availability. Furthermore, incremental updates and frame-by-frame rendering optimizations reduce GPU load, and combined with load balancing technology, maintain smooth interaction in high-concurrency scenarios. In summary, the proposed solution achieves efficient, flexible, and stable vehicle simulation, significantly improving user experience and operational efficiency.

[0082] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the vehicle simulation method based on containerization technology provided in the above-mentioned embodiments.

[0083] Figure 5 The following is a schematic diagram showing the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application. Figure 5 The computer system 500 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0084] like Figure 5 As shown, computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes, such as the methods described in the above embodiments, based on programs stored in read-only memory (ROM) 502 or programs loaded from storage 508 into random access memory (RAM) 503. RAM 503 also stores various programs and data required for system operation. CPU 501, ROM 502, and RAM 503 are interconnected via bus 504. An input / output (I / O) interface 505 is also connected to bus 504.

[0085] The following components are connected to the I / O interface 505: an input section 506 including a keyboard, mouse, and the like; an output section 507 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 508 including devices such as a hard disk; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. Removable media 511, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 510 as needed, so that computer programs read from the media can be installed in the storage section 508 as needed.

[0086] In particular, according to embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for executing the methods illustrated in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication section 509 and / or installed from removable media 511. When executed by the central processing unit (CPU) 501, the computer program performs the various functions defined in the system of the present application.

[0087] It should be noted that the computer-readable medium described in the embodiments of this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may, for example, be an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. This propagated data signal may take a variety of forms, including, but not limited to, an electromagnetic signal, an optical signal, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0088] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0089] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. In some cases, the names of these units do not constitute limitations on the units themselves.

[0090] Another aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a computer processor, causes the computer to perform the containerization-based vehicle simulation method described above. The computer-readable storage medium may be included in the electronic device described in the above embodiments, or may exist independently and not be incorporated into the electronic device.

[0091] Another aspect of the present application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the containerization-based vehicle simulation method provided in each of the above embodiments.

[0092] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the present invention. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by one of ordinary skill in the art without departing from the spirit and technical principles disclosed herein are intended to be covered by the claims of the present invention.

Claims

1. A vehicle simulation method based on containerization technology, characterized in that: The method is executed on the cloud and includes: In response to an initial operation instruction from the terminal, sending a container group creation request to the container management platform; Invoke the container management platform to create a target container group and load vehicle simulation resources, and obtain initial state parameters generated by the vehicle simulation resources, wherein the initial state parameters include default configuration parameters of vehicle components; If the container group is successfully created, a persistent connection channel is established with the terminal, and initial status response data is generated based on the initial status parameters; Sending the first status response data to the terminal based on the persistent connection channel, so that the terminal creates and renders the vehicle three-dimensional model according to the default configuration parameters; receiving an update operation instruction sent by a terminal, forwarding the update operation instruction to a simulation engine in a target container group, and receiving dynamic state response data generated by the simulation engine based on the update operation instruction, the dynamic state response data including a change result of the initial state parameter; The dynamic state response data is sent to the terminal based on the persistent connection channel to update the rendering state of the vehicle three-dimensional model.

2. The vehicle simulation method based on containerization technology according to claim 1, characterized in that: The loading of vehicle simulation resources includes: Obtaining a simulation resource file of a target vehicle model and loading the simulation resource file into a shared storage space of a container group; The initialization interface in the simulation resource file is called to generate the initial state parameters. The initial state parameters serve as the only data source of the first state response data and are used to drive the initial rendering of the vehicle three-dimensional model.

3. The vehicle simulation method based on containerization technology according to claim 1, characterized in that: Forward update operation instructions to the simulation engine in the target container group, including: Extracting the action identifier and parameter value contained in the update operation instruction as instruction parameters; Parsing the container group identifier and the service identifier in the update operation instruction, wherein the service identifier is derived from registration information in the vehicle simulation resource; Locating a target container group according to the container group identifier, and determining a target simulation engine running in the target container group; The service identifier and the instruction parameters are encapsulated into a message body that complies with an inter-container communication protocol, and the message body is forwarded to the target simulation engine based on the inter-container communication protocol to generate dynamic state response data.

4. The vehicle simulation method based on containerization technology according to claim 3 is characterized in that: Generate dynamic status response data, including: The simulation engine calls the dynamic link library in the container according to the service identifier; executing a dynamic link library to generate state change data, wherein the state change data includes a correction value of the initial state parameter; The state change data is combined with the container group identifier and the service identifier to form dynamic state response data, which is used to update the rendering state of the vehicle three-dimensional model.

5. The vehicle simulation method based on containerization technology according to claim 1, characterized in that: After sending the dynamic status response data to the terminal, it also includes: In response to a resource update notification issued by the image repository, stopping the simulation engine in the target container group; Replacing the current vehicle simulation resource with an updated simulation resource file, wherein the updated simulation resource file includes a new version of the initialization interface and the dynamic link library; Calling the new version of the initialization interface to generate new initial state parameters, wherein the new initial state parameters overwrite the default configuration values ​​of the original initial state parameters; Generate update response data based on the new initial state parameters, and send the update response data to the terminal based on the persistent connection channel to trigger the resetting of the vehicle three-dimensional model rendering state.

6. A vehicle simulation method based on containerization technology, characterized in that: The method is executed based on a terminal and includes: In response to the initial operation instruction, a container group creation request is sent to the cloud; receiving the container group state and initial state parameters returned by the cloud, wherein the initial state parameters include default configuration values ​​of vehicle components; If the container group is created successfully, a persistent connection channel with the cloud is established; receiving initial status response data based on the persistent connection channel, and triggering initial rendering of the vehicle three-dimensional model based on the initial status response data; Sending an update operation instruction to the cloud based on the persistent connection channel, and receiving dynamic state response data, wherein the dynamic state response data includes a change result of the initial state parameter; The rendering state of the vehicle three-dimensional model is updated according to the dynamic state response data.

7. The vehicle simulation method based on containerization technology according to claim 6, characterized in that: The sending of the update operation instruction includes: In response to an operation event triggered by a user on an interactive component of the three-dimensional vehicle model, capturing an interaction event type and event parameters; Generate a target action identifier based on the preset mapping relationship between the interaction event type and the action identifier; Extracting the parameter value to be modified of the target vehicle component from the event parameter, and encapsulating the target action identifier, the actual parameter value to be modified, and the current container group identifier into a structured operation instruction, wherein the current container group identifier is derived from the received container group state information; The structured operation instruction is sent to the cloud based on the persistent connection channel to drive the cloud to call the simulation engine of the target container group according to the target action identifier, perform the state change based on the parameter value to be modified, and generate dynamic state response data including the state change result.

8. The vehicle simulation method based on containerization technology according to claim 6, characterized in that: After receiving the dynamic status response data, it also includes: Receiving update response data sent by the cloud based on the persistent connection channel, the update response data is generated by the cloud in response to the resource update notification based on new initial state parameters generated by the new version of the simulation resource; Parsing the update response data to obtain new initial state parameters, where the new initial state parameters overwrite the original initial state parameters stored in the terminal; The rendering state of the vehicle three-dimensional model is reset based on the new initial state parameters, and a historical operation instruction cache associated with the target container group is cleared, where the historical operation instruction cache contains a sent action identification sequence.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the vehicle simulation method based on containerization technology as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor of a computer, the computer is caused to execute the vehicle simulation method based on containerization technology according to any one of claims 1 to 8.

Images