A new hardware-in-the-loop testing method and system for brake domain controllers

Abstract

The present invention relates to the field of intelligent vehicle testing technology, and discloses a novel hardware-in-the-loop testing method and system for a brake domain controller. The system includes a device under test, an information acquisition system, a test bench, a bench configuration system, and an automated testing system. During the test, the device under test establishes a circuit connection with a physical motor and a brake. The information acquisition system is used to collect working data of the physical motor. The test bench is used to interact with the device under test. The bench configuration system is used to build a vehicle dynamics model and a test environment model. The automated testing system includes a conversion module and a test control module. The conversion module is used to call a test environment parameter file according to a preset strategy and convert the test environment parameter file into a target test case. The test control module is used to control the execution of the test. The present invention can complete highly automated HIL testing of the domain controller, can meet diverse functional testing requirements, and has a low test execution cost.

Description

Technical Field

[0001] The present invention relates to the field of intelligent vehicle testing technology, and in particular to a novel hardware-in-the-loop testing method and system for a braking domain controller. Background Art

[0002] In recent years, the rapid development of brake domain controllers (BDCs) in the automotive electronics industry has shown a trend toward diversification and intelligence. With the advancement of new energy vehicles and autonomous driving technologies, the complexity of braking systems has increased significantly, and traditional brake control functions are gradually evolving towards integration and intelligence. Modern BDCs not only manage braking execution but also coordinate multiple functions such as electric power braking, ABS (anti-lock braking system), and ESP (electronic stability program). Through highly integrated designs, they achieve more precise control and higher performance. In this context, hardware-in-the-loop (HIL) testing is often used to verify BDC functionality. However, the testing effectiveness of existing methods still leaves much room for improvement.

[0003] First, domain controller interface communication testing is a significant pain point. Hardware interface and communication protocol consistency must be ensured between the test equipment and the domain controller, otherwise incompatibility may occur during testing. The domain controller must process forwarded messages ranging from 2 to 30 frames, initially estimated to contain approximately 1,200 to 1,500 signals. This massive number of signals significantly increases the workload for signal consistency testing. Secondly, during hardware-in-the-loop (HIL) testing, data acquisition accuracy and real-time performance are extremely demanding. Because the domain controller must rapidly respond and implement necessary control functions while processing multiple inputs, key sensors in the test system must meet real-time standards, placing even higher demands on the design of data sources. Furthermore, due to the functional coupling of the domain controller, testing complexity increases exponentially. The complexity of test case writing and execution not only directly increases the risk of system functional coverage but also increases cycle costs. Utilizing a systematic approach to effectively simulate various possible application scenarios to verify domain controller functionality has become a complex task.

[0004] Therefore, in the process of verifying and testing the pre-development functions of the brake domain controller, it is urgent to establish a new hardware-in-the-loop testing method and system for the brake domain controller to adapt to the multifunctional coupling characteristics of today's brake domain controller and its diversified testing requirements under complex and changeable operating conditions and application scenarios. Summary of the Invention

[0005] The present invention aims to provide a novel hardware-in-the-loop testing method and system for brake domain controllers, which can complete highly automated HIL testing of domain controllers, meet diverse functional testing requirements, and have low test execution costs.

[0006] To achieve the above objectives, the present invention provides the following basic solutions.

[0007] Option 1

[0008] A new hardware-in-the-loop test system for brake domain controllers, including a device under test, an information acquisition system, a test bench, a bench configuration system, and an automated test system;

[0009] The device under test is a brake domain controller; during the test, the device under test establishes a circuit connection with a physical motor and a brake, and the physical motor controls the application and release of the brake; the information acquisition system is used to collect working data of the physical motor;

[0010] The test bench is a HIL test bench and is used to interact with the device under test; the test bench configuration system is used to build a vehicle dynamics model and a test environment model; the test bench configuration system forms a test closed loop through the test bench, the device under test, the physical motor and the brake;

