Multi-task whole vehicle testing method, device and equipment and storage medium

Abstract

The invention discloses a multi-task whole vehicle testing method, device and equipment and a storage medium, relates to the technical field of whole vehicle testing, and discloses a multi-task whole vehicle testing method which comprises the steps that a preset testing priority, a target testing script and a vehicle identification code are acquired; matching vehicle type configuration according to the vehicle identification code, and generating a multi-task detection sequence according to the vehicle type configuration; generating a target control signal according to the target test script, the multi-task detection sequence and a preset test priority; and performing a whole vehicle test according to the target control signal to obtain a whole vehicle test result. Through the technical means of obtaining the preset test priority, the target test script and the vehicle identification code, matching the vehicle type configuration to generate the multi-task detection sequence, and generating the target control signal to execute the whole vehicle test, the technical effects of multi-task ordered whole vehicle test matched with the vehicle type and improvement of the test pertinence and efficiency are realized.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and in particular to multi-task vehicle testing methods, apparatus, equipment and storage media. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards a highly integrated domain convergence model, the number of powertrain domain controllers, chassis domain controllers, and various auxiliary control devices within vehicles is constantly increasing. This necessitates comprehensive testing of dozens of controllers and numerous functional items throughout the entire vehicle process. Before mass-produced vehicles roll off the assembly line, they need to undergo functional checks covering multiple domains, including the powertrain and chassis domains, to verify the operational status and collaborative capabilities of each controller. After-sales service scenarios also rely on functional checks to pinpoint hidden problems that may arise during long-term vehicle operation.

[0003] Given the aforementioned technological background, traditional technologies typically rely on manual operation to perform vehicle function testing. This involves manually triggering vehicle control functions, manually reading controller feedback data, and manually entering test results to achieve a complete inspection process. Some solutions also use external diagnostic tools or dedicated test script environments to perform auxiliary testing with a low degree of automation. In these traditional methods, manual testing is time-consuming, standards are difficult to unify, and signal conflicts between multiple domain controllers are difficult to completely avoid during operation. Furthermore, test results often need to be manually synchronized to various business systems, resulting in insufficient data accuracy and long turnaround times.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a multi-task vehicle testing method, apparatus, equipment, and storage medium, which aims to solve the technical problem of being unable to effectively complete the collaborative testing and result processing of multiple vehicle functions without the reliance on external equipment.

[0006] To achieve the above objectives, this application proposes a multi-task vehicle testing method, the method comprising: Obtain the preset test priority, target test script, and vehicle identification number; Match vehicle model configurations based on the vehicle identification code, and generate multi-task detection sequences based on the vehicle model configuration; A target control signal is generated based on the target test script, the multi-task detection sequence, and the preset test priority. The vehicle is tested based on the target control signal to obtain the vehicle test results.

[0007] In one embodiment, the step of generating a target control signal based on the target test script, the multi-task detection sequence, and a preset test priority includes: The target test script is parsed to obtain the initial control signal; The initial control signal and the preset test priority are sent to the multi-domain signal arbitration module so that the multi-domain signal arbitration module determines and feeds back the local area network bus resources based on the initial control signal and the preset test priority; The target control signal is generated based on the local area network bus resources and the multi-task detection sequence.

[0008] In one embodiment, the step of performing a vehicle test based on the target control signal to obtain the vehicle test result includes: Obtain the initial test threshold range; The vehicle is tested according to the target control signal, and the target operating condition data of the vehicle is collected during the test. The target operating condition data is analyzed according to the scenario adaptive verification strategy to obtain feedback signals; When the feedback signal falls within the range of the initial test threshold, the vehicle test result is determined to be a pass.

[0009] In one embodiment, the step of analyzing the target operating condition data according to the scenario adaptive verification strategy to obtain a feedback signal includes: Obtain the threshold for the number of detection data; The target operating condition data is denoised using a Kalman filter strategy to obtain denoised operating condition data. When the number of noise reduction condition data exceeds the threshold of the number of detection data, the target condition data is analyzed according to the scene adaptive verification strategy to obtain a feedback signal.

[0010] In one embodiment, after the step of performing a vehicle test based on the target control signal to obtain the vehicle test result, the method further includes: The correction coefficient matrix and operating condition parameter deviations are determined based on the vehicle test results. The updated test threshold range is calculated based on the correction coefficient matrix and the deviation of the operating condition parameters; The initial test threshold range is updated based on the updated test threshold range to perform a whole vehicle test with the updated threshold.

[0011] In one embodiment, the step of obtaining the preset test priority, the target test script, and the vehicle identification code includes: Update the initial test script by vehicle type, domain controller, and function item level to obtain the updated test script; Perform multi-task conflict verification on the update test script to obtain functional test items and security test items; Determine the preset test priority based on the functional test items and the security test items; The target test script is obtained based on the functional test items and safety test, the safety test items and the preset test priority, and the vehicle identification number corresponding to the target test script is determined.

[0012] In one embodiment, the step of matching vehicle model configuration based on the vehicle identification code and generating a multi-task detection sequence based on the vehicle model configuration includes: The vehicle identification code is sent to the cloud scheduling module, so that the cloud scheduling module can retrieve the vehicle configuration database based on the vehicle identification code to perform vehicle matching and return the vehicle configuration. Generate a multi-task detection sequence for the corresponding vehicle model based on the vehicle configuration.

