A hardware-in-the-loop testing method, device and electronic equipment

Abstract

The application discloses a hardware-in-the-loop test method and device and electronic equipment, and relates to the technical field of automobile electronics. In the optimization stage, the simulated annealing algorithm is adopted, the parameters are adjusted according to the characteristics of the electronic stability control system, and the data distribution is optimized, so that the test data quality and the fault detection capability are improved. In the verification stage, the generated test data is subjected to actual operation test, the actual output is compared with the expected result, data problems are fed back, the optimized test data that fails to pass the verification is sent to the target hardware-in-the-loop test model for optimization and adjustment, so as to form a closed-loop optimization and verification process, and the iteration of the closed-loop process comprehensively covers all possible working conditions and fault modes, avoids missing key test points, enhances the reliability of the electronic stability control system, and also ensures the accuracy, effectiveness, comprehensiveness, sufficiency of the hardware-in-the-loop test of the electronic stability control system, and reduces the limitation of the hardware-in-the-loop test of the electronic stability control system.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, and more specifically, to a hardware-in-the-loop testing method, apparatus, and electronic device. Background Technology

[0002] With the rapid development of automotive electronics technology, the Electronic Stability Control (ESC) system, as a key system for ensuring vehicle driving stability and safety, is of paramount importance in terms of its reliability. Hardware-in-the-Loop (HIL) testing is an important means to ensure that ESC functions properly under various complex operating conditions.

[0003] During ESC HIL testing, generating ESC HIL test data is crucial. Because the working principle of ESC involves complex dynamic models and real-time electronic control logic, its operating conditions are diverse and complex, including normal driving, emergency braking, slippery road surfaces, and extreme cornering. Each condition involves numerous parameter variations and combinations. Current ESC HIL test data generation relies solely on manual experience to create test scenarios and generate test data. This is not only extremely labor-intensive and inefficient, but also fails to comprehensively cover all possible operating conditions and failure modes, easily overlooking critical test points, leading to inadequacies and limitations in ESC HIL testing.

[0004] Therefore, how to improve the efficiency and sufficiency of ESC HIL testing, and how to reduce the limitations of ESC HIL testing, are the problems that this application urgently needs to solve. Summary of the Invention

[0005] In view of this, this application discloses a hardware-in-the-loop testing method, apparatus, and electronic device, which aims to improve the sufficiency and efficiency of ESC HIL testing and reduce the limitations of ESC HIL testing.

[0006] To achieve the above objectives, the disclosed technical solution is as follows:

[0007] The first aspect of this application discloses a hardware-in-the-loop testing method, the method comprising:

[0008] Initial test data for multiple scenarios is generated through a pre-trained target hardware-in-the-loop test model; wherein, the target hardware-in-the-loop test model is trained by a gradient descent optimization algorithm, an adaptive learning rate adjustment strategy, and embedding vectors in an embedding space of a preset dimension.

[0009] Extract hardware-in-the-loop test features related to the electronic stability control system from the initial test data of the multi-scenario test;

[0010] Analyze whether the hardware-in-the-loop test characteristics conform to the normal operating range of the electronic stability control system, and obtain the analysis results;

[0011] Based on the analysis results, the hardware-in-the-loop test characteristics are adjusted to obtain the adjusted test characteristics;

[0012] Based on the simulated annealing algorithm, the characteristics of the electronic stability control system, and the adjusted test features, the initial test data for the multiple scenarios are batch optimized to obtain optimized test data for the multiple scenarios and then verified.

[0013] The validated and optimized multi-scenario test data will be applied to the testing of the electronic stability control system.

[0014] The optimized multi-scenario test data that fails verification is sent to the target hardware-in-the-loop test model for optimization and adjustment, so as to form a closed-loop optimization verification process.

[0015] A second aspect of this application discloses a hardware-in-the-loop testing apparatus, the apparatus comprising:

[0016] The generation unit is used to generate initial test data for multiple scenarios through a pre-trained target hardware-in-the-loop test model; wherein the target hardware-in-the-loop test model is trained by a gradient descent optimization algorithm, an adaptive learning rate adjustment strategy, and embedding vectors in an embedding space of a preset dimension.

[0017] The extraction unit is used to extract hardware-in-the-loop test features related to the electronic stability control system from the initial test data of the multi-scenario system.

[0018] The analysis unit is used to analyze whether the hardware-in-the-loop test characteristics conform to the normal operating range of the electronic stability control system and obtain the analysis results.

[0019] An adjustment unit is used to adjust the hardware-in-the-loop test characteristics based on the analysis results to obtain the adjusted test characteristics;

[0020] The batch optimization unit is used to perform batch optimization on the initial test data of the multi-scenario based on the simulated annealing algorithm, the characteristics of the electronic stability control system and the adjusted test characteristics, so as to obtain optimized multi-scenario test data and verify it.

[0021] The application unit is used to apply the validated and optimized multi-scenario test data to the electronic stability control system test;

[0022] The optimization and adjustment unit is used to send the optimized multi-scenario test data that has failed verification to the target hardware-in-the-loop test model for optimization and adjustment, so as to form a closed-loop optimization and verification process.

[0023] The third aspect of this application discloses an electronic device including a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the hardware-in-the-loop testing method as described in any of the first aspects. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0025] Figure 1 This is a schematic flowchart of a hardware-in-the-loop testing method disclosed in an embodiment of this application;

[0026] Figure 2 This is a schematic diagram of the architecture of the target hardware-in-the-loop test model disclosed in the embodiments of this application;

[0027] Figure 3 This is a schematic diagram illustrating the test data optimization process of the simulated annealing algorithm disclosed in the embodiments of this application;

[0028] Figure 4 This is a schematic diagram of the process for generating HIL test data as disclosed in the embodiments of this application;

[0029] Figure 5 This is an architecture diagram of the hardware-in-the-loop testing system disclosed in an embodiment of this application;

[0030] Figure 6 This is an overall schematic diagram of the hardware-in-the-loop testing disclosed in the embodiments of this application;

[0031] Figure 7 This is a schematic diagram of the structure of a hardware-in-the-loop testing device disclosed in an embodiment of this application. Detailed Implementation

[0032] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a 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.

[0034] As the background technology shows, the current ESC HIL test data generation relies solely on manual experience to write test scenarios and generate test data. This not only involves a huge workload and low testing efficiency, but also makes it difficult to fully cover all possible operating conditions and failure modes, easily missing key test points, resulting in inadequacies and limitations in ESC HIL testing.

[0035] To address the aforementioned issues, this application discloses a hardware-in-the-loop (HIL) testing method, apparatus, and electronic device. Because the target HIL test model can automatically optimize and filter the generated test data according to the characteristics and testing requirements of the electronic stability control system (ESS), removing invalid or redundant data and retaining only the most valuable test data, it not only reduces the storage space and processing time of test data but also improves the testing efficiency and accuracy of HIL testing for EES. In the optimization phase, a simulated annealing algorithm is used to adjust parameters and optimize data distribution based on the characteristics of the EES, improving test data quality and fault detection capabilities. In the verification phase, the generated data is subjected to actual operational testing. By comparing the actual output with the expected results, data problems are identified, and test data is regenerated. The optimized test data that fails verification is sent to the target HIL test model for further optimization and adjustment, forming a closed-loop optimization and verification process. This iterative closed-loop process comprehensively covers all possible operating conditions and fault modes, avoiding omissions of key test points, enhancing the reliability of the EES, and ensuring the accuracy, effectiveness, and comprehensiveness of HIL testing for the EES. Furthermore, by batch generating multi-scenario test data to solve the problem of time-consuming data generation, by automatically optimizing data through algorithms to reduce repeated manual debugging, and by providing a rapid comparison benchmark through the generation of closed-loop test data and expected results, the sufficiency of hardware-in-the-loop testing of electronic stability control systems is improved, and the limitations of hardware-in-the-loop testing of electronic stability control systems are reduced. The specific implementation method is described in detail in the following embodiments.