[0011] The automated testing system includes a conversion module and a test control module; the conversion module is used to call the test environment parameter file according to a preset strategy and convert the test environment parameter file into a target test case; the test control module adjusts the parameters of the vehicle dynamics model and the test environment model through the bench configuration system according to the target test case, and controls the test execution.

[0012] Option 2

[0013] A novel hardware-in-the-loop testing method for a braking domain controller is provided, wherein the method adopts a novel hardware-in-the-loop testing system for a braking domain controller as described in Solution 1 for testing; the method comprises the following steps:

[0014] Step 1: Configure a test system; the test system is a new hardware-in-the-loop test system for a brake domain controller;

[0015] Step 2: Build a vehicle dynamics model and a test environment model using the test bench configuration system. Verify whether there is any fault information in the new hardware-in-the-loop test system. If no fault information is found, proceed to the next step. If fault information is found, generate a warning message and send it to the tester, ending the process.

[0016] Step 3: The automated test system generates a target test case, and the test control module adjusts the parameters of the vehicle dynamics model and the test environment model through the test bench configuration system according to the target test case, and controls the test execution;

[0017] During the test, monitor and record test data until the speed of the vehicle under test decelerates to zero or reaches the maximum test time of this test case; when a single test is completed or exceeds the set maximum test time, execute the next step;

[0018] Step 4: End the test.

[0019] The working principle and advantages of the present invention are:

[0020] First, this solution specifically designs a motor information feedback system that can effectively simulate the system's motion state. The introduction of a physical motor in conjunction with the DUT can provide the DUT with more realistic and richer working condition information, helping to improve the reliability of functional testing. Specifically, the physical motor system is based on the working principle of "start signal-motor activation-clamping release-feedback loop". After the motor executes the instruction, it can promptly transmit the current stop or maintain current state information to the domain controller (DUT); at the same time, the hardware current working circuit adopted by the solution can support testers to perform fault injection tests of typical electrical performance (overcurrent, undercurrent, overvoltage, undervoltage, etc.) as required, facilitating the implementation of reproducible hardware fault injection, effectively reproducing the extreme test scenarios that the brake domain controller may encounter during the actual vehicle testing phase, and making the system's safety assessment more accurate and reliable.

[0021] Second, this solution can complete highly automated HIL testing of domain controllers. This solution has a special automated testing system, which is used as the overall scheduling software. The test environment parameter file is called according to the preset strategy, and data flow is achieved with other simulation software. The test environment parameter file is then converted into the target test case, thereby realizing the automatic generation of the test case file, which is convenient for the subsequent one-click start of the test. The application of this solution can realize the "end-to-end" automated testing process closed loop from requirement files (word, excel) to test cases (Pkg). The automated use case generation method can adapt to the complex and changeable operating conditions and application scenarios of the brake domain controller, and efficiently complete the construction and execution of different use cases, thereby realizing full-domain test verification; it can greatly save the working time of test personnel in test case design, writing and use case execution, greatly improve test efficiency, and effectively control the development cycle and cost, ensuring the reliability and safety of the brake domain controller in actual application.

[0022] Third, this solution incorporates vehicle dynamics simulation and test scenario simulation into its testing, providing richer metrics for hardware-in-the-loop testing. Compared to traditional hardware-in-the-loop testing, this solution addresses the lack of key parameters characteristic of the external scenarios during braking system operation. This effectively alleviates the current difficulty in executing extreme test cases in real-vehicle road testing due to random variations in external conditions, while also improving test effectiveness and efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a schematic diagram of the system structure of a first embodiment of a novel hardware-in-the-loop testing method and system for a braking domain controller according to the present invention;

[0024] Figure 2 This is a schematic diagram of a method according to a first embodiment of a novel hardware-in-the-loop testing method and system for a braking domain controller of the present invention;

[0025] Figure 3 This is a schematic diagram of the operation of a conversion module in a first embodiment of a novel hardware-in-the-loop testing method and system for a braking domain controller according to the present invention;

