Vehicle software simulation test method, system, device and storage medium

Abstract

This invention relates to a vehicle software simulation testing method, system, apparatus, and storage medium. The method includes, in response to a test task instruction, obtaining the software to be tested corresponding to the test task, the model file and test script of the software to be tested, and task information required by the software to be tested to execute the test task; instantiating a Docker container based on the model file, the software to be tested, the test script, the task information, and a preset Docker base image required for model simulation to generate a simulation test environment; and starting the Docker container to execute simulation tests of the software to be tested based on the simulation test environment. This invention can automatically create and run simulation tests based on the simulation test environment, eliminating the need for manual creation by the user, thus improving efficiency and meeting the needs of numerous and frequently updated autonomous driving software.

Description

Technical Field

[0001] This invention relates to the field of software model simulation technology, and specifically to a vehicle software simulation testing method, system, device, and storage medium. Background Technology

[0002] Software testing often employs model simulation testing. With the rise of electric and intelligent vehicles, there is an increasing number of intelligent software applications, leading to a growing demand for model simulation and a significant increase in the workload that developers are investing in model simulation.

[0003] In related technologies, model simulation requires R&D personnel to manually load the model in the simulation test system on a PC workstation (industrial control computer), and then manually configure the corresponding running parameters, environment variables, and running scripts in the simulation environment to complete the model simulation environment setup. After the environment setup is complete, the software to be tested is run in the simulation environment for testing.

[0004] It is evident that the aforementioned model simulation testing system suffers from low efficiency. Summary of the Invention

[0005] One objective of this invention is to provide a vehicle software simulation testing method to solve the problem that the efficiency of model simulation testing in the prior art is low and it is difficult to meet the increasing demand for model simulation testing. Another objective is to provide a vehicle software simulation testing system. A third objective is to provide a vehicle software simulation testing device.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] Firstly, a vehicle software simulation testing method, applied to a server, the method comprising:

[0008] In response to a test task instruction, obtain the software to be tested corresponding to the test task, the model file and test script of the software to be tested, and the task information required by the software to be tested to execute the test task;

[0009] Based on the model file, the software to be tested, the test script, the task information, and the preset Docker base image required for model simulation, the Docker container is instantiated to generate a simulation test environment;

[0010] Start the Docker container and perform simulation tests on the software under test based on the simulation test environment.

[0011] Based on the aforementioned technical means, after a test task is triggered, the software to be tested, the model file and test script corresponding to the test task, and the task information required by the software to be tested to execute the test task are automatically obtained. Based on the basic environment already built on the server, a Docker container can be created by combining the model file, the software to be tested, the test script, the task information, and a pre-set Docker base image that is compatible with all software running and required for model simulation. This Docker container can generate a simulation environment for the software to be tested. Therefore, the server can run the simulation test of the software to be tested based on this simulation environment. The entire simulation test process is automatic and does not require the user to manually create the simulation environment. This testing method has high work efficiency and meets the needs of numerous and frequently updated autonomous driving software.

[0012] Furthermore, the Docker base image includes simulation testing software and a startup script. The step of instantiating a Docker container to generate a simulation testing environment based on the model file, the software to be tested, the test script, the task information, and the preset Docker base image required for model simulation includes:

[0013] In response to the invocation instruction of the startup script, the following Docker container instantiation process is executed:

[0014] Copy the model file, the software to be tested, the test script, and the task information into the Docker base image;

[0015] Run the Docker base image, create a Docker container based on the simulation test software, the software to be tested, the model file and the task information, instantiate the Docker container, and generate a simulation test environment.

[0016] Based on the above technical means, since the Docker base image pre-sets simulation test software and startup scripts, and these software can be adapted to various software required for software simulation testing, a Docker container can be created by calling the model file, the software to be tested, the test script, and the task information. When the Docker container starts, it can generate a simulation test environment for the software to be tested, realizing automatic creation of the simulation test environment, replacing manual creation, and improving work efficiency.

[0017] Furthermore, the step of running the Docker base image, creating a Docker container based on the simulation test software, the software to be tested, the model file, and the task information, instantiating the Docker container, and generating a simulation test environment includes:

[0018] Run the Docker base image, load the model file into the MATLAB of the simulation test software, and compile the model file based on the MATLAB according to the software to be tested to obtain the simulation model of the software to be tested.

[0019] Associate the simulation test software corresponding to the test task, and execute test instances based on the simulation test software;

[0020] Based on the environment required by the software under test, the task information is configured into the software under test and the simulation model. The task information includes running parameters and environment variables.

[0021] The Docker container is instantiated to generate a simulation test environment.

[0022] Based on the above technical means, the entire simulation test environment required for the software to be tested can be created in a Docker container.

[0023] Furthermore, after starting the Docker container and performing simulation tests on the software under test based on the simulation test environment, the method further includes:

[0024] After the test task is completed, the Docker container is destroyed.

[0025] Based on the above technical means, since the simulation test environment inside the Docker container is destroyed after use, the Docker container will regenerate a new simulation test environment for the next simulation test, instead of repeatedly modifying the environment inside the Docker container. This can avoid the situation where frequent changes to the environment cause problems.

[0026] Furthermore, after starting the Docker container and performing simulation tests on the software under test based on the simulation test environment, the method further includes:

[0027] The simulation test data is uploaded to the cloud platform. The simulation test data includes the simulation test log and test results after each script in the test script is executed, as well as the data file and log file after the test task is completed.

[0028] The aforementioned technical methods facilitate users' viewing of test results.

[0029] Secondly, the technical solution adopted by the present invention is as follows:

[0030] A vehicle software simulation testing method, applied to a cloud platform, the method comprising:

[0031] In response to the setting operation of the test task, the test task and its corresponding model file, software to be tested, test script and task information are determined according to the setting operation, and the association relationship between the test task and the model file, the software to be tested, the test script and the task information is established;

[0032] When the test task meets the triggering conditions, the test task is sent to the execution server.

[0033] Based on the aforementioned technical means, the cloud platform provides users with a settings interface, eliminating the need for users to conduct software testing at a fixed PC workstation. The cloud platform configures servers to execute test tasks, allowing users to set up test tasks on any computer. The cloud platform automatically schedules servers to execute test tasks, simplifying the software testing process. Furthermore, users can perform multiple test tasks in parallel, or handle test tasks alongside other tasks without waiting.

[0034] Furthermore, before sending the test task to the execution server when the test task meets the triggering conditions, the method further includes:

[0035] The execution server is determined based on the test task, the task type executed by each server, and its current running status.

[0036] Based on the aforementioned technical means, the cloud platform can configure and schedule multiple servers to execute multiple test tasks simultaneously. During the server scheduling process, a better execution server is allocated to the test task according to the type of task being executed and its current running status, thereby improving the efficiency of multi-task parallel testing.

[0037] Furthermore, before sending the test task to the execution server when the test task meets the triggering conditions, the method further includes:

[0038] Displays the operating information of each server, including the type of task being performed by the server and its current operating status;

[0039] In response to a selection operation based on the runtime information, the execution server is determined according to the selection operation.

