Model test method and device for electric vehicle and nonvolatile storage medium

Abstract

The invention discloses a model test method and device for an electric vehicle and a nonvolatile storage medium. The method comprises the following steps: acquiring a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copy model, and determining a target signal line; the target signal line is replaced with a preset stub function, and the stub function comprises a fault injection interface function; based on the fault injection interface function, preset fault data are input, the copy model is tested, a target test result is obtained, and the target test result is represented as a test result corresponding to the to-be-tested model. According to the invention, the technical problem that the test result is not accurate enough due to the fact that only the input / output interface is exposed and the test requirement cannot be met by means of a third-party test tool in the current model test is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electric vehicles, in particular to a model testing method and device for electric vehicles and a nonvolatile storage medium. BACKGROUND

[0002] With the vigorous development of new energy electric vehicles and the significant improvement of the intelligent level of automobiles, the development scale of automobile electronic software function components is increasing, and the complexity of software is also increasing. In order to cope with this challenge, formalized models play an increasingly important role in the software development process, greatly simplifying the development process of automobile electronic software. However, for model testing, it usually depends on the test tools provided by third parties, which encapsulate the model into a test environment and only expose the input and output interfaces of the model, thereby allowing test cases to be input from the input interface for testing. Although this method meets the testing needs to some extent, its limitation lies in the inability to conduct detailed fault injection testing on the internal logic of the model, which is crucial for ensuring the reliability and stability of software under complex conditions.

[0003] Currently, to meet the demand for fault injection testing in model logic, the usual solution is to directly modify the model design and introduce new input interfaces in the model logic that needs to be spiked (i.e., fault injection points). However, this method has several significant drawbacks. First, it destroys the integrity of the original model, causing the object being tested to be inconsistent with the original design, which may affect the accuracy and reliability of the test results. Second, in the process of modifying the model, human errors may introduce new problems that may be difficult to detect in subsequent testing, thereby reducing the overall quality of the software.

[0004] To address the above problems, no effective solutions have been proposed so far. SUMMARY

[0005] The embodiments of the present application provide a model testing method and device for electric vehicles and a nonvolatile storage medium to at least solve the technical problem that the current model testing relies on third-party test tools to only expose input and output interfaces, which cannot meet the testing needs, resulting in inaccurate test results.

[0006] According to an aspect of an embodiment of the present application, a model testing method of an electric vehicle is provided, including: obtaining a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copied model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0007] Optionally, the inputting of the preset fault data based on the fault injection interface function to test the copied model to obtain the target test result includes: obtaining a state of a fault injection enabling interface; determining whether the fault data needs to be injected based on the state; in the case that the fault data needs to be injected, calling the fault injection interface function to input the fault data based on a preset stub function switching function to test the copied model to obtain the target test result.

[0008] Optionally, the obtaining of the state of the fault injection enabling interface includes: defining a global variable corresponding to the fault injection enabling interface; receiving a numerical value of the global variable input based on a target account; and determining the state of the fault injection enabling interface based on the numerical value of the global variable.

[0009] Optionally, in the case that the fault data does not need to be injected, the to-be-tested model is tested to obtain a standard test result; and the target test result and the standard test result are compared to determine a fault response result of the to-be-tested model.

[0010] Optionally, the querying of the signal line with the preset name in the copied model to determine the target signal line includes: querying the signal line with the preset name in the copied model based on a regular expression to determine the target signal line.

[0011] Optionally, the fault data includes at least one of the following: signal fault data, sensor fault data, actuator fault data, and software logic fault data.

[0012] According to another aspect of an embodiment of the present application, a model testing device of an electric vehicle is also provided, including: an obtaining module configured to obtain a to-be-tested model in the electric vehicle; a copying module configured to copy the to-be-tested model to obtain a copied model; a querying module configured to query a signal line with a preset name in the copied model to determine a target signal line; a replacing module configured to replace the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; and a testing module configured to input preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0013] According to a further aspect of the embodiments of the present application, a non-transitory storage medium is also provided, which includes a stored program, wherein the program, when executed, controls a device in which the non-transitory storage medium is located to perform any one of the model testing methods for an electric vehicle.

