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

Abstract

The invention relates to a vehicle software simulation test method, system and device and a storage medium, and the method comprises the steps: obtaining to-be-tested software corresponding to a test task, a model file and a test script of the to-be-tested software, and task information needed when the to-be-tested software executes the test task in response to a test task instruction; according to the model file, the to-be-tested software, the test script, the task information and a Docker basic mirror image required by preset model simulation, instantiating a Docker container to generate a simulation test environment; and starting the Docker container, and executing a simulation test of the to-be-tested software based on the simulation test environment. According to the embodiment of the invention, the simulation test environment can be automatically created, the simulation test is automatically performed based on the simulation test environment, a user does not need to manually create the simulation environment, the working efficiency is high, and the requirements of more automatic driving software and frequent updating are met.

Description

Technical Field

[0001] The present invention relates to the technical field of software model simulation, and in particular to a vehicle software simulation test method, system, device and storage medium. Background Art

[0002] Model simulation testing is often used for software testing. With the trend of automobile electrification and intelligence, there are more and more intelligent software, and the corresponding demand for model simulation is increasing. The workload invested by R&D personnel in model simulation is increasing.

[0003] In related technologies, when simulating a model, R&D personnel are required to enter the simulation test system in a PC workstation (industrial computer) to manually load the model, and then enter the simulation environment to manually configure the corresponding operating parameters, environment variables, and running scripts, etc., to complete the construction of the model simulation environment. After the environment is set up, the software to be tested is run in the simulated environment for testing.

[0004] It can be seen that the above model simulation test system has the problem of low working efficiency. Summary of the invention

[0005] One of the purposes of the present invention is to provide a vehicle software simulation testing method to solve the problem that the model simulation testing in the prior art is inefficient and difficult to meet the current increasing demand for model simulation testing; the second purpose is to provide a vehicle software simulation testing system; the third purpose is to provide a vehicle software simulation testing device.

[0006] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0007] In a first aspect, a vehicle software simulation test method is applied to a server, the method comprising:

[0008] In response to the 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 for the software to be tested to execute the test task;

[0009] Instantiate the Docker container according to the model file, the software to be tested, the test script, the task information and the preset Docker basic image required for model simulation to generate a simulation test environment;

[0010] The Docker container is started, and a simulation test of the software to be tested is performed based on the simulation test environment.

[0011] According to the above-mentioned technical means, after the test task is triggered, the software to be tested corresponding to the test task, the model file and test script corresponding to the software to be tested, and the task information required for the software to be tested to execute the test task are automatically obtained. Based on the basic environment that has been built on the server, by combining the model file, the software to be tested, the test script and the task information with the pre-set Docker basic image required for the model simulation and compatible with all software operations, a Docker container can be created, and the 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 the simulation environment. The entire simulation test process is carried out automatically without the need for the user to manually create a simulation environment. This testing method has high work efficiency and meets the needs of multiple autonomous driving software and frequent updates.

[0012] Further, the Docker basic image includes simulation test software and a startup script, and the Docker container is instantiated according to the model file, the software to be tested, the test script, the task information and the preset Docker basic image required for model simulation to generate a simulation test environment, including:

[0013] In response to the calling 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 basic 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] According to the above-mentioned technical means, since the simulation test software and startup scripts are pre-set in the Docker basic image, and these software can adapt to the various software required for software simulation testing, in this way, a call based on the model file, the software to be tested, the test script, and the task information can be implemented to create a Docker container, and the Docker container can generate a simulation test environment for the software to be tested when it is started, thereby realizing automatic creation of the simulation test environment, eliminating manual creation, and improving work efficiency.

[0017] Further, the running of the Docker basic 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 a simulation model of the software to be tested;

[0019] Associating the simulation test software corresponding to the test task to execute the test instance based on the simulation test software;

[0020] According to the environment required by the software to be tested, configuring the task information into the software to be tested and the simulation model, the task information including operating parameters and environment variables;

[0021] Complete the instantiation of the Docker container and generate a simulation test environment.

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

[0023] Further, after starting the Docker container and performing the simulation test of the software to be tested based on the simulation test environment, the method further includes:

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

[0025] According to the above technical means, since the simulation test environment in the Docker container is destroyed after use, the Docker container will regenerate a new simulation test environment during the next simulation test instead of repeatedly modifying the environment in the Docker container. This can avoid frequent changes to the environment that may cause environmental problems.

[0026] Further, after starting the Docker container and performing the simulation test of the software to be tested based on the simulation test environment, the method further includes:

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

[0028] According to the above technical means, it is convenient for users to view the test results.

[0029] In the second aspect, the technical solution adopted by the present invention is as follows:

[0030] A vehicle software simulation test method, applied to a cloud platform, comprises:

[0031] In response to a setting operation of a test task, determining the test task and its corresponding model file, software to be tested, test script and task information according to the setting operation, and establishing an association relationship between the test task and the model file, the software to be tested, the test script and the task information;

[0032] When the test task meets the trigger condition, the test task is sent to the execution server.

[0033] According to the above technical means, the cloud platform provides users with a setting interface, and users do not need to go to a fixed PC workstation to perform software testing; the cloud platform configures the server to execute test tasks, and users can set test tasks on any computer, and the cloud platform automatically schedules the server to execute test tasks. On the one hand, it simplifies the operating process of software testing, and on the other hand, users can perform multiple test tasks in parallel, or users can process test tasks and other work in parallel without the need for users to wait.

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

[0035] The execution server is determined according to the test task, the execution task type of each server and the current running status of each server.

[0036] According to the above technical means, the cloud platform can configure and schedule multiple servers to execute multiple test tasks at the same time. During the server scheduling process, a better execution server is assigned to the test task based on the server execution task type and its current running status, thereby improving the efficiency of multi-task parallel testing.

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

[0038] Display the operation information of each server, including the type of tasks executed by the server and the current operation status;

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

