Hardware-in-the-loop automatic test method and system

Abstract

The invention discloses a hardware-in-the-loop automatic test method and system, and the method comprises the steps: receiving a technical specification document and a historical failure case library of a tested device, analyzing a technical specification through a natural language processing model to extract key test parameters, carrying out the correlation analysis of the key test parameters and a fault mode in the historical failure case library, and obtaining a fault mode of the tested device; generating a structured test demand table, wherein the structured test demand table comprises test target priorities, constraint conditions and boundary value definitions; based on the structured test demand table and equipment working condition data acquired in real time, generating a plurality of test cases covering boundary conditions and extreme working conditions by using a genetic algorithm; the test cases covering the boundary conditions and the extreme working conditions are screened out from the multiple test cases to obtain a test case sequence, and each case in the test case sequence comprises a fault injection parameter, an expected response threshold value and an execution priority label. According to the method and system, the test coverage rate and efficiency are improved, and manual intervention is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of hardware-in-the-loop testing, in particular to a hardware-in-the-loop automated testing method and system. BACKGROUND

[0002] Hardware-in-the-loop testing (HIL) as a core means of complex system verification plays a key role in the fields of automotive electronic control systems, aerospace equipment and new energy power systems. The traditional HIL testing process has significant technical bottlenecks in the two core links of test case design and test result analysis:

[0003] The test case generation efficiency and coverage are insufficient, and the current test case design highly depends on the experience of engineers, which needs to traverse the function scenarios and fault modes manually. In hardware-in-the-loop testing, different parameter inputs and fault injection timing need to be defined manually, which leads to incomplete coverage of test scenarios (such as missing boundary conditions and transient working conditions), and the test case generation period is long and the efficiency is low.

[0004] The test result analysis is still mainly processed offline by manual, and lacks real-time feature extraction capability for massive test data, which leads to the inability of dynamic iteration of test strategy based on historical data. SUMMARY

[0005] To solve the technical problems in the background art, the present application provides a hardware-in-the-loop automated testing method and system.

[0006] The hardware-in-the-loop automated testing method provided by the present application comprises:

[0007] Receiving the technical specification document and the historical failure case library of the device under test, analyzing the technical specification by a natural language processing model to extract key test parameters, and correlating the key test parameters with the fault modes in the historical failure case library to generate a structured test requirement table, the structured test requirement table containing test target priority, constraint conditions and boundary value definition;

[0008] Based on the structured test requirement table and the real-time collected device working condition data, a plurality of test cases covering boundary conditions and extreme working conditions are generated by using a genetic algorithm;

[0009] From the plurality of test cases, test cases covering boundary conditions and extreme working conditions are selected to obtain a test case sequence, each case in the test case sequence containing fault injection parameters, expected response threshold and execution priority label;

[0010] The test case sequence is executed on the device under test, and real-time response data of the device under test is collected and analyzed to dynamically adjust the test case sequence.

[0011] Preferably, the key test parameters include, but are not limited to, working voltage range, temperature threshold and signal response time; and the correlation analysis includes matching the correlation between historical failure modes and the key test parameters through a cosine similarity algorithm, and assigning a risk weight to each failure mode.

[0012] Preferably, the population initialization of the genetic algorithm generates extreme working condition parameters based on Monte Carlo simulation, including voltage transient fluctuation ± 20%, low temperature-40℃ startup and communication signal delay 0-500ms.

[0013] Preferably, the test cases covering boundary conditions and extreme working conditions are selected from a plurality of test cases, specifically: the failure coverage of the test cases is evaluated through a reinforcement learning model, and the test cases meeting a coverage threshold are selected from a plurality of test cases.

[0014] Preferably, the coverage threshold is set to be ≥ 95%.

[0015] Preferably, the real-time response data of the device under test is collected and analyzed to dynamically adjust the test case sequence, specifically including:

[0016] for any test case in the test case sequence;

[0017] if the real-time response data reflects that no failure is detected for consecutive N times of testing, the execution priority of the test case is reduced;

[0018] if the real-time response data reflects that the test case detects a new failure mode, the test case sequence is updated, and the execution order and resource allocation ratio of subsequent test cases are dynamically adjusted.

[0019] Preferably, it further includes:

