A vehicle testing method and apparatus
By constructing a vehicle dynamics model and a hardware-in-the-loop testing platform, combined with a fault mode library, the problems of long testing cycles, high costs, and low reliability in traditional real-vehicle testing are solved, achieving efficient, low-cost, and reliable fault simulation applicable to multiple environments.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ANHUI UNIV OF SCI & TECH
- Filing Date
- 2025-09-25
- Publication Date
- 2026-06-02
AI Technical Summary
Traditional real-vehicle testing is time-consuming and inefficient, while extreme failure testing is costly and lacks reliability.
A vehicle dynamics model and a hardware-in-the-loop testing platform are constructed. The core components of the vehicle and the data acquisition system are synchronized through the TSN protocol. Fault types are injected and fault propagation is simulated. A fault mode library is used to realize realistic fault simulation.
It enables efficient and low-cost vehicle testing, is applicable to multiple environments, and does not damage the vehicle during fault testing, thus improving test reliability.
Smart Images
Figure CN121207565B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of vehicle testing, and in particular to a vehicle testing method and apparatus. Background Technology
[0002] With the rapid development of new energy vehicles, automotive products are being updated and replaced more and more frequently. Each update requires testing of the new product. Traditional real vehicle testing needs to be carried out in closed venues or on roads. Testing in various environmental scenarios requires going to different test sites and different seasons, so the testing cycle is long and inefficient.
[0003] In addition, for fault testing, such as extreme fault scenarios like complete failure of the motor controller during high-speed driving or double front tire blowout, real vehicle fault testing would result in vehicle damage and high testing costs. If pure virtual simulation testing is used, the reliability of the test results is not high. Summary of the Invention
[0004] To address the aforementioned problems, this invention provides a vehicle testing solution that is highly efficient, low-cost, and reliable.
[0005] To achieve the above objectives, the present invention provides a vehicle testing method, comprising: acquiring hardware parameters of a vehicle under test; constructing a vehicle dynamics model based on the hardware parameters; constructing a fault mode library for the vehicle under test, the fault mode library including fault types, triggering conditions, and propagation logic between various faults; constructing a hardware-in-the-loop testing platform, the hardware-in-the-loop testing platform including vehicle core components, environmental simulation equipment, and a data acquisition system, and synchronizing the time of the vehicle dynamics model, vehicle core components, and data acquisition system via the TSN protocol; testing the vehicle under test in the hardware-in-the-loop testing platform, and when the triggering conditions are met, injecting the corresponding fault type into the vehicle dynamics model, the vehicle dynamics model generating a fault propagation sequence and fault response based on the fault type and propagation logic and sending them to the vehicle core components, and collecting data on the vehicle core components' response through the data acquisition system; and analyzing the data to obtain test results.
[0006] Optionally, constructing the vehicle dynamics model based on the hardware parameters includes: constructing a vehicle subsystem model using multibody dynamics software based on the hardware parameters, wherein the subsystem model includes a body model, a suspension model, a tire model, a powertrain system model, a braking system model, and a steering system model; associating the interfaces of the subsystem models, including associating the suspension with the body, the powertrain with the body, and the braking / steering system with the body; and configuring the multibody dynamics solver in the vehicle dynamics model.
[0007] Optionally, a fault mode library for the vehicle under test is constructed, including: acquiring fault data sources for the fault mode library; classifying the fault data sources to determine fault types; quantifying the feature parameters of all fault types; and determining the triggering conditions for the faults, including operating condition triggering, time triggering, and event triggering.
[0008] Optionally, the characteristic parameters of all fault types are quantified, including: determining the characteristic parameters corresponding to the fault type; and establishing a mapping model between the characteristic parameters and the physical signals of the real vehicle to ensure the physical consistency between virtual faults and real faults.
[0009] Optionally, a mapping model between the characteristic parameters and the physical signals of the actual vehicle is established, including:
[0010] The mapping model between torque decay rate and motor output torque is as follows:
[0011]
[0012] in, This is the actual output torque. To provide the rated output torque, Torque attenuation rate, This is the speed correction factor;
[0013] The mapping model between the pressure drop rate and the brake wheel cylinder pressure is as follows:
[0014]
[0015] in, For the pressure of the present moment, The initial pressure of the wheel cylinder, rate of pressure drop Duration of the fault This is the position correction factor;
[0016] The mapping model between the deviation ratio and the acquired voltage signal is as follows:
[0017]
[0018] in, This indicates the voltage collected by the BMS. Indicates the actual voltage of the battery cell. Indicates the deviation ratio. This represents random noise.
[0019] Optionally, the operating condition triggering includes: determining a combination of trigger fault types; determining the trigger threshold for each fault type and the triggering logic relationship between each fault type; and triggering fault simulation when the vehicle condition meets the trigger threshold and the triggering logic relationship.
[0020] Optionally, the method for determining the propagation logic is as follows: determining the propagation path based on the physical signal correlation of the vehicle, including the primary propagation path and the secondary propagation path; determining the delay time of fault propagation based on the signal transmission speed, ECU response time, and physical process time; determining the degree of influence between faults; and setting propagation termination conditions to avoid unlimited propagation.
[0021] Optionally, the vehicle under test is tested in the hardware-in-the-loop test platform, including: controlling the vehicle dynamics model to simulate the set road conditions, driving the vehicle with a virtual driver, and transmitting the simulation data to the vehicle's core components; when the vehicle meets the fault triggering conditions, injecting fault data from the fault mode library, and collecting data from the vehicle's core components through the data acquisition system; triggering other faults according to the propagation logic between faults, injecting fault data, and collecting data from the vehicle's core components through the data acquisition system.
[0022] On the other hand, the present invention also provides a vehicle testing device, comprising: an acquisition unit for acquiring hardware parameters of a vehicle under test; a first construction unit for constructing a vehicle dynamics model based on the hardware parameters; a second construction unit for constructing a fault mode library for the vehicle under test, the fault mode library including fault types, triggering conditions, and propagation logic between various faults; a third construction unit for constructing a hardware-in-the-loop testing platform, the hardware-in-the-loop testing platform including vehicle core components, environmental simulation equipment, and a data acquisition system, and synchronizing the time of the vehicle dynamics model, vehicle core components, and data acquisition system through the TSN protocol; a testing unit for testing the vehicle under test in the hardware-in-the-loop testing platform, injecting a corresponding fault type into the vehicle dynamics model when the triggering conditions are met, the vehicle dynamics model generating a fault propagation timing sequence and fault response based on the fault type and propagation logic and sending them to the vehicle core components, and collecting data after the vehicle core components react through the data acquisition system; and an analysis unit for analyzing the data to obtain test results.
[0023] The advantages of this invention over the prior art are as follows: This testing method combines a vehicle dynamics model with a hardware-in-the-loop testing platform, which is not only applicable to different environments, but also has a short testing cycle and high efficiency. Furthermore, the fault testing will not damage the vehicle and has low testing costs. In addition, by constructing a fault mode library with propagation function, fault simulation that conforms to real vehicle conditions is realized, which improves the reliability of the test. Attached Figure Description
[0024] Figure 1 This is a flowchart of a vehicle testing method provided by the present invention;
[0025] Figure 2This is a flowchart of the process for constructing a fault mode library for a vehicle under test, provided by the present invention.
[0026] Figure 3 This is a structural diagram of a vehicle testing device provided by the present invention. Detailed Implementation
[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.
[0028] Reference Figure 1 This embodiment provides a vehicle testing method, including the following steps:
[0029] S10: Obtain the hardware parameters of the vehicle under test.
[0030] Specifically, in this embodiment, taking a new energy vehicle as an example, the parameters of the target vehicle collected include geometric parameters such as body size (length × width × height), curb weight, and wheelbase, as well as parameters of the power system such as motor power / torque and battery capacity, parameters of the braking system such as brake master cylinder diameter and pipeline length, and parameters of the steering system such as steering ratio and power assist motor. The above parameters can be obtained by measuring the actual vehicle or determined by the specifications.
[0031] It should also be noted that the parameters listed above are only the core parameters collected. Other vehicle parameters, such as tire parameters and other motor parameters, are described in detail in this embodiment.
[0032] S20: Construct a vehicle dynamics model based on the hardware parameters.
[0033] In this embodiment, a model is constructed based on multibody dynamics software (such as ADAMS and SIMPACK) according to the "component-subsystem" hierarchy to reconstruct the physical behavior of each system.
[0034] Specifically, this involves building a vehicle body model. First, the vehicle's CAD model is imported, retaining the load-bearing structures such as the frame and chassis, while simplifying non-load-bearing components such as interior trim and decorative parts, balancing accuracy and computational efficiency. Second, material values for the body are assigned according to requirements. Finally, the rigid and flexible structures are processed accordingly to ensure that the deformation of the body under stress (such as steering roll and braking pitch) is consistent with the actual vehicle, providing a stable installation foundation for other subsystems.
[0035] Building the suspension model involves assembling components such as the lower control arm, springs, shock absorbers, and steering knuckles according to the actual vehicle structure, and defining the geometric dimensions and physical parameters (stiffness, damping) of each component. Next, based on the mechanical connections of the actual vehicle (such as ball joints and bushings), constraints are added to the model (allowing rotation, restricting translation, etc.) to simulate the motion trajectory of the wheels during bouncing (such as changes in camber and toe angles). Finally, referring to real vehicle suspension test data, the spring stiffness and shock absorber damping are adjusted to ensure that the bouncing characteristics of the virtual suspension (such as wheel travel and roll gradient) match those of the real vehicle. This ensures that the suspension filters road bumps and controls the vehicle's attitude during simulated vehicle operation, providing stable contact conditions for the tires.
[0036] The tire model construction involves using commonly used engineering tire models (such as the Pacejka Magic Formula and the UA Tire model), based on "empirical formulas + experimental data," to describe the mechanical characteristics of the tire under different working conditions. Then, tire dynamics test data (such as lateral stiffness, self-aligning torque, and rolling resistance) are imported, and model coefficients are fitted to ensure accurate calculation of tire grip under different slip ratios, sideslip angles, and vertical loads. Finally, environmental adaptation settings are implemented to support dynamic adjustment of the road adhesion coefficient, simulating the impact of different road surfaces (dry, wet, and icy) on tire grip.
[0037] The process of building a dynamic system model includes constructing hydraulic / pneumatic models of the master cylinder, pipelines, wheel cylinders, and ESP controller, defining pressure transmission paths and losses (such as pipeline friction and leakage); then, based on wheel cylinder pressure, brake pad friction coefficient, and brake disc area, the wheel braking force is calculated, and combined with ABS / ESP control logic, such as slip ratio control and pressure regulation, the braking process is simulated.
[0038] Building a steering system model involves constructing components such as the steering wheel, steering column, steering gear, and tie rods, defining the steering gear ratio and clearance, and simulating the mechanical transmission of steering force. Then, the control strategy of the power steering motor is imported, such as the mapping relationship between vehicle speed, steering angle, and power steering torque, to simulate the power steering effect under different working conditions (such as light steering at low speed and stable steering at high speed).
[0039] After constructing the complete vehicle model, the subsystem models need to be linked according to the actual vehicle logic to form a complete digital twin model of the vehicle. First, the interfaces of the subsystem models are linked, including the connection between the suspension and the body, the powertrain and the body, and the braking / steering system and the body. Then, the vehicle controller (VCU) model is constructed as the signal center to receive driver operation signals, such as accelerator, brake, and steering, and issue instructions to each subsystem according to the actual vehicle control logic (such as motor torque requests and brake pressure requests). Finally, the multibody dynamics solver in the vehicle dynamics model is configured, including selecting a multibody dynamics solver such as ADAMS / Dynamic or SIMPACK / Solver, and then setting the time step. A larger step size (such as 10ms) is used for normal operating conditions to balance efficiency and accuracy, while a smaller step size (such as 1ms) is used for dynamic scenarios such as fault injection and emergency braking to avoid losing details.
[0040] S30: Construct a fault mode library for the vehicle under test. The fault mode library includes fault types, triggering conditions, and propagation logic between each fault.
[0041] In this embodiment, the fault mode library is used to inject fault data into the vehicle dynamics model during testing. For example... Figure 2 The aforementioned step S30 specifically includes the following steps:
[0042] S301: Obtain the fault data source of the fault mode library; it should be noted that the fault data source can be obtained through various channels, such as historical data from the R&D department of the car company, parts suppliers, or FMEA reports, etc. The main contents include fault type, failure mechanism, impact consequences, etc.
[0043] S302: Classify the fault data source to determine the fault type; In this embodiment, a three-level classification method of "system-component-fault type" is adopted to structure the faults and ensure that each fault is uniquely identifiable. The system classification includes power system, braking system, steering system, electronic and electrical system, etc.; the component classification refers to the subdivision of core components under each system, such as "motor controller, power battery, engine" under the power system; the fault type refers to the definition of specific faults under each component, such as IGBT open circuit, hydraulic leakage, insufficient torque output, etc.
[0044] S303: Quantify the characteristic parameters of all fault types; First, determine the characteristic parameters corresponding to the fault type. It should be noted that the mapping between characteristic parameters and physical signals is the core link connecting "virtual fault configuration" and "real hardware response." Its essence is to transform adjustable abstract parameters into physical signals that can be perceived and executed by real vehicle components, ensuring the physical authenticity and monitorability of the injected fault. Specifically, the characteristic parameters corresponding to the fault type are determined by identifying the physical cause of the fault type, its process, and its final impact. For example, the cause of an IGBT open circuit fault is a phase loss in the three-phase current, resulting in a proportional decrease in motor output torque, physically manifested as a torque drop; the cause of a brake line hydraulic leakage fault is an increase in the hydraulic system volume, resulting in a gradual decrease in wheel cylinder pressure over time, physically manifested as a pressure drop; the cause of a BMS voltage acquisition deviation fault is sampling resistor drift or line voltage drop, affecting the deviation between the acquired voltage and the actual voltage, manifested as a voltage deviation.
[0045] Furthermore, after determining the characteristic parameters corresponding to the fault type, a mapping model between the characteristic parameters and the physical signals of the actual vehicle is established to ensure the physical consistency between virtual faults and real faults. In this embodiment, the mapping model between torque attenuation rate and motor output torque is as follows:
[0046]
[0047] in, This is the actual output torque. To provide the rated output torque, Torque attenuation rate, This is the speed correction factor.
[0048] The mapping model between the pressure drop rate and the brake wheel cylinder pressure is as follows:
[0049]
[0050] in, For the pressure of the present moment, The initial pressure of the wheel cylinder, rate of pressure drop Duration of the fault This is the position correction factor.
[0051] The mapping model between the deviation ratio and the acquired voltage signal is as follows:
[0052]
[0053] in, This indicates the voltage collected by the BMS. Indicates the actual voltage of the battery cell. Indicates the deviation ratio. This represents random noise.
[0054] By accurately mapping, the fault parameters of the virtual configuration are transformed into physical phenomena consistent with those of the real vehicle, avoiding the problem that the parameters can be adjusted but the physical reality is not real.
[0055] It should be noted that the above are just examples of individual fault types. Other fault types can be quantified according to actual needs, and will not be elaborated here.
[0056] S304: Determine the triggering conditions for the fault.
[0057] In this embodiment, the triggering conditions include operating condition triggering, time triggering, and event triggering. Among them, operating condition triggering is the priority triggering condition. Operating condition triggering refers to the triggering of a combination of real-time vehicle state parameters, such as vehicle speed + throttle opening + motor speed. The triggering conditions are vehicle speed > 60km / h, throttle opening > 70%, and motor speed > 3000rpm, and the triggering result is IGBT open circuit. Alternatively, the triggering parameter combination is brake pedal force + wheel cylinder pressure. The triggering conditions are pedal force > 300N and pressure > 120bar, and the triggering result is hydraulic leakage.
[0058] Other triggering conditions, such as time-triggered conditions, refer to triggering according to the test process sequence, such as "injecting a fault 15 seconds after scenario start" or "injecting a secondary fault 300ms after the initial fault occurs," which are used for scenarios that require precise control of the test rhythm. Event-triggered conditions refer to triggering based on specific system events, such as "injecting brake line leakage when ESP is activated (ABS is working)" or "injecting BMS voltage deviation when fast charging mode is switched," which simulate the coupled scenario of faults and system operation.
[0059] Additionally, it should be noted that fault propagation is based on the vehicle system coupling relationship, quantifying the propagation process of the fault from the triggering component to the associated system to ensure the simulation of the real fault propagation path. First, the physical / signal connections between components are analyzed through the system architecture diagram, and the propagation path is drawn. For example, the propagation path of a motor controller fault is "motor controller → BMS (overcurrent protection) → thermal management system (stop cooling) → ESP (braking compensation)". Then, the propagation delay and impact degree are determined. The propagation delay refers to the response time of the fault from the triggering component to the associated system. For example, the delay from motor controller fault to BMS is 280ms, and the delay from BMS to thermal management system is 100ms. The impact degree refers to the proportion of the performance impact of the fault on the associated system. For example, if the motor controller fault causes BMS overcurrent protection, the battery output current limit will drop from 200A to 50A (impact degree 75%). Finally, the propagation termination condition is determined, that is, the rules for stopping the fault propagation are set, such as "the fault will terminate after propagation to a level 3 associated system" or "the propagation will terminate after the system enters a safe mode (such as high voltage power failure)", to avoid unlimited propagation leading to test failure.
[0060] S40: Construct a hardware-in-the-loop test platform, which includes vehicle core components, environmental simulation equipment and data acquisition system, and synchronizes the time of the vehicle dynamics model, vehicle core components and data acquisition system through the TSN protocol.
[0061] Specifically, the key components of the actual vehicle are first connected, including brake calipers (with pressure sensors), steering motors (with angle sensors), and motor controllers (with CAN bus interfaces), and then connected to the test platform via high-voltage wiring harnesses and CAN bus.
[0062] Then deploy environmental simulation equipment, such as high and low temperature chambers to simulate extreme temperatures, and road surface simulation platforms to simulate different road surface conditions.
[0063] Finally, configure the data acquisition card to collect physical signals such as voltage, current, pressure, and temperature.
[0064] It should be noted that after the hardware is built, time synchronization is required. In this embodiment, the Time Sensitive Network (TSN) protocol is used to achieve time synchronization of the vehicle dynamics model, actual vehicle components, and data acquisition system. Finally, communication protocol adaptation is performed, and the test platform and the actual vehicle ECU are communicated based on the CAN FD protocol to parse the vehicle status messages (such as vehicle speed and torque requests) and fault diagnosis messages (DTC codes) sent by the ECU.
[0065] S50: The vehicle under test is tested in the hardware-in-the-loop test platform. When the triggering condition is met, the corresponding fault type is injected into the vehicle dynamics model. The vehicle dynamics model generates a fault propagation sequence and fault response according to the fault type and propagation logic and sends them to the vehicle core components. The data after the vehicle core components react is collected through the data acquisition system.
[0066] Specifically, firstly, the vehicle dynamics model is controlled to simulate the driving scenario to be tested. A virtual driver drives the vehicle, providing real-time feedback on dynamic loads such as road resistance and air resistance. Then, the actual vehicle components (brake calipers, steering motors) receive control commands from the vehicle dynamics model to simulate braking and steering operations during real driving, while the data acquisition system synchronously records the state parameters of each component.
[0067] When the vehicle meets the fault triggering conditions (e.g., throttle opening reaches 75% after 15 seconds of testing), the test control software injects an "IGBT open circuit" fault into the motor controller, adjusting the motor output torque in real time (from 200 N·m to 100 N·m). Then, fault propagation monitoring is initiated, recording the time it takes for the fault to propagate from the motor controller to the BMS (e.g., 280 ms), the protective actions triggered by the BMS (e.g., cutting off the high-voltage circuit), and the response of the ESP controller. When the fault propagation conditions are met, fault propagation is initiated, and subsequent feedback data is monitored. When the propagation termination conditions are met, fault propagation is stopped, and the test ends.
[0068] S60: Analyze the data to obtain test results.
[0069] In this embodiment, data analysis includes preprocessing the test data, such as using a Kalman filter to remove outlier data and using linear interpolation to fill in missing data segments. Then, the metrics to be tested are calculated, such as fault diagnosis accuracy, emergency response time, braking distance deviation, etc.
[0070] As can be seen from the above embodiments, this testing method, by combining the vehicle dynamics model with a hardware-in-the-loop testing platform, is not only applicable to different environments, but also has a short testing cycle and high efficiency. Furthermore, the fault testing does not damage the vehicle and has low testing costs. In addition, by constructing a fault mode library with propagation capabilities, it achieves fault simulation that conforms to real vehicle conditions, thereby improving the reliability of the test.
[0071] Reference Figure 3 This embodiment also provides a vehicle testing device, including:
[0072] The acquisition unit 100 is used to acquire the hardware parameters of the vehicle under test. It should be noted that since the specific acquisition method and process have been described in detail in step S10 of the above-mentioned vehicle testing method, they will not be repeated here.
[0073] The first construction unit 200 is used to construct a vehicle dynamics model based on the hardware parameters. It should be noted that since the specific construction method and process have been described in detail in step S20 of the above-mentioned vehicle testing method, they will not be repeated here.
[0074] The second construction unit 300 is used to construct a fault mode library for the vehicle under test. The fault mode library includes fault types, triggering conditions, and propagation logic between each fault. It should be noted that since the specific construction method and process have been described in detail in step S30 of the above-mentioned vehicle testing method, they will not be repeated here.
[0075] The third construction unit 400 is used to construct a hardware-in-the-loop test platform. The hardware-in-the-loop test platform includes vehicle core components, environmental simulation equipment, and a data acquisition system, and synchronizes the time of the vehicle dynamics model, vehicle core components, and data acquisition system through the TSN protocol. It should be noted that since the specific construction method and process have been described in detail in step S40 of the above-mentioned vehicle testing method, they will not be repeated here.
[0076] The test unit is used to test the vehicle under test in the hardware-in-the-loop test platform. When the triggering condition is met, the corresponding fault type is injected into the vehicle dynamics model. The vehicle dynamics model generates a fault propagation sequence and fault response according to the fault type and propagation logic and sends them to the vehicle core components. The data after the vehicle core components react is collected by the data acquisition system. It should be noted that since the specific test method and process have been described in detail in step S50 of the above-mentioned vehicle test method, they will not be repeated here.
[0077] The analysis unit 600 is used to analyze the data to obtain test results. It should be noted that since the specific analysis method and process have been described in detail in step S60 of the above-mentioned vehicle testing method, they will not be repeated here.
[0078] In addition, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium may store a program that, when executed, includes some or all of the steps of the method for monitoring any vehicle driving behavior described in the above method embodiments.
[0079] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0080] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.
[0081] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.
[0082] The above description, with reference to the accompanying drawings, illustrates an exemplary flowchart for monitoring the driving behavior of a vehicle according to an embodiment of the present invention. It should be noted that the numerous details included in the above description are merely illustrative of the invention and not intended to limit it. In other embodiments of the invention, the method may have more, fewer, or different steps, and the order, inclusion, function, and other relationships between the steps may differ from those described and illustrated.
Claims
1. A vehicle testing method, characterized in that, include: Obtain the hardware parameters of the vehicle under test; A vehicle dynamics model is constructed based on the hardware parameters; Constructing a fault mode library for the vehicle under test, the fault mode library includes fault types, triggering conditions, and propagation logic between various faults; including: acquiring fault data sources for the fault mode library; classifying the fault data sources to determine fault types; quantifying the feature parameters of all fault types; determining the triggering conditions of faults, including condition triggering, time triggering, and event triggering; wherein, quantifying the feature parameters of all fault types includes: determining the feature parameters corresponding to the fault type; establishing a mapping model between feature parameters and real vehicle physical signals to ensure the physical consistency between virtual faults and real faults; wherein, establishing a mapping model between feature parameters and real vehicle physical signals includes: The mapping model between torque decay rate and motor output torque is as follows: ； in, This is the actual output torque. To provide the rated output torque, Torque attenuation rate, This is the speed correction factor; The mapping model between the pressure drop rate and the brake wheel cylinder pressure is as follows: ； in, For the pressure of the present moment, The initial pressure of the wheel cylinder, rate of pressure drop Duration of the fault This is the position correction factor; The mapping model between the deviation ratio and the acquired voltage signal is as follows: ； in, This indicates the voltage collected by the BMS. Indicates the actual voltage of the battery cell. Indicates the deviation ratio. Indicates random noise; A hardware-in-the-loop test platform is constructed, which includes vehicle core components, environmental simulation equipment and data acquisition system, and the time of the vehicle dynamics model, vehicle core components and data acquisition system is synchronized through the TSN protocol; The vehicle under test is tested in the hardware-in-the-loop test platform. When the triggering condition is met, the corresponding fault type is injected into the vehicle dynamics model. The vehicle dynamics model generates a fault propagation timing sequence and fault response according to the fault type and propagation logic and sends them to the vehicle core components. The data acquisition system collects the data after the vehicle core components react. The test results are obtained by analyzing the data.
2. The vehicle testing method according to claim 1, characterized in that, The step of constructing a vehicle dynamics model based on the hardware parameters includes: Based on the hardware parameters, a vehicle subsystem model is constructed using multibody dynamics software. The subsystem model includes a body model, a suspension model, a tire model, a powertrain model, a braking system model, and a steering system model. Associating the interfaces of the subsystem models, including the association between the suspension and the body, the association between the powertrain and the body, and the association between the braking / steering system and the body; Configure the multibody dynamics solver in the vehicle dynamics model.
3. The vehicle testing method according to claim 1, characterized in that, The operating condition triggering includes: Determine the combination of triggering fault types; Determine the trigger thresholds for each fault type and the triggering logic relationships between each fault type; When the vehicle condition meets the trigger threshold and trigger logic relationship, a fault simulation is triggered.
4. The vehicle testing method according to claim 1, characterized in that, The method for determining the propagation logic is as follows: The propagation path is determined based on the physical signal correlation of the vehicle, including the primary propagation path and the secondary propagation path; The delay time for fault propagation is determined based on signal transmission speed, ECU response time, and physical process duration. Determine the degree of impact between the faults; Set conditions to terminate the spread to prevent unlimited propagation.
5. The vehicle testing method according to claim 1, characterized in that, The vehicle under test is tested in the hardware-in-the-loop test platform, including: The vehicle dynamics model is controlled to simulate the set road conditions, and the vehicle is driven by a virtual driver, and the simulation data is transmitted to the core components of the vehicle. When the vehicle meets the fault triggering conditions, fault data from the fault mode library is injected, and data of the vehicle's core components is collected through the data acquisition system. Other faults are triggered based on the propagation logic between faults, fault data is injected, and data from the vehicle's core components is collected through the data acquisition system.
6. A vehicle testing device, characterized in that, include: The acquisition unit is used to acquire the hardware parameters of the vehicle under test. The first construction unit is used to construct a vehicle dynamics model based on the hardware parameters; The second construction unit is used to construct a fault mode library for the vehicle under test. The fault mode library includes fault types, triggering conditions, and propagation logic between various faults. This includes: acquiring fault data sources for the fault mode library; classifying the fault data sources to determine fault types; quantifying the feature parameters of all fault types; determining the triggering conditions for faults, including condition-triggered, time-triggered, and event-triggered conditions. Quantifying the feature parameters of all fault types includes: determining the feature parameters corresponding to the fault type; establishing a mapping model between feature parameters and real vehicle physical signals to ensure the physical consistency between virtual and real faults. Establishing the mapping model between feature parameters and real vehicle physical signals includes: The mapping model between torque decay rate and motor output torque is as follows: ； in, This is the actual output torque. To provide the rated output torque, Torque attenuation rate, This is the speed correction factor; The mapping model between the pressure drop rate and the brake wheel cylinder pressure is as follows: ； in, For the pressure of the present moment, The initial pressure of the wheel cylinder, rate of pressure drop Duration of the fault This is the position correction factor; The mapping model between the deviation ratio and the acquired voltage signal is as follows: ； in, This indicates the voltage collected by the BMS. Indicates the actual voltage of the battery cell. Indicates the deviation ratio. Indicates random noise; The third building unit is used to build a hardware-in-the-loop test platform, which includes vehicle core components, environmental simulation equipment and data acquisition system, and synchronizes the time of the vehicle dynamics model, vehicle core components and data acquisition system through the TSN protocol; The test unit is used to test the vehicle under test in the hardware-in-the-loop test platform. When the triggering condition is met, the corresponding fault type is injected into the vehicle dynamics model. The vehicle dynamics model generates a fault propagation timing sequence and fault response according to the fault type and propagation logic and sends them to the vehicle core components. The data acquisition system collects the data after the vehicle core components react. The analysis unit is used to analyze the data to obtain test results.
7. A computer-readable storage medium, comprising a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of a vehicle testing method as described in any one of claims 1 to 5.