[0036] It should be noted that the hardware-in-the-loop testing method, apparatus, and electronic device provided in this application can be used in fields such as automotive electronics. The above is merely an example and does not limit the application areas of the hardware-in-the-loop testing method, apparatus, and electronic device provided in this application.

[0037] refer to Figure 1 The diagram shown is a flowchart of a hardware-in-the-loop testing method disclosed in an embodiment of this application. The hardware-in-the-loop testing method mainly includes the following steps:

[0038] S101: Generate initial test data for multiple scenarios through a pre-trained target hardware-in-the-loop test model; wherein, the target hardware-in-the-loop test model is trained by a gradient descent optimization algorithm, an adaptive learning rate adjustment strategy, and embedding vectors in an embedding space of a preset dimension.

[0039] To address the requirements for generating ESC HIL test data, a specialized target hardware-in-the-loop (HIL) test model was designed. This HIL test model employs a deep neural network architecture, including an input layer, hidden layers, and an output layer. The hidden layers consist of a Multilayer Perceptron (MLP) and a Transformer module with a self-attention mechanism, which are used to process the time-series features in the ESC test data. The structure of the target HIL test model is as follows: Figure 2 As shown.

[0040] Figure 2 In the middle, the input layer is used to collect vehicle driving status information, sensor data, control commands, etc.

[0041] The Transformer module, which is a self-attention mechanism, includes a multi-head self-attention layer and a feedforward neural network layer.

[0042] Figure 2 The document demonstrates the structure and connection methods of the input, hidden, and output layers of the target hardware-in-the-loop test model, and labels the function and data flow of each layer, enabling an intuitive understanding of the internal structure and working principle of the target hardware-in-the-loop test model.

[0043] The specific training process of the hardware-in-the-loop test model is shown in A1-A3.

[0044] A1: Obtain data from multiple sources; wherein, the multiple sources consist of at least the electronic stability control system (ESC) operation data under different road conditions and weather conditions, physical model simulation data, and preset database data.

[0045] In A1, the input layer of the target hardware-in-the-loop test model receives data from multiple sources, including actual vehicle data, physical model simulation data, and empirical data.

[0046] Actual vehicle data collection: Under different road conditions (such as urban roads, highways, and mountain roads), driving styles (aggressive driving, gentle driving), and weather conditions (sunny, rainy, and snowy), ESC operation data is collected through onboard sensors, including time-series data such as wheel speed, steering wheel angle, lateral acceleration, and longitudinal acceleration.

[0047] Physical model simulation data: Utilizing vehicle dynamics physical models, the operation of ESC under various conditions is simulated, generating corresponding test data to supplement the deficiencies of actual data collection. For example, relying on vehicle dynamics physical models, such as the classic vehicle monorail model (which can accurately characterize the longitudinal and lateral dynamic responses of a vehicle), the working process of ESC under diverse conditions is simulated. Taking the emergency avoidance scenario on icy and snowy roads as an example, parameters such as a road adhesion coefficient as low as 0.2, an initial vehicle speed of 80 km / h, and a steering wheel rotating rapidly at a rate of 300 rpm are first set in the model. Based on the vehicle dynamics equations, the model calculates in real time the changes in physical quantities such as wheel speed, vehicle slip angle, and longitudinal braking force, simulating the dynamic process of correcting the vehicle's trajectory by precisely applying braking force to different wheels when ESC intervenes, generating continuous test data covering the vehicle's motion state and ESC control commands. Collecting data on such extreme working conditions in actual roads is not only highly dangerous, but also difficult to reproduce due to site and environmental limitations. However, by using physical model simulation, complete test data under such working conditions can be generated efficiently, supplementing the missing data in special, dangerous or difficult-to-reproduce working conditions in actual collected data, and enriching the test dataset.

[0048] Experience data: Based on long-term practical experience, domain experts have compiled typical fault data (such as sensor faults and actuator faults) and special operating condition data (such as emergency braking and high-speed turning).

[0049] A2: Preprocess the multi-channel data sources to obtain the embedding vector of the embedding space with preset dimensions.

[0050] Preprocessing includes normalization, feature extraction, format conversion, data cleaning, and other operations to make the data suitable for model training.

[0051] Normalization process:

[0052] Since the data values ​​and dimensions of different data sources vary greatly, a minimum-maximum normalization method is adopted to facilitate model learning. For each feature, its minimum and maximum values ​​are calculated, and then the minimum and maximum values ​​are mapped to the interval [0, 1] according to formula (1). For example, the original range of wheel speed data is 0-200km / h. After normalization, it is mapped to the interval [0, 1] so that different features have the same scale, thus obtaining time series features.

[0053] (1)

[0054] in, Features of time series; The minimum value of the feature; The maximum value of the feature.

[0055] Feature extraction:

[0056] For time series data, the following methods are used to extract sliding window statistical features, frequency domain features, and sequence difference features:

[0057] (a) Extracting statistical features of a sliding window: A fixed-size sliding window is used to slide across the time series to calculate the statistical features of the data within the window, including but not limited to the mean, standard deviation, maximum value, minimum value, and median. For example, for a time series of wheel speeds, the window size is set to 10 time steps, and the average speed and standard deviation of the speed within each window are calculated to capture the local variation features of the data.

[0058] (b) Extracting frequency domain features: The time series data is converted to the frequency domain using Fourier transform to extract frequency domain features such as the spectrum and power spectrum. By analyzing the frequency domain features, periodic variation patterns in the data can be discovered, which has a good feature representation capability for some periodic signals in the ESC system (such as the rotation signal of a wheel).

[0059] (c) Extracting sequence difference features: Performing a difference operation on the original time series to obtain the changes between adjacent time steps, which are used as new features. For example, calculating the difference in steering wheel angle can reflect the driver's steering speed.

[0060] Format conversion:

[0061] Time series data is divided into fixed-length sequence segments, each containing feature vectors from multiple time steps. For example, data on features such as wheel speed and steering wheel angle over 100 time steps can be combined into a single sequence segment and used as an input sample for the model.

[0062] A3: The initial hardware-in-the-loop test model is trained using the gradient descent optimization algorithm, adaptive learning rate adjustment strategy, and embedding vector until the initial hardware-in-the-loop test model converges, resulting in the target hardware-in-the-loop test model. The initial hardware-in-the-loop test model is the untrained hardware-in-the-loop test model, while the target hardware-in-the-loop test model is the hardware-in-the-loop test model that has learned the input-output relationship, fault characteristics, and statistical laws of the electronic stability control system under various operating conditions.

[0063] Specifically, the process of preprocessing multi-channel data sources to obtain embedding vectors in a preset-dimensional embedding space is shown in B1-B7.

[0064] B1: Calculate the minimum and maximum values ​​of multi-channel data sources using the min-max normalization method.

[0065] B2: Map the minimum and maximum values ​​to a preset interval according to the preset mapping formula to obtain time series features; wherein, the time series features are composed of different features of the same scale.

[0066] The execution process and principle of B1-B2 are consistent with the execution process and principle of the normalization process in A2 above, and can be referred to. They will not be repeated here.

