Abnormal program positioning method, test system, device, equipment, medium and product

Abstract

This application relates to an anomaly location method, testing system, apparatus, equipment, medium, and product. The method includes: determining the location of stub programs that the test program of the device under test (DUT) reaches during the abnormal operating conditions of the hardware-in-the-loop test; pre-setting multiple stub programs at critical program locations in the DUT's test program through stub insertion; and determining the anomaly location result in the test program based on the location of the stub programs reached during the abnormal operating conditions. This method can improve the efficiency of anomaly location.

Description

Technical Field

[0001] This application relates to the field of new energy technology, and in particular to an abnormal program location method, testing system, device, equipment, medium and product. Background Technology

[0002] Hardware-in-the-Loop (HiL) testing is a testing method that combines the device under test (DUT) with a virtual simulation environment. It is mainly used to verify the functionality, performance, and reliability of the DUT in complex real-world environments.

[0003] Taking hardware-in-the-loop testing of automotive electronics as an example, the data monitoring solution for hardware-in-the-loop testing of automotive electronics mainly uses simulation software in computer equipment to simulate communication with the device under test (such as the whole vehicle or devices in the vehicle), obtains the running data during the test in the simulation software, and observes whether the changes in the running data during the test meet expectations, whether there are any faults, etc., to determine whether the test passes.

[0004] However, in related technologies, hardware-in-the-loop testing requires examining the test program line by line in the device under test (DUT) when the test fails, which leads to low efficiency in identifying the abnormal program. Summary of the Invention

[0005] Based on this, this application provides an abnormal program location method, testing system, apparatus, equipment, medium, and product, which can improve the efficiency of identifying abnormal programs.

[0006] In a first aspect, this application provides an abnormal program location method, which includes: determining the location of the stub program that the test program of the device under test runs to when there is an abnormal operating condition during the hardware-in-the-loop test of the device under test; multiple stub programs are pre-set at the key program locations in the test program of the device under test by stub insertion; and determining the abnormal program location result in the test program based on the location of the stub program that the test program runs to when there is an abnormal operating condition.

[0007] The technical solution provided in this application addresses the fact that switching the operating conditions of the device under test (DUT) leads to switching of program execution. When the DUT has an abnormal operating condition, it indicates that the program after the switch is abnormal. Thus, when an abnormal operating condition is triggered, the computer device obtains the location of the stub program that the test program runs to during the abnormal operating condition, thereby quickly locking the abnormal program in the test program when the abnormal operating condition occurs. Compared with the solution of checking the test program in the DUT line by line to locate the abnormal program in the test program, this application embodiment can improve the efficiency of identifying the abnormal program.

[0008] In some embodiments, determining the location of the stub program to which the test program of the device under test (DUT) runs under abnormal operating conditions includes: acquiring the system time when the abnormal operating condition occurs, and acquiring the running times and locations of multiple stub programs; determining the running time of a target stub program that matches the system time when the abnormal operating condition occurs from the running times of the multiple stub programs; determining the location of the target stub program corresponding to the running time of the target stub program from the locations of the multiple stub programs, and determining the location of the target stub program as the location of the stub program to which the test program of the DUT runs under abnormal operating conditions.

[0009] In the technical solution provided by this application embodiment, in the event of an abnormal operating condition, the system time when the abnormality occurs is matched with the running time of the stub program, thereby enabling the location of the target stub program being executed at the time of the abnormality. This effectively avoids the asynchrony between the acquisition of running data under each operating condition and the acquisition of multiple stub program locations. For example, if the communication link used to transmit the locations of multiple stub programs is delayed, the acquisition of running data under the i-th (exemplarily, i is an integer greater than or equal to 3) operating condition may result in the acquisition of the location of the stub program under the (i-2)-th operating condition, leading to a deviation in the location of the target stub program determined based on the current time. Therefore, by synchronizing the acquisition time of the running data with the running time of the stub program, this application embodiment can improve the accuracy of the determined location of the target stub program.

[0010] In some embodiments, the hardware-in-the-loop test of the device under test (DUT) exhibits an abnormal operating condition, including: acquiring the operating data of the DUT under each operating condition and the system time of each operating condition during multiple operating condition tests in the hardware-in-the-loop test of the DUT; identifying abnormal operating data in the operating data under each operating condition and determining the operating condition corresponding to the abnormal operating data as an abnormal operating condition; and acquiring the system time of the abnormal operating condition, including: determining the system time of the abnormal operating condition based on the system time of each operating condition.

[0011] In the technical solution provided in this application embodiment, abnormal operating conditions are determined by operating data under each operating condition, thereby providing a quantitative standard for determining abnormal operating conditions and improving the accuracy of determining abnormal operating conditions; and by determining the system time of occurrence of abnormal operating conditions through the correlation between operating data under each operating condition and the system time of occurrence of each operating condition, the accuracy of determining the system time of occurrence of abnormal operating conditions is improved.

[0012] In some embodiments, determining abnormal operating data in the operating data under each operating condition includes: acquiring multiple types of variables to be tested and determining the normal value range of each type of operating data corresponding to each type of variable to be tested; determining the operating data under each type of variable to be tested from the operating data under multiple operating conditions; and determining the operating data that is outside the normal value range of each type of operating data as abnormal operating data.

[0013] In the technical solution provided in this application embodiment, by determining the normal value range of each type of test variable corresponding to each type of running data, it is possible to accurately detect the abnormal conditions of running data under each type of test variable, thereby improving the accuracy of abnormal running data determination.

[0014] In some embodiments, obtaining the runtime and location of multiple stub programs includes: sending a variable type to be tested to the device under test; the variable type is used by the device under test to enable multiple stub programs at the key program location associated with the variable type, and the enabled multiple stub programs are used to provide feedback on the runtime and location of the multiple stub programs; and receiving the runtime and location of the multiple stub programs sent by the device under test.

[0015] In the technical solution provided in this application embodiment, multiple stub programs are enabled at key program locations associated with the test variable type by using the test variable type. Thus, the test device only enables stub programs at the key program locations associated with the required test variable type, reducing the number of stub programs running in the test program, increasing the execution speed of the test program, thereby improving the testing efficiency of the test device, and reducing the difference between the test time and the actual running time of the test device, thus improving the effectiveness of the test of the test device.

[0016] In some embodiments, determining the runtime of a target staking program that matches the system time of an abnormal operating condition from the runtime times of multiple staking programs includes: obtaining the time delay between the test start time of the test program and the runtime start time of the test program; determining a reference time of the abnormal operating condition based on the time delay and the system time of the abnormal operating condition; and determining the runtime of the target staking program that matches the system time of the abnormal operating condition from the runtime times of multiple staking programs based on the reference time of the abnormal operating condition.

[0017] In the technical solution provided in this application embodiment, the reference time of the abnormal working condition is determined based on the time delay and the system time of the abnormal working condition. This enables the system time recorded by the computer device to be strictly aligned with the timing of the timer in the device under test. This is beneficial for determining the running time of the target stub program that matches the system time of the abnormal working condition from the running times of multiple stub programs, and improves the accuracy of determining the running time of the target stub program.

[0018] In some embodiments, obtaining the time delay between the test start time of the test program and the run start time of the test program includes: obtaining a first time delay between the test start time of the test program and the time when the power supply voltage of the device under test reaches a stable voltage; wherein the test program starts initialization when the power supply voltage of the device under test reaches a stable voltage; obtaining a second time delay between the initialization start time of the test program and the run start time of the test program; and determining the time delay based on the first time delay and the second time delay.