[0040] Based on the aforementioned technical means, the cloud platform can configure and schedule multiple servers to execute multiple test tasks simultaneously. During the server scheduling process, based on the type of task being executed and its current running status, the platform recommends a better execution server to the user to execute the test task, while also providing interactive features to the user to improve the user experience.

[0041] Furthermore, the method also includes:

[0042] When the current time reaches the task trigger time, it is determined that the test task meets the trigger conditions;

[0043] Alternatively, a click operation on the trigger control is detected, determining that the test task meets the triggering conditions.

[0044] Based on the aforementioned technical means, the cloud platform provides multiple test task triggering methods to adapt to the different triggering requirements of different test tasks, enrich the functions of the test system, and improve the effect of software simulation testing.

[0045] A vehicle software simulation testing system, the system comprising a server and a cloud platform;

[0046] The server is used to perform the method described in the first aspect above;

[0047] The cloud platform is used to perform the method described in the second aspect above.

[0048] Furthermore, the server includes basic software for running Docker, a scheduling client, and a Docker base image. The scheduling client is used to create Docker containers based on the Docker base image and to call the simulation environment to test the software under test when the Docker container generates a simulation environment. The basic software for Docker is used to drive the Docker container to generate the simulation environment.

[0049] Furthermore, the cloud platform includes a simulation task management module and a server management module. The simulation task management module is used to create simulation test tasks and trigger test tasks; the server management module is used to create and connect to servers and configure the servers.

[0050] A vehicle software simulation testing device, the device comprising:

[0051] The acquisition module is used to obtain, in response to the test task instruction, the software to be tested corresponding to the test task, the model file and test script of the software to be tested, and the task information required by the software to be tested to execute the test task;

[0052] The simulation environment generation module is used to instantiate a Docker container and generate a simulation test environment based on the model file, the software to be tested, the test script, the task information, and the preset Docker base image required for model simulation.

[0053] The testing module is used to start the Docker container and perform simulation tests on the software under test based on the simulation test environment.

[0054] A vehicle software simulation testing device, the device comprising:

[0055] The setting module is used to respond to the setting operation of the test task, determine the test task and its corresponding model file, software to be tested, test script and task information according to the setting operation, and establish the association relationship between the test task and the model file, the software to be tested, the test script and the task information;

[0056] The task distribution module is used to distribute the test task to the execution server when the test task meets the triggering conditions.

[0057] An electronic device includes: a memory and a processor;

[0058] The memory is used to store computer programs / instructions; the processor is used to implement the method described in the first aspect above, or to implement the method described in the second aspect above, according to the computer programs / instructions stored in the memory.

[0059] A computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the method described above.

[0060] A computer program product comprising a computer program that, when executed by a processor, is used to implement the method described above.

[0061] The beneficial effects of this invention are:

[0062] (1) The vehicle software simulation test of this application has high efficiency. First, the cloud platform provides a simulation test setting interface, and users can directly set simulation test related information on the setting interface. Based on the execution server configured on the cloud platform, the cloud platform can directly trigger the execution server to execute test tasks and complete software simulation tests. Users do not need to go to a fixed PC workstation to operate. Second, users only need to select the software to be tested, the model file corresponding to the software to be tested, and the test script, and configure some related task information for the software to be tested. The server can call up this information and automatically build the simulation environment of the software to be tested in a Docker container. Users do not need to manually modify the environment in the test system, which improves work efficiency. Third, based on the deployment of multiple Docker containers on each server or the deployment of multiple servers on the cloud platform, multiple test tasks can be processed in parallel. Therefore, the simulation test method provided by this application is suitable for the current testing needs of increasing intelligent software and frequent updates of intelligent software, especially in the field of autonomous driving, and meets the needs of autonomous vehicle software testing.

[0063] (2) The vehicle software simulation test of this application is not prone to errors. First, there is no need to manually build the simulation environment. Second, each test task creates a new simulation environment in a Docker container, which is destroyed after the test task is completed, without affecting the basic environment information. Therefore, the probability of errors can be reduced. Attached Figure Description

[0064] Figure 1 A schematic diagram of a vehicle software simulation testing system provided in an embodiment of this application;

[0065] Figure 2 A schematic diagram of a server for a vehicle software simulation testing system provided in an embodiment of this application;

[0066] Figure 3 A schematic diagram of a Docker container for a vehicle software simulation testing system provided in an embodiment of this application;

[0067] Figure 4 A schematic diagram of a cloud platform for a vehicle software simulation testing system provided in an embodiment of this application;

[0068] Figure 5 A flowchart illustrating a vehicle software simulation testing method provided in an embodiment of this application;

[0069] Figure 6 A schematic diagram illustrating the generation of a simulation test environment and Docker container instantiation for server scheduling-related information provided in an embodiment of this application;

[0070] Figure 7 A flowchart illustrating a vehicle software simulation testing method according to another embodiment of this application;

[0071] Figure 8 This application provides a schematic diagram of the operation flow of a vehicle software simulation testing system according to an embodiment of the present application.

[0072] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0073] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

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

[0075] The conventional method for software testing is model-based simulation testing. Because software testing has high requirements for the runtime environment, a fixed PC workstation is typically set up for testing. After developing or modifying software, developers need to manually load the model required for testing the software on the PC workstation, and manually configure the corresponding runtime parameters, environment variables, and runtime scripts, etc., manually building the model simulation environment. Once the environment is set up, the software under test is run in the simulation environment for testing.

[0076] Before the advent of intelligent vehicles, the number of software applications in automobiles was relatively small, resulting in less demand for software testing. Therefore, the aforementioned testing methods were sufficient for R&D needs. However, with the rise of electric and intelligent vehicles, the number of intelligent software applications is increasing, leading to a greater demand for model simulation and a significantly larger workload for R&D personnel. The existing testing methods are inefficient and no longer meet the requirements for automotive software testing. Therefore, there is an urgent need to develop a highly efficient and error-resistant software simulation testing system to meet the demands of automotive software testing.

[0077] like Figure 1 As shown in the embodiment of this application, a vehicle software simulation testing system is proposed. The system includes a cloud platform and at least one server. The cloud platform can schedule and manage at least one server to execute test tasks. The server is used to automatically build a test environment and automatically test the test software according to the test tasks.

[0078] As an example, the cloud platform can provide users with a simulation test interface, through which users can test the software. The cloud platform can also generate test tasks based on the settings information on the settings interface, and trigger the server to execute the test tasks by sending the test tasks to the server. After the server completes the test tasks, it will feed the test data back to the cloud platform, and users can view the test data based on the simulation test interface.

[0079] Based on this testing system, users can directly open the simulation testing interface on any workstation's computer to perform software testing, without needing to go to a specific PC workstation (a PC workstation is a graphical interface, and running software tests through a graphical interface would occupy a PC workstation). Furthermore, test tasks are distributed to the server for execution, and the execution of test tasks does not affect the use of the user's workstation computer. One server can execute multiple test tasks simultaneously, or multiple servers can be used to execute multiple test tasks concurrently, achieving parallel processing of multiple test tasks. Therefore, the vehicle software simulation testing system provided in this application embodiment is convenient to operate, eliminating the need for operation at a specific location, and allows for multiple test tasks to run in parallel, both of which improve the efficiency of software testing and are suitable for applications with increasingly demanding software testing needs.