[0067] B3: Calculate the statistical characteristics of the sliding window by sliding a window of a preset size across the time series.

[0068] B4: Transform the time series features to the frequency domain using Fourier transform to extract frequency domain features.

[0069] B5: Perform difference calculations on the time series to obtain the changes between adjacent time steps, and use the changes as the difference features of the series.

[0070] The execution process and principle of B3-B5 are consistent with the execution process and principle of feature extraction in A2 above, and can be referred to. They will not be repeated here.

[0071] B6: Divide the sliding window statistical features, frequency domain features, and sequence difference features into sequence segments of a preset length; each sequence segment includes feature vectors for multiple time steps.

[0072] B7: The sequence segments of a preset length are processed by the Transformer layer of a deep neural network to map each sequence segment of the preset length to an embedding space of a preset dimension, thereby obtaining the embedding vector of the embedding space of the preset dimension.

[0073] The time-series features in the ESC test data are processed using a multilayer perceptron and a self-attention mechanism Transformer module.

[0074] When processing time series features of ESC test data, the original feature vectors must first be embedded. Because the original time series data (such as wheel speed, steering wheel angle, etc.) are usually low-dimensional feature representations, in order for the model to better learn the complex patterns in the data, it is necessary to map them to an embedding space of a preset dimension, i.e., a high-dimensional embedding space, to obtain the embedding vector of the preset-dimensional embedding space.

[0075] Suppose the input is a time series, with a feature vector x at each time step t. t Its dimension is din For example, at a certain moment, the eigenvector x t It may include multiple feature values ​​such as the current wheel speed, steering wheel angle, and lateral acceleration, which together constitute a d in A dimensional vector. An embedding vector e is obtained by linearly transforming it using a learnable weight matrix. t The expression for the learnable weight matrix is ​​shown in Equation (2). The formula for the embedding vector is shown in Equation (3).

[0076] (2)

[0077] in, Let R be the learnable weight matrix; R is the mathematical set of real numbers, where all elements of the matrix are real numbers; d in For dimensions; The dimension of the embedded space.

[0078] (3)

[0079] in, For embedding vectors; For feature vectors; This is a learnable weight matrix.

[0080] Formula (3) transforms the feature vector at each time step into a high-dimensional embedding vector, enabling the target hardware-in-the-loop test model to more effectively capture the relationships between data in this high-dimensional space.

[0081] During the training of the target hardware-in-the-loop test model, a gradient descent-based optimization algorithm was employed, combined with an adaptive learning rate adjustment strategy, to accelerate the model's convergence speed and improve its stability. Specifically, the processing involved:

[0082] The momentum-based stochastic gradient descent algorithm introduces a momentum term when updating parameters, helping the model pass through local minima and saddle point regions more quickly during gradient descent and reducing oscillations. The momentum update formula is shown in formula (4).

[0083] (4)

[0084] in, It is the momentum of the t-th iteration; μ is the momentum coefficient, which is usually taken as 0.9; Let be the momentum at the (t-1)th iteration; η be the learning rate; For the loss function with respect to the parameters The gradient.

[0085] In the initial training phase of ESC braking test data, since the model parameters are randomly initialized and may be far from the optimal solution, a relatively large learning rate is initially set, such as η=0.1, with a momentum coefficient μ=0.9. This allows the model to move quickly in the parameter space, rapidly capturing the general patterns in the ESC braking data, such as quickly learning the overall decreasing trend of wheel speed during braking and the preliminary relationship between steering wheel angle and vehicle steering stability. As training progresses, after approximately 10 epochs, the model approaches the optimal solution, but may oscillate around it due to the excessively large learning rate. At this point, the learning rate is reduced to η=0.01.

[0086] For example, when the target hardware-in-the-loop (HIL) test model is learning subtle changes in wheel speed during braking (such as differences in speed decay rates under different braking intensities), a smaller learning rate allows the HIL test model to fine-tune its parameters, improving its ability to fit these detailed features. When training has reached 20-30 epochs, the learning rate is further reduced to η=0.001. At this stage, the model primarily fine-tunes the learned patterns, such as more accurately learning the features of the ESC system under specific braking conditions (such as the instantaneous response during emergency braking), preventing the model from skipping the optimal solution.

[0087] As mentioned above, by continuously adjusting the weights and bias parameters of the target hardware-in-the-loop test model through a large amount of training data, the target hardware-in-the-loop test model can learn the input-output relationship, fault characteristics, and statistical patterns of the ESC system under various operating conditions, thereby enabling it to generate high-quality test data according to different test requirements.

[0088] S102: Extract hardware-in-the-loop test features related to the Electronic Stability Control (ESC) system from initial test data of multiple scenarios.

[0089] The specific process of extracting hardware-in-the-loop test features related to ESC from the initial test data is shown in C1-C3.

[0090] C1: Obtain the test objectives and test specifications for ESC.

[0091] C2: Determine test requirements and constraints based on test objectives and test specifications.

[0092] C3: Input the test requirements and constraints into the target hardware-in-the-loop test model to extract the test data sequence from the initial test data through the target hardware-in-the-loop test model, and determine the test data sequence as hardware-in-the-loop test features related to ESC.

[0093] When generating ESC HIL test data using a trained target hardware-in-the-loop test model, the specific test requirements and constraints are first determined based on the ESC test objectives and specifications. For example, specific functional modules to be tested are identified, such as the brake pressure control module and the vehicle speed sensor signal processing module; the range and accuracy requirements of the input signals are clarified, such as the wheel speed sensor's measurement range of 0-250 km / h and resolution of 0.1 km / h; and the types of test scenarios to be simulated are defined, including acceleration, deceleration, and constant speed driving during normal driving, as well as various emergency braking and dangerous operating conditions, such as emergency braking and steering operations on low-friction surfaces.

[0094] These test requirements and constraints are passed as input to the target hardware-in-the-loop (HIL) test model. The HIL model then uses its learned knowledge and patterns to generate corresponding test data sequences. For each test scenario, the HIL model generates sensor input signals such as wheel speed, steering wheel angle, and acceleration that conform to physical laws, as well as expected ESC control output signals, such as braking pressure commands for each wheel and engine torque adjustment commands. During data generation, the model fully considers the internal physical characteristics and logical relationships of the ESC system, such as the pressure response characteristics of the braking system, the friction model between the tires and the road surface, and various logical judgment conditions in the control algorithm. This ensures that the generated data is physically reasonable and logically coherent, realistically simulating the vehicle's operating state under various actual conditions. This effectively covers various functional and performance test points of the ESC, improving the comprehensiveness and effectiveness of HIL testing.

[0095] S103: Analyze whether the hardware-in-the-loop test characteristics meet the normal operating range of the ESC system and obtain the analysis results.

[0096] In S103, if the hardware-in-the-loop test characteristics are within the normal operating range of the ESC system, the analysis result is obtained that the hardware-in-the-loop test characteristics meet the normal operating range; if the hardware-in-the-loop test characteristics are not within the normal operating range of the ESC system, the analysis result is obtained that the hardware-in-the-loop test characteristics do not meet the normal operating range.

[0097] Among them, different hardware-in-the-loop test characteristics result in different normal operating ranges in the ESC system.

[0098] S104: Adjust the hardware-in-the-loop test characteristics based on the analysis results to obtain the adjusted test characteristics.

[0099] In particular, the hardware-in-the-loop test characteristics are adjusted based on the analysis results to ensure that the test data accurately reflects the true state of the ESC.