[0040] According to the above technical means, the cloud platform can configure and schedule multiple servers to execute multiple test tasks at the same time. During the server scheduling process, based on the server execution task type and its current running status, it recommends a better execution server to the user to execute the test task, and at the same time provides interaction to the user to improve the user experience.

[0041] Furthermore, the method further comprises:

[0042] When the current time reaches the task trigger time, determining that the test task meets the trigger condition;

[0043] Alternatively, a click operation of a trigger control is detected, and it is determined that the test task meets the trigger condition.

[0044] Based on the above technical means, the cloud platform provides a variety of 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 software simulation test effect.

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

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

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

[0048] Furthermore, the server includes basic software for running Docker, a scheduling client and a Docker basic image. The scheduling client is used to create a Docker container based on the Docker basic image, and when the Docker container generates a simulation environment, the simulation environment is called to test the software to be tested; the Docker basic software 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 is used to create and connect to servers and configure the servers.

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

[0051] An acquisition module, for obtaining, in response to a 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 for the software to be tested to execute the test task;

[0052] A simulation environment generation module is used to instantiate a Docker container and generate a simulation test environment according to the model file, the software to be tested, the test script, the task information and the preset Docker basic image required for model simulation;

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

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

[0055] A setting module, used to respond to the setting operation of the test task, determine the test task and its corresponding model file, the software to be tested, the test script and the task information according to the setting operation, and establish an 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 sending module is used to send the test task to the execution server when the test task meets the trigger condition.

[0057] An electronic device, comprising: a memory, 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 or the method described in the second aspect according to the computer programs / instructions stored in the memory.

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

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

[0061] Beneficial effects of the present invention:

[0062] (1) The vehicle software simulation test of the present application is highly efficient. First, the cloud platform provides a setting interface for the simulation test. Users can directly set the simulation test related information on the setting interface. Based on the configuration of the execution server on the cloud platform, the cloud platform can directly trigger the execution server to execute the test task and complete the software simulation test. Users do not need to go to a fixed PC workstation to operate. Secondly, users only need to select the software to be tested, the model file and test script corresponding to the software to be tested, and configure some relevant task information for the software to be tested. The server can mobilize this information and automatically build a simulation environment for the software to be tested in the Docker container. Users do not need to enter the test system to manually modify the environment, thereby improving work efficiency. Thirdly, by deploying multiple Docker containers on each server, or deploying multiple servers on the cloud platform, multiple test tasks can be processed in parallel. Therefore, the simulation test method provided by the present application is adapted to the current testing needs of increasing intelligent software and frequent intelligent software updates, especially in the field of autonomous driving, and meets the needs of autonomous driving vehicle software testing.

[0063] (2) The vehicle software simulation test of the present application is not prone to errors. First, there is no need to manually build a simulation environment. Second, a new simulation environment is generated for each Docker container created for each test task, which is destroyed after the test task is completed without affecting the basic environment information. Therefore, the probability of errors can be reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Figure 1 A schematic diagram of a vehicle software simulation test system provided in one embodiment of the present application;

[0065] Figure 2 A schematic diagram of a server of a vehicle software simulation test system provided in one embodiment of the present application;

[0066] Figure 3 A schematic diagram of a Docker container of a vehicle software simulation test system provided in one embodiment of the present application;

[0067] Figure 4 A schematic diagram of a cloud platform of a vehicle software simulation test system provided in one embodiment of the present application;

[0068] Figure 5 A flowchart of a vehicle software simulation test method provided in one embodiment of the present application;

[0069] Figure 6 A schematic diagram of generating a simulation test environment and instantiating a Docker container for server scheduling related information provided in an embodiment of the present application;

[0070] Figure 7 A flowchart of a vehicle software simulation test method provided by another embodiment of the present application;

[0071] Figure 8 A schematic diagram of the operation flow of a vehicle software simulation test system provided in one embodiment of the present application;

[0072] Fig. 9 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0073] The following will describe the embodiments of the present invention 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 contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways 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, 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 illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being 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 complicated.

[0075] The conventional method of software testing is model-based simulation testing. Since software testing has high requirements for the operating environment, a fixed PC workstation is usually set up for software testing. After developing or modifying a piece of software, R&D personnel need to manually load the model required for testing the software to be tested on the PC workstation, and manually configure the corresponding operating parameters, environment variables, and running scripts, etc., and manually build the model simulation environment. After the environment is built, run the software to be tested in the simulated environment for testing.

[0076] Before the intelligentization of automobiles, there were fewer software applications on automobiles and fewer software testing requirements, so the above-mentioned testing methods have met the research and development needs. However, with the wave of automobile electrification and intelligence, there are more and more intelligent software, and the corresponding model simulation requirements are increasing, and the workload invested by R&D personnel in model simulation is increasing. The above-mentioned testing methods have low working efficiency and can no longer meet the needs in the application of automobile software testing. Therefore, it is urgent to propose a software simulation test system with high working efficiency and low error-proneness to meet the needs of automobile software testing.

[0077] like Figure 1 As shown, an embodiment of the present application proposes a vehicle software simulation test system, which includes a cloud platform and at least one server, wherein the cloud platform can schedule and manage at least one server, the cloud platform schedules and manages the server to execute test tasks, and the server is used to automatically build a test environment according to the test tasks and automatically test the test software.

[0078] As an example, the cloud platform can provide users with a simulation test interface, through which users can perform software tests. The cloud platform can also generate test tasks based on the user's setting information on the setting interface, and trigger the server to execute the test tasks by sending the test tasks to the server. After the server executes the test tasks, the test data is fed 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 test interface on the computer at any workstation to perform software testing without having to go to a specific PC workstation to perform software testing (a PC workstation is a graphical interface, and running software testing in a graphical interface will occupy a PC workstation); and the test task is sent to the server for execution. During the execution of the test task, the use of the user's workstation computer is not affected. One server can execute multiple test tasks at the same time, or multiple servers can be used to execute multiple test tasks at the same time to achieve parallel processing of multiple test tasks. Therefore, the vehicle software simulation test system provided in the embodiment of the present application is, on the one hand, easy to operate and does not require operation at a specific location; on the other hand, multiple test tasks can be performed in parallel, which improves the work efficiency of software testing and is suitable for applications with increasing software testing requirements.