[0080] It should be noted that the cloud platform and server achieve the above work by building a simulation test management system on the cloud platform and a simulation test execution system on the server. The following mainly describes one composition example of the simulation test management system and the simulation test execution system, as well as their corresponding functions:

[0081] As an example, such as Figure 2 As shown, the server includes the basic software for running Docker, a scheduling client, and a Docker base image (the diagram illustrates Docker containers 1, 2, 1…n instantiated from the Docker base image). The scheduling client is used to schedule relevant information (such as the software to be tested, model files, test scripts, task information, etc.), creates Docker containers based on the Docker base image, provides the necessary information for generating a simulation environment for the Docker containers, such as simulation test software, tests the software to be tested in the simulation environment based on the simulation test software, and uploads the test data obtained during the test to the cloud platform; the Docker base software is used to drive the instantiation of Docker containers and generate a simulation environment within the Docker containers.

[0082] It should be noted that Docker is an open-source application container engine that allows packaging an application and its dependencies into a portable container, which can then be deployed to a Linux server. This embodiment, based on the Docker container, can generate a simulation environment for the software under test within the Docker container. The software is then tested within this simulation environment. After testing, the Docker container can be destroyed without affecting the basic information of the simulation testing system.

[0083] In some examples, a simulation environment for the test software is built by manually modifying and setting parameters within the test system environment. For instance, if the test system has a basic environment, when testing software 1, the user enters the basic environment of the test system, modifies the basic environment according to the environment requirements of software 1, and obtains simulation environment a for software 1. Then, the simulation software 1 is tested in simulation environment a. When the user needs to test software 2, they enter simulation environment a and modify it (or restore simulation environment a to the basic environment and then modify it) to obtain simulation environment b for software 2, and then test software 2 in simulation environment b. This method of setting up environments requires a high level of expertise from the user, can only be done manually, and is cumbersome and inefficient.

[0084] To achieve automatic generation of simulation environments, as an example, this application proposes using Docker containers to create image simulation environments. The simulation environment generated by the Docker container is a new simulation environment for the software under test, not an environment modified from the base environment. For example, if a user needs to test software 1 in the test system, the Docker container generates simulation environment a for software 1 based on scheduling-related information (including the base environment); if the user needs to test software 2 in the test system, the Docker container generates simulation environment b for software 2 based on scheduling-related information (including the base environment). Since the base environment information of the test system is not modified, the user's expertise is not highly required, and manual operation is unnecessary. Furthermore, Docker containers can be destroyed after executing the test task, allowing for the repeated generation of different test environments; multiple Docker containers can also be created to simultaneously generate simulation environments for multiple test tasks.

[0085] However, simulation testing requires running multiple software programs, such as simulation test software and the software under test, with the simulation test software encompassing various functionalities. Running multiple software programs within Docker containers presents compatibility challenges. Therefore, some examples employ multiple Docker container images for multiple environments, with each Docker container running different software programs. This approach also requires coordinating the outputs and inputs of each Docker container to achieve complete software testing, making the setup complex. Therefore, this application provides the following solution: First, a Docker base image is generated that is compatible with all software required for vehicle software simulation testing (including simulation test software, the software under test, etc.). Then, the software under test, its model files and test scripts, and the task information required for the software under test to execute test tasks are automatically copied to the Docker base image, generating a Docker container. The Docker container then generates a simulation environment, automatically building the simulation environment for the software under test. This simulation environment is compatible with the operation of various simulation test software programs and other testing software. Compared to manual setup, this method is more efficient and simpler to configure.

[0086] Optionally, in this embodiment of the application, the scheduling client is used to schedule relevant information and create Docker containers, thereby enabling the Docker containers to generate a simulation environment for the software under test based on the relevant information. The specific implementation process is as follows:

[0087] The Docker base image deployed on the server contains the basic software, environment variables, and runtime parameters required for model simulation. The scheduling client connects to the cloud platform and can download the software to be tested, model files, test scripts, and task information from the cloud platform. This information is then packaged into the Docker base image. Once the Docker base image receives this information, it can be instantiated using the deployed Docker base software, resulting in a Docker container (e.g.,...). Figure 3 As shown in the figure, when the Docker container starts, it generates a simulation environment for the software under test.

[0088] As an example, an open-source Ubuntu system is used to create a Docker base image. Simulation testing software such as MATLAB and SIMULINK are installed in the Docker base image, and basic environment variables and runtime parameter files are configured. At the same time, workspace for the software to be tested, models, and test scripts is reserved in the Docker base image. When the image is instantiated, parameters can be modified and reserved content can be written, thus forming a Docker container that can execute model simulation tests.

[0089] As an example, such as Figure 4As shown, the cloud platform includes a server management module and a simulation task management module. The simulation task management module is used to create simulation test tasks and manage test tasks; the server management module is used to create servers, connect to servers, and manage servers.

[0090] Optionally, the server management module manages the server by configuring the server, monitoring the server status, and scheduling the server.

[0091] Completing software simulation testing requires setting up and running test tasks. In this embodiment, test tasks are set up through a cloud platform and run through a simulation server. Therefore, a server for running test tasks needs to be configured on the cloud platform to form a complete software simulation testing system. The server configured on the cloud platform for running test tasks includes: a new server (which can be an icon linking to the server address), monitoring of the server's status, and scheduling of servers based on their status.

[0092] For example, in the server management module, a new server is created, and this server is the one described above. Figure 2 The server shown is connected to the cloud server. In addition, the server management module is also used to configure the newly created server, such as configuring the server's working directory, the maximum number of tasks to run, etc. (each server can run multiple test tasks, and the number of test tasks to run can be configured through the server management module of the cloud platform).

[0093] Optionally, the cloud platform can create multiple servers and run multiple test tasks on these servers. Optionally, different servers can run different types of test tasks.

[0094] When a cloud platform establishes connections with multiple servers, it needs to schedule these servers based on their status. For example, after a user sets up a test task, the server management module monitors whether each server is executing a task and schedules a server that is not currently executing a task as the execution server for that test task, allowing the test task to be executed immediately without waiting. Alternatively, after a user sets up a test task, the server management module schedules a server matching the type of the test task as the execution server for that test task, ensuring efficient resource utilization and the normal operation of the test task.

[0095] Optionally, test task management includes triggering test tasks, task queues, task scheduling, and task records.

[0096] For example, the simulation task management module provides a simulation test interface. Users set up simulation tasks based on the simulation test interface, and the simulation task management module creates test tasks in the system. The simulation test interface allows users to set the test task type, the software to be tested, the model file used for testing, the test script, task information, and the triggering method of the test task.

