Reliability verification method, electronic device, and storage medium

Abstract

The application relates to the field of reliability tests, in particular to a reliability verification method, an electronic device and a storage medium. The method comprises the following steps: obtaining fault configuration information, wherein the fault configuration information comprises configuration information of one or more hardware faults; generating a fault configuration instruction based on the fault configuration information; sending the fault configuration instruction to a device to be verified; and determining a reliability verification result of the device to be verified based on obtained log information of the device to be verified. The hardware reliability of the device to be verified is verified through the fault configuration instruction for configuring the hardware fault of the device to be verified, so that the comprehensiveness of the reliability verification is improved.

Description

Technical Field

[0001] This application relates to the field of reliability testing technology, and in particular to a reliability verification method, electronic device, and storage medium. Background Technology

[0002] Reliability testing is used to evaluate the performance and durability of a system, device, or component under specific conditions to ensure that it functions properly within its intended lifespan.

[0003] In related technologies, reliability verification often involves injecting software faults into the device and extracting the device logs after the fault injection. The log data is then analyzed to determine whether the software fault has occurred and to obtain the verification results. However, hardware reliability verification often involves creating actual hardware faults. Clearly, these reliability verification methods only verify the software reliability of the device. Alternatively, while hardware reliability verification may be used, the methods are often costly and can easily cause irreparable damage to the device. Therefore, there is a lack of solutions for hardware reliability verification without harming the device, making it difficult to automatically and comprehensively verify device reliability. Summary of the Invention

[0004] This application provides a reliability verification method, an electronic device, and a storage medium to improve the comprehensiveness of device reliability verification.

[0005] In a first aspect, embodiments of this application provide a reliability verification method, the method comprising:

[0006] Obtain fault configuration information, which includes configuration information for one or more hardware faults;

[0007] Based on the fault configuration information, a fault configuration instruction is generated;

[0008] Send the fault configuration command to the device to be verified;

[0009] Based on the obtained log information of the device to be verified, the reliability verification result of the device to be verified is determined.

[0010] In specific implementation, the electronic device can execute the reliability verification method provided in the embodiments of this application. The fault configuration information acquired by the electronic device may include information on one or more pre-set hardware faults, or it may include information on one or more hardware faults set by the user. The electronic device can generate a fault configuration instruction based on the fault configuration information. The fault configuration instruction can instruct the device under test to make adjustments to simulate the hardware fault in the fault configuration information. The log information of the device under test can reflect whether the device under test has detected the hardware fault. Therefore, the reliability verification result of the device under test can be determined based on the log information of the device under test. This design can simulate the occurrence of hardware faults in the device under test and perform reliability verification on the device under test, thereby improving the comprehensiveness of the reliability verification of the device under test.

[0011] In one possible design, the reliability verification method provided in this application embodiment includes one or more of the following hardware faults: a first fault and a second fault;

[0012] The generated fault configuration instruction includes:

[0013] Generate a first instruction corresponding to the first fault, the first instruction including information about the target sensor in the device to be verified; and / or,

[0014] Based on the instruction set of the device to be verified, a second instruction corresponding to the second fault is generated.

[0015] In practice, for the first fault, the electronic device can obtain data from each sensor in the device to be verified through the Intelligent Platform Management Interface (IPMI) protocol and determine the relevant information of the target sensor corresponding to the first fault. Then, the electronic device can simulate the fault of the target sensor by configuring the relevant parameters of the target sensor in the first instruction.

[0016] In one possible design, the reliability verification method provided in this application embodiment, wherein generating a second instruction corresponding to the physical hardware fault based on the instruction set of the device to be verified includes:

[0017] If the instruction set is an instruction set of an ARM Advanced Reduced Instruction Set Machine architecture, then generate instructions for failure of the Reliability Availability and Serviceability Tool (RAStool).

[0018] If the instruction set is not the instruction set of the ARM architecture, then an instruction for checking abnormal MCE faults is generated.

[0019] In practice, the electronic device determines its architecture type through the instruction set of the device to be verified, thereby generating corresponding second faults for devices with different architectures, so that the reliability verification method provided in this application can be more widely applied to devices with different architectures.

[0020] In one possible design, the reliability verification method provided in this application embodiment, wherein determining the reliability verification result of the device to be verified based on the obtained log information of the device to be verified includes:

[0021] In response to the device under test meeting the verification conditions, the reliability verification result of the device under test is determined based on the obtained log information of the device under test.

[0022] In practice, the verification conditions can be pre-set to be applicable to multiple types of devices to be verified, or the user can set them to be specific to a certain type of device to be verified according to their needs. By judging whether the device to be verified can meet the verification conditions, and combining the log information to reflect whether the device to be verified has detected the hardware fault, the reliability of the electronic device to be verified can be verified from multiple perspectives, thus improving the comprehensiveness of the reliability verification of the device to be verified.