[0100] To better illustrate the process of adjusting hardware-in-the-loop test characteristics based on analysis results, an example is provided below:

[0101] Taking the "emergency braking test scenario on low-friction road surface" as an example:

[0102] 1. Test scenario: "Emergency braking on icy and snowy road surface (coefficient of adhesion 0.2)";

[0103] 2. Key Parameters: The initial test features (key parameters) generated by the target hardware-in-the-loop test model include:

[0104] Sensor input signals: wheel speed sequence (front wheels 85km / h, rear wheels 82km / h), lateral acceleration (0.7g), steering wheel angle (5°);

[0105] ESC control output signals: left front wheel brake pressure command (60 bar), right front wheel brake pressure command (55 bar);

[0106] 3. Analysis Results:

[0107] By comparing the normal operating range of the ESC system (based on physical characteristics and design specifications), two features were found to be outside the range:

[0108] 3.1 Lateral acceleration (0.7g):

[0109] The normal operating range of the ESC system is as follows: on low-adhesion road surfaces (adhesion coefficient 0.2), the maximum lateral acceleration should be ≤0.4g (because the road surface friction is limited, exceeding this will inevitably cause sideslip, which does not conform to the laws of physics).

[0110] Analysis result: This feature does not conform to the normal operating range.

[0111] 3.2, Left front wheel braking pressure (60 bar):

[0112] The normal operating range of the ESC system is as follows: the maximum working pressure of the brake actuator is 50 bar (the physical limit of the hardware). If this is exceeded, the actuator protection logic will be triggered, and it will not be considered a "normal operating state".

[0113] Analysis result: This feature does not conform to the normal operating range.

[0114] 4. Adjustment process (corrected based on analysis results):

[0115] 4.1 Lateral acceleration adjustment:

[0116] Root cause of the problem: The initial data did not take into account the friction limit of low-adhesion road surfaces. The lateral acceleration of 0.7g far exceeds the load-bearing capacity of ordinary vehicles driving on normal roads, which will cause the vehicle to actually skid and cannot reflect the true state of ESC in "stabilizing the vehicle body during normal braking".

[0117] Adjustment logic: Based on the relationship between road surface adhesion coefficient and vehicle dynamics (maximum lateral acceleration ≈ adhesion coefficient × g, where g is gravitational acceleration), the reasonable range is calculated as follows:

[0118] The upper limit of the normal range = 0.2 (adhesion coefficient) × 9.8 m / s² ≈ 0.2g (after taking safety redundancy, it is set to 0.3g).

[0119] Adjustment procedure: The lateral acceleration was corrected from 0.7g to 0.3g to ensure that it meets the physical constraint of "no sideslip on low-adhesion surfaces" and is consistent with the control objective of ESC to "suppress sideslip".

[0120] 4.2 Adjustment of left front wheel brake pressure:

[0121] Root cause of the problem: 60 bar exceeds the hardware limit of the brake actuator (50 bar). In actual testing, the actuator will cut off the output due to overpressure protection, causing the data to fail to reflect the normal control logic of ESC (such as dynamic pressure distribution).

[0122] Adjustment logic: Use the physical limits of the actuator as the boundary, while retaining fault detection redundancy (allowing it to approach but not exceed the limit), and set the normal range to 0~48 bar (leaving a 2 bar safety margin).

[0123] Adjustment procedure: Adjust the left front wheel brake pressure from 60 bar to 48 bar, and adjust the right front wheel pressure to 44 bar in the same proportion (55 / 60) (to ensure a reasonable pressure difference that conforms to the ESC's "balanced braking between left and right wheels" logic).

[0124] 4.3 Other Feature Verification and Retention:

[0125] Wheel speeds (front wheels 85km / h, rear wheels 82km / h): within the normal operating speed range of ESC (0~120km / h), and the wheel speed difference (3km / h) is consistent with the characteristics of slight slippage on low-friction surfaces, requiring no adjustment.

[0126] Steering wheel angle (5°): Within the reasonable range (-10°~10°) for "minor steering correction during emergency braking", which is consistent with actual driving behavior and requires no adjustment.

[0127] 5. Adjusted test features:

[0128] Sensor input signals: wheel speed (front wheels 85km / h, rear wheels 82km / h), lateral acceleration (0.3g), steering wheel angle (5°).

[0129] ESC control output signals: left front wheel brake pressure (48 bar), right front wheel brake pressure (44 bar).

[0130] Adjusted value:

[0131] The revised test characteristics satisfy both the physical constraints of the ESC system (hardware limits, road friction) and the control logic (pressure distribution balance, sideslip suppression), ensuring that the data can accurately reflect the real state of ESC under "low-friction road emergency braking" (such as dynamically adjusting pressure to prevent lock-up and maintain vehicle stability) during subsequent simulated annealing algorithm optimization, thus laying the foundation for the effectiveness of HIL testing.

[0132] S105: Based on the simulated annealing algorithm, ESC characteristics, and adjusted test features, perform batch optimization on the initial test data for multiple scenarios to obtain optimized multi-scenario test data and verify it.

[0133] In S105, based on the vehicle dynamics model and ESC characteristics, the value range and interrelationship of key parameters in the initial test data of multiple scenarios are defined. The key parameters are fine-tuned through simulated annealing algorithm so that the key parameters meet the physical constraints. Based on the adjusted test characteristics, the initial test data of multiple scenarios are batch optimized to obtain optimized multi-scenario test data.

[0134] Since the data generated by the target hardware-in-the-loop test model may contain a certain degree of randomness and uncertainty, a data optimization strategy based on simulated annealing algorithm is adopted to further improve the quality and usability of the data. Based on predefined optimization objectives, such as maximizing test coverage, improving fault detection rate, and ensuring the physical validity of the data, the generated test data is filtered and adjusted.

[0135] For example, by fine-tuning key parameters in test data using simulated annealing algorithms, the system is made more likely to trigger potential fault modes in the ESC system while meeting physical constraints, thereby improving the sensitivity of fault detection. Specifically, this involves defining the value ranges and interrelationships of key parameters based on the vehicle dynamics model and the working principles of the ESC system. For example, wheel speed... Satisfy, among which, Maximum design speed; steering wheel angle Within the designated range. Simultaneously, braking force... With wheel speed There is a certain relationship between the vehicle's mass m and other factors, and these factors must be met. ,in, is the coefficient of friction between the tire and the ground; N is the vertical load on the wheel.

[0136] The specific process of optimizing test data for the simulated annealing algorithm, such as... Figure 3 As shown. Figure 3 A flowchart illustrating the data optimization algorithm is shown.

[0137] Figure 3 The test data optimization process of the simulated annealing algorithm includes steps such as generating the initial solution, setting the temperature parameters, searching for neighborhood solutions, and judging the acceptance criteria.

[0138] This paper focuses on scenarios where simulated annealing algorithms optimize large model-generated data. Taking the scenario of maximizing the number of scenarios that trigger potential ESC faults (such as uneven brake pressure distribution, wheel lock-up and loss of control) and covering various ESC system operating conditions (low-friction road surface, sharp turn, emergency braking, etc.) as an example, the application process of the simulated annealing algorithm is introduced as follows:

[0139] 1. Parameter preparation, the specific parameters are shown in Table 1:

[0140] Table 1

[0141]

[0142] 2. Algorithm Flow:

[0143] Step 1: Initialization (Building initial test data):

[0144] A. Initial solution generation:

[0145] (1) Generate the initial test dataset X using a large model. raw (Including parameters such as wheel speed, braking force, and road surface adhesion coefficient).

[0146] (2) From X raw One set is randomly selected as the initial solution x0, in the format of a vector: x0=[v 轮速 F 制动力 δ 方向盘转角 , ...].

[0147] (3) Constraint verification: If x0 violates a hard constraint (such as v), 轮速 For speeds >300km / h, replace with boundary values ​​(e.g., force a setting to 300).

[0148] B. Temperature parameter initialization:

[0149] Directly assign the initial temperature T= Subsequently, through T= Iterative cooling.

[0150] Step 2: Neighborhood solution generation (fine-tuning test data):

[0151] Target:

[0152] Near the current solution, make small adjustments to the parameters to generate new test data that may trigger a fault.

[0153] Operation logic:

[0154] For the current solution Random perturbation is applied to each parameter: .

[0155] Constraint revalidation:

[0156] Generate neighborhood solutions Then, check again whether the hard constraints are met (e.g., the road surface adhesion coefficient must be in the range of [0.1, 1.0]). If they are violated, the parameters are corrected (e.g., if they exceed the upper limit, they are set as boundary values).

[0157] Step 3: Calculate the objective function (evaluate the value of the test data):

[0158] core:

[0159] A multi-objective weighted function is used to quantify the "fault detection capability" and "reasonableness" of the test data. Objective function definition: .

[0160] The explanations for each part are as follows:

[0161] The fault trigger count is the number of ESC fault modes that the data can trigger (such as uneven brake distribution, wheel lock-up and loss of control, etc., if triggered, increment by 1);

[0162] Coverage contribution is the proportion of new operating conditions covered by data to the total operating conditions (+1 if no data was covered).

[0163] Physical deviation refers to the degree of deviation between the data and the physical limits (e.g., points will be deducted if the braking force exceeds the limit).

[0164] Weighting coefficients (e.g.) =0.6, , (Highlighting the priority of fault detection).

[0165] Step 4: Acceptance Criteria Judgment (Deciding whether to adopt new data):

[0166] Target:

[0167] Balancing the exploration of new faults with convergence to a good solution, a certain probability of accepting solutions that are temporarily worse is allowed (to avoid getting trapped in local optima).

[0168] Calculate the target difference: ;

[0169] like <0: New data is better, accept directly. ;

[0170] like 0: The new data is temporarily worse, and we enter the probability acceptance phase.

[0171] Probability Acceptance Formula:

[0172] Calculate the acceptance probability P and compare it with a random number to decide whether to accept the application. .

[0173] Step 5: Temperature Update and Iteration Termination

[0174] Temperature decay:

[0175] After each iteration, with Lower the temperature (e.g.) =0.95), the temperature gradually converges.