[0014] According to a further aspect of the embodiments of the present application, a computer device is also provided, which includes a processor configured to execute a program, wherein the program, when executed, performs any one of the model testing methods for an electric vehicle.

[0015] According to a further aspect of the embodiments of the present application, a computer program product is also provided, which includes a computer program configured to, when executed by a processor, implement any one of the model testing methods for an electric vehicle.

[0016] In the embodiments of the present application, the model testing method for an electric vehicle is adopted, the model to be tested of the electric vehicle is obtained, the model to be tested is copied to obtain a copied model, a signal line with a preset name in the copied model is queried to determine a target signal line, the target signal line is replaced by a preset stub function, the stub function includes a fault injection interface function, and the copied model is tested based on the fault injection interface function by inputting preset fault data to obtain a target test result, wherein the target test result represents a test result corresponding to the model to be tested, the purpose of testing different faults is achieved, the technical effect of improving the accuracy of the test result while protecting the model to be tested is achieved, and the technical problem that the current model testing with the help of a third-party testing tool only exposes the input and output interfaces and cannot meet the testing requirements, resulting in an inaccurate test result, is solved. BRIEF DESCRIPTION OF DRAWINGS

[0017] The accompanying drawings, which are included to provide a further understanding of the present application and constitute a part of this application, illustrate embodiments of the present application and together with the description serve to explain the present application. In the drawings:

[0018] Figure 1 Fig. 1 shows a hardware structure block diagram of a computer terminal for implementing the model testing method for an electric vehicle;

[0019] Figure 2 Fig. 2 is a flowchart of the model testing method for an electric vehicle according to an embodiment of the present application;

[0020] Figure 3 Fig. 3 is a schematic diagram of a stub function module in the model testing method for an electric vehicle according to an optional embodiment of the present application;

[0021] Figure 4is a structural block diagram of a model test device of an electric vehicle provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the personnel in the technical field better understand the present application scheme, the technical scheme in the embodiment of the present application will be described clearly and completely in the following with reference to the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, not all. Based on the embodiment in the present application, all other embodiments obtained by the person skilled in the art without creative labor should belong to the protection scope of the present application.

[0023] It should be noted that the terms "first", "second" and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not necessarily limit to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0024] According to an embodiment of the present application, a method embodiment of a model test method of an electric vehicle is provided. It should be noted that the steps shown in the flowchart of the drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown herein.

[0025] The method embodiment provided by the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 A hardware structural block diagram of a computer terminal for implementing a model test method of an electric vehicle is shown. As shown in Figure 1 The computer terminal 10 can include one or more processors (the processor can include but not limited to a microprocessor MCU or a programmable logic device FPGA processing device) (shown in 102a, 102b,..., 102n in the figure), a memory 104 for storing data. In addition, it can also include a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which can be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. Those skilled in the art can understand that Figure 1The illustrated structure is merely schematic and does not limit the structure of the electronic device described above. For example, the computer terminal 10 can further include more or fewer components than those shown in FIG. 1, or have a different configuration from that shown in FIG. 1. Figure 1 Figure 1 The illustrated structure is merely schematic and does not limit the structure of the electronic device described above. For example, the computer terminal 10 can further include more or fewer components than those shown in FIG. 1, or have a different configuration from that shown in FIG. 1.

[0026] It should be noted that the one or more processors and / or other data processing circuitry described above can be referred to herein generally as "data processing circuitry". The data processing circuitry can be embodied in whole or in part as software, hardware, firmware, or any combination thereof. In addition, the data processing circuitry can be a single standalone processing module, or incorporated in whole or in part within any one of the other elements of the computer terminal 10. As referred to in embodiments of the present application, the data processing circuitry functions as a processor to control, for example, the selection of the variable resistance terminal path connected to the interface.

[0027] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage means corresponding to the model testing method of an electric vehicle according to embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, i.e., implements the model testing method of an electric vehicle according to the application. The memory 104 can include a high-speed random access memory, and can further include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 104 can further include a memory disposed remotely with respect to the processor, which can be connected to the computer terminal 10 through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0028] The display can be, for example, a touch screen type liquid crystal display (LCD) that enables a user to interact with the user interface of the computer terminal 10.

