An EMB test method based on whole vehicle road working condition

Abstract

This invention relates to the field of vehicle inspection and testing technology, and specifically to an EMB testing method based on full-vehicle road conditions. The method involves obtaining EMB testing requirements and generating test cases containing trigger conditions, safety boundaries, and evaluation metrics. These test cases are then sent to a test vehicle equipped with the EMB system to be tested. The test vehicle performs EMB testing based on the test cases, and a preset fault is injected into the EMB system after the trigger conditions are met during vehicle operation. Test operation data after fault injection is collected, and the preset fault is deactivated after a preset time. Evaluation metrics for the test vehicle are determined based on the test operation data. This solution can inject faults during real-world road operation, simulating the inertial and dynamic loads of a vehicle suddenly encountering brake failure, which is difficult to simulate with traditional bench testing. It can also capture changes in vehicle attitude during braking failure at the moment of turning, bumping, or high-speed driving.

Description

Technical Field

[0001] This manual relates to the field of vehicle inspection and testing technology, and in particular to an EMB test method based on the road conditions of a whole vehicle. Background Technology

[0002] Against the backdrop of rapid iteration in intelligent electric vehicle technology, the Electronic Mechanical Braking (EMB) system, as the ultimate form of brake-by-wire technology, has become a key research and development area in the industry due to its disruptive architecture that eliminates hydraulic lines and enables the motor to directly drive the brake caliper, exhibiting significant advantages such as fast response speed, high control precision, and easy integration into autonomous driving.

[0003] Currently, real-world road testing of EMB systems suffers from several shortcomings. At the scenario level, test cases rely on manual judgment of trigger timing, leading to significant fluctuations in key parameters such as vehicle speed and pedal rate within the same scenario, resulting in poor data comparability. At the execution level, there is a lack of a real-time control closed loop linked to the vehicle's dynamics. At the data level, data acquisition, storage, and analysis utilize separate tools, resulting in time-consuming data fusion and analysis. These deficiencies cause EMB systems to heavily rely on experience accumulation and repeated trial and error for braking performance verification, control strategy iteration, and safety boundary confirmation, making it difficult to meet the stringent requirements of advanced autonomous driving for rapid response and precise execution of braking systems.

[0004] Therefore, this specification provides an EMB testing method based on full-vehicle road conditions. Summary of the Invention

[0005] This specification provides an EMB testing method based on full vehicle road conditions to partially solve the aforementioned problems existing in the prior art.

[0006] The following technical solution is adopted in this specification: This manual provides an EMB testing method based on full-vehicle road conditions, including: S1. Obtain EMB testing requirements and generate test cases that include trigger conditions, security boundaries, and evaluation metrics; S2. Send the test cases to the test vehicle that has the EMB system to be tested installed; S3. The test vehicle performs EMB testing based on the test cases, and injects a preset fault into the EMB system after the triggering conditions are met during the operation of the test vehicle. S4. Collect the test operation data after the fault injection of the test vehicle, and remove the preset fault after a preset time; S5. Based on the test operation data, determine the evaluation indicators for the test vehicle.

[0007] Based on the aforementioned technical means, this solution can inject faults into real road operation, simulating the inertial and dynamic loads of a vehicle suddenly encountering braking failure, which is difficult to simulate in traditional bench testing. It can capture the vehicle's attitude changes at the moment of braking failure during cornering, bumps, or high-speed driving—something bench simulation cannot fully reproduce. By collecting operational data after fault injection, it is possible to realistically verify whether the EMB system can switch to a backup strategy instantly. A closed-loop "fault injection-recovery" mechanism is implemented, ensuring test safety and efficiency, preventing dangerous situations caused by prolonged loss of braking capability, and enabling high-risk failure tests to be conducted on open or closed roads. It can completely record transient data throughout the entire process from "normal state → fault outbreak → degraded control → fault recovery," which is crucial for analyzing the impact and stability during system recovery—something static testing cannot obtain. Real road test data is more convincing than pure simulation or bench data and can directly support functional safety certification. It can discover coupling defects between the EMB system and other systems such as suspension and tires under extreme failure conditions, which is difficult to exhaustively detect with pure software simulation.