[0023] In one possible design, the reliability verification method provided in this application embodiment includes one or more of the following conditions:

[0024] The inspection reporting time is less than or equal to the preset reporting time, and the inspection reporting time is the time when the device to be verified provides the inspection results;

[0025] The difference between the inspection reporting time and the fault injection time is less than or equal to a preset value;

[0026] The device to be verified is in normal operating condition.

[0027] In practice, electronic devices can determine the timeliness of fault correction of the device under test by the inspection and reporting time. The fault correction capability of the device under test can be determined by whether the device under test can correct the recoverable fault and return to normal operation. This realizes a multi-angle reliability verification method for the device under test.

[0028] In one possible design, the reliability verification method provided in this application embodiment, wherein determining the reliability verification result of the device to be verified based on the obtained log information of the device to be verified includes:

[0029] Based on the first log information corresponding to the first fault, determine the verification result corresponding to the first fault; and / or, based on the second log information corresponding to the second fault, determine the verification result corresponding to the second fault.

[0030] In one possible application scenario, where the fault configuration information includes multiple faults, the reliability verification result of the device to be verified can be determined by any of the following examples.

[0031] In some examples, for the multiple faults, if the reliability verification of each fault passes, then the reliability verification of the device to be verified passes.

[0032] In some examples, for the multiple faults, if the reliability verification of a preset number of faults passes, then the reliability verification of the device to be verified passes.

[0033] In some examples, for the plurality of faults, if the ratio of the total number of faults that pass verification to the total number of the plurality of faults is a preset ratio, then the reliability verification of the device to be verified passes; in some examples, for the plurality of faults, if the reliability verification of the target fault among the plurality of faults passes, then the reliability verification of the device to be verified passes.

[0034] In one possible design, the reliability verification method provided in this application embodiment further includes:

[0035] Generate software fault instructions;

[0036] Send the software fault command to the device to be verified;

[0037] Obtain the software operation result after the software fault instruction is injected into the device to be verified, and determine the reliability verification result of the device to be verified based on the software operation result.

[0038] In practice, the electronic device also sends a software fault command to the device under test to instruct it to make adjustments, thus simulating a corresponding software fault in the device under test. Then, the electronic device can determine the reliability verification result of the device under test based on the software operation result of the device under test under the software fault. By combining the above-mentioned reliability verification results for hardware faults, the reliability verification of the device under test is realized in both software and hardware aspects, thereby improving the comprehensiveness of the reliability verification of the device under test.

[0039] In one possible design, the reliability verification method provided in this application embodiment includes an availability value, a fault tolerance value, and a recoverability value in the software operation results; obtaining the software operation results after injecting the software fault instruction into the device to be verified includes:

[0040] Obtain the fault injection time of the software fault instruction injected into the device to be verified and the fault repair time of the device to be verified.

[0041] The availability value of the device to be verified is determined based on its service performance before the fault injection time.

[0042] The fault tolerance value of the device to be verified is determined based on the service performance of the device between the fault injection time and the fault repair time.

[0043] The recoverability value of the device to be verified is determined based on its service performance after the fault repair time.

[0044] In practice, the electronic device acquires the fault injection and fault repair times of the device under test, dividing the device into three stages: before fault injection, during fault injection, and after fault repair. By determining the availability, fault tolerance, and recoverability values ​​of the device under test, the electronic device examines its service performance at each stage. Ultimately, the electronic device can determine the software execution outcome of the device under test. This design allows for comprehensive verification of the service performance of the device under test at each stage when it experiences a software fault.

[0045] In one possible design, the reliability verification method provided in this application embodiment, wherein determining the reliability verification result of the device to be verified based on the software running result includes:

[0046] If the availability value, the fault tolerance value, and the recoverability value all reach the corresponding preset thresholds, then the device to be verified is determined to have passed the reliability verification.

[0047] In practice, the preset threshold set by the electronic device can be set separately for each of the three parameters, or it can be the same preset threshold set uniformly for the three parameters. By comparing the preset threshold with the three parameters, the electronic device can realize the reliability verification of the device under test in terms of software faults.

[0048] In a second aspect, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the method as described in the first aspect and any of its designs.

[0049] Thirdly, an embodiment of this application provides a reliability verification system, the system comprising: an electronic device as described in the second aspect and one or more devices to be verified;

[0050] The device to be verified includes:

[0051] The receiving module is used to receive fault configuration commands;

[0052] The configuration module is used to respond to the fault configuration command and modify the configuration parameters;

[0053] The logging module is used to generate log information.

[0054] In practice, after receiving a fault configuration command from the electronic device, the device under test (DUT) responds by modifying its own configuration parameters to simulate a corresponding fault state and generates log information. The electronic device can then determine whether the DUT has passed reliability verification based on whether the corresponding fault is recorded in the log information. This design simulates hardware failures in the DUT and performs reliability verification, thus improving the comprehensiveness of the reliability verification process.