[0029] Figure 2 is a flowchart of the model testing method of an electric vehicle according to embodiments of the present application, as shown in Figure 2 The method includes the following steps:

[0030] In step S202, a model to be tested of an electric vehicle is obtained.

[0031] ​In this step, the to-be-tested model herein can be various software models in new energy electric vehicles. For example, a battery management system (BMS) model, an electric motor control (EMC) model, an in-vehicle network communication model, and the like.

[0032] In step S204, the to-be-tested model is copied to obtain a copied model.

[0033] In this step, the to-be-tested model is copied to obtain a copied model, which can ensure that the original structure of the to-be-tested model is not changed when subsequent fault injection is performed. Specifically, before starting the operation, the to-be-tested model can be backed up first to ensure that it can be restored to the original state in any unexpected situation. Then, a test framework is constructed, which should be compatible with the development environment but independent of the actual development process. The test framework can be a virtual development environment or an independent test workstation on a physical server. It is ensured that the framework contains all the resources and tools required for testing, such as test scripts, simulation environments, fault injection tools, and the like. The to-be-tested model can be copied to the test framework to obtain a copied model.

[0034] Through the above steps, a complete copy of the to-be-tested model can be effectively created and verified in the test framework, and then detailed fault injection testing can be performed, while ensuring that the original model in the development environment is not affected, and effective isolation of the punched model and the original model is achieved.

[0035] In step S206, a signal line with a preset name in the copied model is queried to determine a target signal line.

[0036] In this step, the signal line with the preset name in the copied model is queried, which is usually a signal line marked as De series. The purpose is to determine the target signal line, i.e., the position where fault injection testing is required. In the system modeling and simulation software, a signal line is a path through which data is transmitted from one module to another module. That is, the signal line is a bridge connecting the source module (such as a sensor model, a function module) and the target module (such as a controller, a display model) in the model, used to transmit analog or digital signals, data streams, or control information. It ensures the correct and timely flow of data between different functional modules and is the material carrier of interaction between parts of the model. The signal line can transmit various types of data, including but not limited to real numbers, complex numbers, integers, Boolean values, structures, arrays, or matrices.

[0037] In the query results, each signal line with the De prefix can be checked to confirm that they are indeed the target signal lines that need to be tested for fault injection. Specifically, the positions and connections of the signal lines can be manually checked through a graphical user interface (GUI) to ensure that the script does not misreport or miss report.

[0038] For each target signal line found in the query, record its complete path in the model, data type, source module, and target module, and other information. These information will be used in the subsequent fault injection function design and insertion process.

[0039] Through the above steps, the signal lines with the preset name in the copy model can be effectively queried, and the target signal lines can be determined, thereby preparing for the subsequent fault injection test. This not only improves the efficiency and accuracy of the test, but also ensures the automation and standardization of the test process, which is especially important for large or complex electric vehicle software model testing.

[0040] In step S208, the target signal line is replaced with a preset stub function, wherein the stub function includes a fault injection interface function.

[0041] In this step, a standard stub function, that is, a stub function, can be established first. The stub function should include a fault injection interface through which the tester can input preset fault data to simulate different fault scenarios. The stub function internally implements the logic of normal signal transmission and the logic of fault signal processing. In normal mode, the stub function is like a transparent signal line and does not affect the transmission of signals; in fault mode, according to the input fault data, the stub function simulates fault behaviors such as signal interruption, data error, etc.

[0042] The specific positions of the target signal lines in the copy model are identified, including their connected source modules and target modules. A new module can be inserted at any point on the signal line, so that the signal processing logic at that point can be replaced with the logic of the stub module. On each target signal line, the designed stub module is inserted using the "insert block" function. This may require disconnecting the signal line and then reconnecting the input and output ports of the stub module to the signal line.

[0043] Figure 3 is a schematic diagram of a stub function module in a model test method of an electric vehicle according to an optional embodiment of the present application, as Figure 3As shown, the target signal line is replaced with a stub function, which can include a fault injection interface function and a fault cut-in enable interface. Specifically, the fault injection interface function is configured in the stub function module to ensure that the interface can be enabled or disabled by an external control signal (such as global variable A). At the same time, the normal behavior of the stub module in the non-fault injection mode is defined, i.e. when A = 0, the stub module should transparently pass the signal to simulate the normal function of the signal line.