[0026] Figure 4 A schematic diagram of mapping a novel hardware-in-the-loop testing method for a braking domain controller and a system embodiment 3 of the present invention;

[0027] Figure 5 This is a schematic diagram of index definition in Embodiment 3 of a novel hardware-in-the-loop testing method and system for a braking domain controller according to the present invention. DETAILED DESCRIPTION

[0028] The following is a further detailed description through specific implementation methods:

[0029] Example 1

[0030] The embodiment is basically as shown in the attached Figure 1 Shown: A new hardware-in-the-loop test system for a brake domain controller, including a device under test, an information acquisition system, a test bench, a bench configuration system, and an automated test system.

[0031] The DUT is a brake domain controller. During testing, it establishes a circuit connection with a physical motor and brake, with the physical motor controlling the application and release of the brake. This hardware circuit connection allows for fault injection through the circuits, facilitating subsequent fault injection testing of typical electrical performance (e.g., overcurrent, undercurrent, overvoltage, undervoltage, etc.).

[0032] The physical motor specifically refers to the clamping motor in the electric parking brake (EPB) system, which is responsible for controlling the application and release of the brake. The physical motor is a motor system that includes a motor assembly, a transmission assembly, a sensor assembly, and a microcontroller assembly. The motor assembly uses a conventional DC motor or a stepper motor to provide the torque required for the operation of the motor system to clamp or release the brake; the transmission assembly is composed of conventional gears, screws, etc., which are used to convert the rotational motion of the motor assembly into the linear motion required to clamp or release the brake; the sensor assembly includes a position sensor (such as a Hall sensor, a photoelectric sensor, etc.) for detecting information such as the position and clamping status of the motor assembly to ensure precise control and feedback of the motor system; the microcontroller assembly is used to receive signals from other controllers (such as ABS or BCM) and control the reverse and clamping / release actions of the motor assembly.

[0033] The information acquisition system is used to collect the working data of the physical motor. In this embodiment, the information acquisition system is composed of an information acquisition sensor, a data acquisition module and a data processing unit. The information acquisition sensor is used to monitor various parameters of the motor in real time, such as voltage, current, temperature, etc. The data acquisition module is used to convert the parameters collected by the information acquisition sensor into digital data and perform preliminary processing. The data processing unit is used to analyze the data of the data acquisition module and extract useful information from it to provide support for subsequent decision-making. Through these components, the information acquisition system can achieve comprehensive monitoring of the motor status, help the system to promptly discover and solve potential problems, thereby improving the safety and efficiency of the overall system.

[0034] Through the above settings, this solution specifically introduces a physical motor to participate in the test. Compared with conventional test solutions, existing test solutions often use a simple controller for testing. This solution lacks flexibility and is difficult to meet the requirements of dynamic load changes. In addition, the solution uses a simulation model to replace the actual motor operation. Since the control algorithm is deeply coupled with the motor characteristics, if the motor is to be replaced, the control parameters need to be readjusted, which greatly increases the test maintenance cost and time. This solution overcomes the above limitations by introducing a physical motor and an information acquisition system. In this solution, the interface of the physical motor adopts standardized and normalized principles, making replacement relatively simple. At the same time, the information acquisition system can monitor the operating status of the motor in real time, and the collected data can be used for online analysis and optimization of the control strategy, making it more suitable for dynamic working condition testing that conforms to the actual operating status of the system.

[0035] The test bench is an existing HIL test bench used for interacting with the device under test. In this embodiment, the selected HIL test bench comprises a stable power output module, a multi-channel data acquisition and processing device, and high-precision sensors to ensure stable data acquisition and transmission during testing. Furthermore, the test bench features a wide range of input / output interfaces, compatible with various domain controllers, ensuring test versatility.

[0036] The test bench configuration system is used to build a vehicle dynamics model and a test environment model; the test bench configuration system forms a test closed loop through the test bench, the test piece, the physical motor and the brake.