[0176] Termination conditions:

[0177] when When the time is reached, the algorithm stops and outputs the current solution x as the optimized test data.

[0178] S106: Apply the validated and optimized multi-scenario test data to the testing of electronic stability control systems.

[0179] In S106, the validated and optimized multi-scenario test data is applied to the electronic stability control system test through the HIL test platform.

[0180] The HIL test platform includes components such as a hardware simulator, a real-time operating system, and test management software.

[0181] Hardware simulator: Simulates the physical characteristics of the real vehicle's ESC system, replacing the actual vehicle hardware in testing. It receives test data (such as wheel speed, braking force, road adhesion coefficient, and other virtual operating condition parameters) from a large model via a data interface, converts it into hardware-recognizable bus signals, accurately reproduces the physical response of the ESC system hardware, and feeds back hardware status data (such as actual braking force and current wheel speed feedback values) to the real-time operating system, providing realistic interactive feedback for the control logic.

[0182] Real-time operating system: Ensures the real-time and deterministic nature of the testing process. It receives control commands (such as "trigger ESC intervention under simulated sharp turning conditions") through the control interface and schedules the hardware simulator to execute them; it collects real-time status data from the hardware simulator (such as pressure values ​​fed back by the ESC actuator) and performs closed-loop calculations based on the control algorithm (such as adjusting braking force distribution according to the current wheel speed difference); it processes data and forwards commands strictly according to the time-triggered mechanism of HIL testing (such as 1ms-level cycles) to ensure that the timing of the testing process is consistent with the dynamic response of the actual vehicle.

[0183] Test management software: This software coordinates the entire testing process, achieving integrated management of "test requirements - execution - analysis." It sends test requirement instructions (such as "generate ESC fault test scenarios for low-adhesion road surfaces") to the large model, clarifying test objectives and constraints; it performs post-processing and analysis of test data (such as calculating fault detection rates and generating test reports) to determine the validity of the data generated by the large model and the quality of the ESC system control logic; and it receives test result data (such as ESC trigger fault types and control response times) from the real-time operating system through a feedback interface, enabling real-time recording and monitoring.

[0184] Specifically, the process of applying the validated and optimized multi-scenario test data to the electronic stability control system test is shown in D1-D4.

[0185] D1: Inject the validated and optimized multi-scenario test data into the ESC hardware system model or the actual ESC hardware device in the hardware-in-the-loop test platform for simulation testing or actual operation testing to obtain test results.

[0186] Verifying the optimized multi-scenario test data is a crucial step in ensuring its accuracy and effectiveness. The generated data is then injected into the ESC hardware system model or actual ESC hardware device within the HIL test platform for simulation testing or real-world operational testing.

[0187] D2: Compare the test results with the expected output results to see if there are any differences.

[0188] The expected output is a pre-set result intended for comparison with the test results.

[0189] D3: If the test results differ from the expected output results, obtain the difference results.

[0190] If the test result does not differ from the expected output, the test result will be output directly.

[0191] D4: The process of evaluating and verifying the differences in the results through a pre-defined analysis method to complete the testing of the electronic stability control system.

[0192] The preset analysis methods include, but are not limited to, error analysis, statistical analysis, and fault mode analysis.

[0193] In D4, the difference results are evaluated and verified by at least one of the analysis methods of error analysis, statistical analysis and failure mode analysis, and the evaluation and verification results are fed back to the target hardware-in-the-loop test model for optimization and adjustment, so as to complete the electronic stability control system test process.

[0194] To facilitate understanding the process of obtaining validated and optimized multi-scenario test data, combined with... Figure 4 To illustrate, Figure 4 A schematic diagram of the process for generating HIL test data is shown.

[0195] The connection methods and interface designs between the test data generated by the target hardware-in-the-loop test model and components such as the hardware simulator, real-time operating system, and test management software in the HIL test platform, specifically as follows: Figure 5 As shown. Figure 5 The architecture diagram of the hardware-in-the-loop test system is shown.

[0196] S107: Send the optimized test data that has not passed verification to the target hardware-in-the-loop test model for optimization and adjustment to form a closed-loop optimization verification process.

[0197] By comparing the actual output results with the expected output results, the data is evaluated and verified using methods such as error analysis, statistical analysis, and failure mode analysis. If problems are found in the data, such as the system response not meeting expectations in certain test scenarios or the failure not being effectively detected, the relevant information is fed back to the large model for regeneration or adjustment, forming a closed-loop optimization and verification process. This continuously improves the quality of HIL test data and ensures that various potential problems in the ESC system can be accurately detected.

[0198] This solution integrates the ESC HIL test data generated by the target hardware-in-the-loop test model into the existing HIL test system. During data interaction with the hardware simulator, it ensures that the generated sensor input signals are accurately and in real-time transmitted to the simulator, while also receiving hardware status information from the simulator for real-time adjustment and optimization of the test data. Regarding integration with real-time operating systems and test management software, this solution achieves efficient data management and scheduling, automatically loading and executing test data according to the test plan, monitoring and recording during the test process, and generating detailed test reports.