[0013] In addition, to achieve the above objectives, this application also proposes a multi-task vehicle testing device, which includes: a data acquisition module for acquiring a preset test priority, a target test script, and a vehicle identification code; The vehicle model matching module is used to match the vehicle model configuration according to the vehicle identification code and generate a multi-task detection sequence according to the vehicle model configuration; The signal generation module is used to generate a target control signal based on the target test script, the multi-task detection sequence, and the preset test priority. The vehicle testing module is used to perform vehicle testing based on the target control signal and obtain vehicle test results.

[0014] In addition, to achieve the above objectives, this application also proposes a multi-task vehicle testing device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-task vehicle testing method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-task vehicle testing method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the multi-task vehicle testing method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: By acquiring vehicle identification codes and matching vehicle model configurations, the testing solution can be specifically adapted to the configuration requirements of different vehicle models. Secondly, by pre-setting test priorities and generating multi-task detection sequences, orderly scheduling of multi-task tests is achieved, avoiding execution conflicts between different test tasks. Based on the target test script, detection sequence, and priority, control signals are generated and tests are executed, replacing traditional manual operation and disordered automated testing modes. This reduces the risk of missed tests and misjudgments caused by manual intervention and improves the degree of test standardization. It solves the limitations of some existing automated solutions that are only adapted to a single vehicle model or general scenario and cannot accurately match the personalized configurations of mass-produced vehicles. Compared with existing technologies, it achieves the technical effects of accurate adaptation to multiple vehicle models, orderly and efficient testing of multiple tasks, improved test standardization, and reduced missed test and misjudgment rates. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the multi-task vehicle testing method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the multi-task vehicle testing method of this application; Figure 3 A simplified flowchart illustrating the multi-task vehicle testing method provided in Embodiment 2 of this application; Figure 4 This is a schematic diagram of the module structure of the multi-task vehicle testing device according to an embodiment of this application; Figure 5 This is a schematic diagram of the equipment structure of the hardware operating environment involved in the multi-task vehicle testing method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application embodiment is as follows: obtain a preset test priority, a target test script, and a vehicle identification code; match the vehicle model configuration according to the vehicle identification code, and generate a multi-task detection sequence according to the vehicle model configuration; generate a target control signal according to the target test script, the multi-task detection sequence, and the preset test priority; perform a whole vehicle test according to the target control signal to obtain the whole vehicle test result.

[0025] In this embodiment, for ease of description, the following description will focus on identifying a multi-task vehicle testing device as the execution subject.

[0026] Since existing technologies cannot effectively complete the collaborative detection and result processing of multi-domain functions of a vehicle without the reliance on external equipment, this application provides a solution. By acquiring the vehicle identification code and matching the vehicle model configuration, the testing scheme can be specifically adapted to the configuration requirements of different vehicle models. Secondly, by presetting test priorities and generating multi-task detection sequences, the orderly scheduling of multi-task tests is realized, avoiding execution conflicts between different test tasks. Based on the target test script, detection sequence, and priority, control signals are generated and tests are executed, replacing traditional manual operation and disordered automated testing modes. This reduces the risk of missed tests and misjudgments caused by manual intervention and improves the degree of test standardization. It solves the limitation of some existing automated solutions that are only adapted to a single vehicle model or general scenario and cannot accurately match the personalized configuration of mass-produced vehicles. Compared with existing technologies, it achieves the technical effects of accurate adaptation to multiple vehicle models, orderly and efficient testing of multiple tasks, improved testing standardization, and reduced missed test and misjudgment rates.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or multi-task vehicle testing equipment capable of performing the above functions. The following description uses a multi-task vehicle testing equipment as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, the embodiments of this application provide a multi-task vehicle testing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-task vehicle testing method of this application.

[0029] In this embodiment, the multi-task vehicle testing method includes steps S10 to S40: Step S10: Obtain the preset test priority, target test script, and vehicle identification code; It should be noted that the preset test priority is a rule that is set in advance for the execution order of functional test tasks in various domains of the vehicle. It is used to avoid signal conflicts between different test tasks and ensure that critical functions are tested first. It is based on the importance of functions and safety, for example, power domain-related tests have higher priority than other domains, ensuring that the testing is carried out in an orderly manner.

[0030] In addition, the target test scripts are sets of instructions written at the vehicle model-domain controller-function item level, containing key information such as interface names, issued values, and expected feedback, and serve as the basis for executing whole-vehicle tests. Each script corresponds to a specific function's testing process, ensuring standardized and regulated testing operations.

[0031] Furthermore, the Vehicle Identification Number (VIN) is a unique identifier for a vehicle, containing key information such as model, manufacturer, and year of manufacture. It can be used to accurately match the specific configuration of a vehicle. This identifier allows for quick identification of the corresponding testing requirements, ensuring the relevance of the testing.

[0032] Understandably, by determining the execution order of each test task through pre-set rules, obtaining the test instruction set for the corresponding vehicle model and function, and collecting the vehicle's unique identification, a foundation is laid for accurate matching of subsequent test tasks.