[0019] In the technical solution provided in this application embodiment, the determination of the time delay not only takes into account the first time delay between the start time of the test program and the time when the power supply voltage of the device under test reaches a stable voltage, but also takes into account the second time delay between the initialization start time of the test program and the start time of the test program, thereby improving the accuracy of the determined time delay.

[0020] In some embodiments, determining the reference time of the abnormal operating condition based on the time delay and the system time of the abnormal operating condition includes: determining the reference time of the abnormal operating condition based on the system time of the abnormal operating condition and the test start time of the test program; and determining the reference time of the abnormal operating condition based on the time delay and the reference time of the abnormal operating condition.

[0021] In the technical solution provided in this application embodiment, since the determination of the reference time of the occurrence of abnormal working conditions not only takes into account the system time of the occurrence of abnormal working conditions and the test start time of the test program, but also needs to take into account the time delay between the test start time and the run start time of the test program, the reference time of the occurrence of abnormal working conditions can be accurately matched with the timing time of the timer of the device under test, thereby improving the accuracy of the determined reference time of the occurrence of abnormal working conditions.

[0022] In some embodiments, based on the reference time when the abnormal operating condition occurs, determining the running time of the target piling program that matches the system time of the abnormal operating condition from the running times of multiple piling programs includes: obtaining the latest reference time obtained under the previous operating condition of the abnormal operating condition, and determining a target time interval between the latest reference time obtained under the previous operating condition and the reference time when the abnormal operating condition occurs; determining the running time of the piling program located in the target time interval from the running times of multiple piling programs; and determining the running time of the piling program located in the target time interval as the running time of the target piling program that matches the system time of the abnormal operating condition.

[0023] In the technical solution provided in this application embodiment, by determining the target time interval between the latest obtained reference time under the previous operating condition and the reference time when the abnormal operating condition occurs, the target time interval can reflect the time interval of the abnormal program running corresponding to the abnormal operating condition, thereby determining the running time of the pile program located in the target time interval, which can accurately reflect the running time of the abnormal program corresponding to the abnormal operating condition, and improve the accuracy of the determined running time of the target pile program.

[0024] In some embodiments, determining the abnormal program location result in the test program based on the location of the stub program to which the test program runs under abnormal operating conditions includes: determining the target program location matched under abnormal operating conditions based on the location of the stub program to which the test program runs under abnormal operating conditions; determining the location of each set program matched under each normal operating condition before the abnormal operating conditions; and determining the abnormal program location result in the test program based on the target program location and each set program location.

[0025] In the technical solution provided by this application embodiment, since there is still a large amount of data in the target program position of the abnormal working condition matching, the abnormal program location result in the test program is determined according to the target program position of the abnormal working condition matching and the set program positions of each normal working condition matching before the abnormal working condition. This can avoid the situation of checking the target program position of the abnormal working condition matching line by line. Therefore, the embodiment of this application can improve the efficiency of determining the abnormal program location result.

[0026] In some embodiments, determining the abnormal program location result in the test program based on the target program location and each set program location includes: determining the union program location of all set program locations; and determining the program locations of the target program location that are not included in the union program locations as the abnormal program location result in the test program.

[0027] In the technical solution provided in this application embodiment, by determining the program position that is not included in the union program position of the target program position as the abnormal program location result in the test program, the program under normal working conditions can be excluded, and the abnormal program location result is located to the position where the program has not appeared under normal working conditions. This avoids repeatedly checking the program under normal working conditions and improves the effectiveness of the abnormal program location result determined in the test program.

[0028] In some embodiments, before determining the location of the stub program to which the test program of the device under test runs under abnormal operating conditions, the method further includes: in response to a test start command to start testing the test program, sending operating condition parameters of each operating condition to a test bench connected to the device under test; wherein the operating condition parameters of each operating condition are used by the test bench to simulate an environment that matches the operating condition parameters of each operating condition, so that the device under test runs under each operating condition.

[0029] In the technical solution provided in this application embodiment, the test bench simulates the environment matching the operating parameters of each operating condition according to the operating parameters of each operating condition sent by the computer equipment, without the need for manual adjustment of the operation of the test bench, thus improving the testing efficiency of the device under test.

[0030] Secondly, this application provides a hardware-in-the-loop testing system, which includes a computer device and a device under test (DUT). The computer device is connected to the DUT. The computer device is used to determine the location of the stub program that the DUT's test program runs to under abnormal operating conditions during the hardware-in-the-loop testing of the DUT. Multiple stub programs are pre-set at the critical program locations in the DUT's test program through instrumentation. The abnormal program location result in the test program is determined based on the location of the stub program that the test program runs to under abnormal operating conditions.

[0031] In some embodiments, the hardware-in-the-loop testing system further includes a communication device and a debugger; the computer device connects to the device under test (DUT) via the communication device; the computer device also connects to the DUT via the debugger; the DUT is used to send operating data under multiple operating conditions to the computer device via the communication device, and to send the locations of multiple stub programs to the computer device via the debugger.

[0032] In some embodiments, the hardware-in-the-loop test system further includes a test bench; the test bench is connected to the device under test (DUT), and a computer device is also connected to the test bench via a communication device; the computer device is further configured to, in response to a test start command to begin testing the test program, send operating condition parameters for each operating condition to the test bench connected to the DUT via the communication device; the test bench is configured to simulate an environment matching the operating condition parameters for each operating condition, so that the DUT operates under each operating condition.

[0033] Thirdly, this application provides an abnormal program location device, which includes: a location determination module, used to determine the location of the stub program that the test program of the device under test runs to when there is an abnormal operating condition during the hardware-in-the-loop test of the device under test; multiple stub programs are pre-set at the key program locations in the test program of the device under test by stub insertion; and a result determination module, used to determine the abnormal program location result in the test program based on the location of the stub program that the test program runs to when there is an abnormal operating condition.

[0034] Fourthly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method of any one of the first aspects.

[0035] Fifthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method of any one of the first aspects.

[0036] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method in any of the first aspects. Attached Figure Description

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

[0038] Figure 1 Schematic diagrams of the hardware-in-the-loop test system provided in some embodiments;

[0039] Figure 2 Schematic diagrams of the hardware-in-the-loop test system provided for other embodiments;

[0040] Figure 3 A flowchart illustrating the abnormal program location method provided in the first embodiment;

[0041] Figure 4 A flowchart illustrating the abnormal program location method provided in the second embodiment;

[0042] Figure 5 A flowchart illustrating a method for determining the execution time of a target pile program that matches the system time of an abnormal operating condition, as provided in some embodiments.

[0043] Figure 6 A flowchart illustrating the abnormal program location method provided in the third embodiment;

[0044] Figure 7 A flowchart illustrating the abnormal program location method provided in the fourth embodiment;

[0045] Figure 8 A schematic diagram of a hardware-in-the-loop test system is provided as another embodiment;

[0046] Figure 9 A schematic diagram of the structure of an abnormal program location device provided in some embodiments;

[0047] Figure 10 A schematic diagram of the structure of a computer device provided for some embodiments. Detailed Implementation

[0048] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0050] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined. In the description of the embodiments of this application, "each" means each of the multiple options, unless otherwise explicitly defined.

[0051] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0052] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0053] Figure 1 A schematic diagram of the hardware-in-the-loop test system provided in some embodiments, such as Figure 1 As shown, the hardware-in-the-loop test system includes a computer, communication equipment, a device under test (DUT), and a test bench. The computer is connected to the DUT via the communication equipment, and the computer is also connected to the test bench via the communication equipment.

