Novel hardware-in-the-loop test method and system for brake domain controller

Abstract

The invention relates to the technical field of intelligent automobile testing, and discloses a novel hardware-in-the-loop testing method and system for a brake domain controller, and the system comprises a tested piece, an information collection system, a testing rack, a rack configuration system, and an automatic testing system. In the test, the tested piece is in circuit connection with the entity motor and the brake; the information acquisition system is used for acquiring working data of the entity motor; the test bench is used for interacting with a tested piece; the rack configuration system is used for building a vehicle dynamics model and a test environment model; the automatic test system comprises a conversion module and a test control module. The conversion module is used for calling the test environment parameter file according to a preset strategy and converting the test environment parameter file into a target test case; the test control module is used for controlling test execution. According to the invention, highly automatic HIL test of the domain controller can be completed, diversified function test requirements can be met, and the test execution cost is low.

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 brake domain controller. Background Art

[0002] In recent years, the rapid development of Brake Domain Controller (BDC) in the automotive electronics industry has shown a trend of diversification and intelligence. With the advancement of new energy vehicles and autonomous driving technology, the complexity of the braking system has increased significantly, and traditional brake control functions have gradually developed towards integration and intelligence. Modern brake domain controllers not only need to manage braking execution, but also need to coordinate multiple functions such as electric power braking, ABS (anti-lock braking system), ESP (electronic stability program), etc., to achieve more precise control and higher performance through highly integrated design. In this context, in order to verify the function of the brake domain controller, hardware-in-the-loop testing (HIL) technology is often used for functional testing. However, the testing results of existing methods still have a lot of room for improvement.

[0003] First, the interface communication test of the domain controller is a pain point that cannot be ignored. The consistency of the hardware interface and communication protocol must be ensured between the test equipment and the domain controller, otherwise incompatibility will occur during the test. The number of forwarding messages that the domain controller needs to process is as many as 2 to 30 frames, and it is preliminarily estimated that it contains about 1200 to 1500 signals. Such a large number of signals significantly increases the workload of signal consistency compliance testing. Secondly, in the hardware-in-the-loop (HIL) test process, the accuracy and real-time requirements of data acquisition are extremely high. Since the domain controller needs to respond quickly and realize the necessary control functions while processing multiple inputs, this requires that the key sensors in the test system can meet the real-time standards, which puts higher requirements on the design of data sources. In addition, due to the functional coupling of the domain controller, the complexity of the test work increases exponentially. The writing and execution of test cases not only directly leads to an increase in the risk of system functional coverage, but also increases the cycle cost. How to use a systematic approach to effectively simulate various possible application scenarios to verify the functions of the domain controller 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 urgently necessary to establish a new hardware-in-the-loop testing method and system for the brake domain controller to adapt to the characteristics of the multi-functional coupling of today's brake domain controllers and their diversified testing needs 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 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 cost.

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

[0007] Solution 1

[0008] 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;

[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 collection system is used to collect working data of the physical motor;

[0010] The test bench is a HIL bench and is used to interact with the DUT; the bench configuration system is used to build a vehicle dynamics model and a test environment model; the bench configuration system forms a test closed loop through the test bench, the DUT, 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] Solution 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 Scheme 1 for testing; the method comprises the following steps:

[0014] Step 1, configuring 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 through the test bench configuration system; verify whether there is fault information in the new hardware-in-the-loop test system. If there is no fault information, execute the next step; if there is fault information, generate a warning message and send it to the tester, and end 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 bench configuration system according to the target test case, and controls the test execution;

[0017] During the test, monitor and record the test data until the speed of the vehicle under test slows down 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, 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 specially designs a motor information feedback system that can effectively simulate the system's motion state. The introduction of a physical motor to cooperate with the DUT can provide the DUT with more realistic and richer working condition information, which helps 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 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, which is convenient for reproducible hardware fault injection, effectively reproducing the extreme test scenario conditions 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 is specially equipped with an 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 realized 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 test. Applying this solution, an "end-to-end" automated testing process closed loop from requirement files (word, excel) to test cases (Pkg) can be realized. 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 applications.

[0022] Third, the test of this solution incorporates vehicle dynamics simulation and test scenario simulation, providing richer indicator input for hardware-in-the-loop testing. Compared with traditional hardware-in-the-loop testing, this solution can fill the gap of the lack of key parameters of external scene characteristics in the operating conditions of the braking system, effectively alleviate the difficulty of executing extreme condition use cases due to random changes in external conditions in the current real vehicle road test, and improve the effectiveness and efficiency of the test. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0024] Figure 2 A schematic diagram of a method of a novel hardware-in-the-loop test method and system embodiment 1 for a brake domain controller of the present invention;