[0033] In one feasible implementation, step S10 may include steps S11 to S14: Step S11: Update the initial test script according to vehicle model, domain controller, and function item level to obtain the updated test script; It should be noted that a domain controller is a control unit that integrates multiple functional modules for a specific vehicle domain. It is responsible for the coordinated control and signal processing of various functions within that domain. Common examples include power domain controllers (Power Control Units, PCUs) and chassis domain controllers. It is a core component in the integrated development of vehicle electronic architecture domains, enabling centralized management of multiple distributed functions.

[0034] In addition, the initial test script is a set of raw test instructions that has not undergone hierarchical optimization and content updates. It only contains basic test operation requirements and has not been adjusted to take into account vehicle differences, domain controller characteristics, and functional item subdivisions.

[0035] Furthermore, the updated test script is a script that supplements, modifies, and improves the initial test script according to the three-level structure of vehicle model, domain controller, and function item, making it more suitable for the configuration and testing requirements of specific vehicle models.

[0036] Understandably, the original initial test script is hierarchically adjusted and optimized according to different vehicle models, corresponding domain controller types, and specific functional items, ultimately resulting in a more adaptable updated test script.

[0037] Step S12: Perform multi-task conflict verification on the update test script to obtain functional test items and security test items; It should be noted that multi-task conflict verification checks whether there are contradictory situations in the update test script where different test tasks cannot be executed simultaneously. In other words, it determines whether simultaneous execution of test content would lead to functional conflicts or distorted test results. This embodiment avoids conflict scenarios such as simultaneous execution of electronic parking brake activation and hill descent control.

[0038] In addition, functional tests are tests used to verify whether the vehicle's basic functions are operating normally. They cover the testing of conventional functions such as vehicle driving, handling, and assistance, and are core test items to ensure the basic user experience of the vehicle.

[0039] Furthermore, safety test items are test contents designed for functions that are crucial to vehicle driving safety. They are directly related to the life safety of drivers and passengers and are key test contents with higher priority than ordinary function test items.

[0040] Understandably, conflict checks are performed on the test scripts after hierarchical updates to identify and separate conflicting test tasks, ultimately clearly distinguishing between ordinary functional test items and critical security test items.

[0041] Step S13: Determine the preset test priority based on the functional test items and the security test items; Understandably, based on the basic usability of functional test items and the security importance of security test items, and combined with the execution logic of test tasks, the execution order of different test items is set, that is, the preset test priority is determined.

[0042] Step S14: Obtain the target test script based on the functional test items and safety test, the safety test items and the preset test priority, and determine the vehicle identification code corresponding to the target test script.

[0043] It should be noted that the target test script is a final set of test instructions that integrates functional test items, safety test items, and preset test priority rules. It serves as the direct basis for executing the whole vehicle test, ensuring that the test is orderly and comprehensive.

[0044] It is understandable that functional test items, safety test items, and preset test priorities are integrated and optimized to form a target test script that can be executed directly, while clearly defining the unique identifier of the vehicle to which the target test script is adapted.

[0045] Through a series of operations including hierarchical script updates, conflict checking, priority setting, and target script generation, precise adaptation and orderly planning of test scripts were achieved. Hierarchical updates ensured that the scripts were tailored to the vehicle model and domain controller characteristics, conflict checking prevented functional conflicts during testing, and priority setting ensured that safety-critical test items were executed first. The resulting target test scripts were highly standardized and clearly corresponded to vehicle identification codes, laying the foundation for accurate matching of vehicle model configurations and efficient test execution, significantly reducing the risk of missed or false tests, and improving the relevance and reliability of the tests.

[0046] Step S20: Match vehicle model configuration according to the vehicle identification code, and generate a multi-task detection sequence according to the vehicle model configuration; It should be noted that vehicle configuration is a collection of information regarding the type, functional modules, and hardware parameters of the domain controller installed in a specific vehicle, and configurations vary between different vehicle models. It determines the test items and specific testing standards required for the vehicle and is the core basis for generating test sequences.

[0047] In addition, the multi-task testing sequence is an ordered list of test tasks planned according to the vehicle configuration, which clarifies the execution order of functional tests in each domain. This sequence avoids conflicting tasks from being executed simultaneously, such as preventing the electronic parking brake activation and hill descent control tests from being performed at the same time, ensuring the smooth progress of the test.

[0048] Understandably, by using the vehicle's unique identifier to find the corresponding vehicle configuration information, and then planning a conflict-free and orderly list of test tasks based on that configuration, the tests can be made to ensure that they are consistent with the actual conditions of the vehicle.

[0049] In one feasible implementation, step S20 may include steps S21-S22: Step S21: Send the vehicle identification code to the cloud scheduling module so that the cloud scheduling module can retrieve the vehicle model configuration database based on the vehicle identification code to perform vehicle model matching and return the vehicle model configuration. It should be noted that the cloud-based scheduling module is the core processing module responsible for receiving vehicle identification codes, retrieving vehicle configuration data for matching, and providing feedback on the vehicle configuration. It possesses rapid response and accurate matching capabilities, efficiently locating the detailed configuration of the corresponding vehicle model based on its unique identifier, ensuring compatibility for subsequent testing.

[0050] Additionally, the vehicle configuration database is a collection of data storing configuration information such as domain controller types, functional modules, and hardware parameters corresponding to various vehicle models. This database covers configuration details for multiple mass-produced vehicles, providing comprehensive and reliable data support for accurate vehicle matching.