[0037] Specifically, the test bench configuration system is equipped with existing simulation software such as VeriStand, CarSim and MATLAB / Simulink to support verification testing of various functions of the brake domain controller. Among them, CarSim is responsible for providing a vehicle dynamics model to simulate vehicle behavior and dynamic response, and to send vehicle information data through the TCP / UDP protocol. MATLAB software is responsible for simulating the signal interaction logic of other key units involved in signal interaction with the brake domain controller, and providing the necessary input trigger information for the device under test. VeriStand, as the hub responsible for configuring the real-time test environment, can comprehensively integrate the vehicle dynamics model of CarSim and the strategy model generated by MATLAB, while supporting the configuration of the test bench's hard-wired interface to achieve signal flow interaction with the object under test in a normal working environment.

[0038] At the same time, VeriStand, through joint debugging with Labview unit modules, provides a visual foundation for defining test scenarios, editing test cases, and monitoring expected results, waiting for the call and execution of automated testing software.

[0039] The automated testing system includes a conversion module, a test control module and a fault injection module.

[0040] The conversion module is used to call the test environment parameter file according to a preset strategy and convert the test environment parameter file into a target test case; the test control module adjusts the parameters of the vehicle dynamics model and the test environment model through the bench configuration system according to the target test case, and controls the test execution.

[0041] The fault injection module is used to simulate and inject vehicle hardware faults and vehicle communication faults.

[0042] Specifically, the preset strategy includes: selecting key test variables; based on the key test variables, retrieving a set of related environment parameters and assigning values; setting the increase or decrease of the key test variables, and analogically generating a series of test environment parameter files.

[0043] The key test variables include vehicle speed; the associated environmental parameters include driving operation signals, gear signals, test scenario characteristic parameters and the braking domain controller's own characterization signal.

[0044] When converting a test environment parameter file into a target test case, the file is first imported into Excel and then converted into an automated parameter file using Python. This setup allows the conversion module to flexibly call the test environment parameters (read, write, assign, etc.) written in Excel using a Python-based programming program, enabling data flow with other simulation software, thereby automating the generation of test case files and facilitating subsequent one-click testing.

[0045] Specifically, when converting the test environment parameter file into a target test case, it also includes: based on Excel, signal assignment for basic test operations; the basic test operations include power-on operation, braking operation, and gear shifting operation, and the corresponding signal assignments are step1: keyon = 1; step2: brkstate = 0; step3: VL2RCOM_GearPos = 2.

[0046] When the control test is executed, the test control module first collects the scheduling start signal input by the tester; and controls the power-on of the test bench according to the scheduling start signal; after confirming that the power-on is successful (here, the power-on success is determined based on the characteristic parameter that the motor current value returned after the test bench is powered on is greater than zero), based on the target test case, the braking operation assignment and the gear shifting operation assignment are performed in the vehicle dynamics model, wherein the test control module determines whether the gear shifting is successful based on the motor clamping status information uploaded by the test piece.

[0047] The test control module is also used to monitor test execution and generate a test report after the target test cases have been executed. Specifically, in actual applications, the test control module can operate based on or be integrated into the ECUtest software, effectively invoking ECUtest software functions and further expanding system functionality.

[0048] like Figure 2 As shown, this embodiment also provides a new hardware-in-the-loop testing method for a brake domain controller, which uses the above-mentioned new hardware-in-the-loop testing system for a brake domain controller for testing; the method includes the following steps:

[0049] Step 1: Configure a test system; the test system is a new hardware-in-the-loop test system for a brake domain controller.

[0050] Specifically including: resetting each component of the new hardware-in-the-loop test system.

[0051] Step 2: Build the vehicle dynamics model and test environment model through the test bench configuration system; verify whether there is any fault information in the new hardware-in-the-loop test system. If no fault information exists, proceed to the next step; if fault information exists, generate a warning message and transmit it to the tester, and end the process.

[0052] In step 3, the automated test system generates a target test case, and the test control module adjusts the parameters of the vehicle dynamics model and the test environment model through the test bench configuration system according to the target test case, and controls the test execution.