[0055] In one possible design, the reliability verification system provided in this application embodiment further includes:

[0056] The inspection module is used to detect whether the device to be verified has malfunctioned;

[0057] If a fault is detected, the inspection results will be reported.

[0058] In practice, the device under test (DUT) performs inspections via the Baseboard Management Controller (BMC). If a fault is detected, the DUT reports the inspection results. This allows the electronic device to determine its self-testing capability based on whether a fault was detected, or to determine the timeliness of the DUT's inspection based on the timing of the inspection report. This design verifies the DUT's inspection capabilities, enhancing the comprehensiveness of the reliability verification process.

[0059] Fourthly, embodiments of this application provide a computer-readable storage medium including a computer program that, when run on an electronic device, causes the electronic device to perform the methods described in the first aspect and any of its designs.

[0060] Fifthly, embodiments of this application provide a computer program product, including a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the method as described in the first aspect and any of its designs.

[0061] The beneficial effects of this application are as follows:

[0062] This application provides a reliability verification method, electronic device, and storage medium. By generating a fault configuration instruction using configuration information including one or more hardware faults, and sending the fault configuration instruction to the device under test, the hardware reliability of the device under test is verified through the device's log information. This avoids the problems in related technologies, which can only verify the software reliability of the device, or, although they can verify the hardware reliability, often use methods that induce real hardware faults, potentially causing irreparable damage to the device. This application improves the comprehensiveness of device reliability verification by using fault configuration instructions to simulate hardware faults in the device under test.

[0063] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0064] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0065] Figure 1 This is a schematic diagram of a reliability verification method provided in an embodiment of this application;

[0066] Figure 2 This is a schematic diagram of another reliability verification method provided in an embodiment of this application;

[0067] Figure 3 This is a schematic diagram of another reliability verification method provided in the embodiments of this application;

[0068] Figure 4 This is a schematic diagram of the hardware structure of an electronic device using an embodiment of this application;

[0069] Figure 5 A schematic diagram of the structure of a reliability verification system provided in the embodiments of this application;

[0070] Figure 6 This is a schematic diagram of the hardware structure of a computing device according to an embodiment of this application. Detailed Implementation

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

[0072] The embodiments of this application involve at least one, including one or more; wherein, multiple means two or more. Furthermore, it should be understood that in the description of this application, terms such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance, nor as indicating or implying order. In the description of this application, "A and / or B" includes three options: including A; including B; and including both A and B.

[0073] The following describes some of the concepts involved in the embodiments of this application.

[0074] Device to be verified: In this application, it refers to the device that needs to be verified for reliability, which is mostly hardware device, such as server, computer, etc.

[0075] Instruction set: refers to the set of instructions used by the Central Processing Unit (CPU) to calculate and control the computer system. Each new type of CPU is designed with a set of instructions that work in conjunction with other hardware circuits. In this application embodiment, the instruction set refers to the instruction set in the CPU of the device to be verified, which can be the Advanced Reduced Instruction Set Machine (ARM) instruction set, x86 instruction set, etc.

[0076] ARM architecture: a low-power processor architecture based on the principle of reduced instruction set computing. If the device is based on ARM architecture, it will embed reliability, availability, and serviceability tools (RAStool). Therefore, in this embodiment of the application, for the ARM architecture device to be verified, instructions for RAStool failure will be generated.

[0077] x86 architecture: a widely used computer processor architecture. If a device uses an x86 architecture, it will embed Machine Checked Exceptions (MCE) as an extension feature of the x86 architecture to enhance remote monitoring and management capabilities. Therefore, in this embodiment of the application, for non-ARM architecture, i.e., x86 architecture, instructions for MCE faults will be generated.

[0078] BMC: A dedicated microcontroller, usually integrated on the server motherboard, is used to remotely monitor and manage various aspects of the server, including but not limited to hardware status such as temperature, voltage, and fan speed.

[0079] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0080] The reliability verification method in this application embodiment can be applied to application scenarios such as device updates, replacements, and initial installations. It verifies the device before actual use to avoid operational or functional failures due to insufficient error reporting and correction capabilities during actual use. The reliability verification method in this application embodiment can be implemented by software, hardware, or a combination of both. The following example uses an electronic device as the execution subject to illustrate the reliability verification method in this application embodiment.

[0081] like Figure 1 The diagram shown is a schematic flowchart of a reliability verification method provided in an embodiment of this application. Specifically, it includes steps S11 to S14:

[0082] S11: Obtain fault configuration information.

[0083] The fault configuration information may include configuration information for one or more hardware faults.

[0084] In some application scenarios, electronic devices can perform reliability verification on the device under test while the device under test is in an operational state. For example, after the device under test is deployed, the electronic device can initiate business traffic to the device under test, simulating data transmission and business operations in the actual working environment of the device under test, thus putting the device under test in a real working state.