[0080] It should be noted that the cloud platform and the server implement the above work based on building a simulation test management system on the cloud platform and building a simulation test operation system on the server. The following is mainly based on a composition example of the simulation test management system and the simulation test operation system and the corresponding functions.

[0081] As an example, Figure 2 As shown, the server includes basic software for running Docker, a scheduling client and a Docker basic image (the figure shows Docker containers 1, 2, 1...n after the Docker basic image is instantiated). The scheduling client is used to schedule related information (such as software to be tested, model files, test scripts, task information, etc.), create a Docker container based on the Docker basic image, and provide the required information for the Docker container to generate a simulation environment, such as simulation test software. The software to be tested is tested in a simulation environment based on the simulation test software, and the test data obtained during the test is uploaded to the cloud platform; the Docker basic software is used to drive the instantiation of the Docker container and generate a simulation environment in the Docker container.

[0082] It should be noted that the Docker container is an open source application container engine that allows an application and its dependent packages to be packaged into a portable container and then published to a Linux server. Based on the application of the Docker container, this embodiment can generate a simulation environment belonging to the current software to be tested in the Docker container, and the software to be tested is tested in the simulation environment. After the test is completed, the Docker container can be directly destroyed without affecting the basic information of the simulation test system.

[0083] In some instances, the simulation environment corresponding to the test software is built by manually modifying and setting some parameters in the environment of the test system. For example, the test system is configured with a basic environment. When the user needs to test the software to be tested 1 in the test system, the user enters the basic environment of the test system, modifies the basic environment according to the environmental requirements corresponding to the software to be tested 1, obtains the simulation environment a of the software to be tested 1, and then tests the simulation software 1 in the simulation environment a. When the user needs to test the software to be tested 2 in the test system, the user enters the simulation environment a to modify the environment (or restores the simulation environment a to the basic environment and then modifies it), obtains the simulation environment b of the software to be tested 2, and then tests the simulation software 2 in the simulation environment b. This environment building method requires high professionalism from the user, can only be done manually, and the process is cumbersome and the work efficiency is extremely low.

[0084] In order to realize the automatic generation of the simulation environment, as an example, the embodiment of the present application proposes to use a Docker container to mirror the simulation environment. The simulation environment generated by the Docker container is a new simulation environment for the current software to be tested, not an environment modified under the basic environment. For example, the user needs to test the software to be tested 1 in the test system, and the Docker container generates a simulation environment a for the software to be tested 1 based on the relevant information of the schedule (including the basic environment); the user needs to test the software to be tested 2 in the test system, and the Docker container generates a simulation environment b for the software to be tested 2 based on the relevant information of the schedule (including the basic environment). The basic environment information of the test system is not modified, so the user's professionalism is not required, and no manual operation is required. In addition, the Docker container can be destroyed after executing the test task, and different test environments can be repeatedly generated; it is also possible to simultaneously generate simulation environments for multiple test tasks by creating multiple Docker containers.

[0085] However, since multiple software needs to be run during the simulation test, such as simulation test software and software to be tested, the simulation test software includes multiple functional software. There are challenges in software compatibility when running multiple software in a Docker container, so in some examples, multiple Docker containers are used to mirror multiple environments, and multiple Docker containers run multiple software respectively. In this way, it is also necessary to associate the output and input of each Docker container to achieve the completed software test, and the setting method is relatively complicated. Therefore, the embodiment of the present application provides: first, a Docker basic image that is compatible with all software required for vehicle software simulation testing (including simulation test software, software to be tested, etc.) is generated; then the software to be tested, the model file and test script of the software to be tested, and the task information required for the software to be tested to execute the test task are automatically called, copied to the Docker basic image, and a Docker container is generated. The Docker container generates a simulation environment, and the simulation environment of the software to be tested is automatically built, and the operation of various simulation test software, test software and other software can be compatible in the simulation environment. Compared with manual construction, it is efficient and the setting method is simple.

[0086] Optionally, the embodiment of the present application implements the scheduling of relevant information and the creation of a Docker container by scheduling a client, so that the Docker container can generate a simulation environment of the software to be tested based on the relevant information. The specific implementation process is as follows:

[0087] The Docker base image deployed by the server contains the basic software, environment variables and operating parameters required for model simulation. The scheduling client is connected to the cloud platform. The scheduling client can download the software to be tested, model files, test scripts and task information through the cloud platform, and then package this information into the Docker base image. After the Docker base image obtains this information, it can drive the instantiation of the Docker base image through the deployed Docker basic software to obtain the Docker container (such as Figure 3 As shown in the figure), when the Docker container is started, a simulation environment for the software to be tested is generated.

[0088] As an example, the open source Ubuntu system is used to create a Docker basic image, in which simulation test software such as MATLAB and SIMULINK are installed, and basic environment variables and running parameter files are configured. At the same time, a workspace for the software to be tested, models, and test scripts is reserved in the Docker basic image. When the image is instantiated, it supports modifying parameters and writing reserved content, thereby forming a Docker container that can execute model simulation tests.

[0089] As an example, 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 test task management; the server management module is used to create servers, connect to servers and manage servers.

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

[0091] To complete the simulation test of a software, it is necessary to set the test task and run the test task. In this embodiment, the test task is set through the cloud platform, and the test task is run through the simulation server. Therefore, it is necessary to configure the server that runs the test task on the cloud platform to form a complete system for software simulation testing. Among them, the server configured by the cloud platform to run the test task includes: a new energy server (which can be an icon with a server address linked to it), monitoring the status of the server, and scheduling the server based on the status of the server.