[0008] Furthermore, S2 also includes S21: The hydraulic braking system of the test vehicle is shielded by a reversible hydraulic shielding device.

[0009] Furthermore, the EMB system includes disc EMB actuators for all four wheels of the test vehicle.

[0010] Furthermore, the preset fault is the failure of a single wheel of the test vehicle.

[0011] Furthermore, the evaluation indicators include at least fault diagnosis time, braking force redistribution response time, peak vehicle yaw rate, and residual braking efficiency.

[0012] Furthermore, the test run data includes the time intervals at which the controller of the EMB system issues fault codes; S5 specifically includes: The fault diagnosis time is determined based on the time interval at which the controller of the EMB system issues fault codes.

[0013] Furthermore, S5 specifically includes: From the test operation data, the moment when the controller of the EMB system issued a fault code is determined as the fault initiation moment, and the moment when the motor current of the non-failed wheel of the test vehicle rises is determined as the braking force distribution moment. The braking force redistribution response time is determined based on the fault initiation time and the braking force distribution time.

[0014] Furthermore, S5 specifically includes: From the test run data, determine the yaw rate data of the test vehicle collected by the IMU; Based on the yaw rate data, the peak yaw rate of the test vehicle is determined.

[0015] Furthermore, S5 specifically includes: From the test run data, determine the actual vehicle deceleration after the braking force is redistributed; The percentage of the actual vehicle deceleration to the target deceleration of the test vehicle under the same operating conditions without faults is calculated as the remaining braking efficiency of the test vehicle.

[0016] Furthermore, S1 generates test cases that include triggering conditions, security boundaries, and evaluation metrics, specifically including: Obtain environmental data from the test site; Based on the EMB testing requirements and the environmental data, test cases containing trigger conditions, security boundaries, and evaluation metrics are generated.

[0017] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects: This solution can inject faults into real-world road conditions, simulating the inertial and dynamic loads of a vehicle suddenly experiencing braking failure, which is difficult to replicate using traditional bench testing. It can capture the vehicle's attitude changes at the moment of braking failure during cornering, bumps, or high-speed driving—something bench simulation cannot fully reproduce. By collecting operational data after fault injection, it can realistically verify whether the EMB system can switch to a backup strategy instantly. It implements a closed-loop "fault injection-recovery" mechanism, ensuring test safety and efficiency, preventing dangerous situations caused by prolonged loss of braking capability, and enabling high-risk failure tests to be conducted on open or closed roads. It can completely record transient data throughout the entire process from "normal state → fault outbreak → degraded control → fault recovery," which is crucial for analyzing the impact and stability during system recovery—data that static testing cannot obtain. Real-world road test data is more convincing than pure simulation or bench data and can directly support functional safety certification. It can discover coupling defects between the EMB system and other systems such as suspension and tires under extreme failure conditions, which is difficult to exhaustively detect with pure software simulation. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings: Figure 1 A flowchart illustrating an EMB testing method based on full-vehicle road conditions, provided as an embodiment of this specification; Figure 2 This manual provides a schematic diagram of a test vehicle. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort are within the scope of protection of this application.

[0020] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0021] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0022] Figure 1 A flowchart illustrating an EMB testing method based on full-vehicle road conditions, provided for embodiments of this specification, includes the following steps: S1: Obtain EMB testing requirements and generate test cases that include trigger conditions, security boundaries, and evaluation metrics.

[0023] S2: Send the test cases to the test vehicle that has the EMB system to be tested installed.

[0024] This specification describes the process of performing EMB testing based on full-vehicle road conditions. In the embodiments described herein, this EMB testing process can be executed by a server. However, this specification does not limit the type of device or platform used to perform the EMB testing process based on full-vehicle road conditions; for example, a personal computer, mobile terminal, or other such device or platform can also be used. For ease of description, the following description uses a server as the execution entity.