[0097] Optionally, users can set up multiple test tasks on the cloud platform. When multiple test tasks need to be executed, the simulation task management module manages the order of these test tasks, i.e., the management of the task queue. For example, after the simulation task management module determines the trigger time based on the triggering method of the test task and triggers the test task, it sends the test task to the task queue and assigns a task number (1…100). The task queue then distributes the tasks to the real server in ascending order of their task indices.

[0098] Optionally, the simulation test interface also includes a task status display window, which is used to display the task status. For example, the status of a task that is being executed is RUNNING, and the status of a task that is not being executed is WAITTING.

[0099] Optionally, the task status display window also supports modifying the order of test tasks. For example, users can manually change the priority of test tasks with a WAITTING status, executing tasks that need to be executed earlier first, i.e., task scheduling. This can be achieved by adding priority tags to the task queue, thus modifying the order of test tasks in the queue. Alternatively, the execution order of test tasks can be modified by moving their positions within the queue.

[0100] Optionally, the cloud platform also includes a project management module and a report management module. The project management module is used for maintaining basic project information, uploading and configuring simulation models, uploading and configuring software under test, uploading and configuring test scripts, and maintaining project members. The report management module is used for collecting simulation test logs, collecting test results, analyzing test results, generating and downloading test reports.

[0101] The following describes the construction process of the vehicle software simulation testing system:

[0102] Server configuration: A Linux server running the Ubuntu system is deployed for simulation testing. The necessary environment and configuration parameters for the scheduling client to run are configured on the server. The configured scheduling client is then installed on the server.

[0103] Install Docker and Docker Compose (the software that runs basic Docker) on the server and configure the Docker container runtime environment. Use Docker Compose to build the Docker base image required for model simulation. The base image contains the integrated testing environment and necessary tools (such as simulation testing software) required for model simulation, such as MATLAB, SIUMLINK, startup scripts, etc.

[0104] Cloud platform deployment: A simulation test management system is set up on the cloud platform. The simulation test management system includes a server management module, a simulation task management module, a project management module, and a report management module. Among them, the server management module creates and configures servers based on the deployed servers, including configuring the maximum number of tasks that can be run on the server and the working directory (such as the test task type).

[0105] In addition, the cloud platform also includes a module for obtaining object storage space. Users upload models, software to be tested, and test scripts to object storage space and / or code library to obtain the model address that can be accessed externally. Then, they configure it to the cloud platform. The cloud platform obtains the address of the module's object storage space and / or code library, or obtains the models, software to be tested, and test scripts in the object storage space and / or code library.

[0106] After creating a new server on the cloud platform, connect to the server, download the server's access credential information, generate an access credential file based on the access credential information and the address information of the cloud platform, and upload the access credential file to the corresponding server's configuration directory.

[0107] After the server installs the scheduling client, it downloads the access credential file uploaded by the cloud platform and modifies the scheduling client's configuration file according to the access credential file. For example, it configures the address of the cloud platform in the scheduling client.

[0108] Optionally, in order to standardize and unify the file storage location for vehicle software simulation testing, the server also modifies the local working directory of the scheduling client, modifies the storage directory of the Docker base image and the directory of the test software on the local scheduling client, and sets the working directory for the runtime log.

[0109] After the above settings are completed, start the scheduling client. Once started, the scheduling client sends a heartbeat to the server every 10 seconds. The server and the scheduling client maintain a connection through heartbeats. When the server receives a test task from the cloud platform, it transmits the test task to the scheduling client.

[0110] Optionally, when reporting a heartbeat, the scheduling client checks the number of instantiated Docker containers currently running. If the number of running containers reaches the system's maximum concurrent task count, it reports "Busy"; otherwise, it reports "Idle." For example, assuming the server is configured to run 5 Docker containers simultaneously, when the server receives a test task for the first time, the scheduling client schedules the instantiation of the Docker base image, creating a Docker container. If a second test task is received during this execution, the scheduling client detects that there is now one Docker container running the test task, and the server can handle 5 in parallel, so it reports an "Idle" status (or reports an "Idle" status if no Docker containers are running the test task). If a sixth test task is received, the scheduling client detects that the number of Docker containers running the test task has reached 5, and the sixth test task cannot be executed, so it reports a "Busy" status. The server then reports the current status to the cloud platform, which displays the server's current status.

[0111] After the server and cloud platform are deployed, users can create test projects and test tasks through the simulation test interface provided by the cloud platform, and then the server will execute the test according to the test task.

[0112] Based on the aforementioned vehicle software simulation testing system, this application also proposes a vehicle software simulation testing method, applied to a server, such as... Figure 5 As shown, the method includes:

[0113] S501, in response to the test task instruction, obtains the software under test corresponding to the test task, the model file and test script of the software under test, and the task information required by the software under test to execute the test task;

[0114] As an example, test task instructions are issued by the cloud platform. After receiving the test task instructions, the server obtains the model files, software to be tested, test scripts, and task information required for the test task, so that the user can perform tests specific to the test task.

[0115] It should be noted that the software under test refers to the object being tested. The model file provides a blueprint for the test (e.g., the purpose and standards of the test) to simulate the operating scenario model of the software under test. The test script refers to the tool that implements the test activities. For example, the test script performs automated testing on the software under test according to the guidelines in the model file, verifies whether the response behavior of the software under test meets the expectations in the model file, and realizes the testing of the software under test.

[0116] Optionally, the model files, the software to be tested, the test scripts, and the task information can be downloaded from the cloud platform. For example, after a user sets up a test task through the cloud platform, the cloud platform sends the test task instructions to the server. The server receives the test task instructions and downloads the model files, the software to be tested, the test scripts, and the task information from the cloud platform according to the address or file information indicated in the test task instructions.

[0117] Optionally, such as Figure 6 As shown, the server is also connected to a remote repository. The test task instructions issued by the cloud platform include the model file repository address, the software to be tested repository address, the test script repository address, and task information. The server can download the corresponding model file based on the model file repository address, download the corresponding software to be tested based on the software to be tested repository address, and download the corresponding test script based on the test script repository address.

[0118] In some embodiments, this step is applied to a scheduling client on a server, which provides a runtime environment for the scheduling client. The scheduling client maintains a connection with the server by sending a heartbeat to the server every 10 seconds. Simultaneously, when sending a heartbeat, it also reports its current status, which includes "idle" and "busy". When the scheduling client detects that the number of Docker containers executing test tasks has reached the set number of parallel tasks (the set number of tasks that can be executed simultaneously), the current status is "busy"; when the scheduling client detects that the number of Docker containers executing test tasks has not reached the set number of parallel tasks, the current status is "idle".

[0119] The server then sends the test tasks to be triggered to the scheduling client based on the client's current status. For example, if the scheduling client is "idle," the test tasks are sent to it.

[0120] After receiving a test task instruction, the scheduling client retrieves detailed information such as the model file, the software to be tested, the test script, and task information corresponding to the test task. The specific retrieval methods are listed above.

[0121] After receiving the test task instruction, the scheduling client executes the test task and continues to send heartbeats and report the current status based on the number of Docker containers executing the test task.