[0044] Through these steps, the target signal line can be replaced with a stub function containing a fault injection interface, so that in-depth testing of the model under fault conditions can be realized without affecting the normal function of the model.

[0045] In step S210, based on the fault injection interface function, preset fault data is input to test the replicated model, and target test results are obtained, wherein the target test results represent the test results corresponding to the model to be tested.

[0046] In this step, the replicated model is tested using the fault injection interface function, and the target test results are obtained. This process evaluates the response and stability of the system by simulating fault conditions, ensuring that the software can safely handle exceptions in actual operation. Based on the functions of the software and possible fault scenarios, a series of fault data sets are prepared. These data should cover various types of potential problems, such as sensor reading abnormalities, communication errors, memory overflow, etc. By controlling the enable interface (such as global variable A), the fault injection interface is activated, so that the fault data input in the next step can be correctly received and processed by the test model. The preset fault data is input to the test model through the fault injection interface. This step can be automated by using custom scripts. Execute the test model and observe the execution flow, output results and abnormal handling mechanism of the model under fault data input. Record the output results of the model under fault conditions, including but not limited to system state, error message, log record, etc. Analyze whether the model's reaction when encountering faults meets the expectations and whether the system can run stably or safely enter the fault handling program. Compare the results of the fault injection test with the test results of the model under normal conditions (i.e. without enabling the fault injection interface), and evaluate the fault tolerance and recovery of the model.

[0047] Based on the collected data, a detailed test report is prepared, which should include fault types, input fault data, model reactions, and any unexpected situations. The test report is submitted to the development team, who can correct the code and improve the model's handling ability based on the findings in the report.

[0048] Through the above process, the behavior of the software model under the preset fault condition can be systematically tested, and the target test result obtained can help the development team to evaluate and improve the stability and security of the model, so as to ensure that the product can maintain basic functions and take appropriate protective measures when facing various abnormal situations that may occur in actual operation. This testing method plays an important role in the software development cycle and has an important role in improving the quality of the final product and user safety.

[0049] By establishing a standard function model for plugging, the consistency and standardization of the fault injection interface are ensured, and the potential risks caused by directly modifying the model are avoided. Moreover, the name of the signal line of the model is used as a key marker to locate the position where the fault injection interface needs to be plugged, which not only reduces the errors caused by manual operation, but also enables the fault injection interface to be inserted in batches through multi-point marking, thereby significantly improving the testing efficiency.

[0050] Through the above steps, the purpose of setting different faults for testing can be achieved, thereby realizing the technical effect of improving the accuracy of the test result while protecting the model to be tested, and further solving the technical problem that the current model test with the help of a third-party testing tool can only expose the input and output interfaces, which cannot meet the testing requirements, resulting in inaccurate test results.

[0051] As an optional embodiment, based on the fault injection interface function, the preset fault data is input to test the copy model and obtain the target test result, including: obtaining the state of the fault cut-in enabling interface; based on the state, determining whether the fault data needs to be injected; in the case where the fault data needs to be injected, based on the preset function plugging function, the fault injection interface function is called to input the fault data, the copy model is tested, and the target test result is obtained.

[0052] Optionally, before starting the test, ensure that the test environment is ready, which includes loading the replica model, configuring necessary test tools, and setting environment parameters. Determine whether the current is in the fault injection mode by querying the fault injection enable interface (e.g., global variable A) in the model. This step ensures that the fault injection function is activated only when the test needs to simulate faults. If the enable interface value indicates that the model is in the fault injection mode, prepare the preset fault data. This step may involve building different fault data sets according to various fault scenarios defined in the test plan. Use the stub function switching function to dynamically select whether to call the fault injection interface function according to the value of the enable interface. When the enable interface value is "1", it indicates that fault injection is needed; otherwise, the model runs normally. Once it is determined that fault injection is needed, input the preset fault data to the replica model through the fault injection interface function to stimulate the model to enter an abnormal working state in order to observe and record its response. After inputting the fault data, execute the replica model to run it under the preset fault condition. Monitor the output and behavior of the model closely and record all relevant data, including but not limited to the state changes of the model, system response time, error handling process, etc. These recorded data constitute the target test results. The obtained test results can be compared with the expected behavior to evaluate the stability and safety of the model under fault conditions. If the model can correctly identify errors, respond in a timely manner, and recover to the predetermined state after fault injection, the test is considered successful.