[0051] Understandably, the unique vehicle identifier is sent to the cloud-based processing module. Upon receiving the identifier, the module retrieves a database storing configuration information for various vehicle models, accurately searches for the identifier, and then provides the corresponding vehicle's configuration information.

[0052] Step S22: Generate a multi-task detection sequence for the corresponding vehicle model based on the vehicle model configuration.

[0053] It should be noted that the multi-task testing sequence is an ordered list of test tasks planned based on the configuration information of a specific vehicle model, clearly defining the execution order of functional tests in each domain. In this embodiment, the sequence will be planned according to the logic of prioritizing the power domain over the chassis domain. For example, the driving mode switching test will be executed first, followed by the electronic parking brake test, to avoid task conflicts.

[0054] Understandably, based on the specific vehicle configuration information fed back from the cloud, and combined with the priority and relevance of functions in each domain, a conflict-free and orderly test task list is planned, and a multi-task detection sequence for the corresponding vehicle model is generated.

[0055] Step S30: Generate a target control signal based on the target test script, the multi-task detection sequence, and the preset test priority; It should be noted that the target control signal is an instruction signal used to drive the various domain controllers of the vehicle to perform specific test operations. It is determined by the specific requirements of the test script, the execution order of the test tasks, and the priority rules. It can accurately convey the test requirements, enabling the controller to complete the corresponding functional test actions according to the preset process.

[0056] Understandably, by combining standardized test instructions, an orderly list of test tasks, and preset execution priorities, the instruction signals that drive the controller to execute test operations are synthesized, thus ensuring accurate testing.

[0057] In one feasible implementation, step S30 may include steps S31 to S33: Step S31: Parse the target test script to obtain the initial control signal; It should be noted that the initial control signal is the raw instruction signal obtained after parsing the target test script. It contains the basic requirements for driving each domain controller of the vehicle to execute the corresponding test operations, and has not yet undergone priority scheduling and bus resource adaptation optimization. It directly corresponds to the core information such as interface names and issued values ​​in the target test script, and is the basis for generating the subsequent target control signal.

[0058] Understandably, the target test script, which integrates functional test items, security test items, and preset test priorities, is parsed to extract the test instruction information and form the original initial control signal.

[0059] Step S32: Send the initial control signal and the preset test priority to the multi-domain signal arbitration module so that the multi-domain signal arbitration module determines and feeds back the local area network bus resources according to the initial control signal and the preset test priority; It should be noted that the multi-domain signal arbitration module is the core processing module responsible for handling signal conflicts between domain controllers and optimizing LAN bus transmission. It has signal priority judgment and bus resource scheduling capabilities, and can allocate bus usage permissions according to preset rules to ensure priority transmission of critical test signals.

[0060] In addition, the local area network bus resource is a data channel resource used for transmitting signals between various domain controllers in the vehicle. It includes key elements such as bus transmission bandwidth and transmission timing. In this embodiment, it is specifically the CAN bus resource, which is the core carrier for realizing signal interaction between multiple domain controllers.

[0061] Understandably, the original initial control signal and the preset test priority are sent to a module that specifically handles signal conflicts. This module determines the signal execution order based on the priority rules, allocates the corresponding local area network bus resources, and provides feedback.

[0062] Step S33: Generate a target control signal based on the local area network bus resources and the multi-task detection sequence.

[0063] It should be noted that the target control signal is the final execution instruction formed by optimizing and adjusting the initial control signal based on the local area network bus resource allocation results and the multi-task detection sequence. It not only contains the core requirements of the test operation, but also adapts to the bus transmission resources and the test task sequence, ensuring efficient and conflict-free signal transmission.

[0064] Understandably, based on the feedback of local area network bus resource allocation and combined with the planned multi-task detection sequence, the initial control signal is adapted and adjusted to generate a target control signal that can be directly executed.

[0065] Step S40: Perform a vehicle test based on the target control signal to obtain the vehicle test results.

[0066] Understandably, the synthesized command signals are sent to the various domain controllers of the vehicle. After the controllers perform the corresponding operations, they return the relevant data, and the test results of each function are obtained by comparing the data.

[0067] By sequentially acquiring key test parameters and vehicle identifiers, accurately matching vehicle configurations to generate ordered test sequences, synthesizing target control signals, and executing tests, the system achieves precise adaptation and orderly progress of test tasks. This effectively avoids signal conflicts between different test tasks, improves the standardization and efficiency of testing, and significantly reduces the risk of missed tests and misjudgments compared to traditional manual inspection. Simultaneously, it ensures that the tests closely match the actual vehicle configuration, adapting to the needs of mass-produced vehicle production line testing and after-sales service, laying a solid foundation for subsequent cross-system synchronization and problem closure.

[0068] In one feasible implementation, step S40 may include steps S41 to S44: Step S41: Obtain the initial test threshold range; It should be noted that the initial test threshold range is based on the expected threshold range of each functional item constructed under standard operating conditions. These standard operating conditions refer to the conditions of battery voltage 3.0V±0.1V, ambient temperature 25℃, and load rate ≤50%. It is derived from test data of more than 1,000 mass-produced vehicles under standard operating conditions and includes the standard expected thresholds of more than 180 functional items, which serves as the basis for subsequent adaptive adjustments in various scenarios.

[0069] Understandably, the standard expected threshold range for the corresponding function item is retrieved from the built-in standard operating condition basic threshold library to obtain the initial test threshold range for subsequent result determination.