[0053] Specifically, during the configuration process, the test engineer first assigns and sets the associated environmental parameters (driving operation signals, gear signals, test scenario characteristic parameters and the brake domain controller's own characterization signals) in an Excel list, and comprehensively defines the test scenarios, test cases and expected results, and then verifies the validity of the working status of the device under test; so that the automated test system can use Python programs to call and comprehensively manage the configuration signals, and finally generate an automated execution script package file (automated parameter file).

[0054] During the test, monitor and record the test data until the speed of the vehicle under test decelerates to zero or reaches the maximum test time of this test case; when a single test is completed or exceeds the set maximum time limit (5 minutes), execute the next step.

[0055] Specifically, during the test, VeriStand is used to communicate with the DUT and monitor its input and output in real time. It can record the characteristic parameters of the DUT system (system fault flag, brake switch status, requested braking force, current size, etc.), the simulated vehicle motion status, and the characteristic parameters of the laboratory environment.

[0056] Step 4: End the test.

[0057] Specifically, after the test concludes, the speed of the target vehicle corresponding to the DUT is reset to zero, and test data recording ceases. The test control module then generates a test report and saves it to a specific folder, allowing for subsequent modification and optimization of ECU test parameters based on the test results. In practice, iterative testing can be performed and re-run if necessary to ensure that any corrections are effective.

[0058] This embodiment provides a novel hardware-in-the-loop testing method and system for a brake domain controller, which can complete highly automated HIL testing of the domain controller, meet diverse functional testing requirements, and have low test execution costs.

[0059] Example 2

[0060] A novel hardware-in-the-loop testing method for a brake domain controller is provided. This method is based on the first embodiment, but differs in that the method uses the novel hardware-in-the-loop testing system for a brake domain controller as described in the first embodiment to perform automated dynamic braking function testing. The method comprises the following steps:

[0061] Step 1: Configure a test system; the test system is a new hardware-in-the-loop test system for a brake domain controller.

[0062] Specifically including: resetting each component of the new hardware-in-the-loop test system.

[0063] Step 2: Build the vehicle dynamics model and test environment model through the test bench configuration system; verify whether there is any fault information in the new hardware-in-the-loop test system. If no fault information exists, proceed to the next step; if fault information exists, generate a warning message and transmit it to the tester, and end the process.

[0064] In step 3, the automated test system generates a target test case, and the test control module adjusts the parameters of the vehicle dynamics model and the test environment model through the test bench configuration system according to the target test case, and controls the test execution.

[0065] Taking the audited dynamic braking use case as an example, the key test variable is selected as vehicle speed; based on the key test variable, a set of related environmental parameters are retrieved and assigned; and the increase or decrease of the key test variable is set. Specifically, the key test variables include vehicle speed, road slope and tire friction factors, which can cover various functional scenarios of the braking domain controller. Here, the vehicle speed is set to increase in steps of 1km / h, such as Figure 3 As shown, the increment step is 1 km / h, and 60, 61, 62... are set in sequence; and a series of test environment parameter files are generated by analogy.

[0066] Furthermore, when converting the test environment parameter file into the target test case, the test environment parameter file is first imported into Excel and then converted into an automation parameter file based on the Python language. Specifically, the Python program is used to read the Excel file, and the steps in Excel (power on, set variables, observe variables, power off, etc.) are automatically processed in sequence to generate the automated test case execution file package (target test case) for the next test execution.

[0067] The test control module executes predefined target test cases. At the same time, CarSim simulates the vehicle's dynamic response and sends data to VeriStand. Ultimately, key signal parameters are transmitted back to ECUtest for real-time data monitoring, collection, and analysis.

[0068] Step 4: End the test.

[0069] Specifically, after the test is completed, the speed of the target vehicle corresponding to the tested device is reset to zero, the test process data recording is terminated, and the test control module summarizes and generates a test report. The report includes the execution status of each test case and the pass / fail analysis results of each function of the tested brake domain controller.

[0070] Optionally, iterative testing can be performed based on data feedback and improvement results, further enabling ECUtest, VeriStand, and CarSim to fully leverage their respective strengths for efficient ECU testing and verification, confirming that the performance and stability of the ECU (controller) meet design requirements under different test scenarios.

[0071] This embodiment provides a new hardware-in-the-loop testing method and system for a braking domain controller. The overall process is highly automated, and the setting and execution of use cases are automatically controlled by the automated testing system, which can efficiently complete the dynamic braking function test of the device under test.

[0072] Example 3

[0073] like Figure 5 As shown, a novel hardware-in-the-loop testing method for a brake domain controller is described. Based on the first embodiment, the fault injection module includes a function call unit. The function call unit is used to truncate and reconstruct target data. Specifically, the target data truncates by the function call unit includes the CAN matrix and fault codes of the device under test (i.e., the brake domain controller).

[0074] The function call unit has a preset mapping relationship. After truncating the target data, the function call unit will first identify the target message identifier (target ID) in the CAN matrix or fault code, and call the CAPL function according to the mapping relationship to parse the data, that is, to map the target ID to the target ID, target signal, target value, and obtain a mapping table. In this embodiment, the obtained mapping table is as follows: Figure 4 As shown in the figure, the target ID (ID), target signal (signal name), and target value (value) are then reassigned based on the mapping table (signal name, index) to complete the reconstruction of the target data. For the CAN matrix, during reconstruction, the target ID, target signal, and target value can be tampered with to inject fault information. For fault codes, mapping can be established to enable fault code analysis.

[0075] When the test control module calls the ECUtest software function to control the test execution, the fault injection module sets the fault information or parses the fault code based on the function call unit.

[0076] This embodiment provides a new hardware-in-the-loop testing method and system for brake domain controllers. Compared with the first embodiment, it has a special function call unit. Through the setting of this unit, this solution can, on the basis of calling the ECUtest software to execute the test case, provide the ECUtest software that does not have the signal modification and fault analysis functions with equivalent additional parameter modification and fault code analysis functions, thereby enabling automatic fault injection when executing the test case. Moreover, this solution can be used with the existing ECUtest software, with a low application cost. In addition, this solution can also solve the problem that the analysis of the current domain controller fault code can only be collected by professional equipment, and has strong functionality.

[0077] The above is only an embodiment of the present invention. Common knowledge such as the specific structure and characteristics of the scheme is not described in detail here. Ordinary technicians in the relevant field are aware of all common technical knowledge in the technical field of the invention before the application date or priority date, can obtain all existing technologies in the field, and have the ability to apply conventional experimental means before that date. Ordinary technicians in the relevant field can improve and implement this scheme in combination with their own abilities under the guidance of this application. Some typical well-known structures or well-known methods should not become obstacles for ordinary technicians in the relevant field to implement this application. It should be pointed out that for those skilled in the art, without departing from the structure of the present invention, several variations and improvements can be made, which should also be regarded as the scope of protection of the present invention. These will not affect the effect of the implementation of the present invention and the practicality of the patent.

Claims

1. A new hardware-in-the-loop test system for brake domain controllers, characterized by: Including the device under test, information acquisition system, test bench, bench configuration system and automated test system; The device under test is a brake domain controller. During the test, the device under test establishes a circuit connection with a physical motor and brake, and the physical motor controls the application and release of the brake. The circuit connection adopts a hardware circuit connection method, which supports the implantation of faults through the line, including overcurrent, undercurrent, overvoltage, and undervoltage fault injection. The information acquisition system is used to collect operating data of the physical motor; the information acquisition system includes an information acquisition sensor, which is used to monitor parameters of the physical motor in real time, including voltage, current and temperature, to detect and evaluate the operating status of the physical motor; the physical motor is a motor system, including a motor component, a transmission component, a sensor component and a microcontroller component; The test bench is a HIL test bench and is used to interact with the device under test; the test bench configuration system is used to build a vehicle dynamics model and a test environment model; the test bench configuration system forms a test closed loop through the test bench, the device under test, the physical motor and the brake; The automated test system includes a conversion module and a test control module; the conversion module is used to call the test environment parameter file according to a preset strategy and convert the test environment parameter file into a target test case; The test control module adjusts the parameters of the vehicle dynamics model and the test environment model through the test bench configuration system according to the target test case and controls the test execution; The test control module operates based on or is installed in the ECUtest software; The test system is used to perform automated dynamic brake function testing; The preset strategy includes: selecting key test variables; based on the key test variables, retrieving a set of related environmental parameters and assigning values; setting the increase or decrease of the key test variables and analogically generating a series of test environment parameter files; the key test variables include vehicle speed, road slope, and tire friction factors; The automated control system further comprises a fault injection module; the fault injection module is used to simulate and inject vehicle hardware faults and vehicle communication faults; the fault injection module is provided with a function calling unit; the function calling unit is used to truncate target data and reconstruct the target data; the target data truncated by the function calling unit includes the CAN matrix and fault code of the device under test; a mapping relationship is preset in the function calling unit; after truncation of the target data, the function calling unit first identifies the target message identifier in the CAN matrix or fault code, and calls the CAPL function according to the mapping relationship, parses the data, and obtains a mapping table, and then reassigns values ​​based on the mapping table to complete the reconstruction of the target data; When the test control module controls the test execution, the fault injection module sets the fault information or analyzes the fault code based on the function call unit.

2. A new hardware-in-the-loop test system for a brake domain controller according to claim 1, characterized in that: The key test variables include vehicle speed; the associated environmental parameters include driving operation signals, gear signals, test scenario characteristic parameters and the braking domain controller's own characterization signal.

3. A new hardware-in-the-loop test system for a brake domain controller according to claim 1, characterized in that: When converting the test environment parameter file into a target test case, first import the test environment parameter file into Excel, and then convert it into an automation parameter file based on the Python language.

4. A new hardware-in-the-loop test system for a brake domain controller according to claim 3, characterized in that: When converting the test environment parameter file into a target test case, it also includes: based on Excel, signal assignment for basic test operations; the basic test operations include power-on operation, braking operation, and gear shifting operation, and the corresponding signal assignments are step1: keyon=1; step2: brkstate=0; step3: VL2RCOM_GearPos=2.

5. A new hardware-in-the-loop test system for a brake domain controller according to claim 4, characterized in that: When the control test is executed, the test control module first collects the scheduling start signal input by the tester; and controls the power-on of the test bench according to the scheduling start signal; after confirming that the power-on is successful, the braking operation assignment and the gear shifting operation assignment are performed in the vehicle dynamics model based on the target test case.

6. A new hardware-in-the-loop test system for a brake domain controller according to claim 1, characterized in that: The test control module is also used to detect the test execution status and generate a test report after the target test case is executed.

7. A new hardware-in-the-loop testing method for a brake domain controller, characterized in that: Testing is performed using a new hardware-in-the-loop test system for a brake domain controller according to any one of claims 1 to 6; the test comprises the following steps: Step 1: Configure a test system; the test system is a new hardware-in-the-loop test system for a brake domain controller; Step 2: Build a vehicle dynamics model and a test environment model using the test bench configuration system. Verify whether there is any fault information in the new hardware-in-the-loop test system. If no fault information is found, proceed to the next step. If fault information is found, generate a warning message and send it to the tester, ending the process. Step 3: The automated test system generates a target test case, and the test control module adjusts the parameters of the vehicle dynamics model and the test environment model through the test bench configuration system according to the target test case, and controls the test execution; During the test, monitor and record test data until the speed of the vehicle under test decelerates to zero or reaches the maximum test time of this test case; when a single test is completed or exceeds the set maximum test time, execute the next step; Step 4: End the test.

Images