Embedded software automatic testing system and method based on hardware-in-the-loop
By using a hardware-in-the-loop test system based on RBAC access control and FPGA protocol support, the problems of high cost and poor scalability of existing systems are solved, enabling efficient and flexible automated testing of embedded software and improving the verification efficiency and accuracy of complex systems.
Patent Information
- Application Number
- CN202511371110.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-24
- Publication Date
- 2026-01-16
AI Technical Summary
Existing hardware-in-the-loop testing systems have high initial investment and maintenance costs, poor scalability, and poor interface compatibility, making it difficult to meet the comprehensive verification needs of complex systems.
It adopts fine-grained permission isolation based on RBAC permission tree and JWT token, combines genetic algorithm to optimize test queue sorting, and utilizes FPGA to implement multi-path protocol support through real-time communication between software test platform and hardware-in-the-loop platform. It also integrates Kalman filtering and Delta coding to compress test reports, forming a fully closed-loop test ecosystem.
It shortens the verification cycle of complex systems, improves the defect detection rate, reduces the risk of unauthorized operation, and improves the utilization rate of test resources and the versatility of the system.
Smart Images

Figure CN121349864A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of embedded software automatic testing, in particular to a hardware-in-the-loop based embedded software automatic testing system and method. BACKGROUND
[0002] With the rapid development of today's technology, more and more complex systems such as automotive electronic control systems, aerospace flight control systems, etc., have higher and higher requirements for safety and reliability. Traditional testing methods, such as physical prototype testing, require the construction of actual physical models for testing, which not only requires a large investment in model manufacturing and equipment setup, but also has a long testing period. Once a problem is found, the cost of modification is high. Moreover, for some dangerous or difficult-to-reproduce scenarios, physical prototype testing is difficult to effectively simulate, and the performance and reliability of the system under various extreme conditions cannot be fully verified.
[0003] Hardware-in-the-loop (HIL) testing systems were thus born. This system combines actual hardware devices with computer-simulated system models to carry out testing (as described in patent CN110119347A). The core is to use a real-time simulator and corresponding I / O interface to feed back the actual signals output by the control algorithm to the simulator, thereby building a closed-loop testing environment. In this way, the controller can be tested comprehensively and realistically without affecting the real system, covering from simple functional scenarios to complex functional scenarios, including fault injection, extreme condition simulation, and other testing content.
[0004] Application No. 202311281169.4 discloses a system, method, computer-readable storage medium, and computer device for hardware-in-the-loop automatic testing management. The system includes at least a cloud testing platform, an application container engine, a robot control system, and a hardware-in-the-loop simulation platform. The cloud testing platform includes a test confirmation module, a test distribution module, a schedule module, and a client interaction module. The test distribution module is configured to intelligently distribute hardware-in-the-loop testing tasks based on test task information provided by the test confirmation module, schedule information provided by the schedule module, and basic information of the hardware feedback from the hardware-in-the-loop simulation platform. Through the above-mentioned invention, for manual testing and automatic testing, the cloud testing platform, the hardware-in-the-loop simulation platform, and the robot control system can quickly interact to automatically switch hardware in the hardware-in-the-loop simulation platform, intelligently distribute testing tasks, reduce labor costs, and improve testing efficiency.
[0005] The prior art in the above has the following defects: 1. Most of the existing hardware-in-the-loop systems need to be equipped with high-performance real-time processors, high-precision I / O interfaces, special simulation software and customized test tools, and the initial investment and maintenance cost is huge; 2. The existing hardware-in-the-loop system needs to be customized for different test objects, and the interface adaptability is poor, which leads to great limitations in scalability. SUMMARY
[0006] In view of the deficiencies in the prior art, the purpose of the present application is achieved by the following technical solutions: A hardware-in-the-loop based embedded software automatic test system, comprising: A software test platform configured to configure corresponding operation permissions according to different role accounts, create test cases in combination with test objects, generate corresponding test tasks, and transmit the test tasks to a hardware-in-the-loop platform according to a preset queue mechanism, while receiving test running data fed back by the hardware-in-the-loop platform to construct a test report; The hardware-in-the-loop platform is configured to receive and analyze the test tasks, control different functional modules to complete testing and verification in combination with test boards according to a preset test configuration file, generate the test running data, and feed back to the software test platform; The software test platform communicates with the test object in real time through a debugger, and the hardware-in-the-loop platform communicates with the software test platform in real time through high-speed Ethernet.
[0007] By adopting the above technical solutions, the software test platform integrates a dynamic permission control algorithm based on an RBAC model, automatically associates role accounts with test objects to generate a minimum permission test case set, and optimizes test queue sorting using a genetic algorithm. After being transmitted to the hardware-in-the-loop platform through a message middleware (such as RabbitMQ), the real-time kernel schedules FPGA programmable logic resources to load test configuration files, drives multiple PXIe board cards to execute a synchronous excitation-acquisition cycle, combines Kalman filtering to fuse sensor data and digital twin expected values to achieve millisecond-level fault diagnosis, and finally uses Delta encoding to compress the test report feedback to form a "requirement-case-execution-verification" full-closed-loop test ecology. Through the physical level precision of the hardware-in-the-loop and the intelligent arrangement capability of the software platform, the complex system verification cycle is shortened and the defect detection rate is improved, and through the three binding mechanisms of permission-case-hardware, the risk of unauthorized operation is eliminated.
[0008] The application further provides that the software test platform comprises: A user management module configured to create or assign different role accounts by a super administrator, and assign corresponding operation permissions; the role accounts include ordinary users, audit users, project administrators and the super administrator; The project review module is used by the reviewing user to review and filter all test applications, export test cases and test reports, and generate test progress notifications. The version management module is used by the project administrator to create a test baseline version based on the test application, associate it with the test requirement document, create test cases, and track the coverage of the test cases. The test case management module is used by ordinary users to configure project configuration files, write test code, generate test tasks, and submit them to the queue scheduling module after verification, based on the test case and the object to be tested. The queue scheduling module is used to submit the test tasks to the test task management module according to the task submission time and test priority based on a preset queue mechanism. The test task management module is used by the reviewing user to view all the test tasks, export test cases and test reports, and monitor test progress. The results analysis module is used to analyze and push the test report and the test progress notification to the corresponding role account.
[0009] By adopting the above technical solution, fine-grained permission isolation of role accounts (ordinary users / auditors / project administrators / super administrators) is achieved based on RBAC permission trees and JWT tokens. A dynamic workflow engine drives a closed-loop process across the entire chain, from test case creation (ordinary users) to priority queue scheduling (weighted round-robin algorithm), multi-level auditing (auditors), version association (Git version tree matching requirement documents), and result analysis (APRIORI algorithm for defect pattern discovery). The queue scheduling module integrates task submission timestamps with predefined priority coefficients (e.g., weight of security-critical modules = 0.8) to generate the optimal test sequence. The version management module tracks coverage by real-time calculation of the hash mapping matrix between requirement IDs and test cases. The result analysis module uses incremental Delta report compression technology to achieve second-level test report push. A strong binding mechanism of permissions, processes, and data ensures zero unauthorized operations during the testing process, reduces manual intervention, and improves hardware resource utilization through intelligent scheduling algorithms.
[0010] The present invention is further configured such that the hardware-in-the-loop platform includes: The code parsing module is used to receive test tasks and parse them into task execution instructions and functional test logic; The test execution module is used to sequentially allocate the task execution instructions to the corresponding built-in functional modules according to the time sequence and the functional test logic; the built-in functional modules include a digital-to-analog converter module, a pulse width modulation module, a digital input / output interface, a serial peripheral interface, an integrated circuit bus, a multimedia communication interface, and a single-sided half-word transmission protocol. The instance control module is used by the built-in functional module to execute the task execution instructions to run the test board and peripheral resources, and to provide feedback on the test execution data; The report generation module is used to verify the test execution data based on the test cases and generate a test report; the test report includes hardware and software configuration, test pass rate, error log, test case classification statistics, test cycle, input-output comparison chart and boundary condition verification results; The digital-to-analog converter module is used to convert digital signals into analog signals. The digital-to-analog converter module includes multiple high-speed digital-to-analog converters and multiple low-speed digital-to-analog converters. The multiple high-speed digital-to-analog converters have a speed of 1MHz and a precision of 16bit, and perform data synchronization updates and output according to a first-in-first-out queue. The multiple low-speed digital-to-analog converters have a speed of 1KHz and a precision of 12bit. The pulse width modulation module is used to output and acquire PWM waveforms with a frequency of 0-20MHz and a duty cycle of 0-100%, and to count the number of pulses and the duration of high and low levels. The digital input / output interface is used for bidirectional input and output of digital signals and to remove signal jitter; The serial peripheral interface is used to transmit the most significant bit and least significant bit data of variable data length through a four-wire synchronous serial communication mode, and to measure Cs2Clk, Clk2Cs, inter-frame idle time and clock signal oscillation frequency through time parameters. The integrated circuit bus includes a master-slave mode, which controls whether to send or not send an acknowledgment character bit when acting as a slave device, and the clock frequency adjustment range is 100KHz-1MHz; the multimedia communication interface is used to receive data frames and command frames. The single-sided half-word transmission protocol includes dual communication channels, dynamic stress testing, and fault injection diagnosis; the dual communication channels include a fast data channel and a slow data channel; the dynamic stress testing includes time base configuration, cyclic redundancy check, and simple error check; the fault injection diagnosis includes timeout faults and check faults.
[0011] The hardware-in-the-loop platform includes a field-programmable gate array (FPGA) chip, which can change the function of the pins by switching the code stream.
[0012] By adopting the above technical solution, the code parsing module driven by the time-series scheduling algorithm decomposes the test task into atomic instructions (such as 16-bit / 1MHz high-speed DAC signal generation or 0-20MHz PWM duty cycle acquisition), which are dynamically allocated to heterogeneous functional modules through the real-time kernel (SPI four-wire synchronous communication uses a clock phase optimization algorithm to eliminate Cs2Clk timing deviation, and I²C master-slave mode uses an ACK / NACK prediction mechanism to improve transmission reliability under 1MHz clock). The instance control module performs closed-loop testing in combination with dual communication channels (fast channel transmission + slow channel verification). The dynamic stress test injects a fault model based on Markov chain (covering 12 types of defects such as timeout / CRC error), and the report generation module automatically verifies boundary conditions through a differential comparison algorithm (SSIM structure similarity evaluation of input and output waveforms), and finally generates a multi-dimensional test report (including pass rate statistics, defect clustering analysis, etc.). Through the deep coupling of hardware layer nanosecond-level synchronization and algorithm layer intelligent diagnosis (fault location accuracy down to the pin level), the test cycle of complex systems is compressed. At the same time, the test coverage is improved and the false alarm rate is reduced by relying on a fully automated pipeline.
[0013] Secondly, this invention also provides an automated testing method for embedded software based on hardware-in-the-loop, employing the following technical solution: A hardware-in-the-loop (HIL) based automated testing method for embedded software, applied to the aforementioned automated testing system for embedded software, includes: Create and store test projects in the software testing platform, associate them with test requirement documents, and create baseline versions; Apply for the test project in the software testing platform and write test cases or test case code, set and execute the project configuration file, and generate test tasks; Add the test task to a queue, generate a unique queue identifier, and monitor the task status by viewing the queue. During test task execution, the test cases or test case code are converted through a hardware-in-the-loop platform to obtain the task test script; The hardware-in-the-loop platform receives and parses the task test script, generates task execution instructions and functional test logic, and at the same time the test board receives and burns the items to be tested, and sends test signals after the burning is completed. According to the time sequence and the functional test logic, the task execution instructions are assigned to the corresponding built-in functional modules, and the test operation data is obtained by combining the test signals. The test run data is transmitted to the software testing platform through the test board, and the task test script verifies the test run data and obtains the verification result. Based on the verification results, a test report containing the test pass rate and error logs is automatically generated and transmitted to the corresponding role account.
[0014] By adopting the above technical solution, test traceability is ensured through hash mapping (SHA-256 algorithm) between the baseline version and the requirements document. A weighted round-robin queue scheduling algorithm is used to allocate test tasks to the hardware-in-the-loop platform. On the HIL side, a real-time instruction parsing engine is used to convert test case code into atomic operations (such as 16-bit DAC signal generation or PWM duty cycle acquisition). Based on timestamps, functional modules are driven to work with the board under test to execute the test signal excitation-acquisition closed loop. After the test data is verified by the XOR check algorithm, a multi-dimensional report is generated (automatically marking the line number of failed test cases). This achieves full-process automation from requirement association to defect location. The test cycle is compressed through the hardware and software collaboration mechanism, and the error detection rate is improved by relying on baseline version control and real-time data verification.
[0015] In summary, the beneficial technical effects of the present invention are as follows: 1. By leveraging the physical-level precision of hardware-in-the-loop and the intelligent orchestration capabilities of the software platform, the verification cycle of complex systems is shortened and the defect detection rate is improved. Furthermore, user responsibilities are clearly defined to ensure standardized testing processes and reduce the risk of misoperation. The entire process from test case writing to report generation is automated, reducing manual intervention. Multi-task parallel queuing and priority adjustment are supported to improve the utilization of test resources. It is compatible with multiple hardware protocols and adapts to different types of target test boards, enhancing the system's versatility.
[0016] 2. Through an innovative hardware-in-the-loop testing architecture and efficient software platform design, a powerful, flexible, easy-to-use, efficient, and reliable hardware-in-the-loop embedded software automated testing system has been implemented; it not only meets a wide range of testing needs but also provides strong support for continuous improvement of software quality. Attached Figure Description
[0017] Figure 1 This is a schematic diagram of the embedded software automated testing system according to one embodiment of the present invention.
[0018] Figure 2 This is a schematic diagram of the internal operation process of the hardware-in-the-loop platform in Embodiment 3 of the present invention.
[0019] Figure 3 This is a schematic diagram of the internal connections of the hardware-in-the-loop platform in Embodiment 3 of the present invention.
[0020] Figure 4 This is a schematic diagram of the embedded software automated testing method according to Embodiment 4 of the present invention. Detailed Implementation
[0021] The present invention will be further described in detail below with reference to the accompanying drawings.
[0022] Example 1: Reference Figure 1 The present invention discloses a hardware-in-the-loop-based automated testing system for embedded software, comprising: The software testing platform is used to configure corresponding operation permissions according to different role accounts, create test cases in combination with the object under test, generate corresponding test tasks, and transmit them to the hardware-in-the-loop platform according to a preset queue mechanism. At the same time, it receives test run data fed back by the hardware-in-the-loop platform to construct test reports. The hardware-in-the-loop platform is used to receive and parse the test tasks, control different functional modules to complete the tests and verifications according to the preset test configuration files and the test board, generate the test run data, and feed it back to the software test platform. The software testing platform communicates with the object under test in real time through a debugger, and the hardware-in-the-loop platform communicates with the software testing platform in real time through a high-speed Ethernet. In this embodiment, the software testing platform sets up multiple user permissions, each user permission corresponds to different operation functions, the test process is automated through a queue mechanism, and the test results are generated into a report and fed back to the software testing platform after the hardware-in-the-loop platform interacts with the test board. The hardware-in-the-loop platform establishes a high-speed communication link with the software testing platform via Ethernet, simulates the electrical characteristics and dynamic response of the object under test in real time, and performs closed-loop data interaction with the object under test; the hardware-in-the-loop platform synchronously collects key parameters, processes them through a dedicated algorithm, and feeds them back to the software testing platform to form a complete test data chain.
[0023] In this embodiment, the software testing platform is deployed on a PC, employing a B / S architecture. This not only ensures the system's scalability and maintainability but also facilitates remote access and operation via a browser. Developed using Vue and Python FastAPI frameworks, the database uses MySQL to store user data and test cases, providing users with secure and reliable protection. The hardware-in-the-loop platform, acting as a bridge between the PC and hardware devices, is of paramount importance. The FPGA, as the core controller of this module, leverages its powerful parallel processing capabilities and high programmability to support multiple interface protocols such as CAN, Ethernet, and UART. This not only allows the system to flexibly adapt to different types of hardware devices but also ensures efficient and stable data transmission. Furthermore, the FPGA's programmability enables subsequent system upgrades and optimizations.
[0024] The implementation principle of this embodiment is as follows: The software testing platform, based on the RBAC model (super administrator permission coefficient 1.0, project administrator 0.7, audit user 0.5, ordinary user 0.3), dynamically renders the operation interface through the VUE front-end. After verifying permissions using JWT tokens (valid for 30 minutes) through the FastAPI back-end, it generates tasks from test cases in MySQL related to requirement documents (coverage threshold ≥95%) according to urgency weights (high / medium / low = 0.8 / 0.5 / 0.2) using a weighted round-robin queue scheduling algorithm. These tasks are then distributed to the hardware-in-the-loop platform via high-speed Ethernet (transmission latency ≤2ms); FPGA real-time... The task is parsed and the test configuration is loaded (CAN baud rate 1Mbps / Ethernet frame interval ≤10μs). Multiple DACs (high-speed: 1MHz / 16bit±0.0015V, low-speed: 1KHz / 12bit±4mV) and PWM modules (frequency 0-20MHz±0.1%, duty cycle 0-100%±0.5%) output excitation signals. Simultaneously, test board response data is acquired (SPI clock phase deviation ±100ns, I²C bus timeout failure rate ≤1%). The data is verified through dual-channel communication (fast channel throughput ≥100Mbps, slow channel CRC32 error rate <10⁻). 7 After that, combined with fault injection diagnosis (timeout fault threshold 150ms, CRC error rate 15%), a test report is generated (pass rate statistical accuracy ±0.05%, error log located to the pin level), and finally pushed to the front end in real time via WebSocket.
[0025] Example 2: Reference Figure 1 The software testing platform includes: The user management module is used by the super administrator to create or assign different role accounts and assign corresponding operation permissions; the role accounts include ordinary users, auditing users, project administrators and the super administrator; In this embodiment, the user permission management process is as follows: The super administrator creates / assigns accounts with different roles (ordinary users, review users, and project administrators) through the user management module and assigns corresponding operation permissions to achieve operation isolation; After logging in, ordinary users first apply for a project, and after approval, they create test cases in the test case management module, configure project configuration files, and support writing test code. After passing the test and submitting for execution, the test cases enter the queue scheduling module, where the system sorts them according to the submission time and priority; Review users view all projects through the project review module, support exporting test cases and test reports, and monitor test progress in real time; Project administrators create project versions in the version management module, associate them with test requirement documents, track test case coverage, and monitor test progress in real time; All operations (such as test task completion and project review result notification) are pushed to relevant users in real time through the platform notification bar.
[0026] The project review module is used by the reviewing user to review and filter all test applications, export test cases and test reports, and generate test progress notifications. The version management module is used by the project administrator to create a test baseline version based on the test application, associate it with the test requirement document, create test cases, and track the coverage of the test cases. The test case management module is used by ordinary users to configure project configuration files, write test code, generate test tasks, and submit them to the queue scheduling module after verification, based on the test case and the object to be tested. The queue scheduling module is used to submit the test tasks to the test task management module according to the task submission time and test priority based on a preset queue mechanism. The test task management module is used by the reviewing user to view all the test tasks, export test cases and test reports, and monitor test progress. The results analysis module is used to analyze and push the test report and the test progress notification to the corresponding role account.
[0027] In this embodiment, the functional module division of the software testing platform further reveals the system's software architecture. The four core components—user management module, test case management module, and result analysis module—each perform their respective functions, collectively forming the system's complete functional architecture. The user management module ensures the security and integrity of user information while providing a user-friendly front-end interface, enabling users to easily complete authentication and operations within their authorized scope. The test case management module supports users in creating, editing, deleting, and importing / exporting test cases, greatly improving the efficiency of the test preparation phase.
[0028] The implementation principle of this embodiment is as follows: The user management module realizes the dynamic allocation and revocation of role permissions. The super administrator creates a four-layer role system and configures fine-grained operation permissions. The project review module generates a standardized test application process based on the screening operation of the reviewing users. Simultaneously, the version management module is triggered to establish a baseline version and associate it with the requirement document. The project administrator creates test cases covering the requirement traceability matrix. Ordinary users call the versioned test case library in the test case management module to configure the test environment. After code verification, they submit tasks to the queue scheduling module. This module dynamically allocates test resources through resource usage detection and priority algorithm. The test task management module monitors the task status in real time. When an anomaly occurs, it triggers root cause analysis and links with the result analysis module to generate a visual report. Finally, the complete test conclusions of the audit log are pushed according to role permissions, forming an automated test management ecosystem of "access control - process drive - resource optimization - closed-loop feedback".
[0029] Example 3: Reference Figures 2-3 The hardware-in-the-loop platform includes: The code parsing module is used to receive test tasks and parse them into task execution instructions and functional test logic; The test execution module is used to sequentially allocate the task execution instructions to the corresponding built-in functional modules according to the time sequence and the functional test logic; the built-in functional modules include a digital-to-analog converter module, a pulse width modulation module, a digital input / output interface, a serial peripheral interface, an integrated circuit bus, a multimedia communication interface, and a single-sided half-word transmission protocol. The instance control module is used by the built-in functional module to execute the task execution instructions to run the test board and peripheral resources, and to provide feedback on the test execution data; The report generation module is used to verify the test execution data based on the test cases and generate a test report; the test report includes hardware and software configuration, test pass rate, error log, test case classification statistics, test cycle, input-output comparison chart and boundary condition verification results; The digital-to-analog converter module is used to convert digital signals into analog signals. The digital-to-analog converter module includes multiple high-speed digital-to-analog converters and multiple low-speed digital-to-analog converters. The multiple high-speed digital-to-analog converters have a speed of 1MHz and a precision of 16bit, and perform data synchronization updates and output according to a first-in-first-out queue. The multiple low-speed digital-to-analog converters have a speed of 1KHz and a precision of 12bit. The pulse width modulation module is used to output and acquire PWM waveforms with a frequency of 0-20MHz and a duty cycle of 0-100%, and to count the number of pulses and the duration of high and low levels. The digital input / output interface is used for bidirectional input and output of digital signals and to remove signal jitter; The serial peripheral interface is used to transmit the most significant bit and least significant bit data of variable data length through a four-wire synchronous serial communication mode, and to measure Cs2Clk, Clk2Cs, inter-frame idle time and clock signal oscillation frequency through time parameters. The integrated circuit bus includes a master-slave mode, which controls whether to send or not send an acknowledgment character bit when acting as a slave device, and the clock frequency adjustment range is 100KHz-1MHz; the multimedia communication interface is used to receive data frames and command frames. The single-sided half-word transmission protocol includes dual communication channels, dynamic stress testing, and fault injection diagnosis; the dual communication channels include a fast data channel and a slow data channel; the dynamic stress testing includes time base configuration, cyclic redundancy check, and simple error check; the fault injection diagnosis includes timeout faults and check faults.
[0030] The hardware-in-the-loop platform includes a field-programmable gate array (FPGA) chip, which can change the function of the pins by switching the bit stream.
[0031] In this embodiment, the hardware-in-the-loop platform provides the following various test resources: multi-channel DAC modules, multi-channel PWM modules, DIO resources, SPI resources, I2C resources, MSC communication resources, and SENT single-sided half-word transmission protocol. The hardware-in-the-loop platform establishes a high-speed communication link with the test system via Ethernet, simulating data exchange between the controlled object and the object under test, and feeding back test operation data to the test system in real time. The hardware-in-the-loop platform can achieve pin multiplexing by switching code streams and drivers, which improves the scalability of the entire test system and reduces the overall system cost.
[0032] The implementation principle of this embodiment is as follows: the hardware-in-the-loop platform decomposes the test task into atomic operations (such as a 16-bit / 1MHz high-speed DAC outputting a ±0.0015V precision signal or a 20MHz...) through a real-time instruction parsing engine. The PWM duty cycle acquisition error is ±0.1%. Based on the FPGA timestamp scheduler (clock jitter ≤5ns), the multi-function module is synchronously driven. The SPI module transmits MSB / LSB data streams in four-wire synchronous mode (Cs2Clk setup time ≥50ns). The I²C slave device dynamically adjusts the clock frequency (100KHz-1MHz) and decides the ACK / NACK response. The single-sided half-word transmission protocol implements dual-channel stress testing (fast channel 100Mbps throughput / slow channel CRC32 bit error rate) and fault injection (timeout threshold 150ms±5%, CRC error rate 15%±1%). The instance control module reuses pin resources (supports online switching of 8 protocols) to stimulate the test board. The synchronously acquired response data is XORed and then compared by the report generation module with the input and output waveforms and statistical boundary conditions (such as ADC linearity error <1% under temperature change of -40℃~150℃). Finally, a multi-dimensional report with pin-level defect location (pass rate accuracy ±0.05%) is generated and transmitted back to the software test platform in real time via Gigabit Ethernet.
[0033] Example 4: Reference Figure 4 A hardware-in-the-loop (HIL) based automated testing method for embedded software, applied to the aforementioned hardware-in-the-loop based automated testing system for embedded software, comprising: Create and store test projects in the software testing platform, associate them with test requirement documents, and create baseline versions; Apply for the test project in the software testing platform and write test cases or test case code, set and execute the project configuration file, and generate test tasks; Add the test task to a queue, generate a unique queue identifier, and monitor the task status by viewing the queue. During test task execution, the test cases or test case code are converted through a hardware-in-the-loop platform to obtain the task test script; The hardware-in-the-loop platform receives and parses the task test script, generates task execution instructions and functional test logic, and at the same time the test board receives and burns the items to be tested, and sends test signals after the burning is completed. According to the time sequence and the functional test logic, the task execution instructions are assigned to the corresponding built-in functional modules, and the test operation data is obtained by combining the test signals. The test run data is transmitted to the software testing platform through the test board, and the task test script verifies the test run data and obtains the verification result. Based on the verification results, a test report containing the test pass rate and error logs is automatically generated and transmitted to the corresponding role account.
[0034] The implementation principle of this embodiment is as follows: The software testing platform creates a baseline version (coverage ≥95%) through requirement document hash matching (SHA-256). When ordinary users write test case code, it triggers syntax tree analysis (Python AST parsing) and dependency verification. After generating test tasks, a weighted polling queue (urgent weight 0.8) assigns a unique ID. The FPGA real-time kernel of the hardware-in-the-loop platform parses the task script, synchronously burns the test items to the test board (JTAG rate 30MHz) and sends a start signal. Based on the timestamp scheduler, it drives the multi-module collaborative execution, and injects CRC faults (bit error rate 15%±1%) using the one-sided half-word transmission protocol. The test board response data is returned after dual-channel verification (fast channel 100Mbps / slow channel XOR verification). The task script automatically compares the expected value (waveform SSIM>0.98, boundary condition temperature change -40℃~150℃) and generates a report containing pin-level error location (APRIORI defect clustering) (pass rate accuracy ±0.05%), which is finally pushed to the corresponding user via WebSocket.
[0035] The embodiments described herein are preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape, and principle of the present invention should be covered within the scope of protection of the present invention.
Claims
1. A hardware-in-the-loop based embedded software automatic testing system, comprising: a software testing platform configured to configure corresponding operation permissions according to different role accounts, create test cases in combination with a to-be-tested object, generate corresponding test tasks, and transmit the test tasks to a hardware-in-the-loop platform according to a preset queue mechanism, while receiving test running data fed back by the hardware-in-the-loop platform to construct a test report; the hardware-in-the-loop platform configured to receive and analyze the test tasks, control different functional modules to complete testing and verification in combination with a test board according to a preset test configuration file, generate the test running data, and feed back to the software testing platform; the software testing platform is in real-time communication with the to-be-tested object through a debugger, and the hardware-in-the-loop platform is in real-time communication with the software testing platform through high-speed Ethernet.
2. The hardware-in-the-loop based embedded software automated test system of claim 1, wherein, the software testing platform comprises: a user management module configured to create or assign different role accounts by a super administrator, and assign corresponding operation permissions; the role accounts include ordinary users, audit users, project administrators, and the super administrator; a project audit module configured to audit and screen all test applications by the audit users, export test cases and test reports, and generate test progress notifications; a version management module configured to create a test baseline version according to the test applications by the project administrators, associate a test requirement document, create test cases, and track coverage of the test cases; a test case management module configured to configure a project configuration file, write test code, generate test tasks, and complete verification and then submit to a queue scheduling module by the ordinary users according to the to-be-tested object in combination with the test cases; the queue scheduling module configured to submit the test tasks to a test task management module according to a task submission time and a test priority according to a preset queue mechanism; the test task management module configured to view all the test tasks by the audit users, export test cases and test reports, and monitor test progress; a result analysis module configured to analyze and push the test reports and the test progress notifications to corresponding role accounts.
3. The hardware-in-the-loop based embedded software automated test system of claim 1, wherein, the hardware-in-the-loop platform comprises: a code analysis module configured to receive test tasks and analyze them into task execution instructions and functional test logic; a test execution module configured to sequentially assign the task execution instructions to corresponding built-in functional modules according to a time sequence according to the functional test logic; the built-in functional modules include a digital-analog conversion module, a pulse width modulation module, a digital input-output interface, a serial peripheral interface, an integrated circuit bus, a multimedia communication interface, and a single-edge half-word transmission protocol; an instance control module configured to run a test board and peripheral resources by the built-in functional modules executing the task execution instructions, and feed back test running data; a report generation module configured to verify the test running data according to test cases, and generate a test report; the test report includes software and hardware configurations, test pass rates, error logs, case classification statistics, test periods, input-output comparison charts, and boundary condition verification results.
4. The hardware-in-the-loop based embedded software automated test system of claim 3, wherein: The digital-to-analog conversion module is used for converting digital signals into analog signals, and comprises a plurality of high-speed digital-to-analog converters and a plurality of low-speed digital-to-analog converters. The plurality of high-speed digital-to-analog converters have a rate of 1 MHz and a precision of 16 bits, and perform data synchronization update and output according to a first-in-first-out queue; the plurality of low-speed digital-to-analog converters have a rate of 1 kHz and a precision of 12 bits.
5. The hardware-in-the-loop based embedded software automated test system of claim 3, wherein: The pulse width modulation module is used for outputting a PWM waveform with a frequency of 0-20 MHz and a duty cycle of 0-100%, and counting the number of pulses and the time of high and low levels.
6. The hardware-in-the-loop based embedded software automated test system of claim 3, wherein: The digital input and output interface is used for bidirectional input and output of digital signals, and removes signal jitter.
7. The hardware-in-the-loop based embedded software automated test system of claim 3, wherein: The serial peripheral interface is used for transmitting most significant bit data and least significant bit data with an unfixed data length through a four-wire synchronous serial communication mode, and measuring Cs2Clk, Clk2Cs, interframe idle time and clock signal oscillation frequency through time parameters.
8. The hardware-in-the-loop based embedded software automated test system of claim 3, wherein: The integrated circuit bus comprises a master-slave mode, and when acting as a slave device, controls sending or not sending an acknowledgement character bit, and the adjustment interval of the clock frequency is 100 kHz-1 MHz; the multimedia communication interface is used for receiving data frames and command frames.
9. The hardware-in-the-loop based embedded software automated test system of claim 3, wherein: The single-edge half-word transmission protocol comprises a double communication channel, a dynamic stress test and a fault injection diagnosis; the double communication channel comprises a data fast channel and a data slow channel; the dynamic stress test comprises time base configuration, cyclic redundancy check and simple error check; The fault injection diagnosis comprises a timeout fault and a check fault.
10. A hardware-in-the-loop based embedded software automated testing method, characterized by, Comprise: Creating and storing a test project in a software testing platform, associating a test requirement document, and creating a baseline version; Applying the test project in the software testing platform and writing a test case or test case code, setting and executing a project configuration file, and generating a test task; Adding the test task to a queue, generating a queue unique identifier, and monitoring the task state by checking the queue; When the test task is executed, converting the test case or the test case code through a hardware-in-the-loop platform to obtain a task test script; The hardware-in-the-loop platform receives and analyzes the task test script to generate a task execution instruction and a functional test logic, and a test board receives a to-be-tested project for burning, sends a test signal after burning is completed; According to a time sequence, the task execution instruction is distributed to a corresponding built-in functional module according to the functional test logic, and test running data is obtained in combination with the test signal; The test running data is transmitted to the software testing platform through the test board, the task test script checks the test running data to obtain a check result; A test report containing a test pass rate and an error log is automatically generated according to the check result and is transmitted to a corresponding role account.
Citation Information
Patent Citations
Scene design method based on Control component in LoadRunner
CN110119347A
Systems, methods, media and devices for hardware-in-loop automated test management
CN119759747A