[0020] updating the new failure mode detected in the test process and the adjusted test strategy to the historical failure case library; and optimizing the natural language processing model and the parameter configuration of the genetic algorithm through an incremental learning algorithm.

[0021] Preferably, the failure modes include, but are not limited to, electrical failure, mechanical failure, software / firmware failure, environmental adaptability failure, communication failure, power management failure, sensor / actuator failure.

[0022] The present application provides a hardware-in-the-loop automated test system, which comprises:

[0023] The collection module is used for receiving a technical specification document and a historical failure case library of the device under test, analyzing the technical specification by a natural language processing model to extract key test parameters, and performing correlation analysis on the key test parameters and failure modes in the historical failure case library to generate a structured test requirement table, wherein the structured test requirement table comprises test target priorities, constraint conditions and boundary value definitions.

[0024] The test case generation module is used for generating a plurality of test cases covering boundary conditions and extreme working conditions based on the structured test requirement table and real-time collected device working condition data by using a genetic algorithm.

[0025] The analysis module is used for screening test cases covering boundary conditions and extreme working conditions from the plurality of test cases to obtain a test case sequence, wherein each test case in the test case sequence comprises a fault injection parameter, an expected response threshold and an execution priority label.

[0026] The execution module is used for executing the test case sequence on the device under test, collecting and analyzing real-time response data of the device under test to dynamically adjust the test case sequence.

[0027] In the present application, the hardware-in-the-loop automated testing method and system are proposed, the technical specification is analyzed by natural language processing and correlated with historical failure modes to generate a structured test requirement, a test case sequence covering boundary conditions and extreme working conditions is generated by using a genetic algorithm, and the test execution logic is optimized through real-time data analysis and dynamic adjustment mechanism. The method significantly improves the test coverage and efficiency, reduces manual intervention and test time, can cover more boundary conditions and extreme cases, and ensures the comprehensiveness of the test. BRIEF DESCRIPTION OF DRAWINGS

[0028] Figure 1 A workflow structure schematic diagram of the hardware-in-the-loop automated testing method is provided in the present application.

[0029] Figure 2 A system architecture schematic diagram of the hardware-in-the-loop automated testing system is provided in the present application. DETAILED DESCRIPTION

[0030] REFERENCE Figure 1 and Figure 2 The hardware-in-the-loop automated testing method provided in the present application comprises the following steps:

[0031] S1, receiving a technical specification document and a historical failure case library of the device under test, analyzing the technical specification by a natural language processing model to extract key test parameters, and performing correlation analysis on the key test parameters and failure modes in the historical failure case library to generate a structured test requirement table, wherein the structured test requirement table comprises test target priorities, constraint conditions and boundary value definitions.

[0032] Specifically, in hardware-in-the-loop automated testing, the technical specification document of the device under test is parsed by a natural language processing (NLP) model to extract key test parameters (such as operating voltage range, temperature threshold, signal response time, etc.), and then these parameters are analyzed in association with the failure modes in the historical failure case library. Specifically, cosine similarity algorithm or clustering analysis (such as K-means) is used to calculate the matching degree of the current test parameters and the historical failure characteristics (such as failure type, triggering condition, device state), and to identify high-frequency or high-risk failure scenarios (such as voltage drop leading to system restart). Based on the analysis results, a structured test requirement table is generated, which includes:

[0033] Test target priority: According to the severity (critical / serious / general) and frequency (high / medium / low) of the failure, the priority is divided, for example, the high-frequency and critical failure such as "voltage lower than 9V leading to downtime" is set as the highest priority;

[0034] Constraints: Clearly define the limitations of the test environment (such as temperature range -40℃~125℃, maximum test duration ≤24 hours) and resource requirements (such as load current ≤100A);

[0035] Boundary value definition: Based on the critical parameters in the historical failure cases (such as communication delay tolerance upper limit 500ms, voltage transient fluctuation ±20%), the upper and lower limit values of each test parameter are set.

[0036] The finally generated structured test requirement table is stored in table or JSON format, supporting the subsequent automatic generation and dynamic optimization of test cases.

[0037] S2, based on the structured test requirement table and the real-time collected device working condition data, a plurality of test cases covering boundary conditions and extreme working conditions are generated by using genetic algorithm.