[0070] Step S42: Perform a vehicle test according to the target control signal and collect vehicle target operating condition data during the vehicle test; It should be noted that the vehicle target operating condition data are key vehicle condition parameters collected in real time during the whole vehicle test, including battery voltage, ambient temperature, vehicle cumulative mileage, and current domain controller load rate. The battery voltage accuracy can reach ±0.01V, the ambient temperature acquisition range is -40℃~85℃, the vehicle cumulative mileage accuracy is ±1km, and the acquisition frequency is consistent with the signal feedback frequency of 100Hz, which is obtained in real time through the vehicle's native sensors and controller bus.

[0071] Understandably, the vehicle testing operation is performed based on the target control signal, while key vehicle condition parameters are collected in real time during the testing process to obtain the vehicle's target operating condition data.

[0072] Step S43: Analyze the target working condition data according to the scenario adaptive verification strategy to obtain a feedback signal; It should be noted that the scenario-adaptive verification strategy is a complete verification logic that includes preprocessing of operating condition data, dynamic threshold calculation, verification execution, and model optimization. Its core is to adjust the threshold according to real-time operating conditions to adapt to different vehicle conditions. This strategy first uses a Kalman filter algorithm to reduce noise in the target operating condition data, then calculates the dynamic threshold based on the correction coefficient matrix, and finally compares the feedback signal with the dynamic threshold to obtain the verification result.

[0073] Additionally, the feedback signal is the response signal returned by each domain controller of the vehicle after executing the target control signal. It contains key data such as current, voltage, and response time after the controller executes the signal and is used for verification and analysis after being returned via the signal transmission link.

[0074] Understandably, a scenario-adaptive verification strategy is adopted to perform noise reduction processing and dynamic threshold calculation on the collected vehicle target operating condition data, and then compare and analyze it with the response signal returned by the controller to obtain the feedback signal.

[0075] In one feasible implementation, step S43 may include steps S431 to S433: Step S431: Obtain the threshold for the number of detection data; It should be noted that the threshold for the number of detection data is a pre-set standard for the cumulative number of detection data to trigger subsequent model optimization or in-depth analysis. In this embodiment, the threshold is set to 100 times, meaning that after 100 vehicle inspections are completed and the corresponding data is collected, the relevant optimization or analysis process will be initiated.

[0076] Understandably, the system retrieves a pre-set cumulative data quantity standard to obtain the threshold for determining whether to initiate in-depth analysis.

[0077] Step S432: The target operating condition data is denoised using a Kalman filter strategy to obtain denoised operating condition data. It should be noted that the Kalman filter strategy is an algorithm used for data noise reduction, which can effectively remove abnormal information such as instantaneous fluctuations and sensor errors from the collected data, ensuring the stability and accuracy of the data. In this embodiment, the filtering window length of this strategy is set to 5 sampling points, specifically designed for the characteristics of operating condition data.

[0078] In addition, the noise reduction operating condition data is the stable operating condition feature value obtained after processing by the Kalman filtering strategy, which eliminates the interference information in the original target operating condition data and provides a reliable data foundation for subsequent threshold calculation and verification analysis.

[0079] Understandably, the Kalman filter algorithm is used to process the collected target operating condition data, remove abnormal interference information, and obtain stable noise-reduced operating condition data.

[0080] Step S433: When the number of noise reduction working condition data is greater than the threshold of the number of detection data, the target working condition data is analyzed according to the scene adaptive verification strategy to obtain a feedback signal.

[0081] Understandably, the cumulative number of noise reduction working condition data is counted. When this number exceeds the preset threshold for the number of detection data, a scenario-adaptive verification strategy is adopted to conduct a comprehensive analysis of the target working condition data, and finally a feedback signal is obtained for result determination.

[0082] By setting a threshold for the number of test data points, employing Kalman filtering for noise reduction, and triggering deep analysis based on the data volume, accurate preprocessing of the test data and reliable analysis were achieved. The Kalman filtering strategy effectively eliminated abnormal data such as instantaneous voltage fluctuations and temperature sensor errors, preventing interference with subsequent threshold calculations and improving data accuracy. Setting a threshold for the number of test data points ensured sufficient data support for the analysis process, avoiding analytical biases caused by insufficient data and making the feedback signals more closely reflect actual vehicle operating conditions. Ultimately, this provided a high-quality data foundation for scenario-adaptive verification, further improving the accuracy of the overall vehicle test results.

[0083] Step S44: When the feedback signal falls within the range of the initial test threshold, the vehicle test result is determined to be a pass.

[0084] Understandably, the feedback signal obtained from the analysis is compared with the initial test threshold range. If the feedback signal falls within the threshold range, the vehicle test result is determined to be a pass.

[0085] By acquiring the initial test threshold range under standard operating conditions, accurately collecting real-time operating condition data, and using a scenario-adaptive verification strategy to analyze feedback signals and determine results, accurate determination of test results is achieved. Comprehensive collection of vehicle target operating condition data provides a reliable foundation for verification, while the Kalman filter algorithm effectively eliminates abnormal data, avoiding interference with threshold calculation. The scenario-adaptive verification strategy significantly improves detection accuracy by dynamically adjusting thresholds to adapt to different vehicle conditions, maintaining a threshold matching accuracy rate of over 95%, effectively reducing the risk of misjudgment and missed judgment caused by traditional fixed threshold judgment. Simultaneously, the entire process requires no additional external equipment, relying on native vehicle resources to complete data collection and verification, further strengthening the advantage of being independent of external devices and adapting to different vehicle condition detection needs in various scenarios such as mass production vehicle manufacturing and after-sales service.