[0122] S502 instantiates a Docker container to generate a simulation test environment based on the model file, the software to be tested, the test script, the task information, and the preset Docker base image required for model simulation.

[0123] In this step, the pre-defined Docker base image is compatible with all the software required for model simulation, including simulation test software and the software under test. This Docker base image contains simulation test software and startup scripts; for example, simulation test software includes Matrix Labs MATLAB and the Simulink simulation tool within MATLAB. Based on these software components and the task information set for the software under test, the basic runtime environment and environment variables in the Docker base image are modified. The model files, the software under test, and the test scripts are then loaded into the Docker base image. The model files, the software under test, and the test scripts are configured and combined. The Docker base image is then instantiated, creating a Docker container. Since Docker containers are compatible with various software and utilize simulation test software such as Matrix Labs MATLAB, the Simulink simulation tool within MATLAB, and startup scripts, starting this Docker container generates the simulation test environment for the software under test. This allows a single Docker container to generate all the necessary environment for simulation testing and complete the simulation test of the software under test.

[0124] As an example, based on the model file, the software to be tested, the test script, the task information, and the preset Docker base image required for model simulation, a Docker container is instantiated. The specific implementation method is as follows:

[0125] In response to the startup script's invocation, the following Docker container instantiation process is executed:

[0126] Copy the model files, the software to be tested, the test scripts, and the task information into the Docker base image;

[0127] Run the Docker base image, create Docker containers based on the simulation test software, the software to be tested, model files, and task information, instantiate the Docker containers, and generate the simulation test environment.

[0128] The startup script is the script used to instantiate a Docker container. It specifies the procedures to be executed during the Docker container instantiation process. For example, it copies the model files, the software to be tested, the test scripts, and task information into the Docker base image. Then, based on the simulation test software, the software to be tested, the model files, and the task information in the Docker base image, it configures the Docker container, starts the Docker container, and completes the instantiation of the Docker container.

[0129] As an example, when copying the model file to the Docker base image, the model text is loaded into the MATLAB simulation testing software of the Docker base image so that MATLAB can compile the model file.

[0130] As an example, running a Docker base image, creating Docker containers based on simulation test software, the software under test, model files, and task information, and instantiating these Docker containers to generate the simulation test environment can be implemented as follows:

[0131] A1: Run the Docker base image, load the model file into the MATLAB simulation test software, compile the model file based on MATLAB according to the software to be tested, and obtain the simulation model of the software to be tested.

[0132] In this step, when the Docker base image is run, the MATLAB simulation test software will be launched. MATLAB compiles the model files. During the compilation process, the simulation model corresponding to the software under test is compiled in combination with the interface and protocol environment of the software under test, so as to verify the software under test on the simulation model.

[0133] A2: The simulation test software corresponding to the associated test task, so as to execute the test implementation based on the simulation test software;

[0134] Docker base images contain many basic simulation testing software programs. Different testing tasks or scenarios may require different simulation testing software, or a single simulation testing software may be able to perform simulation tests on multiple similar testing tasks or the software under test. Based on this, Docker base images provide basic simulation testing software. After determining the software to be tested and the test scripts, the test scripts are associated with the corresponding simulation testing software and run within that software, thus automatically building the simulation testing software corresponding to the testing task.

[0135] A2: Based on the environment required by the software under test, configure the task information into the software under test and the simulation model. The task information includes the running parameters and environment variables of the software under test.

[0136] After the model is compiled, the task information of the test task is configured into the software under test and the simulation model, thus completing the configuration of the software under test and the simulation model.

[0137] In this step, the environment required by the software to be tested is configured through the script instructions of the startup script, and the relevant task information is configured to the corresponding locations.

[0138] A3: Complete the instantiation of the Docker container and generate a simulation test environment.

[0139] In this step, based on the above configuration, the Docker container is started and instantiated, creating a simulation test environment for the software under test within the Docker container. During the simulation test, the test script uses the simulation test software to call the simulation model to verify the response of the software under test, thus completing the verification of the software under test.

[0140] As an example, simulation testing software can be varied, with different simulation testing software required for different test tasks or different software under test. Therefore, during the running of the Docker base image, the simulation testing software (such as MATLAB and SIMULINK) mounted on the Docker container is specified according to the software under test and the test task. The REST API port of SIMULINK is specified as the Docker container communication port to communicate with the host machine (such as a server) in order to use the simulation testing software to verify the software under test.

[0141] It should be noted that the Docker base image is a static module. After loading the model files, the software to be tested, the test scripts, and task information into the Docker base image, the creation of the Docker container is achieved by establishing the relationship between each file and the Docker container (e.g., ...). Figure 6 As shown in the diagram, for example, you can specify to mount MATLAB and SIMULINK, specify the SIMULINK REST API port as the communication port, and configure the relevant parameters according to the task information. These configurations can then form a Docker container. Finally, start the Docker container to instantiate it, compile the model file using MATLAB, and map the Docker container to the host machine's SIMULINK software REST API port. This allows you to request the API interface within the Docker container from the host machine to configure and execute MIL test tasks.

[0142] As an example, this step is applied to the scheduling client, which creates a Docker container so that the Docker container can generate a simulation test environment inside.

[0143] S503 starts a Docker container and performs simulation tests on the software under test based on the simulation test environment.

[0144] After creating the simulation test environment through step S502, the software to be tested can be simulated.

[0145] In this step, starting the Docker container and executing simulation tests on the software under test based on the simulation test environment can be implemented as follows:

[0146] The simulation model, the software to be tested, and the test scripts are interconnected.

[0147] The test script is executed line by line by calling the API interface of the SIMULINK software. During the execution of the test script, the simulation test software performs simulation tests on the software under test.

[0148] As an example, after starting the Docker container and executing simulation tests on the software under test in the simulation test environment, the process also includes: destroying the Docker container after the test task is completed. That is, when the test task is completed, the Docker container is destroyed, and for the next test task, the Docker container can be regenerated based on the original basic information.

[0149] Optionally, in some examples, after generating the Docker container, a test copy of the test task (including the simulation environment, task information, etc.) is backed up so that the corresponding test copy can be directly called to repeat the test of the software under test. For the same test task and the same software under test, there is no need to generate the simulation test environment repeatedly. The test copy can be quickly called for simulation testing, which improves work efficiency.

[0150] Optionally, as an example, after starting the Docker container and performing simulation tests on the software under test based on the simulation test environment, the process also includes:

[0151] The simulation test data is uploaded to the cloud platform. The simulation test data includes the simulation test logs and test results after each script in the test script is executed, as well as the data files and log files after the test task is completed.

[0152] Specifically, the test scripts are executed one by one by calling the API interface of the SIMULINK software. After each script is completed, the logs and test results are uploaded to the cloud platform. At the same time, the task execution status is queried. After the task is completed (i.e., the test is completed), the task execution data files and log files are collected. The task data files and log files are parsed to generate the data format required by the cloud platform and returned to the cloud platform, synchronizing that the task has been completed.

