Fault testing method and system based on hardware-in-loop simulation
By parsing test requirements into functional modules and automatically generating test cases and modular fault injection control code, the problem of low automation in hardware-in-the-loop simulation testing is solved, and an efficient automated testing process is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 辰致科技有限公司
- Filing Date
- 2025-12-04
- Publication Date
- 2026-05-05
AI Technical Summary
Existing hardware-in-the-loop simulation testing methods have low automation, low testing efficiency, and long process time cycles.
The test requirements are parsed into functional modules, test cases are generated, and the injected faults of the HIL bench are automatically matched. The fault injection control code is encapsulated in a modular way, and the test code is automatically generated and executed on the HIL bench.
It achieves fully closed-loop automated testing, significantly shortens the test case creation time, reduces the input of manual code development, and improves testing efficiency and automation.
Smart Images
Figure CN121979731A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of hardware-in-the-loop simulation technology, specifically a fault testing method and system based on hardware-in-the-loop simulation. Background Technology
[0002] HIL (Hardware-in-the-Loop) is a technology that uses a real-time processor to run simulations. A HIL test bench (i.e., a HIL test bench) combines a physical structure with a precision control system to create an experimental device for verifying the functional performance of equipment or products. It connects real electronic control units (ECUs) to a virtual environment for closed-loop testing. Its advantages include: Real-world integration: Real controllers (such as ECUs) are connected to a virtual vehicle model to simulate various operating conditions; Safety and efficiency: Hazardous scenarios (such as sensor failure) can be repeatedly tested; It is widely used in automotive electronics, aerospace, and industrial equipment testing.
[0003] In existing technologies, the process of obtaining test requirements for braking products and completing HIL bench testing requires manual processes such as requirement decomposition, test case design, and test code writing, which is time-consuming. Therefore, it suffers from low automation and low testing efficiency. Summary of the Invention
[0004] To overcome the shortcomings of existing technologies, this invention provides a fault testing method and system based on hardware-in-the-loop simulation, which solves the problems of low automation and low testing efficiency in existing technologies.
[0005] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: A fault testing method based on hardware-in-the-loop simulation includes the following steps: The test data information is entered into the HIL bench and saved to the test database; the test data information includes: test requirements, software framework, and HIL bench information. The test requirements are parsed into several functional modules, each of which includes one or more test items. The test items are matched with the injection faults of the HIL bench to generate test cases and save them to the test database. Each test case includes one or more test steps. Based on the HIL bench information and software framework, the fault injection control code is modularly encapsulated, and the modularly encapsulated fault injection control code is saved to the test database in a file format; the test steps of the test cases in the test database are associated with the modularly encapsulated fault injection control code to generate test code; Execute the test code on the HIL bench and generate test results.
[0006] The beneficial effects of this invention are: This invention parses the product's testing requirements into several functional modules, each including one or more test items. It automatically matches the testing requirements, software framework, HIL bench information, and injected faults in the HIL bench, automatically generating test cases, then generating and executing test code. This completes the fully closed-loop automated testing of the fault injection HIL bench, achieving a high degree of automation and significantly shortening the test case creation time. Furthermore, this invention combines test cases with modular fault injection control code to generate directly executable test code, greatly reducing the manual input required to develop test case code.
[0007] Based on the above technical solution, the present invention can be further improved as follows.
[0008] As a preferred technical solution, the test requirements are analyzed into several functional modules, each of which includes one or more test items, including the following steps: Based on the different test case code templates in the test database, the test requirements are broken down into independent test items.
[0009] The beneficial effects of adopting the above-mentioned preferred technical solution are: By relying on test case code templates, test requirements are functionally broken down into several functional modules, each containing several test items. This method improves efficiency by 80% compared to the traditional manual decomposition of requirements.
[0010] As a preferred technical solution, test requirements are broken down into independent test items based on different test case code templates in the test database, including the following steps: The test requirements are parsed into test case keywords using the finite state method; Retrieve test case code templates from the test database using test case keywords; Enter the keyword information in the test case code template to generate test cases.
[0011] The beneficial effects of adopting the above-mentioned preferred technical solution are: Keyword retrieval offers high efficiency and accuracy, while the finite state method boasts a clear structure, ease of maintenance, and efficient control.
[0012] As a preferred technical solution, test case code templates are updated as testing requirements increase.
[0013] The beneficial effects of adopting the above-mentioned preferred technical solution are: Test case code templates are updated as test requirements increase, which helps to improve the speed and accuracy of test requirement parsing in a timely manner.
[0014] As a preferred technical solution, when the fault injection control code is modularly encapsulated, the fault injection control code is encapsulated into one or more functions, and each function corresponds to a test step.
[0015] The beneficial effects of adopting the above-mentioned preferred technical solution are: Functions are easy to call and execute, and are highly readable.
[0016] As a preferred technical solution, the test steps of test cases in the test database are associated with modularly encapsulated fault injection control code to generate test code, including the following steps: Associate the test steps of the test cases in the test database with the fault injection control code; Once the test steps for all test cases in the test database are associated, compileable and executable .c code is generated.
[0017] The beneficial effects of adopting the above-mentioned preferred technical solution are: It can replace 90% of the test case code writing work done by developers, improving overall efficiency by more than 90%.
[0018] As a preferred technical solution, in the process of associating the test steps of the test cases in the test database with the fault injection control code, if there is no corresponding fault injection control code for the test steps of the test cases in the test database, an empty code interface is generated and input into the test database, so that the test cases are associated with the empty code interface; then the developers are notified to write the implementation code of the empty code interface, and then the test case file is regenerated.
[0019] The beneficial effects of adopting the above-mentioned preferred technical solution are: It is easier to handle situations where the test steps of the test cases in the test database do not have corresponding fault injection control code, and has a wider range of applications.
[0020] As a preferred technical solution, executing test code on a HIL bench and generating test results includes the following steps: Test code is executed on the HIL bench using DevOps scheduling methods to generate test results.
[0021] The beneficial effects of adopting the above-mentioned preferred technical solution are: DevOps scheduling methods reduce HIL bench idleness and queuing through centralized scheduling and automated allocation, achieving efficient resource utilization; test scripts can be automatically triggered for execution, shortening feedback cycles and accelerating testing efficiency; development, testing, and operations teams share a unified process, reducing manual intervention and facilitating the reuse of test assets.
[0022] As a preferred technical solution, the test data also includes a hardware framework, which contains information about the brakes of the electric vehicle under test.
[0023] The beneficial effects of adopting the above-mentioned preferred technical solution are: This facilitates testing for brake malfunctions in electric vehicles.
[0024] Based on the above technical solutions, the present invention also provides a fault testing system based on hardware-in-the-loop simulation.
[0025] A hardware-in-the-loop simulation-based fault testing system, used to implement the aforementioned hardware-in-the-loop simulation-based fault testing method, includes the following modules connected in sequence: The test data input module is used to input test data information into the HIL bench and save it to the test database; the test data information includes: test requirements, software framework, and HIL bench information. The test case module is used to: parse test requirements into several functional modules, each functional module including one or more test items, match test items with injection faults in the HIL bench, generate test cases and save them to the test database; wherein, the test case includes one or more test steps; The test code generation module is used to: modularize and encapsulate the fault injection control code based on HIL bench information and software framework; save the modularized fault injection control code to the test database using a file format; and associate the test steps of the test cases in the test database with the modularized fault injection control code to generate test code. The test code execution module is used to execute test code on the HIL bench and generate test results.
[0026] Compared with the prior art, the present invention has the following advantages: (1) This invention analyzes the product's test requirements into several functional modules. Each functional module includes one or more test items. It automatically matches the test requirements, software framework, HIL bench information with the injected faults of the HIL bench, automatically generates test cases, and then generates and executes test code. It completes the automated test of fault injection HIL bench in a closed loop, with a high degree of automation and a significant reduction in test case creation time. This invention combines test cases with modular fault injection control code to generate test code that can be run directly, which greatly reduces the manual input of developing test case code. (2) By relying on test case code templates, test requirements are functionally parsed into several functional modules, each including several test items, which improves efficiency by 80% compared to the traditional manual decomposition of requirements. (3) Keyword retrieval has high retrieval efficiency and high accuracy. The finite state method has a clear structure, is easy to maintain, and has high control efficiency. (4) Test case code templates are updated as test requirements increase, which facilitates timely improvement in the speed and accuracy of test requirement parsing; (5) The function's expression is easy to call and execute, and has high readability; (6) It can replace 90% of the test case code writing work done by developers, improving overall efficiency by more than 90%; (7) It is easier to handle situations where the test steps of the test cases in the test database do not have corresponding fault injection control code, and its applicability is wider; (8) DevOps scheduling method reduces HIL bench idleness and queuing through centralized scheduling and automated allocation, and achieves efficient resource utilization; test scripts can be automatically triggered to execute, shortening the feedback cycle and accelerating test efficiency; development, testing and operation teams share a unified process, reducing manual intervention and facilitating the reuse of test assets; (9) Facilitates testing for brake failures in electric vehicles. Attached Figure Description
[0027] Figure 1 This is a schematic diagram illustrating the steps of a fault testing method based on hardware-in-the-loop simulation as described in this invention. Figure 2 This is a diagram illustrating the contents of the test database. Figure 3 Flowchart for test case generation and test code generation; Figure 4 Flowchart for test code execution; Figure 5 Here is a flowchart of the template matching algorithm; Figure 6 Flowchart of the automatic code generation algorithm; Figure 7 This is a schematic diagram of automatically generating test cases for Example 3; Figure 8 This is a schematic diagram of automatically generating test code for Example 3. Detailed Implementation
[0028] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.
[0029] The principles and features of the present invention are described below. The embodiments given are only for explaining the present invention and are not intended to limit the scope of the present invention.
[0030] Example 1 like Figures 1 to 8As shown, a fault testing method based on hardware-in-the-loop simulation includes the following steps: The test data information is entered into the HIL bench and saved to the test database; the test data information includes: test requirements, software framework, and HIL bench information. The test requirements are parsed into several functional modules, each of which includes one or more test items. The test items are matched with the injection faults of the HIL bench to generate test cases and save them to the test database. Each test case includes one or more test steps. Based on the HIL bench information and software framework, the fault injection control code is modularly encapsulated, and the modularly encapsulated fault injection control code is saved to the test database in a file format; the test steps of the test cases in the test database are associated with the modularly encapsulated fault injection control code to generate test code; Execute the test code on the HIL bench and generate test results.
[0031] The beneficial effects of this invention are: This invention parses the product's testing requirements into several functional modules, each including one or more test items. It automatically matches the testing requirements, software framework, HIL bench information, and injected faults in the HIL bench, automatically generating test cases, then generating and executing test code. This completes the fully closed-loop automated testing of the fault injection HIL bench, achieving a high degree of automation and significantly shortening the test case creation time. Furthermore, this invention combines test cases with modular fault injection control code to generate directly executable test code, greatly reducing the manual input required to develop test case code.
[0032] Based on the above technical solution, the present invention can be further improved as follows.
[0033] As a preferred technical solution, the test requirements are analyzed into several functional modules, each of which includes one or more test items, including the following steps: Based on the different test case code templates in the test database, the test requirements are broken down into independent test items.
[0034] The beneficial effects of adopting the above-mentioned preferred technical solution are: By relying on test case code templates, test requirements are functionally broken down into several functional modules, each containing several test items. This method improves efficiency by 80% compared to the traditional manual decomposition of requirements.
[0035] As a preferred technical solution, test requirements are broken down into independent test items based on different test case code templates in the test database, including the following steps: The test requirements are parsed into test case keywords using the finite state method; Retrieve test case code templates from the test database using test case keywords; Enter the keyword information in the test case code template to generate test cases.
[0036] The beneficial effects of adopting the above-mentioned preferred technical solution are: Keyword retrieval offers high efficiency and accuracy, while the finite state method boasts a clear structure, ease of maintenance, and efficient control.
[0037] As a preferred technical solution, test case code templates are updated as testing requirements increase.
[0038] The beneficial effects of adopting the above-mentioned preferred technical solution are: Test case code templates are updated as test requirements increase, which helps to improve the speed and accuracy of test requirement parsing in a timely manner.
[0039] As a preferred technical solution, when the fault injection control code is modularly encapsulated, the fault injection control code is encapsulated into one or more functions, and each function corresponds to a test step.
[0040] The beneficial effects of adopting the above-mentioned preferred technical solution are: Functions are easy to call and execute, and are highly readable.
[0041] As a preferred technical solution, the test steps of test cases in the test database are associated with modularly encapsulated fault injection control code to generate test code, including the following steps: Associate the test steps of the test cases in the test database with the fault injection control code; Once the test steps for all test cases in the test database are associated, compileable and executable .c code is generated.
[0042] The beneficial effects of adopting the above-mentioned preferred technical solution are: It can replace 90% of the test case code writing work done by developers, improving overall efficiency by more than 90%.
[0043] As a preferred technical solution, in the process of associating the test steps of the test cases in the test database with the fault injection control code, if there is no corresponding fault injection control code for the test steps of the test cases in the test database, an empty code interface is generated and input into the test database, so that the test cases are associated with the empty code interface; then the developers are notified to write the implementation code of the empty code interface, and then the test case file is regenerated.
[0044] The beneficial effects of adopting the above-mentioned preferred technical solution are: It is easier to handle situations where the test steps of the test cases in the test database do not have corresponding fault injection control code, and has a wider range of applications.
[0045] As a preferred technical solution, executing test code on a HIL bench and generating test results includes the following steps: Test code is executed on the HIL bench using DevOps scheduling methods to generate test results.
[0046] The beneficial effects of adopting the above-mentioned preferred technical solution are: DevOps scheduling methods reduce HIL bench idleness and queuing through centralized scheduling and automated allocation, achieving efficient resource utilization; test scripts can be automatically triggered for execution, shortening feedback cycles and accelerating testing efficiency; development, testing, and operations teams share a unified process, reducing manual intervention and facilitating the reuse of test assets.
[0047] As a preferred technical solution, the test data also includes a hardware framework, which contains information about the brakes of the electric vehicle under test.
[0048] The beneficial effects of adopting the above-mentioned preferred technical solution are: This facilitates testing for brake malfunctions in electric vehicles.
[0049] Based on the above technical solutions, the present invention also provides a fault testing system based on hardware-in-the-loop simulation.
[0050] A hardware-in-the-loop simulation-based fault testing system, used to implement the aforementioned hardware-in-the-loop simulation-based fault testing method, includes the following modules connected in sequence: The test data input module is used to input test data information into the HIL bench and save it to the test database; the test data information includes: test requirements, software framework, and HIL bench information. The test case module is used to: parse test requirements into several functional modules, each functional module including one or more test items, match test items with injection faults in the HIL bench, generate test cases and save them to the test database; wherein, the test case includes one or more test steps; The test code generation module is used to: modularize and encapsulate the fault injection control code based on HIL bench information and software framework; save the modularized fault injection control code to the test database using a file format; and associate the test steps of the test cases in the test database with the modularized fault injection control code to generate test code. The test code execution module is used to execute test code on the HIL bench and generate test results.
[0051] Example 2 like Figures 1 to 8 As shown, based on Example 1, this example provides a more detailed implementation method.
[0052] This invention provides an automated testing solution for diagnostic fault injection of braking products on a HIL test bench. The invention includes the following steps: test data input, test case generation, test code generation, and test code execution.
[0053] Test data input. Input data is saved to the test database in a specific format. Input test data includes test requirement documents, software framework documents, hardware framework documents (i.e., hardware information of the device under test, such as hardware TP pinout diagrams and wiring harness pinout diagrams), and HIL bench information documents (such as PCBA pinout diagrams), etc.
[0054] Automatic test case generation. Brake product testing requirements are parsed into several functional modules, each containing several test items. These test items are matched with HIL bench injection faults to generate test cases, which include test steps. These test cases are then saved to the test database. During the test requirement parsing process, a template matching method is used to decompose the brake product testing requirements into independent test items based on different test case code templates in the test database. This improves efficiency by 80% compared to traditional manual requirement decomposition. Furthermore, the template library is continuously updated as the analyzed product requirements increase, improving the speed and accuracy of test requirement parsing.
[0055] Automatic test code generation. First, based on the HIL bench information and software framework (e.g., the TSMaster testing framework; TSMaster is an automotive electronics testing tool used for real-time simulation verification in hardware-in-the-loop testing), the fault injection control code is modularly encapsulated (function-level, one function corresponds to one independent test step) and saved to the test database using a file format. Then, using an automatic code generation algorithm, the test steps of the test cases in the test database are associated with the fault injection control code to generate complete executable test code files (for the TSMaster testing framework to call). Using this automatic code generation algorithm can replace 90% of the test case code writing work done by developers, improving overall efficiency by over 90%.
[0056] HIL bench automation testing (test code execution). A test plan is generated in the test database, and test code is executed on the HIL bench via DevOps scheduling to generate test results, which are then sent to relevant personnel.
[0057] More specific methods are as follows: Figure 4The test environment verification includes the following: 1. The test code exists; 2. HIL rack connection successful; 3. Upgrade the MCU chip program on the PCBA board in the HIL test bench to the program version to be tested.
[0058] Figure 5 In this context, template matching employs the following steps: The test requirement document is formatted by parsing test requirement keywords and then parsed into test case keywords using a finite state method (which can be implemented with existing technology, so its specific steps are not described in detail). Test case code templates are then retrieved from the test database using the test case keywords. After filling in the keyword information in the test case code templates, test cases are generated.
[0059] For example: Test requirements document: The XX solenoid valve is disconnected for XX milliseconds / ms, and the diagnostic event reports the XX diagnostic fault code (DTC_XXX); Analysis results: {Module: Solenoid valve; Operation: Open circuit fault; Duration period: XX; Diagnostic fault code: DTC_XXX}; Database search: Using the keywords "solenoid valve" + "open circuit fault", the search returned a test case template for "solenoid valve open circuit fault". Test case generation: Fill in the parsed keywords into the specified positions in the test case template to generate test cases.
[0060] Figure 6 In this context, the automatic code generation algorithm employs the following steps: The test steps described in the test cases are associated with their implementation code (i.e., fault injection control code, represented as functions). Once all test steps of a test case (a test case may have multiple test steps) are associated, compileable and executable .c code is generated. During the association process, if a test step does not have corresponding implementation code in the test database, an empty code interface (function name) is generated according to the implementation code (function) naming rules and appended to the test database to complete the association between the test case and the implementation code. Then, the developers are notified to write the implementation code for this code interface (function name). After the implementation code is written, the test case file is regenerated. Since a test case may have multiple test steps, all test steps need to be processed iteratively before generating the test case. If the implementation code (function) corresponding to a test step does not exist, an empty code interface (with only the function name) is appended first to successfully associate the test step and generate the test code. Then, the developers are notified to append the function content for test execution.
[0061] This invention integrates product testing requirements, software framework, HIL bench information, and HIL bench injection faults with DevOps to achieve a fully closed-loop automated test of fault injection into the HIL bench.
[0062] The present invention has the following technical effects: (1) The present invention analyzes the product test requirements into several functional modules. Each functional module includes one or more test items. The test requirements, software framework, HIL bench information and HIL bench injection faults are automatically matched to automatically generate test cases. Then test code is generated and executed. The fault injection HIL bench automated test is completed in a closed loop. The degree of automation is high and the test case production time is greatly shortened. (2) This invention combines test cases with modular fault injection control code to generate test code that can be run directly, which greatly reduces the manual input of developing test case code.
[0063] Example 3 like Figures 1 to 8 As shown, this embodiment provides a more detailed implementation method based on Embodiments 1 and 2.
[0064] Example 1: Solenoid valve open-circuit fault test, automatically generate test cases, such as... Figure 7 As shown.
[0065] Test requirement input: The XX solenoid valve is disconnected for XX milliseconds / ms, and the XX diagnostic fault code (DTC_XXX) is reported through diagnostic events; Hardware fault diagram: The fault injection point corresponding to the XX solenoid valve is TPXXX; HIL bench definition: Fault injection point TPXXX, corresponding control signal XXValve_TPXX; Example 2: Solenoid valve open circuit fault test, automatically generate test code, such as... Figure 8 As shown.
[0066] As described above, the present invention can be implemented well.
[0067] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0068] In the description of this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. Furthermore, "above," "over," and "on top" of the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.
[0069] In the description of this invention, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0070] In the description of this invention, although embodiments of the invention have been shown and described herein, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this invention.
[0071] In the description of this invention, all features disclosed in all embodiments of this specification, or steps in all methods or processes implied in the disclosure, may be combined and / or extended or replaced in any way, except for mutually exclusive features and / or steps.
[0072] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Based on the technical essence of the present invention, any simple modifications, equivalent substitutions, and improvements made to the above embodiments within the spirit and principles of the present invention shall still fall within the protection scope of the present invention.
Claims
1. A fault testing method based on hardware-in-the-loop simulation, characterized in that, Includes the following steps: The test data information is entered into the HIL bench and saved to the test database; the test data information includes: test requirements, software framework, and HIL bench information. The test requirements are parsed into several functional modules, each of which includes one or more test items. The test items are matched with the injection faults of the HIL bench to generate test cases and save them to the test database. Each test case includes one or more test steps. Based on the HIL bench information and software framework, the fault injection control code is modularly encapsulated, and the modularly encapsulated fault injection control code is saved to the test database in a file format; the test steps of the test cases in the test database are associated with the modularly encapsulated fault injection control code to generate test code; Execute the test code on the HIL bench and generate test results.
2. The fault testing method based on hardware-in-the-loop simulation according to claim 1, characterized in that, The test requirements are broken down into several functional modules, each of which includes one or more test items, including the following steps: Based on the different test case code templates in the test database, the test requirements are broken down into independent test items.
3. The fault testing method based on hardware-in-the-loop simulation according to claim 2, characterized in that, Based on the different test case code templates in the test database, the test requirements are broken down into independent test items, including the following steps: The test requirements are parsed into test case keywords using the finite state method; Retrieve test case code templates from the test database using test case keywords; Enter the keyword information in the test case code template to generate test cases.
4. The fault testing method based on hardware-in-the-loop simulation according to claim 3, characterized in that, Test case code templates are updated as testing requirements increase.
5. The fault testing method based on hardware-in-the-loop simulation according to claim 4, characterized in that, When fault injection control code is modularly encapsulated, it is encapsulated into one or more functions, each function corresponding to a test step.
6. The fault testing method based on hardware-in-the-loop simulation according to claim 5, characterized in that, Associate the test steps of the test cases in the test database with the modularly encapsulated fault injection control code to generate test code, including the following steps: Associate the test steps of the test cases in the test database with the fault injection control code; Once the test steps for all test cases in the test database are associated, compileable and executable .c code is generated.
7. The fault testing method based on hardware-in-the-loop simulation according to claim 6, characterized in that, During the process of associating the test steps of test cases in the test database with the fault injection control code, if there is no corresponding fault injection control code for the test steps of test cases in the test database, an empty code interface is generated and input into the test database, so that the test cases are associated with the empty code interface. Then notify the developers to write the implementation code for the empty code interface, and then regenerate the test case file.
8. The fault testing method based on hardware-in-the-loop simulation according to claim 7, characterized in that, Execute the test code on the HIL bench and generate test results, including the following steps: Test code is executed on the HIL bench using DevOps scheduling methods to generate test results.
9. A fault testing method based on hardware-in-the-loop simulation according to any one of claims 1 to 8, characterized in that, The test data also includes the hardware framework, which contains information about the brakes of the electric vehicle under test.
10. A fault testing system based on hardware-in-the-loop simulation, characterized in that, A fault testing method based on hardware-in-the-loop simulation as described in any one of claims 1 to 9 comprises the following modules connected in sequence: The test data input module is used to input test data information into the HIL bench and save it to the test database; the test data information includes: test requirements, software framework, and HIL bench information. The test case module is used to: parse test requirements into several functional modules, each functional module including one or more test items, match test items with injection faults in the HIL bench, generate test cases and save them to the test database; wherein, the test case includes one or more test steps; The test code generation module is used to: modularize and encapsulate the fault injection control code based on HIL bench information and software framework; save the modularized fault injection control code to the test database using a file format; and associate the test steps of the test cases in the test database with the modularized fault injection control code to generate test code. The test code execution module is used to execute test code on the HIL bench and generate test results.