[0053] The core of this test process is to evaluate and verify the robustness and fault tolerance of the software model using the fault injection interface function through the preset fault data. It not only helps developers to discover and fix potential problems in a timely manner, but also ensures that the software can respond correctly when facing actual faults, thereby ensuring the safe operation of the vehicle.

[0054] As an optional embodiment, obtaining the state of the fault injection enable interface includes: defining a global variable corresponding to the fault injection enable interface; receiving a numerical value of the global variable input based on a target account; and determining the state of the fault injection enable interface based on the numerical value of the global variable.

[0055] Optionally, a global variable, typically a Boolean or integer variable, is defined in the model to control the enablement and disablement of the fault injection functionality. For example, an integer variable A (as the enablement interface identifier) can be defined, with a value of "0" representing disabled fault injection and a value of "1" representing enabled fault injection. A user interface or command line interface can be provided to allow the tester to input the value of the global variable corresponding to the enablement interface. This is typically done before testing, allowing the tester to set whether fault injection is enabled or disabled according to the test plan. Upon receiving the user input value, necessary data validation is performed to ensure that the input value meets the requirements of the defined enablement interface, preventing test anomalies caused by input errors. The current value of the global variable defined above is read in the model or test script, and based on the read global variable value, the state of the fault injection enablement interface is determined. For example, if the value of A is "1", it is determined that the fault injection functionality is enabled; otherwise, if the value of A is "0", the fault injection functionality is in a disabled state. During testing, the value of the global variable can be dynamically adjusted according to testing needs, enabling or disabling the fault injection functionality at different testing stages to achieve test coverage of various scenarios.

[0056] Through the above steps, the tester can accurately control the enablement and disablement of fault injection, ensuring that the model behavior under each test scenario is in accordance with the predetermined fault injection plan, thereby improving the accuracy and efficiency of testing. In the testing of new energy vehicle software models, this mechanism is of great significance in ensuring that the system can safely and stably operate in the face of various faults.

[0057] As an optional embodiment, the replicated model is tested without injecting fault data, and the standard test results are obtained. The target test results are compared with the standard test results to determine the fault response results of the model to be tested.

[0058] Optionally, when testing the fault response of the software model, comparing the target test results with the standard test results is a key step in verifying the correctness of the model's behavior in the face of faults. This process not only evaluates the stability and reliability of the model, but also helps the development team identify and fix potential problems.

[0059] The state of the fault injection enablement interface in the model is set to "off" (e.g., the global variable A is set to 0), ensuring that no fault injection mechanism is triggered. The replicated model is run in normal mode, and a set of pre-defined test data is input, which should cover all normal functions and boundary conditions of the model. The output and behavior of the model under normal operating conditions are collected and recorded, and these data constitute the standard test results, which can be used as a benchmark for subsequent comparison and analysis.

[0060] Compare the target test results with the standard test results in detail. The comparison may include the output data of the model, the changes in system state, the process of error handling, etc. Check whether the model can correctly identify problems when encountering faults, whether it has carried out error handling as expected, and whether it has tried to restore normal operation. In addition, evaluate the performance indicators of the model, such as response speed and resource consumption. Identify the differences between the target test results and the standard test results. These differences may indicate deficiencies in the model's fault handling or the discovery of new problems. Summarize the results of the model's fault response, including the stability of the model, the safety performance, and the overall performance under fault conditions.

[0061] If the behavior of the model after fault injection is consistent with expectations and it can quickly recover to a normal state, it can be considered that the fault handling mechanism of the model is effective. For the problems found or the model behavior that does not meet expectations, write a detailed test report and feed back to the development team for in-depth analysis and repair. Based on the test results, the development team can optimize the fault detection and processing logic of the model, and improve the overall robustness and safety of the system.

[0062] Through the above process, the tester can systematically verify the response and recovery ability of the software model when facing different faults, which is crucial for improving the software quality in high-risk fields such as new energy vehicles. This method ensures that in actual application, even if unexpected faults occur, the system can maintain stable operation as much as possible, ensuring the safety and experience of users.