[0054] For example, the computer equipment may include one of the following: a test host, a computer, an industrial control computer, or a server. For example, the communication equipment may include a CAN communication device or a satellite communication device. For example, the device under test may be a vehicle or a processing device within a vehicle; for example, the processing device may include a Battery Management System (BMS) or an Electronic Control Unit (ECU).

[0055] Test benches are used to simulate the real-world operating environment of the device under test (DUT). For example, a test bench can provide high and low voltage to the DUT to enable its operation. Alternatively, a test bench can provide the DUT with simulated signals of an engine operating at different speeds and loads, thus providing the DUT with an operating environment under varying speeds and loads.

[0056] Computer equipment can acquire the operational data of the device under test (DUT) through communication devices, and determine whether the DUT has passed the test based on whether the operational data is abnormal. For example, the computer equipment may have CANoe or TSMaster software installed, which can be used to acquire the DUT's operational data.

[0057] exist Figure 1 In the illustrated embodiment, hardware-in-the-loop testing determines whether the device under test (DUT) passes the test. If the DUT fails the test, the common practice is to check the test program line by line to locate the faulty program. However, this approach leads to low efficiency in identifying the faulty program.

[0058] To alleviate the aforementioned problems, research has revealed that multiple stub programs are pre-set at critical program locations in the test program of the device under test (DUT). These stub programs provide real-time feedback on their execution positions. Anomalies in the test program can lead to abnormal operating conditions in the hardware-in-the-loop (HIL) test of the DUT. When an abnormal operating condition is detected in the HIL test of the DUT, the location of the stub program at that abnormal condition is determined. Based on the location of the stub program at that abnormal condition, the location of the abnormal program within the test program is determined. This approach takes into account that the switching of the DUT's operating conditions leads to a switching of program execution. The presence of an abnormal operating condition in the DUT indicates an anomaly in the switched program. Thus, when an abnormal operating condition is triggered, the computer device obtains the location of the stub program at that abnormal condition, thereby quickly locating the abnormal program within the test program at the time of the abnormal condition. Compared to a method that checks the test program line by line in the DUT to locate the abnormal program, this embodiment of the application improves the efficiency of identifying the abnormal program.

[0059] Figure 2 Schematic diagrams of the hardware-in-the-loop test system provided for other embodiments, such as Figure 2 As shown, Figure 2 Compared to the example Figure 1 The difference in the embodiments is that, Figure 2 The hardware-in-the-loop test system also includes a debugger. The computer device is connected to the device under test through the debugger. The debugger can obtain the location of multiple stub programs and send the location of the stub program to the computer device.

[0060] In some embodiments, the debugger may include a data parser.

[0061] For example, the device under test (DUT) outputs a CAN message to a communication device, so that the communication device can send a CAN message to a computer device. The CAN message includes the operating data of the DUT under various operating conditions.

[0062] For example, the device under test (DUT) can output Joint Test Action Group (JTAG) protocol data to the debugger. This JTAG protocol data includes the location of stubs. The debugger can then convert the JTAG protocol data into target protocol data, which also includes the location of stubs, and transmit the target protocol data to the computer device. For example, the target protocol may include one of the following: Universal Serial Bus (USB), Video Graphics Array (VGA), High Definition Multimedia Interface (HDMI), etc. For instance, the target protocol data may include USB protocol data.

[0063] Figure 3 A flowchart illustrating the abnormal program location method provided in the first embodiment is shown below. Figure 3 As shown, this method is applied to a computer device and includes the following steps:

[0064] S301. In the event of abnormal operating conditions during the hardware-in-the-loop test of the device under test, determine the location of the stub program that the test program of the device under test will run to during the abnormal operating conditions; multiple stub programs are pre-set at the critical program locations in the test program of the device under test through stub insertion.

[0065] For example, a hardware-in-the-loop (HIL) test system can be used to perform HIL testing on the device under test (DUT). During HIL testing of the DUT, multiple operating conditions can be tested. For example, taking a Battery Management System (BMS) as the DUT, these multiple operating conditions can cover various scenarios from battery charging and discharging to fault handling. For instance, these multiple operating conditions may include at least two of the following: slow charging condition, fast charging condition, discharging condition, high temperature condition, low temperature condition, high altitude condition, overvoltage fault condition, overcurrent fault condition, thermal runaway warning condition, battery balancing condition, hibernation condition, and wake-up condition, etc. This application embodiment does not impose any limitations on these conditions.

[0066] If the test passes under any operating condition, it indicates that the operating condition is a normal operating condition (also known as a non-abnormal operating condition). If the test fails under any operating condition, it indicates that the operating condition is an abnormal operating condition. In some embodiments, multiple operating conditions in the hardware-in-the-loop test can be sequentially determined to be abnormal operating conditions.

[0067] In some embodiments, during hardware-in-the-loop testing of the device under test (DUT), operating data of the DUT under each operating condition can be acquired. Based on the operating data of the DUT under each operating condition, it can be determined whether the operating condition is an abnormal condition. For example, if the operating data of the DUT under a certain operating condition does not meet a preset normal range of operating data values, the operating condition is determined to be an abnormal condition. Another example is if the operating data of the DUT under a certain operating condition does not meet the preset normal range of operating data values ​​for a preset period of time, the operating condition is determined to be an abnormal condition. Yet another example is if the change in the operating data of the DUT under a certain operating condition compared to the operating data of the DUT under the previous operating condition is greater than or equal to a preset change amount, the operating condition is determined to be an abnormal condition. Yet another example is if the change in operating data between two adjacent acquisitions is greater than or equal to a preset change amount, the operating condition corresponding to the later acquired operating data is determined to be an abnormal condition.

[0068] For example, when the device under test is running in one operating condition, the operating data under that operating condition is obtained by executing basic test blocks A, B, C and D. When the device under test is running in another operating condition, the operating data under that operating condition is obtained by executing basic test blocks A, E and D.

[0069] In some embodiments, the execution position of a stub can be the identifier and / or location of the basic test block associated with the stub. In other embodiments, the execution position of a stub can be the line of code in the test program where the stub is located. In some embodiments, a stub can be a program used to report the execution position of the stub. In other embodiments, a stub can be a program used to report the execution position and execution time of the stub.

[0070] For example, a test program may include several basic test blocks, with a stub program set at the input point (also called the in point or program start point) of each basic test block and a stub program set at the output point (also called the out point or program end point) of each basic test block. Alternatively, the test program can be divided according to the variables to be tested, resulting in multiple basic test blocks, with a stub program set before, after, or both before and after each basic test block.

[0071] For example, critical program locations in a test program typically refer to code segments that have a significant impact on the overall performance and functionality of the program. For example, critical program locations in a test program may include at least one of the following: the location of the core data processing function, the location of the program that outputs the runtime data of the variable under test, the location of the input / output interface, the location of conditional statements, the position before and after loop structures, the location of function calls, the location of exception handling, etc., and this application embodiment does not impose any limitations on this.

[0072] In any embodiment of this application, inserting at least one stub program in a program segment or a location may include inserting the stub program at at least one location before, after, or among several intermediate locations of the program segment or location.

[0073] Instrumentation (also known as program instrumentation) involves inserting probes into the program under test while maintaining its original logical integrity. A probe is essentially a code segment (i.e., a stub program) that collects information. It can be an assignment statement or a function call that collects coverage information. By executing the probe, characteristic data of the program's operation (such as the operating data of the device under test) can be emitted. By analyzing this data, the control flow and data flow information of the program can be obtained, and dynamic information such as logical coverage can be obtained, thereby achieving the testing purpose.