[0199] To facilitate understanding of the hardware-in-the-loop testing method, a scenario-based example is provided below:

[0200] 1. Implementation Example Selection:

[0201] The ESC system of a new type of automobile is selected as a specific example. This ESC system features advanced sensor technology and complex control algorithms, enabling more precise vehicle stability control. The hardware components of this ESC are described in detail, including the models and technical parameters of components such as wheel speed sensors, steering wheel angle sensors, acceleration sensors, electronic control units (ECUs), and brake actuators.

[0202] The working principles and logical relationships of its software functional modules, such as the signal acquisition and processing module, vehicle state estimation module, control strategy module, and fault diagnosis module, are introduced.

[0203] The HIL testing objectives and requirements for this ESC were clearly defined, including the regulatory standards to be met, the scope of testing conditions, and the expectations for test accuracy and coverage, providing detailed and specific background information for subsequent data generation and testing processes.

[0204] 2. Data generation process:

[0205] During the data generation phase, a large number of data sources related to the ESC were first collected, including actual driving data collected from multiple test vehicles, covering different road conditions (such as urban roads, highways, mountain roads, etc.), different driving styles (such as aggressive driving, smooth driving, etc.), and various weather conditions (such as sunny days, rainy days, snowy days, etc.), totaling more than 1,000 hours of raw data.

[0206] The raw data was cleaned and preprocessed to remove invalid data and outliers. Then, key features related to ESC performance were extracted using feature extraction techniques, such as the rate of change of wheel speed, the peak and mean of steering wheel angle, and the amplitude and direction of acceleration. These feature data were then normalized and used as training data for the large model.

[0207] The training process of the target hardware-in-the-loop test model was carried out on a high-performance computing platform, using a deep learning algorithm such as the TensorFlow framework. The initial parameters of the model were set, including the number of nodes in the hidden layer, the learning rate, the number of iterations, etc., and the optimal parameter configuration was determined through multiple experiments and optimizations. The specific training process is shown in A1-A3 above, and will not be repeated here.

[0208] When generating test data, specific test scenarios and constraints were determined based on the ESC test requirements. For example, for emergency braking test scenarios on low-friction surfaces, the initial wheel speed was set to be between 80-120 km / h, the braking deceleration was required to be between 0.6-0.8g, and the steering wheel angle during braking was set to be between -10 and 10.

[0209] Because the data generated by the target hardware-in-the-loop (HIL) test model may contain a certain degree of randomness and uncertainty, a data optimization strategy based on simulated annealing algorithm is adopted to further improve data quality and usability. Based on predefined optimization objectives, such as maximizing test coverage, improving fault detection rate, and ensuring the physical plausibility of the data, the generated test data is filtered and adjusted. For example, the simulated annealing algorithm is used to fine-tune key parameters in the test data, making them more likely to trigger potential fault modes in the ESC system while meeting physical constraints, thereby improving the sensitivity of fault detection. It optimizes test data quality by adjusting parameters and optimizes data distribution based on the characteristics of the ESC, making the test data more consistent with the actual test scenario.

[0210] In terms of improving fault detection capabilities, by finding the optimal solution and increasing fault coverage, test data can detect fault modes such as uneven brake pressure distribution and inaccurate wheel lock-up control. Simultaneously, the simulated annealing algorithm can balance multi-objective optimization, weighing different objectives and optimizing the decision-making process. Furthermore, during testing, the simulated annealing algorithm can dynamically adjust test data in real time to adapt to environmental changes and system state alterations.

[0211] The aforementioned test scenarios and constraints are input into the target hardware-in-the-loop (HIL) test model, which generates the corresponding sensor input signal sequence (i.e., the optimized HIL test input data) and the expected ESC control output signal sequence. The generated data undergoes an optimization process based on simulated annealing, further improving data quality and fault detection capabilities.

[0212] The expected ESC control output signal sequence is the output data of the large model's pre-analysis of the corresponding input test data. This data can be used as a control group for the simulation results after HIL testing, providing quantitative comparison benchmark data and accelerating problem localization.

[0213] 3. Data testing process:

[0214] On the HIL test platform, the validated and optimized test data were subjected to actual operational testing. The generated sensor signals, such as wheel speed and steering wheel angle, were transmitted in real-time to the ESC hardware simulator via a data acquisition card to simulate the actual operating state of the vehicle. Simultaneously, the ESC control output signals were monitored and compared with the expected output results. Through multiple tests and data statistics, it was found that the test data generated using the target hardware-in-the-loop test model could effectively detect some potential problems of ESC during emergency braking on low-friction surfaces, such as uneven brake pressure distribution and inaccurate wheel lock-up control—fault modes that are difficult to detect with traditional test data. After detailed analysis and feedback of the test results, the training and data generation process of the target hardware-in-the-loop test model were further optimized, continuously improving the effectiveness of HIL testing and the reliability of the ESC system.

[0215] Detailed analysis and feedback of the test results are as follows: Figure 6 As shown. This application aims to solve the problem of test data generation in HIL testing in the automotive electronics field, especially in ESC (Electronic Stability Control) testing. This application improves the testing efficiency and quality of ESC through an iterative closed-loop process of data generation, optimization, verification, and regeneration. Specifically, in the data generation stage, a large number of ESC-related data sources are collected and preprocessed, and trained using a large model architecture to generate test data that meets testing requirements. In the optimization stage, simulated annealing algorithm is used to adjust parameters and optimize data distribution according to ESC characteristics, improving test data quality and fault detection capabilities. In the verification stage, the generated data is tested on a HIL testing platform. By comparing the actual output with the expected results, data problems are identified, and test data is regenerated. This iterative closed-loop process ensures the accuracy, validity, and comprehensiveness of the test data, enhances the reliability of the ESC system, improves the overall safety and stability of the vehicle, and provides an innovative solution for the intersection of automotive electronics testing technology and artificial intelligence.

[0216] The advantages of this application are as follows:

[0217] 1. Improved testing efficiency: Traditional test data generation methods may require a lot of time and manpower to collect, organize and label, while the large model of this application can automatically generate a large amount of HIL test data in a short time, which greatly shortens the test data preparation cycle and speeds up the testing progress of the entire ESC system.

[0218] 2. Improved Test Data Quality: Intelligent Test Data Optimization: The large model can automatically optimize and filter the generated test data based on the characteristics of the ESC system and testing requirements, removing invalid or redundant data and retaining only the most valuable test data. This not only reduces test data storage space and processing time but also improves testing efficiency and accuracy, allowing testers to focus more on the analysis and resolution of key issues.

[0219] This application focuses on improving HIL (High-Intensity Logic Controller) testing technology in the automotive electronics field, specifically for ESCs (Electronic Stability Control). With the rapid development of automotive electronics technology, the reliability of ESCs, as a key system ensuring vehicle stability and safety, is paramount. HIL testing is crucial for ensuring the proper functioning of ESCs under various complex operating conditions. This patent aims to utilize large-scale modeling technology to address the problems in traditional HIL test data generation, improving ESC testing efficiency and quality, thereby enhancing the overall safety and stability of the vehicle. This application belongs to the innovative field of intersection between automotive electronics testing technology and artificial intelligence. Using ESCs as an example, this application proposes an automated HIL test data generation method. In the implementation selection of the simulation algorithm optimization section, taking ESC HIL testing as an example, it illustrates how to improve the accuracy and coverage of ESC HIL test data generation, batch generate multi-scenario test data to solve the problem of time-consuming data generation, automatically optimize data using algorithms to reduce repeated manual debugging, and create a closed loop between test data and expected results to provide a rapid comparison benchmark, directly improving testing efficiency.