[0038] In this embodiment, the population initialization of genetic algorithm generates extreme working condition parameters based on Monte Carlo simulation, including voltage transient fluctuation ±20%, low temperature -40℃ startup and communication signal delay 0-500ms.

[0039] Specifically, in hardware-in-the-loop automated testing, based on the structured test requirement table (including test target priority, constraint condition and boundary value definition) and the real-time collected device working condition data (such as temperature, voltage, communication load, etc.), test cases covering boundary conditions and extreme working conditions are generated by using genetic algorithm. The specific process is as follows:

[0040] According to the boundary values in the structured requirements (such as voltage range 9V-16V, temperature threshold -40℃~125℃), initial test parameter combinations are generated by Monte Carlo simulation, covering normal conditions, boundary conditions (such as voltage critical value ±5%) and extreme conditions (such as high temperature + full load). Real-time working condition data is used to dynamically adjust the distribution of the initial population (for example, if the current device temperature is 80℃, high-temperature related test cases are generated preferentially).

[0041] The fitness value is defined as the coverage of test cases on boundary conditions, extreme conditions and historical high-frequency fault modes;

[0042] The following indicators are weighted: boundary coverage score (such as whether voltage = 16V is included); extreme scenario score (such as whether the combination of temperature 125℃ + voltage step-down 20% is generated); risk priority score (reference to the coverage of high-weight fault modes in the structured requirement table). The roulette algorithm is used to preferentially retain test cases with high fitness; the parameters of the two parent cases (such as temperature, voltage, signal delay) are exchanged in segments to generate child cases; extreme values are introduced by randomly perturbing parameters with a low probability (such as suddenly changing voltage from 15V to 16.5V). After each iteration, the feasibility of the test cases is evaluated by a reinforcement learning model (such as whether the simulation model pre-verification will cause device damage); cases that do not meet the constraint conditions (such as test duration > 24 hours) or are redundant are eliminated, and the test case sequence with the best coverage is retained. Real-time working condition data (such as the current temperature of the device 90℃) triggers the algorithm to focus on generating related extreme cases (such as temperature rising to 125℃ and superimposing communication load); if a certain type of fault mode frequently occurs in testing, the mutation probability of its corresponding parameter is increased to enhance coverage strength.

[0043] Specifically, relevant examples are as follows:

[0044] Boundary condition case: voltage = 9V (lower limit) + temperature = 125℃ (upper limit) + communication delay = 500ms (critical value);

[0045] Extreme condition case: voltage transient fluctuation ±20% (nominal 12V) superimposed with vibration frequency 200Hz;

[0046] High-risk scenario case: simulate historical high-frequency fault "CAN bus timeout + low temperature -40℃ startup".

[0047] S3, test cases covering boundary conditions and extreme conditions are selected from multiple test cases to obtain a test case sequence, each test case in the test case sequence includes fault injection parameters, expected response threshold and execution priority label.

[0048] In the embodiment, the test cases covering boundary conditions and extreme working conditions are screened from a plurality of test cases, specifically: the fault coverage of the test cases is evaluated by the reinforcement learning model, and the test cases meeting the coverage threshold are screened from the plurality of test cases.

[0049] Specifically, the coverage threshold is set to be greater than or equal to 95%.

[0050] S4, the test case sequence is executed on the device under test, and real-time response data of the device under test is collected and analyzed to dynamically adjust the test case sequence.

[0051] In the embodiment, the real-time response data of the device under test is collected and analyzed to dynamically adjust the test case sequence, specifically including:

[0052] For any test case in the test case sequence;

[0053] If the real-time response data reflects that no fault is detected for consecutive N times of testing, the execution priority of the test case is reduced;

[0054] If the real-time response data reflects that the test case detects a new fault mode, the test case sequence is updated, and the execution order and resource allocation ratio of the subsequent test cases are dynamically adjusted.

[0055] In the embodiment, it also includes:

[0056] The new fault mode detected in the test process and the adjusted test strategy are updated to the historical failure case library; the natural language processing model and the parameter configuration of the genetic algorithm are optimized by the incremental learning algorithm.

[0057] In the embodiment, the fault mode includes but is not limited to electrical fault, mechanical fault, software / firmware fault, environmental adaptability fault, communication fault, power management fault, sensor / actuator fault.