[0074] In some embodiments, the timing of the computer device acquiring runtime data may be the same as the timing of acquiring the location of the stub program; in other words, the acquisition of runtime data and the acquisition of the stub program location are synchronized. For example, if runtime data is acquired at the current moment, the location of the stub program inserted at the program location that outputs the runtime data can also be acquired at the current moment.

[0075] In other embodiments, the timing of the computer device acquiring runtime data may differ from the timing of acquiring the location of the stub program; in other words, the acquisition of runtime data and the acquisition of the stub program location are asynchronous. For example, runtime data may be acquired at the current moment, but the location of the stub program inserted at the location where the runtime data was output may be acquired only at a later moment.

[0076] In some embodiments, a computer device can send the type of the variable to be measured to the device under test (DUT) via a communication device, so that the DUT can determine the critical program location based on the type of the variable and activate the stub program at the critical program location. Exemplarily, the type of the variable to be measured may include: temperature, voltage, current, power, and battery state of charge, etc., and this application embodiment does not limit this.

[0077] In some embodiments, by providing feedback on the location of the stub program, the computer device can obtain the execution order of the basic test blocks in the stub program's test program. In some embodiments, by providing feedback on the execution time of the stub program, the computer device can obtain the execution timing of the basic test blocks in the stub program's test program.

[0078] S302. Based on the location of the stub program that the test program reaches during abnormal operating conditions, determine the abnormal program location result in the test program.

[0079] The exception program can be a segment of program or a line of program. For example, the location result of the exception program can be the identifier and / or location of the exception program (e.g., the basic test block of the exception), or the location result of the exception program can be the line of program in the test program where the exception program is located.

[0080] In some embodiments, when the running position of the stub program is the identifier and / or position of the basic test block associated with the stub program, the identifier and / or position of the basic test block associated with the stub program's position when the test program runs under abnormal operating conditions can be determined as the abnormal program location result in the test program.

[0081] In other embodiments, when the execution position of the stub program is the program line in which the stub program is located, the abnormal program location result in the test program can be determined based on the program line in which the stub program is located.

[0082] The technical solution provided in this application addresses the fact that switching the operating conditions of the device under test (DUT) leads to switching of program execution. When the DUT has an abnormal operating condition, it indicates that the program after the switch is abnormal. Thus, when an abnormal operating condition is triggered, the computer device obtains the location of the stub program that the test program runs to during the abnormal operating condition, thereby quickly locking the abnormal program in the test program when the abnormal operating condition occurs. Compared with the solution of checking the test program in the DUT line by line to locate the abnormal program in the test program, this application embodiment can improve the efficiency of identifying the abnormal program.

[0083] Figure 4 A flowchart illustrating the abnormal program location method provided in the second embodiment is shown below. Figure 4 As shown, Figure 4 Compared to the example Figure 3 The difference in the embodiments is that S301 includes S3011 to S3013.

[0084] S3011. In the event of an abnormal operating condition during the hardware-in-the-loop test of the device under test, obtain the system time when the abnormal operating condition occurs, as well as the running time and location of multiple stub programs.

[0085] In some embodiments, the computer device can determine the current system time of the computer device as the system time when the abnormal operating condition occurs during the hardware-in-the-loop test of the device under test.

[0086] In other embodiments, the computer device can acquire the system time corresponding to each piece of running data under each operating condition. If the running data is abnormal, the operating condition corresponding to the running data is determined as an abnormal operating condition, and the time corresponding to the running data is determined as the system time when the abnormal operating condition occurs. In some embodiments, if multiple consecutive pieces of running data are abnormal running data under a single operating condition, the system time corresponding to the last acquired abnormal running data can be determined as the system time when the abnormal operating condition occurs.

[0087] For example, in some implementation scenarios, the computer device can obtain the running data and system time of the running data under each operating condition, and can also obtain the running time and location of each stub program.

[0088] In some embodiments, the runtime of a stub can be the time recorded by the timer of the device under test (DUT). For example, when the timer of the DUT is started, it can start counting from 0. For a stub, the runtime of the stub is the time when the timer starts counting plus the duration from when the test program starts running until it reaches the stub.

[0089] S3012. From the running times of multiple piling programs, determine the running time of the target piling program that matches the system time when the abnormal working condition occurs.

[0090] In some embodiments, the system time at which an abnormal operating condition occurs can be matched with the execution time of at least one stub program.

[0091] In some embodiments, when the system time of the abnormal operating condition is obtained, the system time of the abnormal operating condition can be converted into a timer time to obtain the timer time of the abnormal operating condition. Among the running times of multiple stub programs, the time that is the same as the timer time of the abnormal operating condition is determined as the running time of the target stub program. Alternatively, the time when the difference between the timer time of the abnormal operating condition and the timer time of the abnormal operating condition is less than a preset duration is determined as the running time of the target stub program. Or, the time when the difference between the timer time of the abnormal operating condition and the timer time of the abnormal operating condition is the smallest is determined as the running time of the target stub program.

[0092] S3013. From the positions of multiple stub programs, determine the position of the target stub program corresponding to the running time of the target stub program, and determine the position of the target stub program as the position of the stub program to which the test program of the device under test runs under abnormal operating conditions.

[0093] Since computer equipment can obtain the execution time of each stub program and the corresponding position of each stub program, the position of the target stub program can be determined when the execution time of the target stub program is determined.

[0094] In the technical solution provided by this application embodiment, in the event of abnormal operating conditions, the system time when the abnormality occurs is matched with the running time of the stub program, thereby enabling the location of the target stub program being executed at the time of the abnormality. This effectively avoids the asynchrony between the acquisition of running data under various operating conditions and the acquisition of multiple stub program locations. For example, if the communication link used to transmit the locations of multiple stub programs is delayed, the acquisition of running data under the i-th operating condition may result in the acquisition of the location of the stub program under the (i-2)-th operating condition, leading to a deviation in the location of the target stub program determined based on the current time. Therefore, by synchronizing the acquisition time of the running data with the running time of the stub program, this application embodiment can improve the accuracy of the determined location of the target stub program.

[0095] In some embodiments, a method is provided to determine that an abnormal operating condition exists in the hardware-in-the-loop test of a device under test (DUT). The method includes: acquiring operating data of the DUT under each operating condition and the system time of each operating condition during multiple operating condition tests in the DUT's hardware-in-the-loop test; identifying abnormal operating data in the operating data under each operating condition; and determining the operating condition corresponding to the abnormal operating data as an abnormal operating condition. In some embodiments, acquiring the system time of the abnormal operating condition includes: determining the system time of the abnormal operating condition based on the system time of each operating condition.

[0096] For example, the computer device can receive operating data under various operating conditions sent by the device under test (via a communication device). For each piece of operating data received, a system time is recorded for that operating data, thereby obtaining the operating data under each operating condition and the system time when each operating condition occurs.

[0097] For example, abnormal operating data can be data that is outside the preset normal range of operating data values. Also for example, abnormal operating data can be operating data whose change is greater than or equal to a preset change. Furthermore, abnormal operating data can be data that is outside the preset normal range of operating data values ​​for a preset period of time.

[0098] In the technical solution provided in this application embodiment, abnormal operating conditions are determined by operating data under each operating condition, thereby providing a quantitative standard for determining abnormal operating conditions and improving the accuracy of determining abnormal operating conditions; and by determining the system time of occurrence of abnormal operating conditions through the correlation between operating data under each operating condition and the system time of occurrence of each operating condition, the accuracy of determining the system time of occurrence of abnormal operating conditions is improved.