[0085] When electronic devices perform reliability verification of hardware faults, they acquire configuration information for one or more hardware faults that need to be configured. For example, the hardware faults may be configuration information for one or more of the following: sensor faults, RAStool faults, and MCE faults.

[0086] S12: Generate fault configuration instructions based on fault configuration information.

[0087] S13: Send a fault configuration command to the device to be verified.

[0088] In this application embodiment, the form of the fault configuration instruction may include, but is not limited to, instructions, code, or scripts. This application embodiment does not impose excessive restrictions on this. In specific implementation, the electronic device generates corresponding fault configuration instructions, fault configuration codes, or fault configuration scripts, etc., based on the fault configuration information and the indicated hardware fault.

[0089] The aforementioned fault configuration information may include one or more hardware faults. These one or more hardware faults may include one or more of the following: a first fault and a second fault.

[0090] The electronic device generates a first instruction corresponding to a first fault, the first instruction including information about the target sensor in the device to be verified; and / or, based on the instruction set of the device to be verified, generates a second instruction corresponding to a second fault.

[0091] In some examples, the fault configuration information may include a first fault. The electronic device can obtain data from each sensor in the device under test via the IPMI protocol and determine the relevant information of the target sensor corresponding to the first fault. Therefore, by configuring the relevant parameters of the target sensor in the first instruction, the fault of the target sensor can be simulated. Optionally, the first instruction may include information from one target sensor or multiple target sensors. For example, the electronic device can obtain data from five sensors in the device under test via the IPMI protocol, such as operating status and upper limits of operating parameters. The electronic device can select two target sensors from these five sensors, set the operating parameters of these two target sensors to values ​​exceeding the upper limits, and generate the first instruction to simulate the hardware fault of the two sensors.

[0092] In some examples, fault configuration information may include a second fault. The electronic device may have the capability to generate multiple second instructions corresponding to the second fault. The electronic device can generate one of multiple second instructions based on the instruction set recorded in the CPU of the device under test.

[0093] In the operation of generating a variety of second instructions, if the instruction set recorded in the CPU of the device to be verified is the instruction set of an ARM architecture machine, then the electronic device can generate instructions for the reliability, availability, and serviceability tool (RAStool) to detect faults; if the instruction set recorded in the CPU of the device to be verified is not the instruction set of an ARM architecture machine, then the electronic device can generate instructions for the machine checking abnormal MCE faults.

[0094] In practical applications, the device to be verified can include, but is not limited to, servers, computers, and other similar devices. Besides the ARM architecture instruction set mentioned above, its primary instruction set can also be the x86 architecture instruction set. Therefore, when generating the second instruction, the electronic device can generate the following alternative second instruction for the x86 architecture instruction set.

[0095] In practical implementation, during the generation of one of several second instructions by the electronic device: if the instruction set recorded by the CPU of the device under test is not an ARM architecture instruction set, then it is an x86 architecture instruction set, and the electronic device generates a second instruction corresponding to the MCE fault of the x86 architecture. By generating the corresponding second instruction through the instruction set of the device under test, the hardware reliability verification of this application can be more widely applied to devices under test with different instruction sets, i.e., different architectures.

[0096] In some application scenarios, fault configuration instructions may include one or more first instructions. Alternatively, fault configuration instructions may include one or more second instructions. Or, fault configuration instructions may include at least one first instruction and at least one second instruction. For example, in a reliability verification, two first instructions and one second instruction for an MCE fault may be generated.

[0097] Furthermore, since the devices to be verified include, but are not limited to, servers and computers, and their instruction sets are all one of the two types mentioned above, and the IPMI protocol is widely used in various devices, the above-mentioned first instruction and second instruction generation methods can be widely applied to various devices to be verified.

[0098] In the above embodiments, the present application embodiments can provide diversified hardware reliability verification for the device to be verified by constructing various fault configuration instructions such as the first instruction and the second instruction, making the hardware reliability verification more comprehensive.

[0099] S14: Based on the obtained log information of the device to be verified, determine the reliability verification result of the device to be verified.

[0100] If the device under test detects a fault, the log information will include, but is not limited to, the fault level, fault tolerance, location of the fault, and fault details. Electronic devices can determine the fault detection capability of the device under test by obtaining its log information.

[0101] Optionally, when the electronic device judges the fault detection capability of the device to be verified through log information, the electronic device can also judge the inspection timeliness and / or fault correction capability of the device to be verified by pre-setting verification conditions.

[0102] In practical implementation, the electronic device can verify the timeliness of the inspection of the device under test by checking the reporting time of the inspection faults of the device itself. This embodiment of the application considers that hardware faults can include recoverable and non-recoverable faults. Therefore, this embodiment of the application can verify the fault correction capability of the device under test through recoverable faults. If the device under test can recover to normal operation when it is experiencing a recoverable fault, the electronic device considers the device under test to have fault correction capability.