[0153] As an example, this step is performed on the scheduling client. In step S502, after creating the Docker container, the scheduling client calls the SIMULINK API interface to load the project configuration file and the scheduling client's runtime environment, configures the runtime environment, and verifies the test script after the runtime environment configuration is completed. After successful verification, the simulation model, the software under test, and the test script are associated with each other, and then the SIMULINK software's API interface is called to execute the test script line by line. During the execution of the test script, the simulation test software performs simulation tests on the software under test.

[0154] In this embodiment, after the test task is triggered, the model file, software to be tested, test script, and task information corresponding to the test task are automatically obtained. Based on the basic environment already built on the server, a Docker container can be created by combining the model file, software to be tested, test script, and task information with the pre-set Docker base image required for model simulation. This Docker container can generate a simulation environment for the software to be tested. Therefore, the server can run the simulation test of the software to be tested based on this simulation environment. The entire simulation test process is automatic and does not require the user to manually create the simulation environment. This testing method has high work efficiency and meets the needs of numerous and frequently updated autonomous driving software.

[0155] Based on the aforementioned vehicle software simulation testing system, this application also proposes a vehicle software simulation testing method applied to a cloud platform, such as... Figure 7 As shown, the method includes:

[0156] S701, in response to the setting operation of the test task, determines the test task and its corresponding model file, software under test, test script and task information according to the setting operation, and establishes the association relationship between the test task and the model file, software under test, test script and task information;

[0157] In this step, the cloud platform provides users with a test task settings interface, which users use to create test tasks. For example, users select the corresponding software to be tested, model file, and test script on the settings interface, and simultaneously set the task information, including the runtime parameters and environment variables required for the software to be tested. Then, users select "Generate Test Task" to complete the test task setup.

[0158] The cloud platform responds to the user's test task settings, determines the test task and its corresponding model file, software to be tested, test script, and task information, and then generates a test task instruction. This instruction can include the test task and its associated model file, software to be tested, test script, and task information. Alternatively, the instruction can also include the task information corresponding to the test task, and the download addresses for the model file, software to be tested, and test script. Furthermore, the test task instruction can take other forms, as long as it allows access to the model file, software to be tested, test script, and task information.

[0159] Once the test task is set up, the test task will be generated and can be triggered to schedule the server to execute the test task.

[0160] As an example, test tasks can be generated and triggered immediately, or they can be processed based on the set triggering method.

[0161] Optionally, to enrich the functionality and flexibility of simulation testing, the cloud platform allows users to configure the triggering method for test tasks according to their needs. For example, triggering methods include manual triggering, single-time scheduled task triggering, and periodic scheduled task triggering. Manual triggering requires the task executor to manually click to start the task; a single-time scheduled task involves inputting a fixed trigger time, which is then automatically triggered upon expiration; a periodic scheduled task involves inputting a Cron expression, which the system parses into a list of trigger times, and the task runs automatically upon expiration. Thus, if a user needs to trigger a test task during non-operational hours, they can choose single-time scheduled task triggering, setting the trigger time to non-operational hours to avoid disrupting their work. If a software requires multiple periodic tests, the user can choose periodic scheduled task triggering, with the cloud platform automatically triggering the test task periodically, eliminating the need for manual triggering or multiple timed triggers by the user, thus preventing omissions or forgetting to trigger the task and affecting the final test results.

[0162] In some examples, to facilitate unified management of test tasks within the same project and to improve the testing efficiency of test tasks within the same project, the cloud platform also provides a project creation module. Test tasks within the same project can be configured with a set of basic project information, which can be shared by test tasks within the same project, saving time in setting up basic information.

[0163] Based on this, a model simulation project is created on the cloud platform, the model file storage address is configured, the repository address of the software to be tested is configured, and the code repository address of the test script is configured. Then, a model simulation test task is created based on the simulation project.

[0164] S702 sends the test task to the execution server when the test task meets the triggering conditions.

[0165] In this step, after the cloud platform generates a test task, it checks whether the test task meets the triggering conditions and then sends the test task to the execution server in a timely manner.

[0166] As an example, if the test task is triggered as soon as it is generated, then the test task is determined to meet the triggering conditions at the time of its generation.

[0167] As an example, if a test task is triggered based on a configured triggering method, then the system determines whether to trigger the test task based on the triggering conditions corresponding to the user-defined triggering method. Optionally, the system determines whether the test task meets the triggering conditions in the following ways:

[0168] For example, if a user sets a scheduled task to trigger, then when the current time reaches the task trigger time, it is determined that the test task meets the trigger conditions.

[0169] If the user sets up a periodic scheduled task to trigger, when the current time reaches the task trigger time, it is determined that the test task meets the trigger conditions. Based on the set period, the time of the next period is determined and updated to the task trigger time that needs to be monitored. Then, the system continues to monitor whether the current time has reached the task trigger time.

[0170] If the user sets up manual triggering, the test task is determined to meet the triggering conditions when a click on the trigger control is detected. For example, if the user manually clicks the trigger control, the triggering conditions are met, and the test task is sent to the execution server.

[0171] Furthermore, in some embodiments, the cloud platform can connect to multiple servers, enabling simulation tests to be executed on these servers. The execution server corresponding to a test task can be selected by the user. For example, when creating a test task, the user selects an execution server based on the servers provided by the cloud platform, and the cloud platform then distributes the test task to that execution server. Alternatively, the cloud platform can provide the optimal execution server based on the type of task being executed and the current running status of each server to execute the test task. With the increasing demand for software testing, multiple test tasks often execute simultaneously. By rationally allocating test tasks for each piece of software under test through a cloud platform, the efficiency of simulation testing can be improved, meeting current needs.

[0172] Specifically, before sending the test task to the execution server when the test task meets the triggering conditions, the following steps are also included:

[0173] The execution server is determined based on the test task, the task type executed by each server, and its current running status;

[0174] In this step, the PTZ platform automatically matches the execution server corresponding to the test task based on the test task, the type of task executed by each server, and its current running status.

[0175] When configuring each server, the corresponding basic test environment can be configured according to the task type. Therefore, the server is bound to the type of task to be executed. When the cloud platform schedules the servers, it selects the server that matches the test task as the execution server. At the same time, when there are multiple servers that match the test task, it also schedules the servers based on the current running status of each server and selects the server that is currently idle as the execution server for the test task.

[0176] The cloud platform automatically matches the execution server corresponding to the test task, eliminating the need for manual selection by the user. Furthermore, the automatically matched execution server by the cloud platform allows for more efficient allocation and scheduling of servers. For example, when multiple test tasks are triggered simultaneously, the cloud platform can consider the characteristics of each task and assign a more suitable execution server to each.

[0177] Alternatively, it can display the operating information of each server, including the type of task being performed and the current operating status; then respond to selection operations based on the operating information, and determine the server to execute based on the selection operation.

[0178] In this step, the PTZ platform directly outputs the servers that can execute the test task to the user based on the test task, the type of task executed by each server, and its current running status. The user then selects the server as the execution server for the test task.

[0179] Compared to the steps above, in this step, users can select a server according to their needs, increasing human-computer interaction. Users can choose a convenient server to execute test tasks based on their actual needs, thus improving the user experience.