[0099] In some embodiments, determining abnormal operating data in the operating data under each operating condition may include: acquiring multiple types of variables to be tested and determining the normal value range of each type of operating data corresponding to each type of variable to be tested; determining the operating data under each type of variable to be tested from the operating data under multiple operating conditions; and determining the operating data that is outside the normal value range of each type of operating data as abnormal operating data.

[0100] For example, different types of variables under test have different normal ranges of operating data. For instance, the normal range of operating data for temperature is different from that for voltage. For example, multiple types of variables under test can be configured by the computer via a communication device before the test begins. Thus, when the device under test receives multiple types of variables under test, it returns operating data for each type of variable to the computer via the communication device during the test.

[0101] In some implementations, the acquired operational data for each type of variable to be tested can be continuously monitored. For example, if the operational data for each type of variable to be tested is within the normal range of its value, it indicates that the operational data is operating normally; if, within a preset time period, the operational data for a certain type of variable to be tested is outside the normal range of its value, the operational data outside the normal range of its value is determined to be abnormal operational data.

[0102] In some implementations, when abnormal operating data for each type of variable under test is obtained, the operating conditions corresponding to the abnormal operating data for each type of variable under test can be determined as abnormal operating conditions.

[0103] In the technical solution provided in this application embodiment, by determining the normal value range of each type of test variable corresponding to each type of running data, it is possible to accurately detect the abnormal conditions of running data under each type of test variable, thereby improving the accuracy of abnormal running data determination.

[0104] In some real-time examples, a method can be provided to obtain the operating data of the device under test (DUT) under various operating conditions and the system time of each operating condition: If the operating data and system time of the DUT under the current operating condition are obtained, a time window with a preset interval is determined, starting from the system time of the current operating condition; if no operating data for the next operating condition is obtained within the time window, the operating data for the next operating condition is set as abnormal operating data, and the end time of the time window is determined as the system time of the next operating condition; if operating data for the next operating condition is obtained within the time window, the time at which the operating data for the next operating condition is obtained is determined as the system time of the next operating condition; the next operating condition is determined as the new current operating condition, and the above steps are repeated until the operating data and system time of the last operating condition are obtained. In this way, it is possible to avoid the inability to test the next operating condition when the program of a certain operating condition becomes unresponsive. Thus, the embodiments of this application can obtain the operating data and the system time of the operating condition for each operating condition that needs to be tested, thereby improving the comprehensiveness of the obtained operating data and the system time of the operating condition.

[0105] In some embodiments, obtaining the runtime and location of multiple stub programs includes: sending a variable type to be tested to the device under test; the variable type is used by the device under test to enable multiple stub programs at the key program location associated with the variable type, and the enabled multiple stub programs are used to provide feedback on the runtime and location of the multiple stub programs; and receiving the runtime and location of the multiple stub programs sent by the device under test.

[0106] For example, in actual use of the device under test (DUT), there are no stub programs. However, during testing, stub programs are set at numerous locations in the basic test blocks of the test program. These basic test blocks include test blocks for outputting runtime data for each type of variable under test. This results in a large number of stub programs in the test program, which not only reduces the execution speed of the test program but also causes a serious mismatch between the test time and the actual runtime of the DUT, leading to low test effectiveness. By enabling multiple stub programs at key program locations associated with the required variable types under test, i.e., only enabling stub programs at the key program locations associated with the required variable types under test and not enabling stub programs at other locations, the number of stub programs running in the test program is reduced.

[0107] In the technical solution provided in this application embodiment, multiple stub programs are enabled at key program locations associated with the test variable type by using the test variable type. Thus, the test device only enables stub programs at the key program locations associated with the required test variable type, reducing the number of stub programs running in the test program, increasing the execution speed of the test program, thereby improving the testing efficiency of the test device, and reducing the difference between the test time and the actual running time of the test device, thus improving the effectiveness of the test of the test device.

[0108] Figure 5 The flowchart illustrates a method for determining the execution time of a target pile program that matches the system time of an abnormal operating condition, as provided in some embodiments. Figure 5 As shown, this method is a further description of S3012, and the method includes S3012a to S3012c.

[0109] S3012a. Obtain the time delay between the start time of the test and the start time of the test program.

[0110] In some embodiments, the time delay may be pre-configured in the computer device.

[0111] In some embodiments, the computer device may respond to a test start command to begin testing the test program and determine the moment of responding to the test start command as the test start moment of the test program.

[0112] In some embodiments, the start time of the test program can be the start time of the timer in the device under test. In other embodiments, there is a preset time difference between the start time of the test program and the start time of the timer in the device under test.

[0113] In some embodiments, the time delay can be determined by: obtaining a first time delay between the start time of the test program and the time when the supply voltage of the device under test reaches a stable voltage; wherein the test program starts initialization when the supply voltage of the device under test reaches a stable voltage; obtaining a second time delay between the start time of the initialization of the test program and the start time of the operation of the test program; and determining the time delay based on the first time delay and the second time delay.

[0114] In some embodiments, the sum of the first delay and the second delay can be determined as the time delay.

[0115] In this way, the determination of the time delay not only takes into account the first time delay between the start of the test program and the moment when the power supply voltage of the device under test reaches a stable voltage, but also the second time delay between the start of the test program initialization and the start of the test program execution, thereby improving the accuracy of the determined time delay.

[0116] S3012b. Determine the reference time for the occurrence of abnormal operating conditions based on the time delay and the system time when the abnormal operating conditions occur.

[0117] In some embodiments, the reference time can be the time synchronized with the timer of the device under test (DUT). By determining the reference time at which the abnormal condition occurs, the time measurement of the computer device is strictly consistent with the time measurement of the timer of the DUT, thereby ensuring precise synchronization between the system clock of the computer device and the timer of the DUT.

[0118] In some embodiments, determining the reference time of the abnormal operating condition based on the time delay and the system time of the abnormal operating condition includes: determining the reference time of the abnormal operating condition based on the system time of the abnormal operating condition and the test start time of the test program; and determining the reference time of the abnormal operating condition based on the time delay and the reference time of the abnormal operating condition.

[0119] For example, the difference between the system time when the abnormal operating condition occurs and the test start time of the test program can be determined as the reference time when the abnormal operating condition occurs. For example, the difference between the reference time when the abnormal operating condition occurs and the time delay can be determined as the baseline time when the abnormal operating condition occurs.

[0120] In this way, the determination of the reference time for the occurrence of abnormal operating conditions not only takes into account the system time of the occurrence of abnormal operating conditions and the test start time of the test program, but also the time delay between the test start time and the run start time of the test program. As a result, the reference time for the occurrence of abnormal operating conditions can be accurately matched with the timing time of the timer of the device under test, thus improving the accuracy of the determined reference time for the occurrence of abnormal operating conditions.

[0121] S3012c: Based on the reference time when the abnormal working condition occurs, determine the running time of the target pile program that matches the system time when the abnormal working condition occurs from the running times of multiple pile programs.

[0122] For example, the target stub program can be one or more stub programs.

[0123] In some embodiments, the time that is the same as the reference time when the abnormal working condition occurs, or the time that is closest to the reference time when the abnormal working condition occurs, among the running times of multiple piling programs, is determined as the running time of the target piling program.