[0025] In one or more embodiments of this specification, the server can obtain EMB testing requirements and generate test cases that include triggering conditions, safety boundaries, and evaluation metrics. For example, triggering conditions could be the vehicle speed reached, the pedal displacement reached, or the duration of maintaining that speed before triggering fault injection. Safety boundaries could be the maximum speed allowed, the maximum yaw rate allowed, etc.

[0026] Test cases can be wirelessly transmitted directly to the test vehicle, which is already equipped with the EMB system under test. Furthermore, to ensure both testing the EMB system and safety, the test vehicle has undergone special treatment. A reversible hydraulic shielding device is used to disable the vehicle's hydraulic braking system. This operation prevents the original hydraulic braking system from participating in braking, serving only as a safety backup, thus achieving a pure EMB braking mode. The EMB system under test may include disc EMB actuators on all four wheels of the test vehicle. Disc EMB actuators are installed on all four wheels of the test vehicle. After installation, calibration of all four wheels is required.

[0027] S3: The test vehicle performs EMB testing based on the test case, and injects a preset fault into the EMB system after the triggering condition is met during the operation of the test vehicle.

[0028] In one or more embodiments of this specification, the test vehicle is located on a closed test road for EMB testing. Upon receiving a test case, the test vehicle can enter a driving state according to the test case. If the test vehicle is an autonomous vehicle, it can automatically perform EMB testing according to the test case, such as driving on the test road according to the driving requirements specified in the test case. If the test vehicle is driven by a driver, the driver can drive on the test road according to the driving requirements specified in the test case, which can be displayed to the driver through a central control display, head-up display, etc.

[0029] When the test vehicle meets the trigger conditions in the test case during operation, such as the test vehicle traveling at a constant speed of 60 km / h in a straight line, and the driver depressing the brake pedal at a rate of approximately 150 mm / s to a travel of 40 mm, with a target deceleration of 0.4g, the fault injection timing is set to 1 second after the pedal displacement exceeds 30 mm. This ensures that the braking state is stable before injecting the fault. Therefore, once the brake pedal sensor detects that the brake pedal has been depressed for more than 30 mm, and the time is greater than 1 second, the trigger condition is met, and a preset fault is automatically injected into the EMB system. It is worth noting that this preset fault can be either included in the test case or pre-set in the test vehicle.

[0030] The preset fault can be the failure of a wheel of the test vehicle, including the failure of a single wheel or multiple wheels. The power supply to the motor of the wheel that needs to fail is disconnected to simulate an open circuit fault.

[0031] It is worth noting that when performing fault injection, the person in charge of the test must sign electronically, the safety officer must be on board, and it must be confirmed that the dual redundant power supply and hydraulic backup are self-testing and ready before the fault injection can be performed. It must also be confirmed that the disconnection resistance of the motor power relay of the faulty wheel is greater than 10 MΩ.

[0032] S4: Collect the test operation data after the fault injection of the test vehicle, and remove the preset fault after a preset time.

[0033] In one or more embodiments of this specification, the test operation data of the test vehicle after fault injection will be detected and collected by the test vehicle itself and various sensors on the test vehicle, and the test operation data can be sent to the server for processing. Of course, the test vehicle will not maintain fault injection indefinitely. After a preset time, the preset fault injected into the test vehicle will be removed, allowing the test vehicle to return to normal.

[0034] In this manual, test operation data can be acquired through full-channel 1000 Hz sampling with a time synchronization accuracy of less than 100 ns.

[0035] S5: Determine the evaluation indicators for the test vehicle based on the test operation data.

[0036] In one or more embodiments of this specification, the server can determine the evaluation metrics of the test vehicle based on the test operation data of the test vehicle. These evaluation metrics correspond to the evaluation metrics in the test cases.

[0037] The evaluation indicators include at least fault diagnosis time, braking force redistribution response time, peak vehicle yaw rate, and residual braking efficiency.

[0038] Test run data may include the time interval between fault codes issued by the EMB system controller. The server then determines the fault diagnosis time based on the time interval between fault codes issued by the EMB system controller. For example, the EMB system controller (such as an ECU, i.e., Electronic Control Unit) should detect current abnormalities and issue a fault code within 10 ms.