[0063] As an optional embodiment, the method further includes: querying the signal lines with the preset name in the duplication model to determine the target signal line, including: querying the signal lines with the preset name in the duplication model based on a regular expression to determine the target signal line.

[0064] Optionally, a pre-set signal line naming rule can be determined first, for example, all signal lines that need to be tested for fault injection have the prefix De. Based on the naming rule, a regular expression is written. Assuming the pre-set name starts with De, the regular expression can be designed as / ^De / . This means matching all signal line names that start with De. A query script is written using MATLAB, Python, or other scripting languages that support regular expression processing. The script can iterate through the entire list of signal lines in the replicated model and apply the above regular expression for filtering. The script should include functions such as reading the model structure, parsing signal line names, applying regular expression matching, etc. Run the script to search and match all signal line names in the replicated model. The script will return a list of all signal lines that meet the pre-set naming rules, which are the target signal lines. Store the information of the target signal lines found, for example, save them to a list or dictionary, to facilitate subsequent fault injection operations. These signal lines can be visually marked in the model editor to intuitively distinguish them from other signal lines.

[0065] Through the above steps and scripts, the target signal lines in the replicated model can be automatically identified and determined, providing a basis for further fault injection testing. This method improves testing efficiency, reduces errors that may be caused by manual signal line searching, and ensures the accuracy and consistency of testing.

[0066] As an optional embodiment, the fault data includes at least one of the following: signal fault data, sensor fault data, actuator fault data, and software logic fault data.

[0067] Optionally, according to the source and nature, the fault data can be divided into the following categories, each type corresponds to different fault scenarios and testing priorities:

[0068] 1. Signal fault data: used to simulate various abnormalities in signal transmission, such as signal loss, signal noise, signal delay, or signal strength attenuation, etc. Application scenarios: used in communication protocol testing, sensor signal processing modules, actuator control signal paths, etc.

[0069] 2. Sensor fault data: used to simulate faults of sensor components, including inaccuracy of sensor output, complete failure of sensor, sensor output out of range, or synchronization problems between sensors. Application scenarios: suitable for autonomous driving systems, active safety systems, powertrain control systems, etc., which highly depend on real-time data received from sensors.

[0070] 3. Actuator fault data: used to simulate faults in actuator components, such as slow response, incorrect action, stuck, or complete non-response. Application scenario: mainly used to verify the response mechanism of the vehicle control system when the actuator fails, ensuring that the system can take safety measures such as slowing down, stopping, or switching to a backup control path.

[0071] 4. Software logic fault data: used to simulate errors in software algorithms or logic processing, including arithmetic operation errors, logic judgment errors, memory overflow, concurrency control problems, and program crashes. Application scenario: suitable for testing all software modules, especially in complex software architectures, to verify the stability, error recovery ability, and data integrity of the software under logical errors.

[0072] The generation of fault data can be random or predefined, depending on the purpose of the test. Random generation is used for comprehensive coverage of possible fault scenarios, while predefined data is used to specifically test certain fault responses. During the test process, the above types of fault data are injected into the software model through the fault injection interface in the model, and the output and behavior of the model are observed and recorded to evaluate the performance and safety of the model under various fault conditions.

[0073] It should be noted that, for the foregoing method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited to the order of the described actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0074] From the above description of the embodiments, those skilled in the art can clearly understand that the model testing method of the electric vehicle according to the above embodiments can be realized by means of software and necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes a plurality of instructions for causing a terminal device (which can be a mobile phone, computer, server, or network device) to execute the methods described in the various embodiments of the present application.

[0075] According to the embodiments of the present application, there is also provided a model testing device for electric vehicles for implementing the above-mentioned model testing method of electric vehicles, Figure 4 is a structural block diagram of the model testing device for electric vehicles provided by the embodiments of the present application, as shown inFigure 4 As shown in the figure, the model testing device of the electric vehicle comprises an acquisition module 402, a copying module 404, an inquiry module 406, a replacement module 408 and a testing module 410, and the model testing device of the electric vehicle is described as follows.

[0076] The acquisition module 402 is configured to acquire a model to be tested in the electric vehicle.