[0103] In one possible implementation, the electronic device can determine the reliability verification result of the device under test based on the obtained log information of the device under test in response to the device under test meeting the verification conditions, thereby realizing multi-faceted reliability verification of the device under test.

[0104] In one alternative implementation, the verification conditions include one or more of the following conditions:

[0105] Condition 1: The inspection reporting time is less than or equal to the preset reporting time;

[0106] Condition 2: The difference between the inspection reporting time and the fault injection time is less than or equal to the preset value;

[0107] Condition 3: The device to be verified is in normal operating condition.

[0108] The inspection reporting time is the time when the Baseboard Management Controller (BMC) of the device to be verified provides the inspection results.

[0109] In some examples, the preset reporting time can be generated when the electronic device sends a fault configuration command, and the preset value can be a fixed value related to the fault type. For example, for a CPU occupancy fault, the preset data can be set to 10 minutes. That is, when the difference between the inspection reporting time and the fault injection time exceeds 10 minutes, it can reflect that the fault inspection timeliness of the device under test is poor. For recoverable faults, the electronic device can use the device under test being in normal operating condition as one of the verification conditions.

[0110] In some application scenarios, conditions 1 and 2 listed above can be used to verify the timeliness of fault inspection of the device under test. If the device under test meets the verification conditions, it indicates that the timeliness of its fault inspection is satisfactory. The electronic device can then be used to perform reliability verification on the device under test.

[0111] In some application scenarios, condition 3 listed above can be used to verify the fault correction capability of the device under test. When the device under test meets the verification conditions, it indicates that its fault correction capability meets the requirements. The electronic device can then be used to perform reliability verification on the device under test.

[0112] As described in the foregoing embodiments, the timeliness of fault inspection and the ability to correct faults are also important indicators reflecting the reliability of the device under test. Therefore, the hardware reliability verification provided in this application can include not only fault detection, but also the timeliness of fault inspection of the device under test and the verification of the device's fault correction capabilities, thus improving the comprehensiveness of reliability verification.

[0113] In the method provided by any of the foregoing embodiments, during the operation of the electronic device determining the hardware reliability verification result of the device to be verified based on the log information of the device to be verified, the electronic device may execute the following process:

[0114] Based on the first log information corresponding to the first fault, determine the verification result corresponding to the first fault; and / or, based on the second log information corresponding to the second fault, determine the verification result corresponding to the second fault.

[0115] The first log is the BMC system log, and the second log is the kernel knel log. Therefore, if the electronic device sends a first command to the device to be verified, it can obtain the BMC system log of the device to be verified, verify whether it has recorded the first fault corresponding to the first command, and compare the recorded fault event with the fault content, fault level, and fault location of the first fault. Similarly, if the electronic device sends a second command to the device to be verified, it can obtain the knel log of the device to be verified, verify whether it has recorded the second fault corresponding to the second command, and compare the recorded fault event with the fault content, fault level, and fault location of the second fault.

[0116] In one possible application scenario, where the fault configuration information includes multiple faults, the reliability verification result of the device to be verified can be determined by any of the following examples.

[0117] In some examples, for multiple faults, the reliability verification of the device under test is considered successful if the reliability verification of each fault is successful.

[0118] In some examples, for multiple faults, if the reliability verification of a preset number of faults is passed, then the reliability verification of the device to be verified is passed; for example, an electronic device can be set to pass the reliability verification of 5 faults, then the device to be verified can be considered to have passed the reliability verification.

[0119] In some examples, for multiple faults, if the ratio of the total number of verified faults to the total number of multiple faults is a preset ratio, then the reliability verification of the device under test is passed; for example, an electronic device can be set to pass the reliability verification when the device under test passes the reliability verification of 60% of all faults, then the device under test can be considered to have passed the reliability verification.

[0120] In some examples, for multiple faults, the reliability verification of the device under test is considered successful if the reliability verification of the target fault among the multiple faults passes. For example, an electronic device can be configured such that if the device under test passes the reliability verification for the first fault of the target sensor, then the device under test can be considered to have passed the reliability verification.

[0121] In view of the comprehensiveness of reliability verification, based on the reliability verification method provided in any of the foregoing embodiments, electronic devices can also perform software reliability verification on the device to be verified.

[0122] After the device under test is deployed, the electronic device can generate a software fault command when it initiates business traffic; send the software fault command to the device under test; obtain the software operation result after the software fault command is injected into the device under test; and determine the reliability verification result of the device under test based on the software operation result.

[0123] Software faults are also categorized as recoverable and unrecoverable. Therefore, electronic devices can still verify the fault correction capabilities of the device under test through recoverable faults. In practice, electronic devices can determine the software operation results of the device under test by examining its performance before, after, and during fault correction.