[0220] The beneficial effects of this application's embodiments are as follows: Because the target hardware-in-the-loop test model can automatically optimize and filter the generated test data according to the characteristics and testing requirements of the electronic stability control system, removing invalid or redundant data and retaining only the most valuable test data, it not only reduces the storage space and processing time of test data but also improves the testing efficiency and accuracy of the electronic stability control system's hardware-in-the-loop testing. In the optimization phase, a simulated annealing algorithm is used to adjust parameters and optimize data distribution based on the characteristics of the electronic stability control system, improving test data quality and fault detection capabilities. In the verification phase, the generated data is subjected to actual operational testing. By comparing the actual output with the expected results, data problems are identified, and test data is regenerated. The optimized test data that fails verification is sent to the target hardware-in-the-loop test model for further optimization and adjustment, forming a closed-loop optimization and verification process. This iterative closed-loop process comprehensively covers all possible operating conditions and fault modes, avoiding omissions of key test points, enhancing the reliability of the electronic stability control system, and ensuring the accuracy, effectiveness, and comprehensiveness of the electronic stability control system's hardware-in-the-loop testing. Furthermore, by batch generating multi-scenario test data to solve the problem of time-consuming data generation, by automatically optimizing data through algorithms to reduce repeated manual debugging, and by providing a rapid comparison benchmark for test data and expected results in a closed loop, the sufficiency of hardware-in-the-loop testing of electronic stability control systems is improved, and the limitations of hardware-in-the-loop testing of electronic stability control systems are reduced.

[0221] Based on the hardware-in-the-loop testing method disclosed in the above embodiments, this application also discloses a hardware-in-the-loop testing device, such as... Figure 7 As shown, the hardware-in-the-loop testing device includes:

[0222] The generation unit 701 is used to generate initial test data for multiple scenarios through a pre-trained target hardware-in-the-loop test model; wherein, the target hardware-in-the-loop test model is trained by a gradient descent optimization algorithm, an adaptive learning rate adjustment strategy, and embedding vectors in an embedding space of a preset dimension.

[0223] Extraction unit 702 is used to extract hardware-in-the-loop test features related to ESC from initial test data of multiple scenarios;

[0224] Analysis unit 703 is used to analyze whether the hardware-in-the-loop test characteristics meet the normal operating range of the ESC system and obtain the analysis results.

[0225] The adjustment unit 704 is used to adjust the hardware-in-the-loop test characteristics according to the analysis results to obtain the adjusted test characteristics;

[0226] The batch optimization unit 705 is used to perform batch optimization on initial test data for multiple scenarios based on the simulated annealing algorithm, ESC system characteristics and adjusted test features, to obtain optimized test data for multiple scenarios and to verify it.

[0227] Application unit 706 is used to apply the validated and optimized multi-scenario test data to the testing of electronic stability control systems;

[0228] The optimization and adjustment unit 707 is used to send the optimized multi-scenario test data that has not passed the verification to the target hardware-in-the-loop test model for optimization and adjustment, so as to form a closed-loop optimization and verification process.

[0229] Furthermore, the generation unit 901 for the training process of the target hardware-in-the-loop test model includes:

[0230] The first acquisition module is used to acquire data from multiple channels; wherein, the multiple channel data sources consist at least of ESC operation data under different road conditions and weather conditions, physical model simulation data, and preset database data;

[0231] The preprocessing module is used to preprocess multi-channel data sources to obtain embedding vectors in a preset dimension embedding space.

[0232] The training module is used to train the initial hardware-in-the-loop test model using a gradient descent optimization algorithm, an adaptive learning rate adjustment strategy, and embedding vectors until the initial hardware-in-the-loop test model converges, resulting in the target hardware-in-the-loop test model. The initial hardware-in-the-loop test model is the untrained hardware-in-the-loop test model, while the target hardware-in-the-loop test model is the hardware-in-the-loop test model that has learned the input-output relationships, fault characteristics, and statistical laws of the data of the electronic stability control system under various operating conditions.

[0233] Furthermore, the preprocessing module includes:

[0234] The first calculation submodule is used to calculate the minimum and maximum values ​​of multi-channel data sources using a minimum-maximum normalization method;

[0235] The first mapping submodule is used to map the minimum and maximum values ​​to a preset interval according to a preset mapping formula to obtain time series features; wherein, the time series features are composed of different features at the same scale;

[0236] The second calculation submodule is used to slide a sliding window of a preset size over the time series to calculate the statistical characteristics of the sliding window.

[0237] The transformation and extraction submodule is used to transform time series features to the frequency domain through Fourier transform in order to extract frequency domain features;

[0238] The third calculation submodule is used to perform difference calculation on the time series to obtain the change between adjacent time steps, and use the change as the difference feature of the series.

[0239] The partitioning submodule is used to divide the sliding window statistical features, frequency domain features, and sequence difference features into sequence segments of preset lengths, respectively; wherein each sequence segment includes feature vectors of multiple time steps;

[0240] The second mapping submodule is used to map each sequence segment of a preset length to an embedding space of a preset dimension through the Transformer layer of the deep neural network, so as to obtain the embedding vector of the embedding space of the preset dimension.

[0241] Furthermore, the extraction unit 702 includes:

[0242] The second acquisition module is used to acquire the test objectives and test specifications of ESC;

[0243] The determination module is used to determine test requirements and constraints based on test objectives and test specifications;

[0244] The extraction and determination module is used to input test requirements and constraints into the target hardware-in-the-loop test model, so as to extract test data sequences from initial test data in multiple scenarios through the target hardware-in-the-loop test model, and determine the test data sequences as hardware-in-the-loop test features related to ESC.

[0245] Furthermore, the batch optimization unit 705 includes:

[0246] The definition module is used to define the value range and interrelationship of key parameters in the initial test data of multiple scenarios based on the vehicle dynamics model and ESC characteristics.

[0247] The batch optimization module is used to fine-tune key parameters using the simulated annealing algorithm. Under the premise of satisfying physical constraints, the key parameters are optimized in batches based on the adjusted test characteristics to obtain optimized multi-scenario test data.

[0248] Furthermore, application unit 706 includes:

[0249] The testing module is used to inject the validated and optimized multi-scenario test data into the ESC hardware system model or the actual ESC hardware device in the hardware-in-the-loop test platform for simulation testing or actual operation testing, and obtain test results.

[0250] The comparison module is used to compare the test results with the expected output results to see if there are any differences.

[0251] The third acquisition module is used to obtain the difference result if the test result differs from the expected output result;

[0252] The evaluation and verification module is used to evaluate and verify the differences in results through preset analysis methods in order to complete the testing process of the electronic stability control system.

[0253] Furthermore, the evaluation and verification module includes:

[0254] The evaluation and verification module is used to evaluate and verify the difference results through at least one of the analysis methods of error analysis, statistical analysis and failure mode analysis, and obtain the evaluation and verification results.

[0255] The feedback module is used to feed back the evaluation and verification results to the target hardware-in-the-loop test model for optimization and adjustment, so as to complete the electronic stability control system test process.

[0256] This application improves the adequacy of hardware-in-the-loop testing for electronic stability control systems and reduces the limitations of hardware-in-the-loop testing for electronic stability control systems.