[0077] The copying module 404 is connected with the acquisition module 402 and configured to copy the model to be tested to obtain a copied model.

[0078] The inquiry module 406 is connected with the copying module 404 and configured to inquire a signal line with a preset name in the copied model to determine a target signal line.

[0079] The replacement module 408 is connected with the inquiry module 406 and configured to replace the target signal line with a preset stub function, wherein the stub function comprises a fault injection interface function.

[0080] The testing module 410 is connected with the replacement module 408 and configured to input preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the model to be tested.

[0081] It should be noted that the acquisition module 402, the copying module 404, the inquiry module 406, the replacement module 408 and the testing module 410 correspond to steps S202 to S210 in the embodiments, and the instances and application scenarios realized by the modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. It should be noted that the above modules as part of the device can run in the computer terminal 10 provided in the embodiments.

[0082] The embodiments of the present application can provide a computer device. Optionally, in the present embodiment, the computer device can be located in at least one network device of a plurality of network devices of a computer network. The computer device comprises a memory and a processor.

[0083] The memory can be configured to store software programs and modules, such as program instructions / modules corresponding to the model testing method and device of the electric vehicle in the embodiments of the present application. The processor executes the software programs and modules stored in the memory to perform various functional applications and data processing, i.e., to implement the model testing method of the electric vehicle described above. The memory can include a high-speed random access memory, and can further include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory can further include remotely disposed memories relative to the processor, which can be connected to the computer terminal through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0084] The processor can call information and applications stored in the memory through the transmission device to perform the following steps: obtaining a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copied model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0085] Optionally, the processor can further execute program codes of the following steps: inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, including: obtaining a state of a fault injection enabling interface; determining whether the fault data needs to be injected based on the state; in the case that the fault data needs to be injected, calling the fault injection interface function to input the fault data based on a preset stub function switching function to test the copied model to obtain the target test result.

[0086] Optionally, the processor can further execute program codes of the following steps: obtaining a state of a fault injection enabling interface, including: defining a global variable corresponding to the fault injection enabling interface; receiving a numerical value of the global variable input based on a target account; determining the state of the fault injection enabling interface based on the numerical value of the global variable.

[0087] Optionally, the processor can further execute program codes of the following steps: in the case that the fault data does not need to be injected, testing the copied model to obtain a standard test result; comparing the target test result with the standard test result to determine a fault response result of the to-be-tested model.

[0088] Optionally, the processor can further execute program codes of the following steps: querying the signal line with the preset name in the copy model to determine the target signal line, comprising: querying the signal line with the preset name in the copy model based on the regular expression to determine the target signal line.

[0089] Optionally, the fault data comprises at least one of the following: signal fault data, sensor fault data, actuator fault data and software logic fault data.

[0090] By adopting the embodiment of the present application, a model testing method of an electric vehicle is provided, which comprises the following steps: obtaining a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copy model; querying a signal line with a preset name in the copy model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function comprises a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copy model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model. The embodiment of the present application can set different faults for testing, thereby achieving the technical effect of improving the accuracy of the test result while protecting the to-be-tested model, and solving the technical problem that the current model testing with the aid of a third-party testing tool can only expose the input and output interfaces and cannot meet the testing requirements, resulting in an inaccurate test result.

[0091] Those skilled in the art can understand that all or part of the steps in the above-mentioned various embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a non-volatile storage medium, which can include a flash disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0092] The embodiment of the present application further provides a non-volatile storage medium. Optionally, in the present embodiment, the non-volatile storage medium can be used to save the program codes executed by the model testing method of the electric vehicle provided by the above-mentioned embodiments.

[0093] Optionally, in the present embodiment, the non-volatile storage medium can be located in any one of the computer terminals in the computer terminal group in the computer network, or in any one of the mobile terminals in the mobile terminal group.

[0094] Optionally, in the embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: obtaining a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copied model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0095] Optionally, in the embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: obtaining a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copied model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0096] Optionally, in the embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: obtaining a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copied model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0097] Optionally, in the embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: obtaining a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copied model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0098] Optionally, in the embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: obtaining a to-be-tested model of the electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copied model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0099] Optionally, in the embodiment, the fault data includes at least one of the following: signal fault data, sensor fault data, actuator fault data, and software logic fault data.