[0124] The software operation results include availability, fault tolerance, and recoverability values. The electronic device takes the moment when it sends the software fault command as the fault injection moment and the moment when the device to be verified returns to normal operation or the fault is determined to be unrecoverable as the fault repair moment. Thus, the electronic device can examine the quality of the service provided by the device to be verified in each time period (i.e., the time period before the fault injection moment, the time period between the fault injection moment and the fault repair moment, and the time period after the fault repair moment), that is, the service performance of the device to be verified.

[0125] In practice, the electronic device acquires the fault injection time when the device under test receives the software fault instruction during the traffic initiation process, as well as the fault repair time of the device under test. The electronic device can determine the availability value of the device under test based on its service performance before the fault injection time. For example, the electronic device can use the probability that the device under test can work normally within a preset time period before the fault injection time as the availability value. Specifically, the electronic device can use the ratio of the time period during which the device under test is in normal operation within the preset time period to the preset time period as the availability value. Alternatively, the electronic device can also determine the availability value of the device under test based on the availability value determination criteria preset by the user for the device under test, and so on.

[0126] Electronic devices can determine the fault tolerance value of the device under test (DUT) based on its service performance between the fault injection and fault repair times. They can also determine the DUT's ability to maintain its original operating or functional state between these times. For example, the DUT can use the proportion of normally functioning components or areas within the DUT as the fault tolerance value; alternatively, it can assess the timeliness of fault detection; or it can determine the DUT's fault tolerance value using pre-set fault tolerance criteria set by the user, and so on.

[0127] Electronic devices can determine the recoverability value of the device under test (DUT) based on its service performance after a fault is repaired. If the software fault command received by the DUT indicates that it simulates a recoverable fault, the electronic device can use the time it takes for the DUT to recover from a faulty state to normal operation during the observation period as the recoverability value. Alternatively, the electronic device can also obtain the recoverability value by examining the DUT's fault correction capabilities. If the software fault command received by the DUT indicates that it simulates an unrecoverable fault, the electronic device can determine its recoverability value by examining its data backup capabilities in the face of an unrecoverable fault during the observation period. Alternatively, the electronic device can also determine the DUT's recoverability value using a fault tolerance value determination standard pre-set by the user for the DUT.

[0128] If the availability value, fault tolerance value, and recoverability value all reach the corresponding preset thresholds, the electronic device can determine that the device to be verified has passed the reliability verification.

[0129] The availability, fault tolerance, and recoverability values ​​can be in the form of numerical values, grades, percentages, etc. The corresponding software thresholds can also be numerical values, grades, percentages, etc. For example, if the availability, fault tolerance, and recoverability values ​​are in the form of percentages, the software thresholds can be set to 70%, 80%, etc.

[0130] Furthermore, considering that software faults are divided into recoverable and unrecoverable faults, the preset thresholds corresponding to the above software operation results can be set to three different values. If the software fault received by the device under test is a recoverable fault, the fault tolerance value and recoverability value of the device under test can be mainly examined. For example, the preset thresholds for the fault tolerance value and recoverability value can be set higher than the preset threshold for the availability value. If the software fault received by the device under test is an unrecoverable fault, the availability value of the device under test can be mainly examined. For example, the preset thresholds for the fault tolerance value and recoverability value can be set lower than the preset threshold for the availability value, and so on.

[0131] Based on the same technical concept, embodiments of this application provide a reliability verification method, which can be executed by the device to be verified. For example... Figure 2 As shown, the reliability verification method may include the following steps:

[0132] S21: Receive fault configuration command;

[0133] S22: Respond to the fault configuration command and modify the configuration parameters;

[0134] S23: Generate log information.

[0135] In practice, after receiving a fault configuration command, the device under test can modify the parameters of the hardware corresponding to the fault, causing the fault to manifest in the device. For example, if the fault configuration command is to overload the CPU, the device under test will modify the CPU load-related parameters to make it believe that the CPU is overloaded. Or, if the fault configuration command is to cause the target memory to be corrupted, the device under test will modify the target memory's operating parameters to make it believe that the target memory is corrupted, and so on.

[0136] In addition, the device to be verified will also detect whether a fault has occurred; if a fault is detected, the inspection results will be reported.

[0137] In some application scenarios, faults can be classified as recoverable or unrecoverable. The device under test will report any fault detected, regardless of whether it is recoverable or unrecoverable.

[0138] Optionally, when the device under test receives a fault configuration command and detects a fault, it can analyze the fault to determine whether it is a recoverable fault. If the fault detected by the device under test is recoverable, the device under test can correct the fault and restore the faulty part to normal operation. If the fault detected by the device under test is unrecoverable, the device under test can issue a fault alarm.

[0139] Based on the same technical concept, embodiments of this application provide a reliability verification method, which can be executed by a reliability verification system. The reliability verification system includes an electronic device that generates and sends fault configuration instructions, and one or more devices to be verified for reliability verification.