[0058] Referring to Figure 1 and Figure 2 , the application provides a hardware-in-the-loop automated test system, which comprises:

[0059] The acquisition module is configured to receive technical specification documents and a historical failure case library of the device under test, analyze the technical specification by a natural language processing model to extract key test parameters, and perform correlation analysis on the key test parameters and fault modes in the historical failure case library to generate a structured test requirement table, wherein the structured test requirement table includes test target priority, constraint conditions and boundary value definitions.

[0060] The test case generation module is configured to generate a plurality of test cases covering boundary conditions and extreme working conditions based on the structured test requirement table and real-time collected device working condition data by using a genetic algorithm.

[0061] an analysis module configured to filter test cases covering boundary conditions and extreme working conditions from the plurality of test cases to obtain a test case sequence, each test case in the test case sequence comprising a fault injection parameter, an expected response threshold, and an execution priority label;

[0062] an execution module configured to execute the test case sequence on the device under test, collect and analyze real-time response data of the device under test to dynamically adjust the test case sequence.

[0063] In the embodiment, the system is composed of a data perception layer, an intelligent decision-making layer, and an execution control layer. The data perception layer deploys a high-speed acquisition card and a protocol converter to capture electrical signals and simulation model state variables of the DUT in real time. The intelligent decision-making layer integrates a GPU-accelerated AI computing unit to run core algorithms such as test case generation, parameter optimization, and abnormality diagnosis. The execution control layer includes a programmable load box, a fault injection module, and a real-time simulator to execute the test instructions generated by AI.

[0064] It should be noted that during the application of the system, the system workflow is as follows:

[0065] 1. Hardware connection and initialization

[0066] The hardware under test (such as the electronic control unit ECU of an electric vehicle) is connected to the test platform through a hardware interface module. This module is responsible for converting hardware signals into a format recognizable by the platform and synchronizing the running state of the hardware. During the initialization process, the software automatically identifies the hardware type and configuration, loads the relevant drivers and test framework.

[0067] 2. Intelligent test case generation

[0068] The system generates test cases with extensive coverage based on the hardware interface, working principle, and historical test data through AI algorithms (such as deep neural networks). Boundary conditions, extreme working environments (such as high temperature, low temperature, voltage fluctuations, etc.), and test scenarios that may cause hardware failure are considered. Test cases include normal operation, fault injection, system fault tolerance, and other scenarios. Each test case involves the input-output behavior of the hardware, signal changes, abnormality detection, etc.

[0069] 3. Adaptive learning and optimization

[0070] After each test execution, the system analyzes the test results and adjusts and optimizes the subsequent test cases. The AI module continuously learns from historical data to gradually improve the coverage of the test and reduce redundant tests.

[0071] For example, when a test case repeatedly produces the same test results, the system adjusts the test strategy to enhance testing of uncovered boundary conditions or extreme cases, avoiding repetitive testing and improving efficiency. The system automatically identifies potential issues that have not been tested through deep learning algorithms and adjusts the test strategy based on feedback, making the testing process increasingly intelligent.

[0072] 4. Test Control and Execution

[0073] The test control module is responsible for scheduling and executing test tasks, and real-time monitoring of hardware behavior.

[0074] The system can control the input signals of the hardware according to the test cases, and collect the output data through the hardware interface module. These data are used to compare with the expected behavior to determine the success or failure of the test.

[0075] The test process supports parallel execution, enabling simultaneous testing of multiple different scenarios, greatly improving test efficiency.

[0076] 5. Result Analysis and Fault Diagnosis

[0077] After the test is completed, the system will generate a detailed test report through the result analysis and report module, including the execution results of each test case, the cause analysis of success and failure. Identify abnormal patterns in test data and automatically perform fault diagnosis. Through machine learning technology, the system can provide possible causes of the fault, the scope of influence, and suggest solutions. For example, if the input voltage is too low during the test, causing the system to restart, the system will automatically analyze and report this problem and suggest optimizing the hardware design. The system also supports cross-departmental sharing of reports, providing different forms of report output (such as PDF, Excel, HTML, etc.), helping engineers quickly analyze and make decisions.

[0078] 6. User Interface and Operation

[0079] Users configure the test environment through an intuitive interface, select the hardware to be tested and load test cases. The system interface supports drag-and-drop operations, allowing users to customize test scenarios and adjust test parameters as needed.