[0124] In other embodiments, the latest reference time obtained under the previous operating condition is obtained, and a target time interval is determined between the latest reference time obtained under the previous operating condition and the reference time when the abnormal operating condition occurred; the running time of the stub program located in the target time interval is determined from the running times of multiple stub programs; the running time of the stub program located in the target time interval is determined as the running time of the target stub program that matches the system time when the abnormal operating condition occurred.

[0125] For example, the latest reference time obtained under the previous operating condition is determined in a similar way to the reference time of the abnormal operating condition. For instance, the reference time of the previous operating condition is determined based on the system time of the previous operating condition and the test start time of the test program; the reference time of the previous operating condition is determined based on the time delay and the reference time of the previous operating condition.

[0126] In this way, by determining the target time interval between the latest obtained reference time under the previous operating condition and the reference time when the abnormal operating condition occurs, the target time interval can reflect the time interval of the abnormal program corresponding to the abnormal operating condition, thereby determining the running time of the pile program located in the target time interval. This can accurately reflect the running time of the abnormal program corresponding to the abnormal operating condition, thus improving the accuracy of the determined running time of the target pile program.

[0127] In the technical solution provided in this application embodiment, the reference time of the abnormal working condition is determined based on the time delay and the system time of the abnormal working condition. This enables the system time recorded by the computer device to be strictly aligned with the timing of the timer in the device under test. This is beneficial for determining the running time of the target stub program that matches the system time of the abnormal working condition from the running times of multiple stub programs, and improves the accuracy of determining the running time of the target stub program.

[0128] Figure 6 A flowchart illustrating the abnormal program location method provided in the third embodiment is shown below. Figure 6 As shown, Figure 6 Compared to the example Figure 3 The difference in implementation is that S302 includes S3021 to S3023.

[0129] S3021. Determine the target program location for the abnormal operating condition based on the location of the stub program that the test program runs to during abnormal operating conditions.

[0130] In some embodiments, the location of the basic test block associated with the stub program can be determined based on the location of the stub program that the test program runs to under abnormal operating conditions, and the location of the basic test block can be determined as the target program location that matches the abnormal operating conditions.

[0131] In some embodiments, where the location of the stub program represents the identifier and / or location of the basic test block, the identifier and / or location of the basic test block can be determined as the target program location for matching abnormal operating conditions. Alternatively, the identifier and / or location of the basic test block, a test block that runs before the basic test block, or a test block that runs after the basic test block can be determined as the target program location for matching abnormal operating conditions.

[0132] S3022. Determine the position of each set program that matches each normal operating condition before the abnormal operating condition.

[0133] For example, if the abnormal operating condition is the j-th operating condition, the normal operating conditions preceding this abnormal operating condition are the normal operating conditions from the 1st operating condition to the (j-1)th operating condition, where j is an integer greater than or equal to 2.

[0134] For example, the computer device can obtain the program position under each operating condition, and thus determine the set program positions matching each normal operating condition before the abnormal operating condition based on the program position under each operating condition.

[0135] S3023. Determine the location of abnormal programs in the test program based on the target program location and the locations of each set program.

[0136] In the technical solution provided by this application embodiment, since there is still a large amount of data in the target program position of the abnormal working condition matching, the abnormal program location result in the test program is determined according to the target program position of the abnormal working condition matching and the set program positions of each normal working condition matching before the abnormal working condition. This can avoid the situation of checking the target program position of the abnormal working condition matching line by line. Therefore, the embodiment of this application can improve the efficiency of determining the abnormal program location result.

[0137] In some embodiments, determining the abnormal program location result in the test program can be achieved by: determining the union of all set program locations; and determining the program locations of the target program location that are not included in the union program locations as the abnormal program location result in the test program.

[0138] For example, the basic test block corresponding to normal operating conditions is located in lines 1 to 50, and the basic test block corresponding to abnormal operating conditions is located in lines 1 to 30 and lines 51 to 60. If lines 1 to 50 can correspond to normal operating conditions, then lines 51 to 60 are determined as the abnormal program location results in the test program.

[0139] In the technical solution provided in this application embodiment, by determining the program position that is not included in the union program position of the target program position as the abnormal program location result in the test program, the program under normal working conditions can be excluded, and the abnormal program location result is located to the position where the program has not appeared under normal working conditions. This avoids repeatedly checking the program under normal working conditions and improves the effectiveness of the abnormal program location result determined in the test program.

[0140] Figure 7 A flowchart illustrating the abnormal program location method provided in the fourth embodiment is shown below. Figure 7 As shown, Figure 7 Compared to the example Figure 3 The difference in implementation is that S303 is included before S301.

[0141] S303. In response to a test start command that initiates testing of the test program, the system sends operating condition parameters for each operating condition to the test bench connected to the device under test.

[0142] The operating parameters for each operating condition are used to simulate an environment that matches the operating parameters of each operating condition on the test bench, so that the device under test can operate under each operating condition.

[0143] For example, a test start command may be generated by the computer device through the user's operation of the computer device.

[0144] In some embodiments, the test bench can operate according to the operating parameters of each operating condition, thereby simulating an environment that matches the operating parameters of each operating condition.

[0145] In some implementation scenarios, when the computer device responds to the test start command, it can send the operating condition parameters of the first operating condition to the test bench. For example, the operating condition parameters of the first operating condition can be the operating condition parameters of the power-on condition. The test bench can simulate the power-on environment of the device under test based on the operating condition parameters of the first operating condition. For example, the test bench supplies power to the device under test (e.g., low-voltage power supply) to enable the device under test to start. After the voltage stabilizes, the device under test initializes the test program. After the test program initialization is completed, the device under test can output operating data to the computer device. When the computer device receives the operating data for a preset duration, it determines that the test of the first operating condition is completed. Then, it can send the operating condition parameters of the second operating condition to the test bench to perform the test of the second operating condition, and so on, until the computer device completes the test of multiple test conditions.

[0146] In the technical solution provided in this application embodiment, the test bench simulates the environment matching the operating parameters of each operating condition according to the operating parameters of each operating condition sent by the computer equipment, without the need for manual adjustment of the operation of the test bench, thus improving the testing efficiency of the device under test.

[0147] Figure 8 A schematic diagram of a hardware-in-the-loop test system is provided as another embodiment, such as... Figure 8 As shown, the hardware-in-the-loop testing system includes a computer device and a device under test (DUT). The computer device is connected to the DUT. The computer device is used to determine the location of the stub program that the DUT's test program runs to under abnormal operating conditions during the hardware-in-the-loop testing of the DUT. Multiple stub programs are pre-set at the critical program locations in the DUT's test program through instrumentation. Based on the location of the stub programs that the test program runs to under abnormal operating conditions, the abnormal program location result in the test program is determined.

[0148] In some embodiments, the hardware-in-the-loop testing system further includes a communication device and a debugger; the computer device connects to the device under test (DUT) via the communication device; the computer device also connects to the DUT via the debugger; the DUT is used to send operating data under multiple operating conditions to the computer device via the communication device, and to send the locations of multiple stub programs to the computer device via the debugger.

[0149] In some embodiments, the computer device is also configured to acquire the system time of each running data when each running data is acquired.

[0150] In some embodiments, the device under test sends the runtime and location of multiple stubs to a computer device via a debugger.

[0151] In some embodiments, the hardware-in-the-loop test system further includes a test bench; the test bench is connected to the device under test (DUT), and a computer device is also connected to the test bench via a communication device; the computer device is further configured to, in response to a test start command to begin testing the test program, send operating condition parameters for each operating condition to the test bench connected to the DUT via the communication device; the test bench is configured to simulate an environment matching the operating condition parameters for each operating condition, so that the DUT operates under each operating condition.