[0086] This embodiment provides a multi-task vehicle testing method. By constructing an automated multi-domain functional testing technology system for vehicles without external device dependence, and by combining the vehicle's native interface with cloud-based intelligent scheduling, it solves the technical problems of existing testing technologies, such as dependence on external devices, weak multi-domain collaborative testing capabilities, and lack of cross-system data synchronization and problem closed-loop management. This achieves the beneficial effects of reducing testing costs, improving testing efficiency and accuracy, shortening the problem closed-loop cycle, and enhancing system scalability.

[0087] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 After step S40, the multi-task vehicle testing method further includes steps S50 to S70: Step S50: Determine the correction coefficient matrix and operating condition parameter deviation based on the vehicle test results; It should be noted that the correction coefficient matrix is ​​a set of coefficients set for different operating parameters and different domain function items, used to adjust the standard threshold according to the actual operating conditions. In this embodiment, this matrix is ​​trained using the Gradient Descent Algorithm (GDA), with a goodness of fit R² ≥ 0.98. For example, for every 0.1V deviation of the battery voltage from the standard value, the corresponding power domain function threshold correction coefficient is adjusted by ±0.05.

[0088] In addition, the operating condition parameter deviation is the difference between the currently collected operating condition parameters and the standard operating condition parameters. The standard operating condition refers to the operating conditions with a battery voltage of 3.0V±0.1V, an ambient temperature of 25℃, and a load rate of ≤50%. The deviation value directly reflects the degree of difference between the current vehicle condition and the standard operating condition.

[0089] Understandably, based on the pass or fail results of the whole vehicle test, combined with the collected operating condition data, the correction coefficient matrix adapted to the current vehicle condition and the parameter difference between the current operating condition and the standard operating condition are determined.

[0090] Step S60: Calculate and update the test threshold range based on the correction coefficient matrix and the operating condition parameter deviation; Understandably, the updated test threshold range adapted to the current vehicle condition is obtained by multiplying the deviation of the operating condition parameters one by one with the corresponding coefficients in the correction coefficient matrix, summing the results, and then substituting them into the preset logic and combining them with the basic threshold. In this embodiment, the updated test threshold range can be calculated using the formula: Dynamic Threshold = Basic Threshold × (1 + Σ(Operating Condition Parameter Deviation × Corresponding Correction Coefficient)).

[0091] Step S70: Update the initial test threshold range according to the updated test threshold range to perform a whole vehicle test with the updated threshold.

[0092] It should be noted that the updated test threshold range is a dedicated threshold interval calculated by combining the deviation of operating parameters and the correction coefficient matrix, which is more in line with the actual operating conditions of the current vehicle than the initial test threshold range.

[0093] It is understandable that the calculated updated test threshold range will replace the original initial test threshold range, and the updated threshold will be used to determine the results when conducting subsequent vehicle tests.

[0094] By determining the deviation between the correction coefficient matrix and the operating condition parameters based on test results, calculating and updating the test threshold range, and updating the initial threshold, adaptive optimization of the test threshold is achieved. The correction coefficient matrix is ​​trained based on a large amount of mass-produced vehicle data, ensuring the scientific nature and accuracy of the threshold adjustment. The precise calculation of the operating condition parameter deviation makes the threshold update more closely match the actual vehicle condition. The updated threshold can adapt to the individual differences of different vehicles, effectively avoiding the misjudgment and missed judgment problems caused by traditional fixed thresholds.

[0095] This embodiment provides a multi-task vehicle testing method. By dynamically adjusting the test threshold based on the vehicle test results, it solves the technical problems of poor adaptability of traditional fixed thresholds under different working conditions, which can easily lead to misjudgment and missed judgment. It achieves the beneficial effect of adaptively optimizing the test threshold according to the actual working conditions of the vehicle, improving the accuracy and reliability of detection.

[0096] For example, to help understand the implementation process of the multi-task vehicle testing method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 3 , Figure 3 A simplified flowchart of a multi-task vehicle testing method is provided, specifically: This solution is divided into three main parts: the vehicle subsystem, the cloud subsystem, and the upstream and downstream interface system. The vehicle subsystem includes the peripheral-free interaction APK, CarAPI, CarService, Vehicle Hardware Abstraction Layer (VHAL), Inter-Process Communication Library (IPCL), and Microcontroller Unit (MCU). The peripheral-free interaction APK connects to the local verification module through a multi-domain signal arbitration module, which is responsible for real-time comparison of feedback signals with expected values. CarAPI connects to VHAL through CarService, VHAL connects to the MCU through IPCL, and the MCU further connects to a multi-domain controller cluster, including the Power Control Unit (PCU), Driver Unit (DU), and Electronic Power Steering (EPS) in the power domain; the Electronic Hand Brake Integration (EHBI) in the chassis domain; Electronic Stability Control (ESC); Electronic Power Steering (EPS); and other domains such as air conditioning / door controllers.