[0039] The server can also determine the moment when the EMB system controller issues a fault code from the test run data, as the fault initiation moment, and the moment when the motor current of the non-failed wheels of the test vehicle rises, as the braking force distribution moment. Based on the fault initiation moment and the braking force distribution moment, the braking force redistribution response time is determined, which is the time interval from when the fault is confirmed by the EMB system controller to when the VDC (Vehicle Dynamics Control) executes the braking force redistribution and the other non-failed wheels begin to compensate for braking force.

[0040] The server can also determine the yaw rate data of the test vehicle collected by the IMU (Inertial Measurement Unit) from the test run data. Based on the yaw rate data, the peak yaw rate of the test vehicle can be determined.

[0041] The server can also determine the actual vehicle deceleration after the braking force redistribution from the test run data. Then, it calculates the percentage of the actual vehicle deceleration to the target deceleration of the test vehicle under the same fault-free operating conditions, as the remaining braking performance of the test vehicle.

[0042] Furthermore, in one or more embodiments of this specification, the server may also acquire environmental data of the test site. Based on the EMB testing requirements and the environmental data, test cases containing triggering conditions, security boundaries, and evaluation metrics are then generated.

[0043] Under different environmental conditions, the triggering conditions and safety boundaries for the same test requirements may need to be changed. For example, if the test is conducted on an 800-m straight asphalt road section in a closed test field, with a measured road surface adhesion coefficient of 0.82, an ambient temperature of 22 ℃, and a lateral wind speed of less than 2 m / s, and the "standard dry road surface" conditions are met based on the above environmental data, then the triggering conditions for normal testing will be determined. If the road conditions indicated by the Ministry of Environmental Protection's data are severe, then the triggering conditions need to be adjusted to adapt to the extreme environment with severe road conditions.

[0044] In one or more embodiments of this specification, the server may employ an EMB testing toolchain for EMB testing. This EMB toolchain may include a host monitoring module, a real-time control module, an execution module, a sensor measurement module, and a communication module.

[0045] The supervisory control module is used to configure test cases, distribute test case parameters, monitor test status, and visualize and manage test execution data. This module allows for unified scheduling of the test process through a human-computer interface, enabling rapid switching of test modes according to different testing needs, and real-time display of key status parameters, providing test personnel with intuitive operation and monitoring methods.

[0046] The real-time control module can establish data interaction with the EMB controller or actuator under test through the high-speed communication interface of the communication module. It can send test cases to the test vehicle and perform tasks such as fault injection control, automated execution of test processes, and generation of various trigger signals.

[0047] The execution module mainly includes a power supply module and the EMB actuator under test. For component-level testing, it can provide a stable power input to a single EMB actuator and support actions such as target clamping force loading, release, and repetitive cycles. For vehicle-level testing, it is necessary to complete the connection between the EMB system and the vehicle power supply, chassis controller, and wheel-end actuators to ensure that braking commands can be accurately executed during road testing. Considering the instantaneous high current demand of the EMB system under heavy load conditions, the power supply module has sufficient power margin and voltage stability capability, and also has undervoltage, overvoltage, and short-circuit protection functions to meet the testing requirements under extreme braking and fault conditions.

[0048] Sensor measurement modules are used to collect key physical quantities during the testing process and are the direct source of objective evaluation data. For component-level bench tests, clamping force sensors, current sensors, voltage sensors, displacement sensors, temperature sensors, and necessary speed measurement devices are configured. For vehicle-level tests, vehicle speed sensors, wheel speed sensors, brake pedal displacement or pedal force sensors, deceleration sensors, inertial measurement units, etc., are configured to support the comprehensive evaluation of braking performance, driving stability, and fault controllability.

[0049] The communication module primarily enables information exchange between modules and protects the testing process. During EMB testing, a large amount of status information and control commands rely on CAN bus transmission. Therefore, this module is configured with a stable CAN communication interface and, in conjunction with RapidECU, constructs a controller communication and calibration channel. This channel is used to read controller messages and internal variables, issue test commands, perform parameter calibration, and monitor the bus operating status in real time, ensuring the stability of the communication link and the accuracy of data exchange during testing.