[0152] Based on the same inventive concept, this application also provides an abnormal program location device for implementing the abnormal program location method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more embodiments of the abnormal program location device provided below can be found in the limitations of the abnormal program location method described above, and will not be repeated here.

[0153] In one exemplary embodiment, Figure 9 A schematic diagram of the structure of an abnormal program location device provided in some embodiments, such as Figure 9 As shown, the abnormal program location device 900 includes:

[0154] The location determination module 901 is used to determine the location of the stub program that the test program of the device under test runs to when there is an abnormal operating condition during the hardware-in-the-loop test of the device under test; the key program positions in the test program of the device under test are pre-set by stub programs.

[0155] The result determination module 902 is used to determine the abnormal program location result in the test program based on the location of the stub program that the test program runs to when it is under abnormal operating conditions.

[0156] In some embodiments, the location determination module 901 includes an acquisition unit, a matching unit, and a stub program location determination unit; wherein, the acquisition unit is used to acquire the system time when the abnormal operating condition occurs, and to acquire the running time and location of multiple stub programs; the matching unit is used to determine the running time of the target stub program that matches the system time when the abnormal operating condition occurs from the running times of the multiple stub programs; the stub program location determination unit is used to determine the location of the target stub program corresponding to the running time of the target stub program from the locations of the multiple stub programs, and to determine the location of the target stub program as the location of the stub program to which the test program of the device under test runs during the abnormal operating condition.

[0157] In some embodiments, the location determination module 901 further includes an abnormal operating condition determination unit, which is used to acquire the operating data of the device under test under each operating condition and the system time of each operating condition in the multiple operating condition tests of the hardware-in-the-loop test of the device under test; determine the abnormal operating data in the operating data under each operating condition, and determine the operating condition corresponding to the abnormal operating data as an abnormal operating condition; the acquisition unit is also used to determine the system time of the abnormal operating condition based on the system time of each operating condition.

[0158] In some embodiments, the abnormal operating condition determination unit is further configured to acquire multiple test variable types and determine the normal value range of each running data corresponding to each test variable type; determine the running data under each test variable type from the running data under multiple operating conditions; and determine the running data that is outside the normal value range of each running data under each test variable type as abnormal running data.

[0159] In some embodiments, the acquisition unit is further configured to send a variable type to be tested to the device under test; the variable type is used by the device under test to enable multiple stub programs at the key program positions associated with the variable type, and the enabled multiple stub programs are used to provide feedback on the running time and position of the multiple stub programs respectively; and to receive the running time and position of the multiple stub programs sent by the device under test.

[0160] In some embodiments, the matching unit is further configured to obtain the time delay between the test start time of the test program and the run start time of the test program; determine the reference time of the abnormal condition occurrence based on the time delay and the system time of the abnormal condition occurrence; and determine the run time of the target stub program that matches the system time of the abnormal condition occurrence from the run times of multiple stub programs based on the reference time of the abnormal condition occurrence.

[0161] In some embodiments, the matching unit is further configured to obtain a first time delay between the start time of the test program and the time when the power supply voltage of the device under test reaches a stable voltage; wherein the test program starts initialization when the power supply voltage of the device under test reaches a stable voltage; obtain a second time delay between the start time of the initialization of the test program and the start time of the run of the test program; and determine the time delay based on the first time delay and the second time delay.

[0162] In some embodiments, the matching unit is further configured to determine a reference time for the occurrence of the abnormal condition based on the system time at which the abnormal condition occurs and the test start time of the test program; and to determine a baseline time for the occurrence of the abnormal condition based on the time delay and the reference time at which the abnormal condition occurs.

[0163] In some embodiments, the matching unit is further configured to obtain the latest reference time obtained under the previous operating condition of the abnormal operating condition, and determine the target time interval between the latest reference time obtained under the previous operating condition and the reference time when the abnormal operating condition occurred; determine the running time of the staking program located in the target time interval from the running times of multiple staking programs; and determine the running time of the staking program located in the target time interval as the running time of the target staking program that matches the system time when the abnormal operating condition occurred.

[0164] In some embodiments, the result determination module 902 includes a program position determination unit, a program position matching unit, and a result determination unit; wherein, the program position determination unit is used to determine the target program position matched for the abnormal operating condition based on the position of the stub program to which the test program runs under abnormal operating conditions; the program position matching unit is used to determine the set program positions matched for each normal operating condition before the abnormal operating condition; and the result determination unit is used to determine the abnormal program location result in the test program based on the target program position and each set program position.

[0165] In some embodiments, the result determination unit is further configured to determine the union program positions of all set program positions; and to determine the program positions of the target program position that are not included in the union program positions as abnormal program location results in the test program.

[0166] In some embodiments, the abnormal program location device 900 further includes a condition parameter configuration unit, which, in response to a test start command to start testing the test program, sends condition parameters of each operating condition to a test bench connected to the device under test; wherein, the condition parameters of each operating condition are used by the test bench to simulate an environment that matches the condition parameters of each operating condition, so that the device under test operates in each operating condition.

[0167] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0168] Each module in the aforementioned anomaly locator can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0169] In one exemplary embodiment, Figure 10This is a schematic diagram of the structure of a computer device provided for some embodiments. The computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface of the computer device is used for exchanging information between the processor and external devices. The communication interface of the computer device is used for wired or wireless communication with external terminals. Wireless communication can be implemented through Wireless Fidelity (WIFI), mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements an abnormal program location method. The display unit of the computer device is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0170] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0171] For example, a computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method of any of the above embodiments.

[0172] For example, in an exemplary embodiment, when the processor executes a computer program, it performs the following: if a power module fault is detected in the target energy storage submodule, it isolates the power module from the battery module in the target energy storage submodule; if the power module and battery module are successfully isolated, it controls the target energy storage submodule to enter a bypass state.

[0173] In one embodiment, a computer-readable storage medium is provided, wherein a computer program, when executed by a processor, implements the steps of the method provided in any of the above embodiments.

[0174] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method provided in any of the above embodiments.

[0175] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the methods described above.

[0176] The processor, functional modules, or functional units in any embodiment of this application may include an integration of one or more of the following: a general-purpose processor, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field-programmable gate array (FPGA), a central processing unit (CPU), a graphics processing unit (GPU), an embedded neural network processing unit (NPU), a controller, a microcontroller, a microprocessor, a programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, a quantum computing-based data processing logic unit, an artificial intelligence (AI) processor, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0177] The memory or computer-readable storage medium in any embodiment of this application may include at least one of non-volatile memory and volatile memory. Non-volatile memory includes integration of one or more of the following: Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Ferromagnetic Random Access Memory (FRAM), Flash Memory, Magnetic Surface Memory, Optical Disc, Compact Disc Read-Only Memory (CD-ROM), Magnetic Tape, Floppy Disk, Flash Memory, Optical Memory, High-Density Embedded Non-Volatile Memory, Resistive Random Access Memory (ReRAM), Magnetoresistive Random Access Memory (MRAM), Ferroelectric Random Access Memory (FRAM), Phase Change Memory (PCM), Graphene Memory, Volatile Memory, etc. Volatile memory includes one or more of the following: Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0178] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0179] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for locating abnormal programs, characterized in that, The method includes: In the event of an abnormal operating condition during the hardware-in-the-loop test of the device under test, the system time at which the abnormal operating condition occurs is obtained, as well as the execution time and position of multiple stub programs in the test program of the device under test; multiple stub programs are pre-set at the key program positions in the test program of the device under test through stub insertion. The test program is initialized when the power supply voltage of the device under test reaches a stable voltage. The test program starts initializing when the power supply voltage of the device under test reaches a stable voltage. Obtain the second time delay between the initialization start time of the test program and the running start time of the test program; The time delay is determined based on the first delay and the second delay; Based on the time delay and the system time when the abnormal operating condition occurred, the reference time when the abnormal operating condition occurred is determined; Based on the reference time when the abnormal working condition occurred, the running time of the target pile program that matches the system time when the abnormal working condition occurred is determined from the running times of the multiple pile programs. Based on the position of the target pile program corresponding to the running time of the target pile program among the multiple pile programs, the abnormal program location result in the test program is determined.