[0140] In practical implementation, when performing reliability verification on any device to be verified, the electronic device can choose to send only the first hardware fault, the second hardware fault, or a software fault to the device to be verified, or it can choose to send one or more faults of various types. Taking sending the first hardware fault, the second hardware fault, and a software fault to the device to be verified as an example, the flow of the reliability verification method provided in this application embodiment will be introduced. Figure 3 The diagram shown is a schematic flowchart of another reliability verification method provided in this application embodiment. Specifically, it includes steps S301 to S312:

[0141] S301: The electronic device generates a first instruction and sends it to the device to be verified;

[0142] S302: Electronic device acquires BMC logs of device to be verified;

[0143] S303: Electronic device determines whether the instruction set of the device to be verified is ARM architecture;

[0144] Specifically, if the device to be verified is based on an ARM architecture, the electronic device executes S304; otherwise, the electronic device executes S305.

[0145] S304: The electronic device generates a RAStool fault command and sends it to the device to be verified;

[0146] S305: The electronic device generates an MCE fault command and sends it to the device to be verified;

[0147] S306: Electronic equipment obtains the inspection reporting time of the device to be verified;

[0148] Specifically, electronic devices record the time when the inspection results reported by the device to be verified are obtained in order to determine the timeliness of the fault inspection of the device to be verified.

[0149] S307: Electronic device acquires the Kenel logs of the device to be verified;

[0150] S308: Electronic equipment determines the hardware reliability of the device to be verified;

[0151] Specifically, after the device to be verified meets the verification conditions including the timeliness of the above-mentioned fault inspection, if the fault information recorded in each log information of the device to be verified is the same as the fault information sent to the device to be verified, then the electronic device can be considered to have passed the hardware reliability verification.

[0152] S309: The electronic device sends a software fault command to the device to be verified;

[0153] S310: The electronic device acquires the software execution results of the device to be verified;

[0154] Specifically, the software's performance results include availability, fault tolerance, and recoverability.

[0155] S311: Electronic equipment determines the software reliability of the device to be verified;

[0156] Specifically, if the availability, fault tolerance, and recoverability of the device to be verified all reach the corresponding preset thresholds, the electronic device can be considered to have passed the software reliability verification.

[0157] S312: Electronic equipment determines the reliability of the device to be verified.

[0158] Specifically, if the device to be verified passes both hardware reliability verification and software reliability verification, then the electronic device can be determined to have passed the reliability verification.

[0159] Based on the same inventive concept, this application also provides an electronic device. This electronic device can perform the steps or operations in the reliability verification method provided in any of the above embodiments, and can achieve the same technical effect, which will not be repeated here. In this embodiment, the structure of the electronic device can be as follows: Figure 4 As shown, it includes a memory 401, a communication module 403, and one or more processors 402.

[0160] The memory 401 is used to store computer programs executed by the processor 402. The memory 401 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0161] Memory 401 may be volatile memory, such as random-access memory (RAM); memory 401 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 401 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 401 may be a combination of the above-described memories.

[0162] Processor 402 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 402 is used to implement the above-described reliability verification method when calling the computer program stored in memory 401.

[0163] The communication module 404 is used to communicate with electronic devices and other servers.

[0164] This application embodiment does not limit the specific connection medium between the memory 401, communication module 403, and processor 402 described above. This application embodiment... Figure 4 The memory 401 and the processor 402 are connected via a bus 404, and the bus 404 is in Figure 4 The diagram uses thick lines to describe the connections between other components; these are for illustrative purposes only and should not be considered limiting. The 404 bus can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 4 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0165] The memory 401 stores a computer storage medium, which in turn stores computer-executable instructions for implementing the reliability verification method of this application embodiment. The processor 402 is used to execute the aforementioned reliability verification method.

[0166] Based on the same inventive concept, embodiments of this application provide a reliability verification system 500.

[0167] Figure 5 This is a schematic diagram of the structure of a reliability verification system provided in an embodiment of this application. Figure 5 As shown, the system includes: a receiving module 501, a configuration module 502, and a logging module 503.

[0168] Receiver module 501 is used to receive fault configuration commands;

[0169] Configuration module 502 is used to modify configuration parameters in response to the fault configuration command;

[0170] Log module 503 is used to generate log information.

[0171] In practice, after receiving a fault configuration command, the receiving module 501 can configure the configuration module 502 to modify the parameters of the hardware corresponding to the fault, causing the device under test to exhibit the fault. For example, if the fault configuration command is to overload the CPU, the device under test will modify the CPU load-related parameters to make it believe that the CPU is overloaded. Or, if the fault configuration command is to cause the target memory to be corrupted, the device under test will modify the target memory's operating parameters to make it believe that the target memory is corrupted, and so on. The logging module 503 generates corresponding log information based on the faults exhibited in the device under test.

[0172] Furthermore, in one possible implementation of the embodiments of this application, such as Figure 5 As shown, it also includes: inspection module 504.