[0050] In one or more embodiments of this specification, a fiber optic gyroscope IMU can be used to replace a conventional MEMS (Micro-electromechanical Systems), achieving a yaw rate accuracy of 0.01° / s (bench-level). A laser Doppler velocimeter is used to calibrate wheel speed, eliminating tire slippage errors. A six-component wheel hub sensor is used to directly measure the tire-ground force to verify the braking force distribution algorithm.

[0051] Figure 2 This manual provides a schematic diagram of a test vehicle. (For example...) Figure 2As shown, various sensors, such as pressure sensors, wheel speed sensors, IMUs, steering wheel angle sensors, and brake pedal sensors, are installed in different locations on the test vehicle, including the front compartment, trunk, and roof. The test vehicle also includes a perception domain controller, an EMB motor controller, a vehicle controller, data acquisition equipment, and a power management module.

[0052] Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0053] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0054] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0055] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0056] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0057] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0058] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0059] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0060] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0061] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0062] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0063] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic or disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0064] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0065] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0066] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0067] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0068] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. An EMB testing method based on whole vehicle road conditions, characterized in that, include: S1. Obtain EMB testing requirements and generate test cases that include trigger conditions, security boundaries, and evaluation metrics; S2. Send the test cases to the test vehicle that has the EMB system to be tested installed; S3. The test vehicle performs EMB testing based on the test case, and injects a preset fault into the EMB system after the triggering condition is met during the operation of the test vehicle. S4. Collect the test operation data after the fault injection of the test vehicle, and remove the preset fault after a preset time; S5. Based on the test operation data, determine the evaluation indicators for the test vehicle.

2. The EMB testing method based on whole vehicle road conditions as described in claim 1, characterized in that, S2 also includes S21: The hydraulic braking system of the test vehicle is shielded by a reversible hydraulic shielding device.

3. The EMB testing method based on whole vehicle road conditions as described in claim 1, characterized in that, The EMB system includes disc-type EMB actuators for all four wheels of the test vehicle.

4. The EMB testing method based on whole vehicle road conditions as described in claim 3, characterized in that, The preset fault is the failure of a single wheel of the test vehicle.

5. The EMB testing method based on whole vehicle road conditions as described in claim 1, characterized in that, The evaluation indicators include at least fault diagnosis time, braking force redistribution response time, peak vehicle yaw rate, and residual braking efficiency.

6. The EMB testing method based on whole vehicle road conditions as described in claim 5, characterized in that, The test run data includes the time intervals at which the EMB system's controller issues fault codes; S5 specifically includes: The fault diagnosis time is determined based on the time interval at which the controller of the EMB system issues fault codes.

7. The EMB testing method based on whole vehicle road conditions as described in claim 5, characterized in that, S5 specifically includes: From the test operation data, the time when the controller of the EMB system issued a fault code is determined as the fault initiation time, and the time when the motor current of the non-failed wheel of the test vehicle rises is determined as the braking force distribution time. The braking force redistribution response time is determined based on the fault initiation time and the braking force distribution time.

8. The EMB testing method based on whole vehicle road conditions as described in claim 5, characterized in that, S5 specifically includes: From the test run data, determine the yaw rate data of the test vehicle collected by the IMU; Based on the yaw rate data, the peak yaw rate of the test vehicle is determined.

9. The EMB testing method based on whole vehicle road conditions as described in claim 5, characterized in that, S5 specifically includes: From the test run data, determine the actual vehicle deceleration after the braking force is redistributed; The percentage of the actual vehicle deceleration to the target deceleration of the test vehicle under the same operating conditions without faults is calculated as the remaining braking efficiency of the test vehicle.

10. The EMB testing method based on whole vehicle road conditions as described in claim 1, characterized in that, S1 generates test cases that include triggering conditions, security boundaries, and evaluation metrics, specifically including: Obtain environmental data from the test site; Based on the EMB testing requirements and the environmental data, test cases containing trigger conditions, security boundaries, and evaluation metrics are generated.

Images