[0100] The embodiment of the present application further provides a computer program product comprising a computer program, and the computer program is executed by a processor to implement the following steps: obtaining a to-be-tested model of an electric vehicle; copying the to-be-tested model to obtain a copied model; querying a signal line with a preset name in the copied model to determine a target signal line; replacing the target signal line with a preset stub function, wherein the stub function comprises a fault injection interface function; inputting preset fault data based on the fault injection interface function to test the copied model to obtain a target test result, wherein the target test result represents a test result corresponding to the to-be-tested model.

[0101] The above-mentioned serial numbers of the embodiments of the present application are only for description, and do not represent the advantages or disadvantages of the embodiments.

[0102] In the above-mentioned embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0103] In several embodiments provided in the present application, it should be understood that the disclosed technical contents can be implemented by other ways. Among them, the above-mentioned device embodiments are only schematic, for example, the division of the units can be a logical function division, and actual implementation can have another division way, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or modules shown or discussed can be indirect coupling or communication connection through some interfaces, units or modules, which can be electrical or other forms.

[0104] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or they can be distributed on multiple units. According to actual needs, part or all of the units can be selected to achieve the purpose of the embodiment scheme.

[0105] In addition, each functional unit in each embodiment of the present application can be integrated in a processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be realized in the form of hardware or in the form of software functional unit.

[0106] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a nonvolatile storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in various embodiments of the present application. The aforementioned storage medium includes a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0107] The above description is only the preferred embodiments of the present application, and it should be pointed out that, for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, and these improvements and refinements should be considered as the protection scope of the present application.

Claims

1. A model testing method for electric vehicles, characterized in that, include: Obtain the test model of the electric vehicle; The model to be tested is copied to obtain a copied model; Query the signal lines with preset names in the replication model to determine the target signal line; The target signal line is replaced with a preset stub function, wherein the stub function includes a fault injection interface function; Based on the fault injection interface function, preset fault data is input to test the replication model and obtain the target test result, wherein the target test result is characterized as the test result corresponding to the model to be tested.

2. The method according to claim 1, characterized in that, The process involves inputting preset fault data based on the fault injection interface function, testing the replication model, and obtaining the target test result, including: Obtain the status of the fault initiation enable interface; Based on the aforementioned state, determine whether fault data needs to be injected; When fault data needs to be injected, the fault injection interface function is called based on the preset stub function switching function to input the fault data, and the replication model is tested to obtain the target test result.

3. The method according to claim 2, characterized in that, The process of obtaining the status of the fault cut-in enable interface includes: Define a global variable corresponding to the fault initiation enable interface; Receive the value of the global variable based on the input from the target account; Based on the value of the global variable, the state of the fault initiation enable interface is determined.

4. The method according to claim 2, characterized in that, Also includes: The replication model is tested without the need to inject fault data to obtain standard test results; The target test results are compared with the standard test results to determine the fault response results of the model under test.

5. The method according to claim 1, characterized in that, The process of querying the signal lines with preset names in the replication model and determining the target signal line includes: Based on regular expressions, the target signal line is determined by querying the signal lines with preset names in the replication model.

6. The method according to any one of claims 1 to 5, characterized in that, in, The fault data includes at least one of the following: signal fault data, sensor fault data, actuator fault data, and software logic fault data.

7. A model testing device for an electric vehicle, characterized in that, include: The acquisition module is used to acquire the test model in the electric vehicle. The copying module is used to copy the model to be tested to obtain a copied model; The query module is used to query the signal lines with preset names in the replication model and determine the target signal line; A replacement module is used to replace the target signal line with a preset stub function, wherein the stub function includes a fault injection interface function; The testing module is used to test the replication model based on the fault injection interface function, input preset fault data, and obtain the target test result, wherein the target test result is characterized as the test result corresponding to the model to be tested.

8. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the non-volatile storage medium to perform the model testing method for the electric vehicle according to any one of claims 1 to 6.

9. A computer device, characterized in that, include: Memory and processor The memory stores computer programs; The processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, the processor performs the model testing method for the electric vehicle according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the model testing method for the electric vehicle according to any one of claims 1 to 6.

Images