2. The method according to claim 1, characterized in that, The hardware-in-the-loop test of the device under test exhibits abnormal operating conditions, including: In the multiple operating condition tests of the hardware-in-the-loop test of the device under test, the operating data of the device under test under each operating condition and the system time of each operating condition are obtained; Identify abnormal operating data in the operating data under each operating condition, and determine the operating condition corresponding to the abnormal operating data as the abnormal operating condition. The step of obtaining the system time of the occurrence of the abnormal operating condition includes: determining the system time of the occurrence of the abnormal operating condition based on the system time of occurrence of each of the operating conditions.

3. The method according to claim 2, characterized in that, The determination of abnormal operating data in the operating data under each of the aforementioned operating conditions includes: Obtain multiple variable types to be tested, and determine the normal value range of each running data corresponding to each variable type to be tested; From the operating data under the multiple operating conditions, determine the operating data under each of the measured variable types; The running data that falls outside the normal range of values ​​for each of the aforementioned variable types is identified as the abnormal running data.

4. The method according to any one of claims 1 to 3, characterized in that, The step of obtaining the execution time and location of the multiple stub programs includes: Send the variable type to be tested to the device under test; the variable type is used by the device under test to enable multiple stub programs at the key program positions associated with the variable type, and the enabled multiple stub programs are respectively used to provide feedback on the running time and position of the multiple stub programs; Receive the running time and location of the multiple staking programs sent by the device under test.

5. The method according to any one of claims 1 to 3, characterized in that, Determining the reference time of the abnormal operating condition based on the time delay and the system time of the abnormal operating condition includes: Based on the system time when the abnormal operating condition occurred and the test start time of the test program, determine the reference time when the abnormal operating condition occurred; The reference time for the occurrence of the abnormal operating condition is determined based on the time delay and the reference time at which the abnormal operating condition occurs.

6. The method according to any one of claims 1 to 3, characterized in that, The step of determining the execution time of the target piling program that matches the system time of the abnormal operating condition from the execution times of the multiple piling programs based on the reference time of the abnormal operating condition includes: Obtain the latest reference time obtained under the previous operating condition of the abnormal operating condition, and determine the target time interval between the latest reference time obtained under the previous operating condition and the reference time when the abnormal operating condition occurred; From the execution times of the multiple stub programs, determine the execution time of the stub program located within the target time interval; The running time of the pile program located in the target time interval is determined as the running time of the target pile program that matches the system time when the abnormal working condition occurs.

7. The method according to any one of claims 1 to 3, characterized in that, The step of determining the abnormal program location result in the test program based on the location of the stub program that the test program reaches during the abnormal operating condition includes: Based on the location of the stub program that the test program reaches during the abnormal operating condition, determine the location of the target program that matches the abnormal operating condition. Determine the positions of the set programs that match each normal operating condition prior to the abnormal operating condition; Based on the target program location and each of the set program locations, the abnormal program location result in the test program is determined.

8. The method according to claim 7, characterized in that, The step of determining the abnormal program location result in the test program based on the target program location and each of the set program locations includes: Determine the union of all the specified program locations; The program locations that are not included in the union of program locations are identified as the abnormal program location results in the test program.

9. The method according to any one of claims 1 to 3, characterized in that, Before determining the location of the stub program to which the test program of the device under test runs during the abnormal operating condition, the method further includes: In response to a test start command that initiates testing of the test program, operating condition parameters for each operating condition are sent to the test bench connected to the device under test. The operating parameters of each of the operating conditions are used by the test bench to simulate an environment that matches the operating parameters of each of the operating conditions, so that the device under test can operate in each of the operating conditions.

10. A hardware-in-the-loop testing system, characterized in that, The hardware-in-the-loop test system includes a computer device and a device under test (DUT); the computer device is connected to the DUT. A computer device is used to, when an abnormal operating condition exists during hardware-in-the-loop testing of a device under test (DUT), acquire the system time of the abnormal operating condition, and acquire the execution time and position of multiple stub programs in the DUT's test program; multiple stub programs are pre-set at key program positions in the DUT's test program through instrumentation; acquire a first time delay between the test start time of the test program and the time when the DUT's power supply voltage reaches a stable voltage; wherein the test program begins initialization when the DUT's power supply voltage reaches a stable voltage; acquire a second time delay between the test program's initialization start time and the test program's execution start time; determine a time delay based on the first and second time delays; determine a reference time of the abnormal operating condition based on the time delays and the system time of the abnormal operating condition; determine the execution time of a target stub program matching the system time of the abnormal operating condition from the execution times of the multiple stub programs based on the reference time of the abnormal operating condition; and determine the abnormal program location result in the test program based on the position of the target stub program corresponding to the execution time of the target stub program from the positions of the multiple stub programs.

11. The hardware-in-the-loop test system according to claim 10, characterized in that, The hardware-in-the-loop test system also includes communication equipment and a debugger; The computer device is connected to the device under test via the communication device; the computer device is also connected to the device under test via the debugger; The device under test is used to send operating data under multiple operating conditions to the computer device through the communication device, and to send the locations of multiple stub programs to the computer device through the debugger.

12. The hardware-in-the-loop test system according to claim 11, characterized in that, The hardware-in-the-loop testing system also includes a test bench; the test bench is connected to the device under test, and the computer device is also connected to the test bench through the communication device. The computer device is also used to send operating condition parameters of each operating condition to the test bench connected to the device under test via the communication device in response to a test start command to start testing the test program. The test bench is used to simulate an environment that matches the operating parameters of each of the operating conditions, so that the device under test can operate under each of the operating conditions.

13. An abnormal program location device, characterized in that, The abnormal program location device includes: The acquisition module is used to acquire, when an abnormal operating condition occurs during the hardware-in-the-loop test of the device under test (DUT), the system time of the abnormal operating condition, and the execution time and position of multiple stub programs in the test program of the DUT; multiple stub programs are pre-set at the key program positions in the test program of the DUT by instrumentation; a first time delay is acquired between the test start time of the test program and the time when the power supply voltage of the DUT reaches a stable voltage; wherein the test program starts initialization when the power supply voltage of the DUT reaches a stable voltage; and a second time delay is acquired between the initialization start time of the test program and the execution start time of the test program. The determination module is configured to: determine a time delay based on the first delay and the second delay; determine a reference time for the occurrence of the abnormal condition based on the time delay and the system time at which the abnormal condition occurred; determine the running time of a target stub program that matches the system time at which the abnormal condition occurred from among the running times of the plurality of stub programs based on the reference time at which the abnormal condition occurred; and determine the abnormal program location result in the test program based on the position of the target stub program that corresponds to the running time of the target stub program among the positions of the plurality of stub programs.

14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images