[0180] In this embodiment, the cloud platform provides a settings interface for users, eliminating the need for users to conduct software testing at a fixed PC workstation. The cloud platform configures servers to execute test tasks, allowing users to set up test tasks on any computer. The cloud platform automatically schedules servers to execute test tasks, simplifying the software testing process. Furthermore, users can perform multiple test tasks in parallel, or process test tasks alongside other tasks without waiting.

[0181] Based on all the above embodiments, taking a piece of software to be tested as an example, the specific operation process of the vehicle software simulation testing system and the specific implementation process of the vehicle software testing method provided in this application embodiment are described as follows:

[0182] like Figure 8 As shown, after the server is set up, it forms a vehicle software simulation testing system with the cloud platform.

[0183] First, users upload the software to be tested, model files, and test scripts to object storage or a code repository, obtain the model address for external access, and configure it on the cloud platform. They then connect to the software artifact management platform, which retrieves the software version information and download address when a new version of the software to be tested is released.

[0184] Create a code repository in the GitLab code repository, package the test project, including test scripts, parameter configuration files, runtime environment files, etc., and upload them to the code repository. When the test engineer updates the test project code, the updated code will be directly synchronized to the code repository.

[0185] Create a new project in the project management module of the cloud platform and configure the project member information.

[0186] In the newly created project, the model storage address, code repository address, and software to be tested address are configured into the corresponding fields in the project. Basic test case information is configured in the project management module; test tasks created in the project can then use the basic test cases configured in the project's basic test cases.

[0187] In the task management module of the cloud platform, test tasks are created based on newly created projects, selecting the software version, model version, and test script to be tested. The task triggering method is then configured in the task management module. Three triggering methods are supported: manual triggering, single-time scheduled task triggering, and periodic scheduled task triggering. Manual triggering requires the task executor to manually click to start the task; single-time scheduled tasks require inputting a fixed trigger time, which will automatically trigger upon expiration; periodic scheduled tasks require inputting a Cron expression, which the system parses into a list of trigger times, and the task will automatically run upon expiration.

[0188] If you manually select an execution server, the server selected by the user will be bound as the execution server. At this point, the test task creation is complete.

[0189] The following is the execution process of the vehicle software testing method:

[0190] Once a task is triggered, it enters the task queue on the cloud platform and is assigned a task number (Task(1…100)). The task queue then distributes the tasks to the scheduling client on the server in ascending order of their index numbers.

[0191] The server sends the task IDs that need to be triggered to the scheduling client on the server based on the status of the task queue. The scheduling client uses the task ID to request detailed task information from the server, and downloads the model files, software to be tested, and test scripts configured in the task according to the reconfiguration parameters of the task, storing them in the working directory of the scheduling client.

[0192] When the scheduling client reports its next heartbeat, it will change the running status to "busy" and report the task execution status to the server, allowing the server to view the task's running status in real time.

[0193] Then, after the client has downloaded the model files, software to be tested, and test scripts required for the task, it runs the Start.sh script in the server directory, which is the startup script.

[0194] After running the startup script, the script's calling instructions copy the software to be tested to the working directory of the MATLAB project, where it will be compiled using MATLAB within the container.

[0195] The scheduling client uses the server socket to query free ports for container internal port mapping and starts the Docker image. When the Docker image runs, it specifies the execution of the htsStart.sh file and MATLAB and SIMULINK project files; and specifies the mapping of the internal port of the SIMULINK software REST API to the host machine port, and creates the Docker container.

[0196] After creating the Docker container, the startup script first starts MATLAB and compiles the model. After completion, it exits MATLAB and then starts MATLAB and SIMULINK. By mapping the Docker container to the host machine's SIMULINK software REST API port, the host machine can request the API interface within the container to configure and execute MIL test tasks.

[0197] The client program calls the SIMULINK software's API interface to load the project configuration file and runtime environment. After the runtime environment is configured, the test script is verified, and then the simulation model, the software under test, and the test script are associated with each other.

[0198] The client program calls the SIMULINK software's API interface to execute test scripts one by one. After each script is executed, the logs and test results are uploaded to the cloud platform. At the same time, the client program queries the task execution status. After the task is completed, it collects the task execution data files and log files, and uploads them to the server to synchronize that the task has been completed.

[0199] The scheduling client program also parses the task's data files and log files, generates the data format required by the cloud platform, and returns it to the cloud platform.

[0200] The scheduling client determines that the Docker container has been destroyed after the test task has been completed.

[0201] After receiving the test task data from the scheduling client, the cloud platform modifies the test task status to the corresponding test result and generates an HTML test report from the uploaded data. The test report includes detailed test run logs and result data.

[0202] Once the test report is generated, the cloud platform will send an email or internal communication tool to notify the person in charge that the task has been completed, and will also send the HTML test report.

[0203] Based on the above process, all testing operations for a test software are completed, including user operations and system operation.

[0204] This application embodiment also provides a vehicle software simulation testing device, the device comprising:

[0205] The acquisition module is used to respond to test task instructions and obtain the software under test, the model file and test script of the software under test, and the task information required by the software under test to execute the test task.

[0206] The simulation environment generation module is used to instantiate Docker containers and generate a simulation test environment based on model files, software to be tested, test scripts, task information, and the preset Docker base image required for model simulation.

[0207] The testing module is used to start Docker containers and perform simulation tests on the software under test based on the simulation test environment.

[0208] The vehicle software simulation testing device provided in this application embodiment can execute the above method embodiment. Its specific implementation principle and technical effect can be found in the above method embodiment, and will not be repeated here.

[0209] This application embodiment also provides a vehicle software simulation testing device, the device comprising:

[0210] The configuration module is used to respond to the configuration operations of test tasks. Based on the configuration operations, it determines the test task and its corresponding model file, software under test, test script and task information, and establishes the association between the test task and the model file, software under test, test script and task information.

[0211] The task distribution module is used to distribute test tasks to the execution server when the test task meets the triggering conditions.

[0212] The vehicle software simulation testing device provided in this application embodiment can execute the above method embodiment. Its specific implementation principle and technical effect can be found in the above method embodiment, and will not be repeated here.

[0213] like Figure 9 As shown in the illustration, this application also provides an electronic device, including: a processor 901 and a memory 902; optionally, the electronic device 900 further includes a communication component 903. The processor 901, memory 902, and communication component 903 are connected via a CAN bus.

[0214] The memory 902 is used to store computer programs / instructions; the processor 901 is used to execute the computer programs / instructions stored in the memory to implement the methods involved in the above embodiments.

[0215] The electronic device 900 also includes a communication interface. The processor, which provides computing and control capabilities, can be a GPU, CPU, NPU, MCU, FPGA, etc. Storage devices include internal memory and non-volatile memory. The non-volatile memory stores the computer programs implementing the above methods. The internal memory provides the environment for program startup and execution. The communication interface is used for wired or wireless communication with external terminals.