[0025] Figure 3 It is a schematic diagram of the operation of a conversion module in Embodiment 1 of a novel hardware-in-the-loop testing method and system for a brake domain controller of the present invention;

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

[0027] Figure 5 The present invention is a schematic diagram of index definition of a third embodiment of a novel hardware-in-the-loop testing method and system for a braking domain controller. DETAILED DESCRIPTION

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

[0029] Embodiment 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 device under test is a brake domain controller; during the test, the device under test establishes a circuit connection with the physical motor and the brake, and the physical motor controls the application and release of the brake. The hardware circuit connection method used here supports the implantation of faults through the line, which facilitates the subsequent fault injection test of typical electrical performance (such as overcurrent, undercurrent, overvoltage, undervoltage and other types of fault injection tests).

[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, including a motor component, a transmission component, a sensor component and a microcontroller component. Among them, the motor component adopts 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 component is composed of conventional gears, screws, etc., which are used to convert the rotational motion of the motor component into the linear motion required to clamp or release the brake; the sensor component includes a position sensor (such as a Hall sensor, a photoelectric sensor, etc.) for detecting information such as the position and clamping state of the motor component to ensure accurate control and feedback of the motor system; the microcontroller component is used to receive signals from other controllers (such as ABS or BCM) and control the reverse and clamping / release action of the motor component.

[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 schemes, existing test schemes often use a single controller for testing. This solution is not flexible enough and it is difficult to meet the requirements of dynamic load changes. In addition, the scheme uses a simulation model to replace the actual motor operation. Due to the deep coupling of the control algorithm and 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 criteria, 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, which is 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 bench and is used to interact with the device under test. In this embodiment, the composition structure of the selected HIL bench includes a stable power output module, a multi-channel data acquisition and processing device, and a high-precision sensor, etc., to ensure the stability of data acquisition and transmission during the test. In addition, the bench is equipped with a variety of input / output interfaces, which can be compatible with different types of domain controllers to ensure the versatility of the test.

[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 the verification test 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 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 CarSim's vehicle dynamics model 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 realizes the visual foundation of defining test scenarios, editing test cases and monitoring expected results by coordinating with Labview unit modules, waiting for the call and execution of automated testing software.

[0039] The automated testing system comprises 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 brake domain controller's own characterization signal.

[0044] When converting the test environment parameter file to the target test case, first import the test environment parameter file into Excel, and then convert it into an automation parameter file based on Python language. With this setting, the conversion module can flexibly call the test environment parameters (read, write, assign, etc.) written in the Excel table through the Python language programming program, and realize data circulation with other simulation software, thereby realizing the automatic generation of test case files, which is convenient for the subsequent one-click start of the test.

[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 sent back 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 detect the test execution status and generate a test report after the target test case is executed. Specifically, in practical applications, the test control module can be operated based on the ECUtest software or installed in the ECUtest software, thereby being able to effectively call the ECUtest software functions and further expand the system functionality.

[0048] like Figure 2 As shown, this embodiment also provides a new hardware-in-the-loop test method for a brake domain controller, which uses a new hardware-in-the-loop test system for a brake domain controller as described above for testing; comprising 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 fault information in the new hardware-in-the-loop test system. If there is no fault information, execute the next step; if there is fault information, generate a warning message and send it to the tester, and end the process.

[0052] 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 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 slows down 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 the input and output of the DUT 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.), simulated vehicle motion status, and laboratory environment characteristic parameters.

[0056] Step 4: End the test.

[0057] Specifically, after the test is completed, the speed of the target vehicle corresponding to the DUT is reset to zero, the test process data recording is terminated, and the test control module generates a test report and saves it to a specific folder, so that the ECU test parameters can be modified and optimized according to the test results. In practical applications, iterative testing can be performed and re-tested when necessary to ensure that the correction of the problem is effective.

[0058] The present 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 a low test execution cost.

[0059] Embodiment 2

[0060] A novel hardware-in-the-loop test method for a brake domain controller is based on the first embodiment, and the difference is that a novel hardware-in-the-loop test system for a brake domain controller as described in the first embodiment is used to perform an automated dynamic brake function test; 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 fault information in the new hardware-in-the-loop test system. If there is no fault information, execute the next step; if there is fault information, generate a warning message and send it to the tester, and end the process.

[0064] 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 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; 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 a 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 Excel, and the steps in Excel (power on, set variables, observe variables, power off, etc.) are automatically processed in sequence, thereby generating an automated test case to be executed 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 dynamic response of the vehicle and sends data to VeriStand, which ultimately transmits key signal parameters 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 under test corresponding to the tested part is reset to zero, the test process data recording is terminated, and the test control module summarizes and generates a test report, which includes the execution status of each test case and the pass / fail analysis results of each function of the brake domain controller under test.

[0070] Optionally, iterative testing can be performed based on data feedback and improvement results, which further enables ECUtest, VeriStand, and CarSim to fully leverage their respective strengths to achieve efficient ECU testing and verification, and confirm that the performance and stability of the ECU (controller) meet the 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] Embodiment 3

[0073] like Figure 5 As shown, a new hardware-in-the-loop test method for a brake domain controller is provided. On the basis of the first embodiment, a function calling unit is provided in the fault injection module. The function calling unit is used to truncate the target data and reconstruct the target data. Specifically, the target data truncate by the function calling unit includes the CAN matrix and fault code of the device under test (i.e., the brake domain controller).

[0074] The function calling unit has a preset mapping relationship. After truncating the target data, the function calling 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, 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. Based on the mapping table (signal name, index), the target ID (ID), target signal (signal name), and target value (value) are reassigned to complete the reconstruction of the target data. For the CAN matrix, during the reconstruction, the target ID, target signal, and target value can be tampered with as fault information to achieve fault injection; for the fault code, the fault code can be parsed through mapping.

[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 analyzes the fault code based on the function calling unit.

[0076] This embodiment provides a new hardware-in-the-loop test method and system for brake domain controllers. Compared with the first embodiment, a function calling unit is specially provided. Through the setting of this unit, this solution can add equivalent parameter modification and fault code analysis functions to ECUtest software that does not have signal modification and fault analysis functions on the basis of calling ECUtest software to execute test cases, thereby realizing automatic fault injection when executing test cases. Moreover, this solution can be used with existing ECUtest software, and the application cost is relatively low. 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. The common sense such as the known specific structure and characteristics in the scheme is not described in detail here. The ordinary technicians in the relevant field are aware of all the common technical knowledge in the technical field of the invention before the application date or priority date, can obtain all the existing technologies in the field, and have the ability to apply the conventional experimental means before that date. The ordinary technicians in the relevant field can improve and implement the scheme in combination with their own abilities under the enlightenment given by this application. Some typical known structures or known methods should not become obstacles for the ordinary technicians in the relevant field to implement this application. It should be pointed out that for the technicians in this field, without departing from the structure of the present invention, several deformations and improvements can be made, which should also be regarded as the protection scope of the present invention, and 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 controller, characterized in that: 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 a brake, and the physical motor controls the application and release of the brake; the information collection system is used to collect working data of the physical motor; The test bench is a HIL bench and is used to interact with the DUT; the bench configuration system is used to build a vehicle dynamics model and a test environment model; the bench configuration system forms a test closed loop through the test bench, the DUT, 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.

2. A new hardware-in-the-loop test system for a brake domain controller according to claim 1, characterized in that: The automatic control system also includes a fault injection module; the fault injection module is used to simulate and inject vehicle hardware faults and vehicle communication faults.

3. A new hardware-in-the-loop test system for a brake domain controller according to claim 1, characterized in that: The preset strategy includes: selecting key test variables; based on the key test variables, retrieving a set of associated 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.

4. A new hardware-in-the-loop test system for a brake domain controller according to claim 3, 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 brake domain controller's own characterization signal.

5. 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.

6. A new hardware-in-the-loop test system for a brake domain controller according to claim 5, 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.

7. A new hardware-in-the-loop test system for a brake domain controller according to claim 6, 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.

8. The novel hardware-in-the-loop test system for a brake domain controller according to claim 1 is 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.

9. A new hardware-in-the-loop testing method for a brake domain controller, characterized in that: The test is performed using a new hardware-in-the-loop test system for a brake domain controller as described in any one of claims 1 to 8; the test comprises the following steps: Step 1, configuring 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 through the test bench configuration system; verify whether there is fault information in the new hardware-in-the-loop test system. If there is no fault information, execute the next step; if there is fault information, generate a warning message and send it to the tester, and end 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 bench configuration system according to the target test case, and controls the test execution; During the test, monitor and record the test data until the speed of the vehicle under test slows down 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, execute the next step; Step 4: End the test.

Images