[0257] This application also provides an electronic device, specifically including a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors to perform the above-described hardware-in-the-loop testing method.

Claims

1. A hardware-in-the-loop testing method, characterized in that, The method includes: Initial test data for multiple scenarios is generated through a pre-trained target hardware-in-the-loop test model; wherein, the target hardware-in-the-loop test model is trained by a gradient descent optimization algorithm, an adaptive learning rate adjustment strategy, and embedding vectors in an embedding space of a preset dimension. Extract hardware-in-the-loop test features related to the electronic stability control system from the initial test data of the multi-scenario test; Analyze whether the hardware-in-the-loop test characteristics conform to the normal operating range of the electronic stability control system, and obtain the analysis results; Based on the analysis results, the hardware-in-the-loop test characteristics are adjusted to obtain the adjusted test characteristics; Based on the simulated annealing algorithm, the characteristics of the electronic stability control system, and the adjusted test features, the initial test data for the multiple scenarios are batch optimized to obtain optimized test data for the multiple scenarios and then verified. The validated and optimized multi-scenario test data will be applied to the testing of the electronic stability control system. The optimized multi-scenario test data that fails verification is sent to the target hardware-in-the-loop test model for optimization and adjustment, so as to form a closed-loop optimization verification process.

2. The method according to claim 1, characterized in that, The training process of the target hardware-in-the-loop test model includes: Acquire data from multiple channels; wherein, the multiple channels of data sources consist at least of electronic stability control system operation data under different road conditions and weather conditions, physical model simulation data, and preset database data; The multi-channel data sources are preprocessed to obtain embedding vectors in an embedding space of a preset dimension; The initial hardware-in-the-loop test model is trained using the gradient descent optimization algorithm, adaptive learning rate adjustment strategy and embedding vector until the initial hardware-in-the-loop test model converges, thus obtaining the target hardware-in-the-loop test model. The initial hardware-in-the-loop test model is an untrained hardware-in-the-loop test model; the target hardware-in-the-loop test model is a hardware-in-the-loop test model that has learned the input-output relationship, fault characteristics, and statistical laws of the data of the electronic stability control system under various operating conditions.

3. The method according to claim 2, characterized in that, The step of preprocessing the multi-channel data sources to obtain embedding vectors in a preset-dimensional embedding space includes: The minimum and maximum values ​​of the multi-channel data sources are calculated using a min-max normalization method; The minimum and maximum values ​​are mapped to a preset interval according to a preset mapping formula to obtain time series features; wherein, the time series features are composed of different features at the same scale; By sliding a window of a preset size across the time series, the statistical characteristics of the sliding window can be calculated. The time series features are transformed to the frequency domain using Fourier transform to extract frequency domain features; The time series is differentially calculated to obtain the change between adjacent time steps, and the change is used as the sequence difference feature. The sliding window statistical features, the frequency domain features, and the sequence difference features are each divided into sequence segments of a preset length; wherein each sequence segment includes feature vectors for multiple time steps; The preset length sequence segments are mapped to a preset dimension embedding space through the Transformer layer of a deep neural network, resulting in an embedding vector for the preset dimension embedding space.

4. The method according to claim 1, characterized in that, The extraction of hardware-in-the-loop test features related to the electronic stability control system from the initial test data of the multiple scenarios includes: Obtain the test objectives and test specifications for the electronic stability control system; Based on the test objectives and test specifications, determine the test requirements and constraints; The test requirements and constraints are input into the target hardware-in-the-loop test model to extract test data sequences from the initial test data of the multi-scenario test model, and the test data sequences are determined as hardware-in-the-loop test features related to the electronic stability control system.

5. The method according to claim 1, characterized in that, The step involves batch optimizing the initial test data for multiple scenarios based on the simulated annealing algorithm, the characteristics of the electronic stability control system, and the adjusted test features, to obtain optimized multi-scenario test data, which is then verified. Based on the vehicle dynamics model and the characteristics of the electronic stability control system, the value range and interrelationship of key parameters in the initial test data of multiple scenarios are defined. The key parameters are fine-tuned by using simulated annealing algorithm, so that the key parameters meet the physical constraints. Based on the adjusted test characteristics, the initial test data of the multiple scenarios are batch optimized to obtain optimized test data of the multiple scenarios.

6. The method according to claim 1, characterized in that, The application of the validated and optimized multi-scenario test data to the electronic stability control system test includes: The validated and optimized multi-scenario test data is injected into the electronic stability control system hardware system model or the actual electronic stability control system hardware device in the hardware-in-the-loop test platform for simulation testing or actual operation testing to obtain test results. Compare the test results with the expected output results to see if there are any differences; If the test results differ from the expected output results, the difference results are obtained. The difference results are evaluated and verified using a preset analysis method to complete the testing process of the electronic stability control system.

7. The method according to claim 6, characterized in that, The process of evaluating and verifying the difference results through a preset analysis method to complete the electronic stability control system test includes: The difference results are evaluated and verified by at least one of the following analytical methods: error analysis, statistical analysis, and failure mode analysis, to obtain the evaluation and verification results; The evaluation and verification results are fed back to the target hardware-in-the-loop test model for optimization and adjustment, in order to complete the electronic stability control system test process.

8. A hardware-in-the-loop testing device, characterized in that, The device includes: The generation unit is used to generate initial test data for multiple scenarios through a pre-trained target hardware-in-the-loop test model; wherein the target hardware-in-the-loop test model is trained by a gradient descent optimization algorithm, an adaptive learning rate adjustment strategy, and embedding vectors in an embedding space of a preset dimension. The extraction unit is used to extract hardware-in-the-loop test features related to the electronic stability control system from the initial test data of the multi-scenario system. The analysis unit is used to analyze whether the hardware-in-the-loop test characteristics conform to the normal operating range of the electronic stability control system and obtain the analysis results. An adjustment unit is used to adjust the hardware-in-the-loop test characteristics based on the analysis results to obtain the adjusted test characteristics; The batch optimization unit is used to perform batch optimization on the initial test data of the multi-scenario based on the simulated annealing algorithm, the characteristics of the electronic stability control system and the adjusted test characteristics, so as to obtain optimized multi-scenario test data and verify it. The application unit is used to apply the validated and optimized multi-scenario test data to the electronic stability control system test; The optimization and adjustment unit is used to send the optimized multi-scenario test data that has failed verification to the target hardware-in-the-loop test model for optimization and adjustment, so as to form a closed-loop optimization and verification process.

9. The apparatus according to claim 8, characterized in that, The generation units during the training process of the target hardware-in-the-loop test model include: The acquisition module is used to acquire data from multiple channels; wherein, the multiple channels data source consists of at least electronic stability control system operation data under different road conditions and weather conditions, physical model simulation data, and preset database data; The preprocessing module is used to preprocess the multi-channel data sources to obtain embedding vectors in an embedding space of a preset dimension. The training module is used to train the initial hardware-in-the-loop test model using a gradient descent optimization algorithm, an adaptive learning rate adjustment strategy, and an embedding vector, until the initial hardware-in-the-loop test model converges to obtain the target hardware-in-the-loop test model. The initial hardware-in-the-loop test model is an untrained hardware-in-the-loop test model; the target hardware-in-the-loop test model is a hardware-in-the-loop test model that has learned the input-output relationships, fault characteristics, and statistical patterns of the electronic stability control system under various operating conditions.

10. An electronic device, characterized in that, It includes a memory, and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the hardware-in-the-loop testing method as described in any one of claims 1 to 7.

Images