[0216] The present invention also provides a computer-readable storage medium / computer program product, wherein the computer-readable storage medium stores computer control instructions / computer program product including computer control instructions, which, when executed by a processor, are used to implement the methods involved in the above embodiments.

[0217] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A vehicle software simulation testing method, characterized in that, Applied to a server, the method includes: In response to a test task instruction, obtain the software to be tested corresponding to the test task, the model file and test script of the software to be tested, and the task information required by the software to be tested to execute the test task; Based on the model file, the software to be tested, the test script, the task information, and the preset Docker base image required for model simulation, the Docker container is instantiated to generate a simulation test environment; Start the Docker container and perform simulation tests on the software under test based on the simulation test environment; The Docker base image includes simulation testing software and a startup script. The process of instantiating a Docker container to generate a simulation testing environment based on the model file, the software to be tested, the test script, the task information, and the preset Docker base image required for model simulation includes: In response to the invocation instruction of the startup script, the following Docker container instantiation process is executed: Copy the model file, the software to be tested, the test script, and the task information into the Docker base image; Run the Docker base image, load the model file into the MATLAB of the simulation test software, and compile the model file based on the MATLAB according to the software to be tested to obtain the simulation model of the software to be tested; Associate the simulation test software corresponding to the test task, and execute test instances based on the simulation test software; Based on the environment required by the software under test, the task information is configured into the software under test and the simulation model. The task information includes running parameters and environment variables. The Docker container is instantiated to generate a simulation test environment.

2. The method according to claim 1, characterized in that, After starting the Docker container and performing simulation tests on the software under test based on the simulation test environment, the method further includes: After the test task is completed, the Docker container is destroyed.

3. The method according to claim 1, characterized in that, After starting the Docker container and performing simulation tests on the software under test based on the simulation test environment, the method further includes: The simulation test data is uploaded to the cloud platform. The simulation test data includes the simulation test log and test results after each script in the test script is executed, as well as the data file and log file after the test task is completed.

4. A vehicle software simulation testing method, characterized in that, Applied to a cloud platform, the method includes: In response to the setting operation of the test task, the test task and its corresponding model file, software to be tested, test script and task information are determined according to the setting operation, and the association relationship between the test task and the model file, the software to be tested, the test script and the task information is established; When the test task meets the triggering conditions, the test task is sent to the execution server so that the server responds to the test task instruction and obtains the software under test corresponding to the test task, the model file and test script of the software under test, and the task information required by the software under test to execute the test task. The Docker base image includes simulation test software and startup script. In response to the call instruction of the startup script, the following Docker container instantiation process is executed: the model file, the software under test, the test script and the task information are copied into the Docker base image; the Docker base image is run; the model file is loaded into the MATLAB of the simulation test software; the model file is compiled based on the software under test using MATLAB to obtain the simulation model of the software under test; the simulation test software corresponding to the test task is associated to execute the test instance based on the simulation test software; the task information, including running parameters and environment variables, is configured into the software under test and the simulation model according to the environment required by the software under test; the Docker container instantiation is completed, and the simulation test environment is generated.

5. The method according to claim 4, characterized in that, Before sending the test task to the execution server when the test task meets the triggering condition, the method further includes: The execution server is determined based on the test task, the task type executed by each server, and its current running status.

6. The method according to claim 4, characterized in that, Before sending the test task to the execution server when the test task meets the triggering condition, the method further includes: Displays the operating information of each server, including the type of task being performed by the server and its current operating status; In response to a selection operation based on the runtime information, the execution server is determined according to the selection operation.

7. The method according to any one of claims 4 to 6, characterized in that, The method further includes: When the current time reaches the task trigger time, it is determined that the test task meets the trigger conditions; Alternatively, a click operation on the trigger control is detected, determining that the test task meets the triggering conditions.

8. A vehicle software simulation testing system, characterized in that, The system includes a server and a cloud platform; The server is used to perform the method according to any one of claims 1 to 3; The cloud platform is used to perform the method according to any one of claims 4 to 7.

9. The system according to claim 8, characterized in that, The server includes basic software for running Docker, a scheduling client, and a Docker base image. The scheduling client is used to create Docker containers based on the Docker base image and call the simulation environment to test the software under test when the Docker container generates a simulation environment. The basic software for Docker is used to drive the Docker container to generate the simulation environment.

10. The system according to claim 8, characterized in that, The cloud platform includes a simulation task management module and a server management module. The simulation task management module is used to create simulation test tasks and trigger test tasks; the server management module is used to create and connect to servers and configure the servers.

11. A vehicle software simulation testing device, characterized in that, The device includes: The acquisition module is used to obtain, in response to the test task instruction, the software to be tested corresponding to the test task, the model file and test script of the software to be tested, and the task information required by the software to be tested to execute the test task; The simulation environment generation module is used to instantiate a Docker container and generate a simulation test environment based on the model file, the software to be tested, the test script, the task information, and the preset Docker base image required for model simulation. The testing module is used to start the Docker container and perform simulation tests on the software under test based on the simulation test environment. The Docker base image includes simulation testing software and startup scripts. The simulation environment generation module is also used for: In response to the invocation instruction of the startup script, the following Docker container instantiation process is executed: Copy the model file, the software to be tested, the test script, and the task information into the Docker base image; Run the Docker base image, load the model file into the MATLAB of the simulation test software, and compile the model file based on the MATLAB according to the software to be tested to obtain the simulation model of the software to be tested; Associate the simulation test software corresponding to the test task, and execute test instances based on the simulation test software; Based on the environment required by the software under test, the task information is configured into the software under test and the simulation model. The task information includes running parameters and environment variables. The Docker container is instantiated to generate a simulation test environment.

12. A vehicle software simulation testing device, characterized in that, The device includes: The setting module is used to respond to the setting operation of the test task, determine the test task and its corresponding model file, software to be tested, test script and task information according to the setting operation, and establish the association relationship between the test task and the model file, the software to be tested, the test script and the task information; The task distribution module is used to distribute the test task to the execution server when the test task meets the triggering conditions, so that the server responds to the test task instruction and obtains the software under test corresponding to the test task, the model file and test script of the software under test, and the task information required by the software under test to execute the test task. The Docker base image includes simulation test software and startup script. In response to the call instruction of the startup script, the following Docker container instantiation process is executed: the model file, the software under test, the test script and the task information are copied into the Docker base image; the Docker base image is run; the model file is loaded into the MATLAB of the simulation test software; the model file is compiled based on the software under test using MATLAB to obtain the simulation model of the software under test; the simulation test software corresponding to the test task is associated to execute the test instance based on the simulation test software; the task information, including running parameters and environment variables, is configured into the software under test and the simulation model according to the environment required by the software under test; the instantiation of the Docker container is completed, and the simulation test environment is generated.

13. An electronic device, characterized in that, include: Memory, processor; The memory is used to store computer programs / instructions; The processor is configured to implement the method as described in any one of claims 1 to 3, or the method as described in any one of claims 4 to 7, according to the computer program / instructions stored in the memory.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, is used to implement the method as described in any one of claims 1 to 7.

15. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images