[0092] For example, the server management module creates a new server, which is the above Figure 2 The cloud server establishes a connection with the 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 running tasks, etc. (each server can run multiple test tasks, and the number of running test tasks 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 based on the multiple servers. Optionally, different servers can run different types of test tasks.

[0094] When the cloud platform establishes connections with multiple servers, it needs to schedule multiple servers, and the servers are specifically scheduled according to the status of the servers. For example, after the user sets a test task, the server management module monitors whether each server is in the status of executing the task, and schedules the server that is not executing the task as the execution server of the test task, so that the test task can be executed immediately without waiting. Alternatively, after the user sets a test task, the server management module schedules a server that matches the type of the test task as the execution service weapon of the test task, and schedules the matching server to run the test task, so as to achieve rational use of resources and ensure that the test task can run normally.

[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. The user sets the simulation task based on the simulation test interface, and the simulation task management module creates the test task in the system. Based on the simulation test interface, the test task type, the software to be tested, the model file used for the test, the test script, the task information, and the triggering method of the test task can be set.

[0097] Optionally, the user 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 multiple test tasks, that is, the management of the task queue. For example, after the simulation task management module determines the trigger time according to the triggering method of the test task and triggers the test task, it sends the test task to the task queue and assigns the task number Task (1...100). The task queue will send the task to the real server according to the task subscript number from small to large.

[0098] Optionally, the simulation test interface further includes a task status display window, which is used to display the task status. For example, the status of an executing task is RUNNING, and the status of an unexecuted task is WAITTING.

[0099] Optionally, the task status display window also supports the modification of the test task order. For example, the user manually modifies the priority of the test task in the WAITTING state, and executes the tasks that need to be executed in advance first, which is task scheduling. The specific implementation method can be: adding a priority tag in the task queue, and modifying the order of the test tasks in the task queue by adding a priority tag to the test tasks in the task queue. Alternatively, the execution order of the test tasks can be modified by moving the position of the test tasks in the task 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 to be tested, 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, and generating and downloading test reports.

[0101] The following is an explanation of the construction process of the vehicle software simulation test system:

[0102] Server configuration: Deploy a Linux server of the Ubuntu system for simulation testing. Configure the environment and related configuration parameters required for the scheduling client to run on the server. Install the configured scheduling client on the server.

[0103] Install Docker and Docker Compose (software for running basic Docker) on the server, and configure the operating environment of the Docker container. Use Docker Compose to build the Docker basic image required for model simulation. The basic image contains the integrated test environment and necessary tools (such as simulation test software) required for model simulation, such as MATLAB, SIUMLINK, startup scripts and other software.

[0104] Cloud platform deployment: Set up a simulation test management system on the cloud platform, which includes a server management module, a simulation task management module, a project management module, and a report management module. The server management module creates and configures the server based on the above-deployed servers, including configuring the maximum number of running tasks and the working directory (such as test task type, etc.) of the server.

[0105] In addition, the cloud platform also includes an object storage space acquisition module. The user uploads the model, the software to be tested, and the test script to the object storage space and / or the code library, obtains the model address for external access, and then configures it to the cloud platform. The cloud platform obtains the address of the module object storage space and / or the code library, or obtains the model, the software to be tested, and the test script in the object storage space and / or the 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 configuration directory of the corresponding server.

[0107] After the server has installed the scheduling client, it downloads the access credential file uploaded by the cloud platform and modifies the configuration file of the scheduling client according to the access credential file. For example, the address of the cloud platform is configured in the scheduling client.

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

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

[0110] Optionally, when the scheduling client reports the heartbeat, it will detect the number of instantiated Docker containers in execution. If the number of already executed containers reaches the upper limit of the number of parallel tasks set in the system, it will report "busy", otherwise it will report "idle". For example, assuming that the server is configured to run 5 Docker containers at the same time, when the server receives the test task for the first time, the scheduling client schedules the Docker base image to instantiate and generate a Docker container. During the process of the Docker container executing the test task, if the second test task is received, the scheduling client detects that the number of Docker containers executing the test task is 1, and the server can process 5 in parallel, so it reports the "idle" status (or when there is no Docker container executing the test task, it reports the "idle" status). If the sixth test task is received, the scheduling client detects that the number of Docker containers executing the test task has reached 5, and the sixth test task can no longer be executed, so it uploads the "busy" status, and the server reports the current status to the cloud platform, and the cloud platform displays the current status of the server.

[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 the server will then execute the test according to the test tasks.

[0112] Based on the above-mentioned vehicle software simulation test system, the embodiment of the present application also proposes a vehicle software simulation test method, which is applied to a server, such as Figure 5 As shown, the method includes:

[0113] S501, 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 the task information required for the software to be tested to execute the test task;

[0114] As an example, the test task instruction is issued by the cloud platform. After receiving the test task instruction, the server obtains the model file, the software to be tested, the test script and the task information required for the test task based on the test task instruction, so as to facilitate the tester to perform the test task on the test task.

[0115] It should be noted that the software to be tested refers to the object to be tested, and the model file provides a blueprint for the test (such as the purpose and standard of the test) to simulate the running scenario model of the software to be tested. The test script refers to a tool to implement the test activities. For example, the test script performs automated testing on the software to be tested according to the guidance in the model file, verifies whether the response behavior of the software to be tested meets the expectations in the model file, and implements the testing of the software to be tested.

[0116] Optionally, the model file, the software to be tested, the test script and the task information can be downloaded from the cloud platform. For example, after the user sets the test task through the cloud platform, the cloud platform sends the test task instruction to the server, and the server receives the test task instruction and downloads the model file, the software to be tested, the test script and the task information from the cloud platform according to the address or file information indicated by the test task instruction.

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

[0118] In some embodiments, this step is applied to the scheduling client in the server, and the server provides a running environment for the scheduling client. The scheduling client maintains a connection with the server by sending a heartbeat to the server every 10 seconds. At the same time, when sending the heartbeat, it also reports the current status, which includes "idle" and "busy". When the scheduling client detects that the number of Docker containers executing the test task reaches the set task parallel number (the number of tasks that can be executed simultaneously), the current state is "busy"; when the scheduling client detects that the number of Docker containers executing the test task does not reach the set task parallel number, the current state is "idle".

[0119] The server sends the test task to be triggered to the scheduling client according to the current state of the scheduling client. For example, when the scheduling client is "idle", the test task is sent to the scheduling client.

[0120] After receiving the test task instruction, the scheduling client obtains the model file, software to be tested, test script, task information and other detailed information corresponding to the test task according to the test task instruction. For specific acquisition methods, please refer to the methods listed above.

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

[0122] S502, instantiating a Docker container according to the model file, the software to be tested, the test script, the task information, and the preset Docker basic image required for the model simulation to generate a simulation test environment;

[0123] In this step, the preset Docker basic image is compatible with the operation of all software required for model simulation, and the software includes simulation test software and software to be tested, etc. The Docker basic image includes simulation test software and startup scripts, for example, simulation test software includes matrix laboratory MATLAB, simulation SIMULINK tools in MATLAB, etc. On the basis of these software, based on the task information set for the software to be tested, the basic operating environment, environment variables, etc. in the Docker basic image are modified, and the model file, the software to be tested, and the test script are loaded into the Docker basic image, the model file, the software to be tested, and the test script are configured and combined, and the Docker basic image is instantiated, and the creation of the Docker container can be completed, based on the Docker container can be compatible with the operation of various software, and based on simulation test software such as matrix laboratory MATLAB, simulation SIMULINK tools and startup scripts in MATLAB, etc., when the Docker container is started, the simulation test environment of the software to be tested can be generated, and one Docker container can generate all environments required for simulation testing, and complete the simulation test of the software to be tested.

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

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

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

[0127] Run the Docker basic 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.

[0128] The startup script is a startup script for instantiating a Docker container. The startup script indicates the process that needs to be executed during the process of starting the Docker container instantiation. For example, the model file, the software to be tested, the test script, and the task information are copied to the Docker base image. Then, based on the simulation test software, the software to be tested, the model file, and the task information in the Docker base image, the Docker container is configured and started to complete the instantiation of the Docker container.

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

[0130] As an example, the specific implementation method of running the Docker basic 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 the simulation test environment can be:

[0131] A1: Run the Docker basic image, load the model file into the MATLAB of the 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 of the simulation test software will be started, and MATLAB will compile the model file. During the compilation process, the simulation model corresponding to the software to be tested is compiled in combination with the interface and protocol environment of the software to be tested, so as to verify the software to be tested on the simulation model.

[0133] A2: Associating the simulation test software corresponding to the test task, so as to execute the test embodiment based on the simulation test software;

[0134] The Docker basic image contains a lot of basic simulation test software. The simulation test software corresponding to different test tasks or different scenarios may be different, or one simulation test software can simulate multiple similar test tasks or software to be tested. Based on this, the Docker basic image provides basic simulation test software. After determining the software to be tested and the test script, the test script is associated with the corresponding simulation test software and runs in the simulation test software to realize the automatic construction of the simulation test software corresponding to the test task.

[0135] A2: According to the environment required by the software to be tested, the task information is configured into the software to be tested and the simulation model. The task information includes the operating parameters and environment variables of the software to be tested.

[0136] After the model is compiled, the task information of the test task is configured into the software to be tested and the simulation model, thus completing the configuration of the software to be tested 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 position.

[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 the instantiation of the Docker container is completed, and a simulation test environment of the software to be tested is generated in the Docker container. During the simulation test process, the test script verifies the response of the software to be tested by calling the simulation model through the simulation test software, and completes the verification of the software to be tested.

[0140] As an example, simulation test software includes multiple types, and different test tasks or different software to be tested require different simulation test software. Therefore, in the process of running the Docker basic image, the simulation test software (such as MATLAB and SIMULINK) mounted in the Docker container is also specified according to the software to be tested and the test task, and the REST API port of SIMULINK is specified as the Docker container communication port to communicate with the host host (such as a server) so as to use the simulation test software to verify the software to be tested.

[0141] It should be noted that the Docker base image is a static module. After the model file, the software to be tested, the test script, and the task information are loaded into the Docker base image, the Docker container is created by establishing the relationship between each file and the Docker container (such as Figure 6 As shown in the figure, for example, specify to mount MATLAB and SIMULINK, specify the REST API port of SIMULINK as the communication port, configure the relevant parameters according to the task information, and these configurations can form a Docker container. Finally, start the Docker container for instantiation, compile the model file through MATLAB, and map the Docker container to the SIMULINK software REST API port of the host machine. You can request the API interface in the Docker container on the host machine to configure and execute the MIL test task.

[0142] As an example, this step is applied to a scheduling client, and a Docker container is created by the scheduling client, so that the Docker container can generate a simulation test environment internally.

[0143] S503, start the Docker container and perform a simulation test of the software to be tested based on the simulation test environment.

[0144] After the simulation test environment is created in step S502, the software to be tested can be subjected to simulation test.

[0145] In this step, the specific implementation method of starting the Docker container and performing the simulation test of the software to be tested based on the simulation test environment can be:

[0146] Associate the simulation model, the software to be tested, and the test scripts.

[0147] The API interface of SIMULINK software is called to execute the test scripts one by one. During the execution of the test scripts, the simulation test software performs simulation test on the software to be tested.

[0148] As an example, after starting the Docker container and performing the simulation test of the software to be tested based on the simulation test environment, the following further includes: after the test task is completed, the Docker container is destroyed. That is, when the test task is completed, the Docker container is destroyed, and the Docker container can be regenerated based on the original basic information for the next test task.

[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 to be tested. For the same test task and the same software to be tested, there is no need to repeatedly generate a simulation test environment, and the test copy can be quickly called for simulation testing, thereby improving work efficiency.

[0150] Optionally, as an example, after starting the Docker container and performing the simulation test of the software to be tested based on the simulation test environment, the following is further included:

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

[0152] Specifically, the API interface of SIMULINK software is called to execute the test scripts one by one. After the execution of a single script, the log and test results are uploaded to the cloud platform. At the same time, the task execution status is queried. After the task is completed (that is, after the test is completed), the data files and log files of the task execution are collected, and the data files and log files of the task are parsed to generate the data format required by the cloud platform and returned to the cloud platform. The synchronization task has been completed.

[0153] As an example, this step is executed on the scheduling client. After creating the Docker container in step S502, the scheduling client calls the SIMULINK API interface to load the project configuration file and the operating environment of the scheduling client, configures the operating environment of the scheduling client, and verifies the test script after the operating environment configuration is completed. After the verification is successful, the simulation model, the software to be tested and the test script are associated with each other, and then the API interface of the SIMULINK software is called to execute the test script one by one. During the execution of the test script, the simulation test software performs simulation testing on the software to be tested.

[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 that has been built on the server, a Docker container can be created by integrating the model file, software to be tested, test script and task information with the pre-set Docker basic image required for model simulation. The Docker container can generate a simulation environment for the software to be tested. Therefore, the server can run a simulation test of the software to be tested based on the simulation environment. The entire simulation test process is carried out automatically without the user having to manually create a simulation environment. This testing method has high work efficiency and meets the needs of multiple autonomous driving software and frequent updates.

[0155] Based on the above-mentioned vehicle software simulation test system, the embodiment of the present application also proposes a vehicle software simulation test method, which is applied to a cloud platform, such as Figure 7 As shown, the method includes:

[0156] S701, in response to a setting operation of a test task, determining the test task and its corresponding model file, software to be tested, test script and task information according to the setting operation, and establishing an association relationship between the test task and the model file, software to be tested, test script and task information;

[0157] In this step, the cloud platform provides the user with a test task setting interface, and the user creates a test task based on the setting interface. For example, the user selects the corresponding software to be tested, model file, and test script on the setting interface, and sets the task information of the test task on the setting interface, wherein the task information includes the operating parameters and environment variables required for the software to be tested, and then selects the test task generation to complete the test task setting operation.

[0158] The cloud platform responds to the user's test task setting operation, determines the test task and its corresponding model file, software to be tested, test script and task information, and generates a test task instruction. Among them, the test task instruction may include the test task and its associated model file, software to be tested, test script and task information. Alternatively, the test task instruction may also include the task information corresponding to the test task, and the download address corresponding to the model file, software to be tested, and test script. Alternatively, the form of the test task instruction can also be other forms, as long as the model file, software to be tested, test script and task information can be obtained through the test task instruction.

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

[0160] As an example, a test task can be triggered when it is generated, or it can be processed based on a set triggering method.

[0161] Optionally, in order to enrich the functions of simulation tests and increase the flexibility of simulation tests, the cloud platform supports users to set the triggering method of test tasks according to their needs. For example, the triggering methods include manual triggering, single-time scheduled task triggering, and periodic scheduled task triggering. Among them, manual triggering requires the task executor to manually click on the task to start running; a single-time scheduled task is to enter a fixed trigger time, which is automatically triggered to run when it expires; a periodic scheduled task is to enter a Cron expression, and the system parses the trigger time list in the Cron expression, and automatically runs after it expires. In this way, if the user needs to trigger the test task during non-operating hours, you can choose a single-time scheduled task trigger and set the trigger time to non-operating hours to avoid affecting the user's work. If a software needs to be tested periodically multiple times, the user can choose a periodic scheduled task trigger, and the cloud platform will automatically trigger the test task according to the period, without the user manually triggering or timing multiple times, which can avoid missing or forgetting the trigger and affecting the final test results.

[0162] In some examples, in order to facilitate the unified management of test tasks of the same project and to improve the test efficiency of test tasks of the same project, the cloud platform also provides a project creation module. The test tasks of the same project can be configured with a set of basic project information. The test tasks of the same project can be shared, saving the time of 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 warehouse address of the software to be tested is configured, the code warehouse address of the test script is configured, and then a model simulation test task is created based on the simulation project.

[0164] S702: When the test task meets the triggering condition, the test task is sent to the execution server.

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

[0166] As an example, if the test task is triggered when the test task is generated, it is determined that the test task meets the triggering condition when the test task is generated.

[0167] As an example, if the test task is triggered based on a set trigger mode, it is determined whether to trigger the test task according to the trigger condition corresponding to the trigger mode set by the user. Optionally, it is determined whether the test task meets the trigger condition in the following manner:

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

[0169] If the user sets a periodic scheduled task trigger, when the current time reaches the task trigger time, it is determined that the test task meets the trigger condition, and the next cycle time is determined according to the set cycle, and the next cycle time is updated to the task trigger time that needs to be monitored, and then the current time is continued to be monitored to see if it reaches the task trigger time.

[0170] If the user sets a manual trigger, when a click operation of the trigger control is detected, it is determined that the test task meets the trigger condition. For example, the user manually clicks the trigger control, the trigger condition is met, and the test task is sent to the execution server.

[0171] Further, in some embodiments, the cloud platform can be connected to multiple servers, and simulation tests can be performed on multiple servers. The execution server corresponding to the test task can be selected by the user. For example, when the user creates a test task, he selects the execution server based on the server provided by the cloud platform, and the cloud platform sends the test task to the execution server. Alternatively, the cloud platform can provide the optimal execution server to execute the test task based on the execution task type and current operating status of each server. In the current situation where there are more and more software testing needs, multiple test tasks often appear to be executed at the same time. Based on the cloud platform, the test tasks of each software to be tested can be reasonably allocated, which can improve the work efficiency of the simulation test and meet the current needs.

[0172] Specifically, when the test task meets the trigger condition, before sending the test task to the execution server, it also includes:

[0173] Determine the execution server based on the test task, the execution task type of 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 execution task type of each server and its current running status.

[0175] When configuring each server, the corresponding test basic environment can be configured according to the task type, so the server is bound to the execution task type. When the cloud platform schedules the server, the server that matches the test task is selected as the execution server; at the same time, when there are multiple servers matching the test task, the server is scheduled based on the current running status of each server, and the server with the current running status of idle is selected as the execution server of the test task.

[0176] The cloud platform automatically matches the execution server corresponding to the test task, without the need for manual selection by the user. The execution server automatically matched by the cloud platform can more reasonably allocate or schedule each server. For example, when multiple test tasks are triggered at the same time, the cloud platform can comprehensively consider the situations of multiple test tasks and allocate more suitable execution servers for multiple test tasks.

[0177] Alternatively, the operation information of each server is displayed, the operation information including the type of task executed by the server and the current operation status; and then a selection operation based on the operation information is responded to, and the execution server is determined according to the selection operation.

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

[0179] Compared with the above steps, in this step, the user can select a server according to needs, increase human-computer interaction, and the user can select a convenient server to perform test tasks according to actual needs to improve user experience.

[0180] In this embodiment, the cloud platform provides a setting interface for users, and users do not need to go to a fixed PC workstation to perform software testing; the cloud platform configures the server to execute test tasks, and users can set test tasks on any computer, and the cloud platform automatically schedules the server to execute test tasks. On the one hand, it simplifies the operational process of software testing, and on the other hand, users can perform multiple test tasks in parallel, or users can process test tasks and other work in parallel without the need for users to wait.

[0181] In combination with all the above embodiments, taking a software to be tested as an example, the specific operation process of the vehicle software simulation test system and the specific implementation process of the vehicle software testing method provided in the embodiment of the present application are described:

[0182] like Figure 8 As shown, after the server is built, a vehicle software simulation test system is formed with the cloud platform.

[0183] First, users upload the software to be tested, model files, and test scripts to the object storage space or code repository, obtain the model address for external access, and configure it in the cloud platform. And connect to the software product management platform. When a new version of the software to be tested is released, the software version information and software download address will be obtained.

[0184] Create a code repository in the code repository GITLAB, package and upload test projects such as test scripts, parameter configuration files, and operating environment files to the code repository. When the test engineer updates the test project code, the updated code is directly synchronized to the code repository.

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

[0186] In the newly created project, the model storage address, code warehouse address, and software address to be tested are configured in the corresponding fields of the project. Configure the basic use case information in the project management module. The test tasks created in the project can try out the basic use cases configured in the project basic use cases.

[0187] In the task management module of the cloud platform, create a test task based on the newly created project, and select the software version, model version, and test script to be tested. And configure the triggering method of the task in the task management module. The task supports three triggering methods: manual triggering, single scheduled task triggering, and periodic scheduled task triggering. Among them, manual triggering requires the task executor to manually click the task to start running; single scheduled tasks are to enter a fixed trigger time, and automatically trigger the operation when it expires; periodic scheduled tasks are to enter a Cron expression, and the system parses the trigger time list in the Cron expression, and automatically runs after the expiration.

[0188] If the execution server is selected manually, the server selected by the user will be bound as the execution server. At this point, the test task is created.

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

[0190] After the task is triggered, it enters the task queue of the cloud platform and is assigned a task number Task (1...100). The task queue sends the task to the scheduling client on the server according to the task index number from small to large.

[0191] The server sends the task ID that needs to be triggered to the scheduling client in the server according to the situation in the task queue. The scheduling client uses the task ID to request detailed task information from the server. According to the task reconfiguration parameters, the model file, software to be tested, and test script configured in the task are downloaded and stored in the working directory of the scheduling client.

[0192] When the scheduling client reports the next heartbeat, the running status will be changed to "busy" and the task execution status will be reported to the server. The server can view the task running status in real time.

[0193] Then, after the model file, the software to be tested, and the test script required for the task are downloaded, the scheduling client runs the Start.sh script in the server directory, that is, the startup script.

[0194] After running the startup script, the calling instructions of the startup script copy the software to be tested to the working directory of the MATLAB project, and then compile it using MATLAB in the container.

[0195] The scheduling client uses the server socket to query the free ports for container internal port mapping and starts the Docker image. When the Docker image is running, it specifies to execute and mount the htsStart.sh file and MATLAB and SIMULINK project files; and specifies that the internal port of the SIMULINK software REST API is mapped to the port of the host machine to create a Docker container.

[0196] After creating the Docker container, the startup script starts MATLAB and compiles the model. After completion, exit MATLAB, and the startup script starts MATLAB and SIMULINK again. By mapping the Docker container to the SIMULINK software REST API port of the host machine, the API interface in the container can be requested on the host machine to configure and execute the MIL test task.

[0197] The scheduling client program calls the API interface of SIMULINK software to load the project configuration file and operating environment. After the operating environment configuration is completed, the test script is verified, and then the simulation model, the software to be tested and the test script are associated with each other.

[0198] The scheduling client program calls the API interface of the SIMULINK software to execute the test scripts one by one. After a single script is executed, the log 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, the data files and log files of the task execution are collected, and the upload server synchronization task has been completed.

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

[0200] After the scheduling client determines that the test task is completed, it destroys the Docker container.

[0201] After receiving the test task data sent back by the scheduling client, the cloud platform modifies the test task status to the corresponding test result, and generates an HTML test report with the uploaded data. The test report includes a detailed log of the test run and result data.

[0202] After the test report is generated, the cloud platform sends an email or internal communication tool to notify the task responsible person that the task has been completed, and sends the HTML test report together.

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

[0204] The present application also provides a vehicle software simulation test device, the device comprising:

[0205] An acquisition module is used to respond to the test task instruction and 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 for the software to be tested to execute the test task;

[0206] The simulation environment generation module is used to instantiate the Docker container and generate a simulation test environment according to the model file, the software to be tested, the test script, the task information and the preset Docker basic image required for the model simulation;

[0207] The test module is used to start the Docker container and perform simulation testing of the software to be tested based on the simulation test environment.

[0208] The vehicle software simulation test device provided in the embodiment of the present application can execute the above method embodiment. Its specific implementation principles and technical effects can be found in the above method embodiment, and this embodiment will not be repeated here.

[0209] The present application also provides a vehicle software simulation test device, the device comprising:

[0210] A 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 an association relationship between the test task and the model file, software to be tested, test script and task information;

[0211] The task delivery module is used to deliver the test task to the execution server when the test task meets the triggering conditions.

[0212] The vehicle software simulation test device provided in the embodiment of the present application can execute the above method embodiment. Its specific implementation principles and technical effects can be found in the above method embodiment, and this embodiment will not be repeated here.

[0213] like Fig. 9 As shown, the embodiment of the present application further provides an electronic device, including: a processor 901, a memory 902; optionally, the electronic device 900 further includes a communication component 903. The processor 901, the memory 902 and the 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, wherein the processor is used to provide computing power and control capabilities, and can be a GPU, CPU, NPU, MCU, FPGA, etc. The storage device includes an internal memory and a non-volatile memory. The non-volatile memory stores a computer program that implements the above method. The internal memory provides an environment for program startup and operation. The communication interface is used to communicate with an external terminal by wire or wireless.

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

[0217] The above embodiments are only preferred embodiments for fully illustrating the present invention, and the protection scope of the present invention is not limited thereto. Any equivalent substitution or change made by a person skilled in the art based on the present invention is within the protection scope of the present invention.

Claims

1. A vehicle software simulation test method, characterized in that: Applied to a server, the method comprises: In response to the 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 for the software to be tested to execute the test task; Instantiate the Docker container according to the model file, the software to be tested, the test script, the task information and the preset Docker basic image required for model simulation to generate a simulation test environment; The Docker container is started, and a simulation test of the software to be tested is performed based on the simulation test environment.

2. The method according to claim 1, characterized in that The Docker basic image includes simulation test software and a startup script. The Docker container is instantiated according to the model file, the software to be tested, the test script, the task information and the preset Docker basic image required for model simulation to generate a simulation test environment, including: In response to the calling 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 basic 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.

3. The method according to claim 2, characterized in that The running of the Docker basic 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: 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 a simulation model of the software to be tested; Associating the simulation test software corresponding to the test task to execute the test instance based on the simulation test software; According to the environment required by the software to be tested, configuring the task information into the software to be tested and the simulation model, the task information including operating parameters and environment variables; Complete the instantiation of the Docker container and generate a simulation test environment.

4. The method according to any one of claims 1 to 3, characterized in that: After starting the Docker container and performing the simulation test of the software to be tested based on the simulation test environment, the method further includes: After the test task is executed, the Docker container is destroyed.

5. The method according to any one of claims 1 to 3, characterized in that: After starting the Docker container and performing the simulation test of the software to be tested based on the simulation test environment, the method further includes: The simulation test data is uploaded to the cloud platform, wherein the simulation test data includes the simulation test log and test results after the execution of each script in the test script is completed, and the data file and log file after the test task is completed.

6. A vehicle software simulation test method, characterized in that: Applied to a cloud platform, the method includes: In response to a setting operation of a test task, determining the test task and its corresponding model file, software to be tested, test script and task information according to the setting operation, and establishing an association relationship between the test task and the model file, the software to be tested, the test script and the task information; When the test task meets the triggering condition, the test task is sent to the execution server.

7. The method according to claim 6, characterized in that When the test task meets the trigger condition, before sending the test task to the execution server, the method further includes: The execution server is determined according to the test task, the execution task type of each server and the current running status of each server.

8. The method according to claim 6, characterized in that When the test task meets the trigger condition, before sending the test task to the execution server, the method further includes: Display the operation information of each server, including the type of tasks executed by the server and the current operation status; In response to a selection operation based on the operation information, an execution server is determined according to the selection operation.

9. The method according to any one of claims 6 to 8, characterized in that: The method further comprises: When the current time reaches the task trigger time, determining that the test task meets the trigger condition; Alternatively, a click operation of a trigger control is detected, and it is determined that the test task meets the trigger condition.

10. A vehicle software simulation test system, characterized in that: The system includes a server and a cloud platform; The server is used to execute the method according to any one of claims 1 to 5; The cloud platform is used to execute the method according to any one of claims 6 to 9.

11. The system according to claim 10, characterized in that The server includes basic software for running Docker, a scheduling client and a Docker basic image. The scheduling client is used to create a Docker container based on the Docker basic image, and when the Docker container generates a simulation environment, the simulation environment is called to test the software to be tested; the Docker basic software is used to drive the Docker container to generate the simulation environment.

12. The system according to claim 10, 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 is used to create and connect to servers and configure the servers.

13. A vehicle software simulation test device, characterized in that: The device comprises: An acquisition module, for obtaining, in response to a 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 for the software to be tested to execute the test task; A simulation environment generation module is used to instantiate a Docker container and generate a simulation test environment according to the model file, the software to be tested, the test script, the task information and the preset Docker basic image required for model simulation; The test module is used to start the Docker container and perform simulation testing of the software to be tested based on the simulation testing environment.

14. A vehicle software simulation test device, characterized in that: The device comprises: A setting module, 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 an association relationship between the test task and the model file, the software to be tested, the test script and the task information; The task sending module is used to send the test task to the execution server when the test task meets the trigger condition.

15. 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 according to any one of claims 1 to 5, or implement the method according to any one of claims 6 to 9, according to the computer program / instructions stored in the memory.

16. A computer-readable storage medium / computer program product, characterized in that: The computer-readable storage medium stores a computer program / the computer program product includes a computer program, and when the computer program is executed by a processor, it is used to implement the method according to any one of claims 1 to 9.

Images