[0097] The cloud-based subsystem comprises a hardware support module, a cloud scheduling subsystem, and core functional modules. The hardware support module includes nginx & kafka servers, application servers, and database servers. The cloud scheduling subsystem provides a management entry point connecting to the test script management module, multi-domain task scheduling module, cross-system synchronization module, and intelligent problem-solving loop module. The core functional modules include the intelligent problem-solving loop module, the multi-domain task scheduling module, and a vehicle-to-cloud three-domain script library. The intelligent problem-solving loop module uses the Jira system and the Line Information Management-Manufacturing Execution System (LIM-MES system) to create work orders, transmit status, and synchronize detection data. The multi-domain task scheduling module is responsible for running scheduling / loop algorithms, storing tasks / results / logs, and interacting with the vehicle-to-cloud three-domain script library.

[0098] The upstream and downstream integration system utilizes the Jira and LIM-MES systems to create work orders, transmit status updates, and synchronize detection data. The diagram also marks a list of unsupported markdowns, such as "Unsupported markdown: list," "Unsupported markdown: list list," and "Unsupported markdown: list," indicating that these contents are not supported in the system. Cross-system interactions are indicated by orange arrows. The overall architecture diagram demonstrates a method for automated multi-domain functional detection of the entire vehicle without external device dependence. It achieves multi-domain collaborative detection, real-time cross-system data synchronization, and automated closed-loop management of detection issues through vehicle-side intrinsic interaction, cloud-based intelligent scheduling, and cross-system closed-loop mechanisms.

[0099] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-task vehicle testing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0100] This application also provides a multi-task vehicle testing device; please refer to [reference needed]. Figure 4 The multi-task vehicle testing device includes: Data acquisition module 10 is used to acquire preset test priorities, target test scripts, and vehicle identification codes; The vehicle model matching module 20 is used to match the vehicle model configuration according to the vehicle identification code and generate a multi-task detection sequence according to the vehicle model configuration; Signal generation module 30 is used to generate target control signals based on the target test script, the multi-task detection sequence, and the preset test priority; The vehicle testing module 40 is used to perform vehicle testing based on the target control signal and obtain vehicle test results.

[0101] The multi-task vehicle testing device provided in this application, employing the multi-task vehicle testing method described in the above embodiments, can solve the technical problem of being unable to effectively complete the collaborative detection and result processing of multi-domain functions of a vehicle without external equipment dependence. Compared with the prior art, the beneficial effects of the multi-task vehicle testing device provided in this application are the same as those of the multi-task vehicle testing method provided in the above embodiments, and other technical features in the multi-task vehicle testing device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0102] In one embodiment, the signal generation module 30 is further configured to parse the target test script to obtain an initial control signal; The initial control signal and the preset test priority are sent to the multi-domain signal arbitration module so that the multi-domain signal arbitration module determines and feeds back the local area network bus resources based on the initial control signal and the preset test priority; The target control signal is generated based on the local area network bus resources and the multi-task detection sequence.

[0103] In one embodiment, the vehicle testing module 40 is further configured to obtain an initial test threshold range; The vehicle is tested according to the target control signal, and the target operating condition data of the vehicle is collected during the test. The target operating condition data is analyzed according to the scenario adaptive verification strategy to obtain feedback signals; When the feedback signal falls within the range of the initial test threshold, the vehicle test result is determined to be a pass.

[0104] In one embodiment, the vehicle testing module 40 is further configured to acquire a threshold for the number of test data. The target operating condition data is denoised using a Kalman filter strategy to obtain denoised operating condition data. When the number of noise reduction condition data exceeds the threshold of the number of detection data, the target condition data is analyzed according to the scene adaptive verification strategy to obtain a feedback signal.

[0105] In one embodiment, the vehicle testing module 40 is further configured to determine a correction coefficient matrix and a deviation of operating parameters based on the vehicle testing results; The updated test threshold range is calculated based on the correction coefficient matrix and the deviation of the operating condition parameters; The initial test threshold range is updated based on the updated test threshold range to perform a whole vehicle test with the updated threshold.

[0106] In one embodiment, the data acquisition module 10 is further configured to update the initial test script according to vehicle model, domain controller, and function item level to obtain the updated test script; Perform multi-task conflict verification on the update test script to obtain functional test items and security test items; Determine the preset test priority based on the functional test items and the security test items; The target test script is obtained based on the functional test items and safety test, the safety test items and the preset test priority, and the vehicle identification number corresponding to the target test script is determined.

[0107] In one embodiment, the vehicle model matching module 20 is further configured to send the vehicle identification code to the cloud scheduling module, so that the cloud scheduling module can retrieve the vehicle model configuration database based on the vehicle identification code to perform vehicle model matching and provide feedback on the vehicle model configuration; Generate a multi-task detection sequence for the corresponding vehicle model based on the vehicle configuration.

[0108] This application provides a multi-task vehicle testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the multi-task vehicle testing method in the above embodiment 1.

[0109] The following is for reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing the multi-task vehicle testing equipment of the embodiments of this application. The multi-task vehicle testing equipment in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The multi-task vehicle testing equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0110] like Figure 5As shown, the multi-tasking vehicle testing equipment may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the multi-tasking vehicle testing equipment. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the multi-task vehicle test equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a multi-task vehicle test equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0111] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0112] The multi-task vehicle testing equipment provided in this application, employing the multi-task vehicle testing method described in the above embodiments, can solve the technical problem of being unable to effectively complete the collaborative detection and result processing of multi-domain functions of a vehicle without external equipment dependence. Compared with the prior art, the beneficial effects of the multi-task vehicle testing equipment provided in this application are the same as those of the multi-task vehicle testing method provided in the above embodiments, and other technical features of this multi-task vehicle testing equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0113] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0115] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the multi-task vehicle testing method described in the above embodiments.