[0080] The interface design is simple, and all test steps can be completed with a simple mouse click. During the test execution process, users can view the test progress, execution status, and current hardware status in real time.

[0081] Users can also view real-time analysis and feedback of test data through a graphical interface, quickly locating problem areas.

[0082] The above merely describes preferred specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art, according to the technical solution and inventive concept of the present application, makes equivalent replacement or change within the technical range disclosed by the present application, which should be covered within the protection scope of the present application.

Claims

1. A hardware-in-the-loop automated testing method, characterized in that: include: Receive technical specification documents and a historical failure case library of the device under test, parse the technical specifications using a natural language processing model to extract key test parameters, perform correlation analysis on the key test parameters and failure modes in the historical failure case library, and generate a structured test requirement table containing test target priorities, constraints, and boundary value definitions; Based on the structured test requirement table and the real-time collected equipment operating condition data, a genetic algorithm is used to generate multiple test cases covering boundary conditions and extreme operating conditions; Filter out test cases that cover boundary conditions and extreme working conditions from multiple test cases to obtain a test case sequence. Each test case in the test case sequence includes fault injection parameters, expected response thresholds, and execution priority labels. The test case sequence is executed on the device under test, and real-time response data of the device under test is collected and analyzed to dynamically adjust the test case sequence.

2. The hardware-in-the-loop automated testing method according to claim 1, wherein: The key test parameters include but are not limited to operating voltage range, temperature threshold and signal response time; the correlation analysis includes matching the correlation between historical failure modes and key test parameters through a cosine similarity algorithm, and assigning a risk weight to each failure mode.

3. The hardware-in-the-loop automated testing method according to claim 1, wherein: The population initialization of the genetic algorithm generates extreme operating condition parameters based on Monte Carlo simulation, and the extreme operating condition parameters include voltage transient fluctuation ±20%, low temperature startup at -40°C, and communication signal delay of 0-500ms.

4. The hardware-in-the-loop automated testing method according to claim 1, wherein: The method of screening out test cases that cover boundary conditions and extreme working conditions from a plurality of test cases specifically includes: evaluating the fault coverage of the test cases through a reinforcement learning model, and screening out test cases that meet the coverage threshold from a plurality of test cases.

5. The hardware-in-the-loop automated testing method according to claim 1, wherein: The coverage threshold was set at ≥95%.

6. The hardware-in-the-loop automated testing method according to claim 1, wherein: The collecting and analyzing of real-time response data of the device under test to dynamically adjust the test case sequence specifically includes: For any test case in the test case sequence; If the real-time response data indicates that no fault is detected in N consecutive tests, the execution priority of the test case is lowered; If the real-time response data reflects that the test case detects a new failure mode, the test case sequence is updated, and the execution order and resource allocation ratio of subsequent test cases are dynamically adjusted.

7. The hardware-in-the-loop automated testing method according to claim 4, wherein: Also includes: Update the new failure modes and adjusted test strategies detected during the test process to the historical failure case library; The parameter configuration of the natural language processing model and the genetic algorithm is optimized through an incremental learning algorithm.

8. The hardware-in-the-loop automated testing method according to claim 1, wherein: The failure modes include, but are not limited to, electrical failure, mechanical failure, software / firmware failure, environmental adaptability failure, communication failure, power management failure, and sensor / actuator failure.

9. A hardware-in-the-loop automated testing system, characterized in that: include: An acquisition module is configured to receive technical specification documents and a historical failure case library of the device under test, parse the technical specifications using a natural language processing model to extract key test parameters, perform correlation analysis on the key test parameters and the failure modes in the historical failure case library, and generate a structured test requirement table containing test target priorities, constraints, and boundary value definitions; A test case generation module is used to generate multiple test cases covering boundary conditions and extreme conditions using a genetic algorithm based on the structured test requirement table and the equipment operating condition data collected in real time; An analysis module is used to filter out test cases that cover boundary conditions and extreme working conditions from multiple test cases to obtain a test case sequence. Each test case in the test case sequence contains fault injection parameters, expected response thresholds, and execution priority labels; The execution module is used to execute the test case sequence on the device under test, collect and analyze the real-time response data of the device under test, and dynamically adjust the test case sequence.

Images