[0173] The inspection module 504 is used to detect whether the device to be verified has malfunctioned; if a malfunction is detected, the inspection result is reported.

[0174] In some application scenarios, faults can be classified as recoverable or unrecoverable. Whether the fault detected by the inspection module 504 is recoverable or unrecoverable, the inspection module 504 will report the detected fault.

[0175] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the communication methods discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the reliability verification method, the implementation of the above-described computer-readable storage medium can be referred to the implementation of the method, and repeated details will not be elaborated further.

[0176] The following reference Figure 6 To describe a computing device 600 according to this embodiment of the present application. Figure 6 The computing device 600 is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0177] like Figure 6The computing device 600 is manifested in the form of a general-purpose computing device. The components of the computing device 600 may include, but are not limited to: at least one processing unit 601, at least one storage unit 602, and a bus 603 connecting different system components (including storage unit 602 and processing unit 601).

[0178] Bus 603 represents one or more of several bus structures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus structures.

[0179] Storage unit 602 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 621 and / or cache memory 622, and may further include read-only memory (ROM) 623.

[0180] Storage unit 602 may also include a program / utility 625 having a set (at least one) of program modules 624, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0181] The computing device 600 can also communicate with one or more external devices 604 (e.g., keyboard, pointing device, etc.), and with one or more devices that enable a user to interact with the computing device 600, and / or with any device that enables the computing device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via the input / output (I / O) interface 605. Furthermore, the computing device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via a network adapter 606. Figure 6 As shown, network adapter 606 communicates with other modules for computing device 600 via bus 603. It should be understood that, although not shown in the figures, other hardware and / or software modules may be used in conjunction with computing device 600, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0182] Based on the same inventive concept, embodiments of this application also provide a verification system, which may include the aforementioned electronic device and one or more devices to be verified. The electronic device can execute the reliability verification method performed by the electronic device in any of the foregoing embodiments.

[0183] This application also provides a computer program product. The methods in this application can be implemented, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, they can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in this application are executed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, network equipment, user equipment, core network equipment, OAM, or other programmable devices.

[0184] A computer-readable storage medium can be an implementation of a computer program product. In other words, this application also provides a computer-readable storage medium that includes a computer program, which, when executed by a processor, implements any of the reliability verification methods described above.

[0185] The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; or an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0186] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0187] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0188] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0189] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0190] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A reliability verification method, characterized in that, The method includes: Obtain fault configuration information, which includes configuration information for one or more hardware faults; Based on the fault configuration information, a fault configuration instruction is generated; Send the fault configuration command to the device to be verified; Based on the obtained log information of the device to be verified, the reliability verification result of the device to be verified is determined.

2. The method according to claim 1, characterized in that, The one or more hardware faults include one or more of the following: a first fault and a second fault; The generated fault configuration instruction includes: Generate a first instruction corresponding to the first fault, the first instruction including information about the target sensor in the device to be verified; and / or, Based on the instruction set of the device to be verified, a second instruction corresponding to the second fault is generated.

3. The method according to claim 2, characterized in that, The step of generating a second instruction corresponding to the physical hardware fault based on the instruction set of the device to be verified includes: If the instruction set is an instruction set of an ARM Advanced Reduced Instruction Set Machine architecture, then generate instructions for failure of the Reliability Availability and Serviceability Tool (RAStool). If the instruction set is not the instruction set of the ARM architecture, then an instruction for checking abnormal MCE faults is generated.

4. The method according to claim 1, characterized in that, The step of determining the reliability verification result of the device under test based on the obtained log information of the device under test includes: In response to the device under test meeting the verification conditions, the reliability verification result of the device under test is determined based on the obtained log information of the device under test.

5. The method as described in claim 4, characterized in that, The verification conditions include one or more of the following conditions: The inspection reporting time is less than or equal to the preset reporting time, and the inspection reporting time is the time when the device to be verified provides the inspection results; The difference between the inspection reporting time and the fault injection time is less than or equal to a preset value; The device to be verified is in normal operating condition.

6. The method according to claim 2, characterized in that, The step of determining the reliability verification result of the device under test based on the obtained log information of the device under test includes: Based on the first log information corresponding to the first fault, determine the verification result corresponding to the first fault; and / or, Based on the second log information corresponding to the second fault, the verification result corresponding to the second fault is determined.

7. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of any one of the methods described in claims 1 to 6.

8. A reliability verification system, characterized in that, The system includes: the electronic device as described in claim 7 and one or more devices to be verified; The device to be verified includes: The receiving module is used to receive fault configuration commands; The configuration module is used to respond to the fault configuration command and modify the configuration parameters; The logging module is used to generate log information.

9. The system as described in claim 8, characterized in that, The device to be verified also includes: The inspection module is used to detect whether the device to be verified has malfunctioned; if a malfunction is detected, the inspection results are reported.

10. A computer-readable storage medium, characterized in that, It includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described in claims 1 to 6.

Images