[0116] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0117] The aforementioned computer-readable storage medium may be included in the multi-task vehicle testing equipment; or it may exist independently and not be assembled into the multi-task vehicle testing equipment.

[0118] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a multi-task vehicle testing device, the multi-task vehicle testing device: acquires a preset test priority, a target test script, and a vehicle identification code; matches a vehicle model configuration according to the vehicle identification code and generates a multi-task detection sequence according to the vehicle model configuration; generates a target control signal according to the target test script, the multi-task detection sequence, and the preset test priority; and performs a vehicle test according to the target control signal to obtain a vehicle test result.

[0119] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0120] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0121] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0122] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described multi-task vehicle testing method. This solves the technical problem of being unable to effectively complete the collaborative detection and result processing of multi-domain functions of a vehicle without external device dependence. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multi-task vehicle testing method provided in the above embodiments, and will not be repeated here.

[0123] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-task vehicle testing method described above.

[0124] The computer program product provided in this application can solve the technical problem of being unable to effectively complete the collaborative detection and result processing of multi-domain functions of the whole vehicle without the dependence on external devices. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the multi-task whole vehicle testing method provided in the above embodiments, and will not be repeated here.

[0125] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A multi-task vehicle testing method, characterized in that, The method includes: Obtain the preset test priority, target test script, and vehicle identification number; Match vehicle model configurations based on the vehicle identification code, and generate multi-task detection sequences based on the vehicle model configuration; A target control signal is generated based on the target test script, the multi-task detection sequence, and the preset test priority. The vehicle is tested based on the target control signal to obtain the vehicle test results.

2. The method as described in claim 1, characterized in that, The step of generating a target control signal based on the target test script, the multi-task detection sequence, and the preset test priority includes: The target test script is parsed to obtain the initial control signal; The initial control signal and the preset test priority are sent to the multi-domain signal arbitration module so that the multi-domain signal arbitration module determines and feeds back the local area network bus resources based on the initial control signal and the preset test priority; The target control signal is generated based on the local area network bus resources and the multi-task detection sequence.

3. The method as described in claim 1, characterized in that, The step of performing a vehicle test based on the target control signal to obtain the vehicle test results includes: Obtain the initial test threshold range; The vehicle is tested according to the target control signal, and the target operating condition data of the vehicle is collected during the test. The target operating condition data is analyzed according to the scenario adaptive verification strategy to obtain feedback signals; When the feedback signal falls within the range of the initial test threshold, the vehicle test result is determined to be a pass.

4. The method as described in claim 3, characterized in that, The step of analyzing the target operating condition data according to the scenario adaptive verification strategy to obtain the feedback signal includes: Obtain the threshold for the number of detection data; The target operating condition data is denoised using a Kalman filter strategy to obtain denoised operating condition data. When the number of noise reduction condition data exceeds the threshold of the number of detection data, the target condition data is analyzed according to the scene adaptive verification strategy to obtain a feedback signal.

5. The method as described in claim 1, characterized in that, After the step of performing a vehicle test based on the target control signal to obtain the vehicle test results, the method further includes: The correction coefficient matrix and operating condition parameter deviations are determined based on the vehicle test results. The updated test threshold range is calculated based on the correction coefficient matrix and the deviation of the operating condition parameters; The initial test threshold range is updated based on the updated test threshold range to perform a whole vehicle test with the updated threshold.

6. The method as described in claim 1, characterized in that, The steps of obtaining the preset test priority, target test script, and vehicle identification code include: Update the initial test script by vehicle type, domain controller, and function item level to obtain the updated test script; Perform multi-task conflict verification on the update test script to obtain functional test items and security test items; Determine the preset test priority based on the functional test items and the security test items; The target test script is obtained based on the functional test items and safety test, the safety test items and the preset test priority, and the vehicle identification number corresponding to the target test script is determined.

7. The method as described in claim 1, characterized in that, The steps of matching vehicle model configuration based on the vehicle identification code and generating a multi-task detection sequence based on the vehicle model configuration include: The vehicle identification code is sent to the cloud scheduling module, so that the cloud scheduling module can retrieve the vehicle configuration database based on the vehicle identification code to perform vehicle matching and return the vehicle configuration. Generate a multi-task detection sequence for the corresponding vehicle model based on the vehicle configuration.

8. A multi-task vehicle testing device, characterized in that, The device includes: The data acquisition module is used to acquire preset test priorities, target test scripts, and vehicle identification codes. The vehicle model matching module is used to match the vehicle model configuration according to the vehicle identification code and generate a multi-task detection sequence according to the vehicle model configuration; The signal generation module is used to generate a target control signal based on the target test script, the multi-task detection sequence, and the preset test priority. The vehicle testing module is used to perform vehicle testing based on the target control signal and obtain vehicle test results.

9. A multi-task vehicle testing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-task vehicle testing method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the multi-task vehicle testing method as described in any one of claims 1 to 7.

Images