A fault diagnosis method and electronic device

Abstract

The application discloses a fault diagnosis method and an electronic device. Fault information of a device is input into a model to obtain a candidate root cause set generated by the model, and the candidate root cause set includes at least two candidate root causes. A candidate tool set is determined based on each candidate root cause in the candidate root cause set, and the candidate tool set includes at least one candidate tool. A target tool is selected from the candidate tool set based on at least the fault information and the candidate root cause set. The target tool is executed, target device information is collected through the target tool, and the target device information is used to distinguish the candidate root causes in the candidate root cause set. Fault diagnosis is performed on the device based on the target device information.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a fault diagnosis method and electronic device. Background Technology

[0002] When a device malfunctions, the diagnosis process typically involves using traditional diagnostic tools to collect data such as system information, event logs, service status, and device status. This collected data is then displayed without any targeted information collection. As a result, the fault diagnosis process consumes a significant amount of time for information processing, impacting the user experience. Summary of the Invention

[0003] In view of this, this application provides a fault diagnosis method and an electronic device, the specific solution of which is as follows:

[0004] A fault diagnosis method, comprising:

[0005] The fault information of the equipment is input into the model to obtain a set of candidate root causes generated by the model, wherein the set of candidate root causes includes at least two candidate root causes;

[0006] A set of candidate tools is determined based on each candidate root cause in the set of candidate root causes, wherein the set of candidate tools includes at least one candidate tool;

[0007] Based at least on the fault information and the candidate root cause set, a target tool is selected from the candidate tool set;

[0008] The target tool is executed to collect target device information, which is used to distinguish candidate root causes in the candidate root cause set.

[0009] The device is diagnosed for faults based on the target device information. Attached Figure Description

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

[0011] Figure 1 This is a flowchart of a fault diagnosis method disclosed in an embodiment of this application;

[0012] Figure 2 This is a flowchart of a fault diagnosis method disclosed in an embodiment of this application;

[0013] Figure 3 This is a flowchart of a fault diagnosis method disclosed in an embodiment of this application;

[0014] Figure 4 This is a schematic diagram of a fault diagnosis process when a system fails to sleep / wake up, as disclosed in an embodiment of this application.

[0015] Figure 5 This is a flowchart of a fault diagnosis method disclosed in an embodiment of this application;

[0016] Figure 6 This is a flowchart of a fault diagnosis method disclosed in an embodiment of this application;

[0017] Figure 7 This is a schematic diagram illustrating the output of multiple fault root causes and the corresponding role types for each fault root cause, as disclosed in an embodiment of this application.

[0018] Figure 8 This is a flowchart of a fault diagnosis method disclosed in an embodiment of this application;

[0019] Figure 9 This is a schematic diagram of the structure of a fault diagnosis system disclosed in an embodiment of this application;

[0020] Figure 10 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0022] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0023] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0024] This application discloses a fault diagnosis method, the flowchart of which is shown below. Figure 1 As shown, it includes:

[0025] Step S11: Input the equipment fault information into the model to obtain a candidate root cause set generated by the model. The candidate root cause set includes at least two candidate root causes.

[0026] If a malfunction occurs during equipment use, the malfunction information can be input into the model. The model then generates a set of candidate root causes, each containing at least two candidate root causes. Each candidate root cause represents a hypothetical cause that could lead to the malfunction corresponding to the malfunction information. The model generates the corresponding set of candidate root causes based on the input malfunction information. It can employ a generative model based on a large language model, or a diagnostic model built on a rule engine, Bayesian network, or graph neural network, as long as it can output the corresponding set of candidate root causes based on the input malfunction information.

[0027] The fault information includes information that reflects the current or historical abnormal operation of the device. In one embodiment, the fault information is a fault description information input by the user. The user can input a fault phenomenon described in natural language through the device's interactive interface, such as: the computer has no sound, the camera cannot be turned on, the computer cannot be woken up after sleeping, etc. In another embodiment, the fault information may include system abnormal status information, error reports or log records automatically detected by the device.

[0028] For example, for the fault message "computer has no sound," the candidate root cause set generated by the model can include multiple candidate root causes, such as: incorrect default playback device, application audio session being muted, abnormal audio service, abnormal audio driver, etc.; as another example, for the fault message "camera cannot be turned on," the candidate root cause set can also include multiple candidate root causes, such as: camera privacy permissions being denied, camera device being disabled, abnormal camera driver, etc.; and as yet another example, for the fault message "computer cannot be woken up after sleep," the candidate root cause set can include multiple candidate root causes, such as: Modern Standby wake-up failure, driver power state transition failure, Fast Startup causing recovery anomalies, etc.

[0029] Step S12: Determine a candidate tool set based on each candidate root cause in the candidate root cause set, wherein the candidate tool set includes at least one candidate tool;

[0030] The candidate tool set includes at least one candidate tool, each of which is used to collect device information related to the corresponding candidate root cause.

[0031] Specifically, a pre-set association relationship can be established to characterize the correspondence between each candidate root cause and each tool. Based on this association relationship, the tools associated with each candidate root cause in the candidate root cause set can be determined, and these determined tools can be used as candidate tools to form a candidate root cause set.

[0032] For example, for the candidate root cause of "default playback device error," associated tools could include: audio endpoint enumeration tools, default playback device query tools, etc.; for the candidate root cause of "application audio session muted," associated tools could include: audio session query tools, process volume status query tools, etc.; for the candidate root cause of "audio service abnormality," associated tools could include: service status query tools; and for the candidate root cause of "audio driver abnormality," associated tools could include: driver status query tools, device manager status query tools, etc. Therefore, when the candidate root cause set includes four candidate root causes—default playback device error, application audio session muted, audio service abnormality, and audio driver abnormality—the corresponding candidate tool set could include: audio endpoint enumeration tools, audio session query tools, service status query tools, and driver status query tools. In this example, for each candidate root cause, only one tool needs to be identified; it is not necessary to identify all associated tools as candidate tools. Of course, each tool associated with each candidate root cause could also be considered a candidate tool; this is not specifically limited here.

[0033] Step S13: Select a target tool from the candidate tool set, based at least on the fault information and the candidate root cause set.

[0034] The target tool is at least one tool selected from the set of candidate tools for performing the acquisition operation in the current diagnosis.

[0035] The target tool can be selected based on the correlation between each candidate tool in the candidate tool set and each candidate root cause in the candidate root cause set. Alternatively, the target tool can be selected based on the ability of each candidate tool to distinguish between candidate root causes in the candidate root cause set by the device information it can collect. Distinguishing ability refers to the extent to which the device information collected by the candidate tool supports or opposes a candidate root cause, thereby distinguishing that candidate root cause from other candidate root causes. For example, an audio session query tool can collect the muted state of an application audio session. This information can directly verify or exclude the candidate root cause that the application audio session is muted, but it does not have the ability to distinguish other candidate root causes such as audio driver abnormalities. Therefore, this tool has a certain distinguishing ability for the current candidate root cause set. Alternatively, the target tool can be selected based on factors such as the collection efficiency or execution risk of each candidate tool. For example, candidate tools with short collection time, low resource consumption, and minimal disturbance to the system state can be given priority as target tools.

[0036] There can be one or more target tools.

[0037] Step S14: Execute the target tool to collect target device information. The target device information is used to distinguish candidate root causes in the candidate root cause set.

[0038] Target device information is used to distinguish candidate root causes in the candidate root cause set. Specifically, target device information is information that can reflect the current status, configuration or operating history of the device. This information can be used to determine whether each candidate root cause is valid or not.

[0039] For example, if the target tool is an audio session query tool, the target device information collected after executing the tool includes: the mute status and volume value of the target application's audio session. This target device information can be used to distinguish candidate root causes. Specifically, if the collected information is "mute=true", that is, the mute status is on, then this information matches the candidate root cause that the application's audio session is muted; if the collected information is "mute=false", that is, the mute status is off, then this information does not match the candidate root cause that the application's audio session is muted.

[0040] For example, if the target tool is a driver status query tool, the target device information collected after executing the tool includes: the device's driver error code, device enable status, etc. This target device information can be used to distinguish candidate root causes. Specifically, if the collected information is "ConfigManagerErrorCode=22", meaning the device is disabled, then this information matches the candidate root cause of the device being disabled; if the collected information is "ConfigManagerErrorCode=0", meaning the device is working normally, then this information does not match the candidate root cause of the driver being abnormal.

[0041] Step S15: Perform fault diagnosis on the equipment based on the target equipment information.

[0042] After determining the target device information, fault diagnosis is performed on the device based on the target information. Specifically, this can be done as follows: Based on the degree of consistency between the target device information and each candidate root cause, the confidence level of each candidate root cause is determined. The confidence level characterizes the probability that each candidate root cause is the true cause of the fault information. The device determines the target candidate root cause from the set of candidate root causes based on the confidence level of each candidate root cause. The target candidate root cause is the determined fault root cause most likely to cause the fault information. Alternatively, it can be done by comparing each candidate root cause with the collected target device information to determine the candidate root cause with the highest matching degree as the fault root cause. Alternatively, it can be done by pre-setting a diagnostic rule base, which pre-stores the corresponding rules between device information and fault root causes. The collected target device information is matched with the rules in the diagnostic rule base to obtain the matching result, and the fault root cause is determined based on the matching result.

[0043] After determining the root cause of the fault, a diagnostic result can be output, which includes at least the root cause of the fault, so that staff can take action as soon as possible based on the diagnostic result to eliminate the fault and restore the normal operation of the equipment.

[0044] The fault diagnosis method disclosed in this embodiment inputs fault information into a model to obtain a candidate root cause set generated by the model. The candidate root cause set includes at least two candidate root causes. This embodiment generates multiple candidate root causes through the model, which can comprehensively cover various hypothetical causes that may lead to the current fault and avoid missing the real root cause. Based on each candidate root cause in the candidate root cause set, a candidate tool set is determined, so that the selection of diagnostic tools corresponds precisely to the current candidate root cause set. This ensures that only tools related to the current candidate root cause are selected, avoiding the collection of device information unrelated to the current fault and reducing system resource consumption. At least based on the fault information and the candidate root cause set, a target tool is selected from the candidate tool set. By screening candidate tools instead of executing all tools, the target device information for distinguishing each candidate root cause can be obtained at a low cost in the early stage of diagnosis, which speeds up the diagnosis process and shortens the user's waiting time. By executing the target tool to collect target device information, the degree of consistency of each candidate root cause is objectively judged based on the target device information, so that the root cause inference has clear information basis and improves the objectivity and accuracy of the diagnosis.

[0045] The flowchart of the fault diagnosis method disclosed in this embodiment is as follows: Figure 2 As shown, it includes:

[0046] Step S21: Input the equipment's fault information into the model to obtain a candidate root cause set generated by the model. The candidate root cause set includes at least two candidate root causes.

[0047] Step S22: Determine a candidate tool set based on each candidate root cause in the candidate root cause set, wherein the candidate tool set includes at least one candidate tool;

[0048] Step S23: Select a target tool from the candidate tool set, based at least on the fault information and the candidate root cause set;

[0049] Step S24: Execute the target tool to collect target device information. The target device information is used to distinguish candidate root causes in the candidate root cause set.

[0050] Step S25: Determine the confidence level of each candidate root cause in the candidate root cause set based at least on the target device information, and identify the candidate root causes with a confidence level higher than that of other candidate root causes as suspected root causes.

[0051] Based on the correspondence between target device information and each candidate root cause, the confidence level of each candidate root cause is determined. The correspondence characterizes the degree to which the target device information supports or opposes a candidate root cause. Specifically, if a supporting relationship exists between the target device information and a candidate root cause, the target device information can be identified as supporting evidence for that candidate root cause. In this case, the target device information indicates an increased probability that the candidate root cause is valid, and the confidence level of the candidate root cause is increased according to the strength of the supporting relationship. Conversely, if an opposing relationship exists between the target device information and a candidate root cause, the target device information can be identified as opposing evidence for that candidate root cause. In this case, the target device information indicates a decreased probability that the candidate root cause is valid, and the confidence level of the candidate root cause is decreased according to the strength of the opposing relationship. Different pieces of device information, based on their correspondence with candidate root causes—that is, supporting or opposing relationships—are used as supporting or opposing evidence in the confidence level calculation, respectively.

[0052] Specifically, the confidence level of each candidate root cause can be determined by comprehensively considering the number of device information in the target device information that has a supporting or opposing relationship with each candidate root cause. The more device information that has a supporting relationship with a candidate root cause and the stronger the relationship, the higher the confidence level of that candidate root cause. Conversely, the more device information that has an opposing relationship with a candidate root cause and the stronger the relationship, the lower the confidence level of that candidate root cause. For example, in diagnosing audio silence faults, suppose the candidate root cause set includes four candidate root causes: incorrect default playback device, application audio session being muted, audio service abnormality, and audio driver abnormality. After executing the audio session query tool, the target device information collected is: target application audio session mute=true. This target device information has a supporting relationship with the candidate root cause of application audio session being muted, so it serves as supporting evidence for this candidate root cause, increasing its confidence. After executing the default device query tool, the target device information collected is: the default playback device is a physical speaker and is in normal condition. This target device information does not have a supporting relationship with the candidate root cause of incorrect default playback device, so it does not receive a confidence increase. Based on the number of supporting evidences obtained for each candidate root cause, the candidate root cause with the highest confidence, application audio session being muted, is identified as the suspected root cause.

[0053] Alternatively, the weight of each piece of information in the confidence calculation can be determined based on the reliability of the source of the target device information, and its reliability level can be determined based on the data source type of the target device information. For example, the target device information from the hardware layer has higher reliability, so its weight can be set higher; the target device information from the software layer has relatively lower reliability, so its weight can be appropriately reduced. The confidence of each candidate root cause can be determined based on the weighted information of each device.

[0054] Of course, there are other ways to determine the confidence level of each candidate root cause, which will not be specified here.

[0055] After determining the confidence level of each candidate root cause in the candidate root cause set, the candidate root cause with the highest confidence level is identified as a suspected root cause. A suspected root cause represents a hypothetical cause inferred from the currently collected target device information that is most likely to lead to the fault corresponding to the fault information. At this point, it cannot be directly identified as the root cause of the fault. Specifically, the candidate root cause with the highest confidence level among all candidate root causes is selected by comparing the confidence levels of each candidate root cause and selecting the candidate root cause with a higher confidence level than the other candidate root causes. This selected candidate root cause is identified as a suspected root cause.

[0056] Step S26: Execute the repair action that matches the suspected root cause and obtain the execution result. The repair action is used to restore the fault corresponding to the fault information of the equipment.

[0057] Each candidate root cause has a corresponding remedial action. After identifying a suspected root cause, the remedial action corresponding to that suspected root cause is determined and executed. The remedial action is used to restore the equipment to avoid or mitigate the fault corresponding to the fault information of the equipment.

[0058] For example, if the suspected root cause is an incorrect default playback device, the corresponding remedial action could include switching the default playback device to a physical speaker or a currently available audio output device; if the suspected root cause is that the application audio session is muted, the corresponding remedial action could include unmute the target application audio session.

[0059] After performing a repair action, the execution result is obtained. The result may include at least: whether the repair action was successfully executed, and information about the device's status changes after the action, such as: whether related service status has been restored, whether device error codes have been resolved, and whether user malfunctions have been eliminated. For example, if the repair action was to switch the default playback device, the result would include: whether the switching operation was successful, whether the default device after the switch is the physical speaker, and whether there is sound output after the switch. If the repair action was to unmute an application's audio session, the result would include: whether the unmute operation was successful, whether the target session's mute status changed from true to false, and whether the target session's volume was restored.

[0060] Furthermore, before executing any repair actions, the risk level of the action is assessed. If the risk level is low, such as involving only software state adjustments that will not cause irreversible damage to the system, the repair action can be executed directly. If the risk level is high, such as involving driver updates, registry modifications, or system configuration changes that may affect system stability, a user confirmation request is first sent, and the repair action is executed only after receiving user confirmation. This risk assessment and user confirmation mechanism ensures that the diagnostic process is controllable, rollbackable, and auditable.

[0061] Step S27: Determine the diagnostic strategy based on the execution results, so as to complete the fault diagnosis of the equipment based on the diagnostic strategy.

[0062] The diagnostic strategy is determined based on the execution results. The diagnostic strategy is used to indicate how to continue to complete the fault diagnosis of the equipment based on the current execution results.

[0063] If the execution result indicates that the repair action was successfully executed and the equipment malfunction has been eliminated after the repair action, the suspected root cause is identified as the root cause of the equipment malfunction, and the diagnosis is complete. If the execution result indicates that the repair action was successfully executed, but the equipment malfunction has not been completely eliminated after the repair action, further verification may be needed to confirm whether the suspected root cause is valid or whether there are other concurrent root causes. If the execution result indicates that the repair action was not successfully executed, such as when the repair action failed, the suspected root cause needs to be re-evaluated, and other candidate root causes should be considered as suspected root causes.

[0064] After determining the diagnostic strategy based on the execution results, the subsequent operations are performed according to the diagnostic strategy until the fault diagnosis of the equipment is completed. The subsequent operations may include: confirming the root cause of the fault, outputting the diagnostic conclusion, reporting the reason for the diagnostic failure and prompting the user to intervene manually, or triggering a new round of candidate root cause inference and tool collection, etc.

[0065] If the root cause of the fault is confirmed based on the execution results, a diagnostic result is output. The diagnostic result includes the finally determined root cause of the fault, at least some target device information that supports the root cause of the fault, the performed repair actions, and the execution results. If the root cause of the fault cannot be confirmed based on the execution results, for example, if the fault does not disappear after performing repair actions, and the confidence level of each candidate root cause is low, a diagnostic failure report is output. The diagnostic failure report includes the diagnostic steps that have been performed, the confidence level of each candidate root cause, the target device information that has been collected, the performed repair actions, and the execution results, so that users or technicians can make manual judgments or further troubleshoot based on the diagnostic failure report.

[0066] The fault diagnosis method disclosed in this embodiment determines the confidence level of each candidate root cause based at least on the target device information. The confidence level is obtained by comprehensively considering multiple factors of the candidate root cause. By quantitatively evaluating each candidate root cause through the confidence level, the likelihood that each candidate root cause is the real cause can be more accurately reflected, thereby improving the accuracy of root cause inference. After determining the confidence level of each candidate root cause, the candidate root cause with the highest confidence level is identified as the suspected root cause, and the repair action matching the suspected root cause is executed. This allows the diagnosis process to switch from inferring the root cause to verifying the root cause, realizing the combination of root cause inference and repair action execution, forming a complete diagnosis process from inference to verification, which improves the interpretability of the diagnosis and the user's trust in the diagnosis results.

[0067] Furthermore, in the fault diagnosis method disclosed in this embodiment, determining the confidence level of each candidate root cause in the candidate root cause set based at least on the target device information can be specifically as follows:

[0068] A first factor is determined, which characterizes the matching degree between the equipment's fault information and each candidate root cause; a second factor is determined, which characterizes the temporal correlation between the occurrence time of the target equipment information and the fault period corresponding to the fault information; a third factor is determined, which characterizes the directional degree of the error codes in the target equipment information to each candidate root cause; a fourth factor is determined, which characterizes the consistency between information in the target equipment information that supports the same candidate root cause; based on the first, second, third, and fourth factors, the confidence level of each candidate root cause is determined.

[0069] After collecting target device information using the target tool, it is necessary to determine the confidence level of each candidate root cause in the candidate root cause set based on the target device information. The confidence level of each candidate root cause can be determined by: determining the first factor, the second factor, the third factor, and the fourth factor, and then comprehensively determining the confidence level of the candidate root cause based on each factor.

[0070] The first factor is used to characterize the matching degree between the fault information of the device and each candidate root cause. The first factor reflects the semantic matching degree between the fault information input by the user and each candidate root cause. In the early stage of diagnosis, based on the fault information input by the user, the semantic correlation between each candidate root cause and the fault information is judged, so that the candidate root cause that is more relevant to the fault phenomenon described by the user has a higher confidence in the initial stage. The fault information input by the user can be text descriptions such as: the computer has no sound, the camera cannot be turned on, the computer cannot be woken up after sleep.

[0071] The matching degree between fault information and candidate root causes can be determined by the model when generating the candidate root cause set. Specifically, based on the input fault information, the model not only outputs the corresponding candidate root cause set, but also outputs the matching degree score between each candidate root cause and the fault information, which serves as the first factor. Alternatively, the first factor can be determined based on a preset mapping relationship between fault information and candidate root causes. Specifically, a correspondence table between fault keywords and candidate root causes can be pre-defined. For example, keywords such as "no sound," "cannot hear," "silent," and "audio" have a high matching degree with audio-related candidate root causes such as "default playback device error," "application audio session muted," "audio service abnormality," and "audio driver abnormality." Alternatively, natural language processing technology or artificial intelligence models can be used to perform semantic understanding of the fault information and calculate the semantic similarity between the fault information and each candidate root cause, which serves as the first factor.

[0072] The second factor is used to characterize the temporal correlation between the occurrence time of the target device information and the fault period corresponding to the fault information. The second factor reflects the temporal proximity between the occurrence time of the target device information and the fault occurrence time described by the user. The closer the target device information is to the fault occurrence time, the stronger its indicative significance of the fault. The farther the target device information is from the fault occurrence time interval, the lower its correlation with the current fault.

[0073] Specifically, the fault time period corresponding to the fault information can be obtained. The fault time period can be extracted from the fault information entered by the user. For example, if the user enters the fault information: "My computer suddenly lost sound this morning," then the fault time period is this morning. The fault time period can also be automatically determined based on the first occurrence time of the abnormal event in the system log. The collection time or occurrence time of the target information can also be obtained. For event log-type target device information, the occurrence time is the timestamp of the event record. For status query-type target device information, such as driver status, service status, etc., the collection time is the execution time of the tool. Then, based on the time difference between the target device information time and the fault time period, the second factor can be determined. Specifically, the second factor is negatively correlated with the time difference; the smaller the time difference, the higher the value of the second factor; the larger the time difference, the lower the value of the second factor. Alternatively, a piecewise function can be used to determine the second factor. For example, target device information within a preset time range before and after the fault time period has the highest second factor value; target device information outside the preset time range but still within a reasonable time window has a medium second factor value; and target device information far from the fault time period has a low second factor value.

[0074] The third factor is used to characterize the degree of indicativeness of error codes in the target device information to each candidate root cause. The third factor reflects the indicative strength of error codes contained in the target device information to each candidate root cause. Error codes can be system error codes, driver error codes, event IDs, etc. Different error codes have different indicativeness to different candidate root causes. Some error codes strongly point to a specific candidate root cause, while some error codes only have general indicative meaning.

[0075] A pre-defined indexing table can be used to link error codes to candidate root causes. This table stores the indexing weight of each error code for each candidate root cause. Based on the error code in the target device information, the indexing table is queried to determine the third factor. For example, `ConfigManagerErrorCode=22` indicates that the device is disabled. This error code has a very strong relevance to the candidate root cause of "device disabled," and its indexing weight can be set to 0.95. It has some relevance to the candidate root cause of "driver exception," and its indexing weight can be set to 0.30. It has virtually no relevance to the candidate root cause of "service exception," and its indexing weight can be set to 0.05.

[0076] The fourth factor is used to characterize the degree of consistency among information supporting the same candidate root cause in the target device information. The fourth factor reflects the consistency of multiple target device information from different sources when pointing to the same candidate root cause. When multiple independent sources of target device information all point to the same candidate root cause, the confidence of the candidate root cause should be further enhanced; conversely, if multiple target device information points in different directions or contradicts each other, the confidence of each candidate root cause should be adjusted accordingly.

[0077] The fourth factor is determined based on the quantity, source independence, and strength of evidence of the target device information supporting each candidate root cause. This can be achieved by counting the number of target device information pieces obtained for each candidate root cause, i.e., the amount of supporting evidence. For each candidate root cause, the more supporting evidence it receives, the higher the value of the fourth factor. The fourth factor can also be determined based on the diversity of the target device information sources. If the target device information supporting the same candidate root cause comes from multiple independent data sources, such as WMI device status, driver status queries, and ETW event tracing, the consistent indication from multiple independent sources has higher credibility than that from a single source, thus the fourth factor value for this candidate root cause is higher than that from only a single data source. Furthermore, the fourth factor can be determined based on the logical consistency between the target device information. If there is logical consistency among multiple target device information pieces, such as a non-zero driver error code and an ETW device initialization failure event occurring simultaneously, both logically pointing to a driver anomaly, the fourth factor value is higher. Conversely, if there is logical contradiction among multiple target device information pieces, such as a zero driver error code but an ETW event indicating device initialization failure, the fourth factor value is lower.

[0078] The confidence level of a candidate root cause is determined by a weighted sum of the first, second, third, and fourth factors. Each factor is assigned a pre-defined weight value, and the sum of the products of each factor and its corresponding weight yields the confidence level of each candidate root cause. The weight values ​​can be pre-set based on the importance of the factor in the confidence calculation, or dynamically adjusted according to the diagnostic scenario; for example, the weights of each factor can differ for different fault types. The weights of each factor satisfy a normalization condition, meaning the sum of the weights of all factors is 1.

[0079] When calculating the confidence level, the weights of each factor can be dynamically adjusted according to the characteristics of each candidate root cause. For example, when the directionality of the error code in the target device information is very clear, that is, the value of the third factor is high, the weight of the third factor can be increased to make the confidence level calculation more dependent on the directionality of the error code. When the time series information of the target device information is not accurate enough, the weight of the second factor can be reduced.

[0080] Additionally, it should be noted that in determining the confidence score in this embodiment, in addition to the four factors mentioned above, other factors may also be considered, such as: a fifth factor to characterize whether there are executable and retrievable verification actions for the candidate root cause; a sixth factor to characterize whether the same device has had similar problems in its historical records; and a seventh factor to characterize whether there is evidence to exclude the candidate root cause, etc. Therefore, the formula for determining the confidence score can be:

[0081] Score=W1×K1+W2×K2+W3×K3+W4×K4+W5×K5+W6×K6-W7×K7

[0082] Wherein, W1 is the first factor, W2 is the second factor, W3 is the third factor, W4 is the fourth factor, W5 is the fifth factor, W6 is the sixth factor, W7 is the seventh factor, K1 is the first weight corresponding to the first factor, K2 is the second weight corresponding to the second factor, K3 is the third weight corresponding to the third factor, K4 is the fourth weight corresponding to the fourth factor, K5 is the fifth weight corresponding to the fifth factor, K6 is the sixth weight corresponding to the sixth factor, and K7 is the seventh weight corresponding to the seventh factor.

[0083] Of course, other factors can be used when determining the confidence level, which will not be elaborated here.

[0084] This embodiment comprehensively evaluates the confidence of each candidate root cause from different dimensions using four factors: the first factor reflects the semantic matching degree between fault information and candidate root causes, ensuring that the diagnostic direction is consistent with the user's description; the second factor reflects the temporal relevance of target device information, ensuring that only evidence within the fault period is used for judgment; the third factor reflects the directionality of error codes to candidate root causes, allowing key error codes to play a decisive role; and the fourth factor reflects the consistency of multi-source evidence, rewarding consistent directionality from multiple sources and penalizing contradictory information. These four factors comprehensively evaluate candidate root causes from four dimensions: semantics, temporality, semantic directionality, and multi-source consistency. Compared to a single-dimensional judgment method, this approach more accurately reflects the probability of each candidate root cause being valid, significantly improving the accuracy of root cause inference. Simultaneously, the multi-dimensional confidence quantification evaluation provides an initial confidence ranking for subsequent verification, enabling the verification process to prioritize the verification of the most likely candidate root causes, thus improving overall diagnostic efficiency.

[0085] This embodiment discloses a fault diagnosis method, the flowchart of which is as follows: Figure 3 As shown, it includes:

[0086] Step S31: Input the equipment fault information into the model to obtain a candidate root cause set generated by the model. The candidate root cause set includes at least two candidate root causes.

[0087] Step S32: Determine a candidate tool set based on each candidate root cause in the candidate root cause set, wherein the candidate tool set includes at least one candidate tool;

[0088] Step S33: Select a target tool from the candidate tool set, based at least on the fault information and the candidate root cause set.

[0089] Step S34: Execute the target tool to collect target device information. The target device information is used to distinguish candidate root causes in the candidate root cause set.

[0090] Step S35: Determine the confidence level of each candidate root cause in the candidate root cause set based at least on the target device information, and identify the candidate root causes with a confidence level higher than that of other candidate root causes as suspected root causes.

[0091] Step S36: Execute the repair action that matches the suspected root cause and obtain the execution result. The repair action is used to restore the fault corresponding to the fault information of the equipment.

[0092] Step S37: Obtain the expected state corresponding to the suspected root cause. The expected state is: if the suspected root cause is established, the state that the device is expected to reach when performing the repair action.

[0093] Each candidate root cause has a corresponding repair action and an expected state after the repair action is completed, i.e., the expected state. The expected state is a predefined criterion used to verify whether a candidate root cause is valid. When a candidate root cause is identified as a suspected root cause, the expected state corresponding to the suspected root cause is obtained from the preset correspondence. The expected state defines the state that the device should present after executing the corresponding repair action, assuming that the suspected root cause is valid.

[0094] For example, for the suspected root cause of an incorrect default playback device, the expected state could include: after performing the repair action of switching the default playback device to the physical speaker, the device's default playback device should change to the physical speaker, and the sound output should be restored. Another example: for the suspected root cause of a muted application audio session, the expected state could include: after performing the repair action of unmuting the target application audio session, the muted state of the target application audio session should change from true to false, and the volume of the target application audio session should be greater than a preset threshold, and the sound output should be restored. Yet another example: for the suspected root cause of an abnormal audio service, the expected state could include: after performing the repair action of restarting the audio service Audiosrv and / or the audio endpoint generator service AudioEndpointBuilder, the running status of the audio service should change from Stopped to Running, audio endpoints should be able to be enumerated normally, and the sound output should be restored.

[0095] The expected state can include one or more expected state parameters. When multiple expected state parameters are included, different matching weights can be set according to the importance of each parameter to comprehensively judge the degree of matching between the execution result and the expected state.

[0096] Step S38: In response to the execution result matching the expected state, the suspected root cause is determined as the root cause of the equipment failure;

[0097] If the execution result matches the expected state, the root cause is determined to be valid and identified as the root cause of the equipment failure. Here, the execution result matching the expected state means that the actual change in the equipment state reflected by the execution result is consistent with the expected state, that is, the change in the equipment state after the repair action has reached the conditions defined by the expected state.

[0098] The matching of the execution result with the expected state can be either a complete match or a partial match. A complete match means that the execution result is completely consistent with the expected state. For a partial match, the expected state includes multiple state parameters. When the actual execution result satisfies most of these parameters, it can also be determined as a match. For example, the expected state consists of three parameters: service state becomes Running, audio endpoints are enumerable, and sound output is restored. The actual execution result is: service state becomes Running, audio endpoints are enumerable, but sound output is not fully restored. When two of the three parameters are satisfied, it can be determined as a partial match, and other factors should be considered together for a comprehensive judgment.

[0099] When determining whether the execution result matches the expected state, the degree of matching can also be determined based on the similarity between the execution result and the expected state. If the similarity exceeds the preset matching threshold, it is determined to be a match; if the similarity does not exceed the preset matching threshold, it is determined to be a mismatch.

[0100] Furthermore, when it is determined that the repair action matches the expected state, the confidence level of the corresponding suspected root cause can be updated, that is, the confidence level of the suspected root cause can be increased, so as to ensure that when a similar problem occurs again, the updated confidence level can be used as the initial confidence level of the root cause, so as to make a basis for selecting the suspected root cause or the root cause of the failure.

[0101] After identifying the suspected root cause of the fault, the diagnostic results are output. The diagnostic results may include: the root cause of the fault, at least some target device information that supports the root cause of the fault, the repair actions performed and the results of the actions performed, and the matching of the results of the actions performed with the expected state.

[0102] Step S39: In response to the mismatch between the execution result and the expected state, update the confidence of the candidate root causes in the candidate root cause set according to the execution result, and redetermine the suspected root causes based on the candidate root cause set after updating the confidence.

[0103] If the execution result is determined to be inconsistent with the expected state, the suspected root cause is not confirmed. Instead, the confidence level of the candidate root causes in the candidate root cause set is updated based on the execution result, and the suspected root cause is re-determined based on the updated candidate root cause set. A mismatch between the execution result and the expected state means that the actual change in the device's state reflected by the execution result does not conform to the expected state. That is, the change in the device's state after performing the repair action does not meet the conditions defined by the expected state. For example, the expected state is a change from silent state to false and sound restored. If the actual execution result is: silent state becomes false but sound is still not restored, or silent state does not become false, then it is determined to be a mismatch, and the suspected root cause is not established.

[0104] When it is determined that the execution result does not match the expected state, the confidence level of the suspected root cause is reduced. The extent of the reduction can be determined based on the degree of mismatch: if the difference between the execution result and the expected state is large, the reduction will be large; if the difference is small, the reduction will be small. In one implementation, if there is clear evidence of opposition, such as that the relevant state has not changed at all after the repair action is performed, the suspected root cause can be excluded from the candidate root cause set or its confidence level can be reduced to zero.

[0105] Updating the confidence level of a suspected root cause can be done in the following ways: if the matching result is a match or a non-match, a pre-set adjustment value is directly increased or decreased; if the matching result is a degree of match, the magnitude of the adjustment value to be increased or decreased can be determined based on the different ranges of the degree of match, and then the confidence level of the suspected root cause is updated based on the determined adjustment value.

[0106] After updating the confidence level of candidate root causes, the confidence level of other candidate root causes in the candidate root cause set can also be updated based on the execution results. Specifically, the execution results, as newly collected device information, can be used to support or oppose other candidate root causes. For example, after performing the repair action of unmute the target application's audio session, if the execution result indicates that the operation was successfully performed but the sound has not been restored, the probability of another possibility being true increases after one possibility is eliminated. Therefore, the execution result can serve as supporting evidence for the candidate root cause of a default playback device error, thereby increasing its confidence level.

[0107] If the execution result does not match the expected state, after updating the confidence levels of candidate root causes in the candidate root cause set, the confidence levels of each candidate root cause in the candidate root cause set need to be re-sorted so that new suspected root causes can be selected based on the updated confidence levels. If a candidate root cause is excluded after updating the confidence levels, that is, its confidence level is reduced to zero or below a preset exclusion threshold, then that candidate root cause will no longer be considered when re-determining suspected root causes.

[0108] After re-identifying the suspected root cause, the remedial actions matching the new suspected root cause are re-executed, and subsequent steps continue until the root cause of the fault is confirmed or a preset termination condition is met. The preset termination condition may include: all candidate root causes in the candidate root cause set are excluded, the number of diagnostic rounds reaches a preset maximum, the diagnostic time exceeds a preset time threshold, or the user actively terminates the diagnostic process. When the termination condition is met, a diagnostic failure report is output, which includes: the excluded candidate root causes and the reasons for exclusion, the history of confidence changes for each candidate root cause, the remedial actions executed, and the execution results.

[0109] Furthermore, when updating the confidence of candidate root causes, the direction of confidence adjustment for other candidate root causes is determined based on the reasons for the mismatch between the current execution result and the expected state. For example, if the execution result is: the unmute operation is successful and the mute state has become false, but the sound has not been restored, then this result reduces the confidence of the suspected root cause that the application audio session is muted, while increasing the possibility that other candidate root causes such as default playback device error or audio driver abnormality are true, and can correspondingly increase the confidence of other candidate root causes.

[0110] like Figure 4 The diagram illustrates the fault diagnosis process when the system fails to sleep / wake up. First, the user inputs fault information, such as: "The computer frequently fails to wake up after going to sleep, and I can only restart it by pressing and holding the power button." Then, based on this fault information, candidate root causes are identified, forming a candidate root cause set. This set may include: R1: Modem Standby / S0ix wake-up failure (initial confidence level 0.25); R2: Driver power state transition failure (initial confidence level 0.20); R3: Storage controller / NVMe timeout (initial confidence level 0.18); R4: Fast Startup affecting recovery (initial confidence level 0.15); R5: BIOS / EC / chipset version issue (initial confidence level 0.12); R6: Automatic restart after blue screen (initial confidence level 0.10). Based on the above set of candidate root causes, the device information that needs to be collected should include: E1: Kernel-Power41 event; E2: Unexpected Shutdown 6008 event; E3: Sleep Enter42 event; E4: Wake107 event; E5: Powertransition109 event; E6: Modern Standby related events 506 / 173 / 137; E7: Storage129 / 153 event; E8: BugCheck1001 event; E9: Fast Startup registry status; E10: BIOS / EC / chipset driver version.

[0111] Next, a candidate tool set is determined, and a target tool is selected from the candidate tool set. The target tool is then used to collect target device information. At this point, the following results are obtained: E1: Sleep Enter42: Exists; E3: Kernel-Power41: Exists; E4: Unexpected Shutdown6008: Exists; E5: Modern Standby506 / 137: Exists; E9: Fast Startup: Enabled. However, some device information required by the candidate root cause is not obtained, such as: E2: Wake107: Missing; E6: Powertransition109: Does not exist; E7: Storage129 / 153: Does not exist; E8: BugCheck1001: Does not exist.

[0112] Based on the obtained target device information, the candidate root causes in the candidate root cause set are reordered according to their respective confidence levels. After adjusting the confidence levels, the confidence level of R1 is increased to 0.78, the confidence level of R4 is increased to 0.46, the confidence level of R5 is increased to 0.42, the confidence level of R2 is increased to 0.25, the confidence level of R3 is decreased to 0.16, and the confidence level of R6 is decreased to 0.08. Based on the ranking of candidate root causes after updating confidence, a suspected root cause is identified. The suspected root cause is R1. This suspected root cause is verified by executing a repair action that matches the suspected root cause to determine whether the execution result after the repair action matches the expected state. For example, for R1, if the root cause is Modem Standby / S0ix wake-up failure, then in the next sleep / wake cycle, it should be observed that: after Sleep Enter, there is a lack of normal Wake events, accompanied by Kernel-Power41 or 6008. Based on this, a sleep / wake operation is executed. For R4, if Fast Startup is the root cause, then after Fast Startup is turned off, the event sequence of Sleep42 → missing Wake 107 → Kernel-Power 41 should decrease or disappear. At this time, the repair action is to turn off Fast Startup to verify whether the execution result matches the expected state. Correspondingly, several candidate root causes with high confidence can be verified separately to determine the final result. The final result is: R1 is the root cause of the failure.

[0113] The fault diagnosis method disclosed in this embodiment obtains the expected state corresponding to the suspected root cause before performing the repair action, and compares the actual execution result with the expected state after performing the repair action. This enables falsifiable verification of the suspected root cause. By clearly defining the expected state change, the diagnosis result is clearly verified, ensuring the accuracy of the diagnosis result. When the execution result does not match the expected state, the confidence level of each candidate root cause in the candidate root cause set is updated according to the execution result. The confidence level of each candidate root cause can be adjusted based on the execution result, improving the overall diagnostic accuracy.

[0114] This embodiment discloses a fault diagnosis method, the flowchart of which is as follows: Figure 5 As shown, it includes:

[0115] Step S51: Input the equipment fault information into the model to obtain a candidate root cause set generated by the model. The candidate root cause set includes at least two candidate root causes.

[0116] Step S52: Determine a candidate tool set based on each candidate root cause in the candidate root cause set, wherein the candidate tool set includes at least one candidate tool;

[0117] Step S53: Select a target tool from the candidate tool set, based at least on the fault information and the candidate root cause set.

[0118] Step S54: Execute the target tool to collect target device information. The target device information is used to distinguish candidate root causes in the candidate root cause set.

[0119] Step S55: Determine the confidence level of each candidate root cause in the candidate root cause set based at least on the target device information, and identify the candidate root causes with a confidence level higher than that of other candidate root causes as suspected root causes.

[0120] Step S56: Execute the repair action that matches the suspected root cause and obtain the execution result. The repair action is used to restore the fault corresponding to the fault information of the equipment.

[0121] Step S57: In response to the existence of the first role identification condition, output multiple root causes of the device and the role type corresponding to each root cause of the fault. The role type is used to characterize the role type of the candidate root cause in the fault propagation chain.

[0122] After determining the confidence level of each candidate root cause in the candidate root cause set based on the target device information, the confidence level distribution of each candidate root cause in the candidate root cause set may exhibit different patterns: One pattern is that the confidence level of one candidate root cause is significantly higher than that of other candidate root causes, in which case this candidate root cause can be directly identified as the root cause of the fault; another pattern is that at least two candidate root causes have confidence levels higher than other candidate root causes, and the difference between the confidence levels of these two candidate root causes is small. In this case, a single confidence level ranking is insufficient to determine a unique root cause of the fault, and further differentiation based on role type is required. Therefore, when determining the diagnostic strategy based on the diagnostic results, different diagnostic strategies are triggered according to the confidence level distribution of each candidate root cause in the candidate root cause set.

[0123] Specifically, when the first role identification condition exists, the output device has multiple root causes of failure and a corresponding role type for each root cause. The role type is used to characterize the role of the candidate root cause in the failure propagation chain. The first role identification condition is characterized by: the existence of at least two candidate root causes in the candidate root cause set; the confidence level of at least two candidate root causes being greater than the confidence level of the other candidate root causes in the candidate root cause set besides the two candidate root causes; and the difference between the confidence levels of at least two candidate root causes being less than a first threshold.

[0124] Specifically, the confidence levels of each candidate root cause in the candidate root cause set can be sorted to determine the candidate root cause with the highest confidence level and the candidate root cause with the second highest confidence level. If the confidence levels of the candidate root cause with the highest confidence level and the candidate root cause with the second highest confidence level are both higher than the confidence levels of other candidate root causes, and the difference between the two is less than a first threshold, then it is determined that a first role identification condition exists. Of course, this embodiment is not limited to two candidate root causes. As long as the difference between the candidate root causes with the highest confidence levels in the confidence ranking is less than the first threshold, it can be determined that a first role identification condition exists. At this time, the output is these candidate root causes and the role type corresponding to each candidate root cause.

[0125] Alternatively, it can be defined as follows: in the candidate root cause set, there are at least two candidate root causes whose confidence levels exceed a preset first confidence threshold, and the difference between their confidence levels and that of the candidate root cause with the highest confidence level is less than the first threshold. This method does not require that the at least two candidate root causes must be higher than all other candidate root causes, as long as they all exceed a certain confidence level and their confidence levels are close. In theory, all candidate root causes that are higher than the first confidence threshold and whose confidence levels are small compared to that of the candidate root cause with the highest confidence level, as well as their corresponding role types, need to be output.

[0126] When the first role identification condition exists, if the target device information cannot significantly distinguish the at least two candidate root causes with the highest confidence, the possible reasons are: there is a causal propagation relationship between these at least two candidate root causes, that is, one root cause is the propagation result or accompanying phenomenon of the other root cause, or at least two candidate root causes correspond to different aspects of the same fault. In this case, it is necessary to further distinguish the roles of these two candidate root causes in order to determine which one is the real main cause of the fault.

[0127] The role types include at least: primary cause and propagation result. Primary cause indicates that the candidate root cause is the starting cause in the failure propagation chain, and other candidate root causes are caused by the primary cause. Propagation result indicates that the candidate root cause is an intermediate state or accompanying phenomenon caused by the primary cause, and should not be regarded as the primary cause of the failure alone.

[0128] In addition, when the first role identification condition exists, the device outputs multiple root causes of failure and the role type corresponding to each root cause. At the same time, it can also output the failure propagation chain or failure propagation path to show the propagation relationship between each candidate root cause.

[0129] For example, in the diagnosis of audio silence faults, the confidence scores of the two candidate root causes, audio driver abnormality and audio service abnormality, in the candidate root cause set are 0.82 and 0.76, respectively, which are much higher than other candidate root causes, and the difference between the two is less than the first threshold, such as 0.10. At this time, it is determined that the first role identification condition exists, and the fault root cause of audio driver abnormality, and the role type of the fault root cause as the main cause, and the fault root cause of audio service abnormality, and the role type of the fault root cause as the propagation result, are output. At the same time, the fault propagation chain is also output: audio driver abnormality → audio service startup failure → audio service abnormality.

[0130] Step S58: In response to the existence of a second role identification condition, output the root cause of the device failure.

[0131] When a second role identification condition exists, the root cause of the output device's failure is identified. The second identification condition indicates that a first candidate root cause exists in the candidate root cause set, and the difference between the confidence level of the first candidate root cause and the confidence levels of other candidate root causes in the candidate root cause set (excluding the first candidate root cause) is greater than a second threshold.

[0132] Specifically, the confidence levels of each candidate root cause in the candidate root cause set are sorted to determine the candidate root cause with the highest confidence level. If the difference between the candidate root cause with the highest confidence level and the candidate root cause with the second highest confidence level is greater than the second threshold, it is determined that a second role identification condition exists. At this time, the confidence level of the candidate root cause with the highest confidence level is much higher than the confidence levels of other candidate root causes in the candidate root cause set.

[0133] When a second role identification condition exists, and it is clearly determined that the confidence level of one candidate root cause is much higher than that of other candidate root causes, then the candidate root cause can be directly identified as the root cause of the failure. In this case, there is no need for further role classification. Alternatively, the candidate root cause can be directly identified as the main cause of the failure, without the need for role classification of other candidate root causes.

[0134] The fault diagnosis method disclosed in this embodiment outputs multiple root causes of faults and the role type corresponding to each root cause, enabling users to clearly understand the causal relationship and propagation path between each candidate root cause. In addition, by setting a first role identification condition and a second role identification condition, a balance is achieved between diagnostic efficiency and diagnostic accuracy. When the confidence distribution is clear, satisfying the second role identification condition allows for direct output of the root cause of the fault, avoiding unnecessary role analysis and improving diagnostic efficiency. When the confidence distribution is ambiguous, satisfying the first role identification condition allows for auxiliary judgment through role type, thereby improving diagnostic accuracy.

[0135] This embodiment discloses a fault diagnosis method, the flowchart of which is as follows: Figure 6 As shown, it includes:

[0136] Step S61: Input the equipment fault information into the model to obtain a candidate root cause set generated by the model. The candidate root cause set includes at least two candidate root causes.

[0137] Step S62: Determine a candidate tool set based on each candidate root cause in the candidate root cause set, wherein the candidate tool set includes at least one candidate tool;

[0138] Step S63: Select a target tool from the candidate tool set, based at least on the fault information and the candidate root cause set.

[0139] Step S64: Execute the target tool to collect target device information. The target device information is used to distinguish candidate root causes in the candidate root cause set.

[0140] Step S65: Determine the confidence level of each candidate root cause in the candidate root cause set based at least on the target device information, and identify the candidate root causes with a confidence level higher than that of other candidate root causes as suspected root causes.

[0141] Step S66: Execute the repair action that matches the suspected root cause and obtain the execution result. The repair action is used to restore the fault corresponding to the fault information of the equipment.

[0142] Step S67: In response to the existence of the first role identification condition, based on the temporal relationship and causal propagation path of the target device information corresponding to at least two candidate root causes, determine the role type corresponding to each of the at least two candidate root causes. The role type includes at least one of the following: main cause, propagation result, and accompanying phenomenon.

[0143] When the first role identification condition exists, it indicates that there are at least two candidate root causes with high confidence and similar confidence levels. It is difficult to determine the unique suspected root cause based solely on the confidence ranking. In this case, the role type corresponding to each of the at least two candidate root causes can be determined based on the temporal relationship and causal propagation path of the target device information corresponding to the at least two candidate root causes. The suspected root cause can then be determined based on the role type, and the suspected root cause can be verified to determine the root cause of the fault.

[0144] After determining the existence of a first role identification condition and identifying at least two candidate root causes with a higher confidence level than other candidate root causes, the corresponding target device information needs to be collected for each of the at least two candidate root causes. If the information has already been collected, it is not necessary to collect it again. After obtaining the target device information corresponding to each of the at least two candidate root causes, the temporal relationship between the target device information corresponding to each of the at least two candidate root causes is then obtained.

[0145] Each candidate root cause has an occurrence time or collection time for the target device information. The timestamps of the target device information corresponding to each candidate root cause are obtained and sorted in chronological order to determine the temporal relationship between the target device information corresponding to at least two candidate root causes.

[0146] Specifically, time information can be obtained from the supporting evidence of each candidate root cause. Supporting evidence refers to the target device information that has a supporting relationship with the candidate root cause. Each target device information is recorded with a timestamp when it is collected. The timestamp reflects the time of occurrence of the system event or the time of device status collection corresponding to the device information. The timestamps of the target device information corresponding to at least two candidate root causes are compared to determine the chronological order of the abnormal events corresponding to each candidate root cause on the timeline. Generally, in the fault propagation chain, the candidate root cause located at the beginning of the timeline is more likely to be the main cause, while the candidate root cause located at the end of the timeline is more likely to be the propagation result or accompanying phenomenon caused by the former.

[0147] In this embodiment, when a candidate root cause corresponds to multiple target device information, the position of the candidate root cause in the fault chain is determined based on the earliest time information among the multiple target device information; or, the time relationship can be determined based on the time distribution characteristics of the target device information corresponding to each candidate root cause. For example, if multiple target device information corresponding to a certain candidate root cause are concentrated in a short period of time after the fault occurs, while the target device information corresponding to another candidate root cause is distributed over a longer time range, then the time position of each candidate root cause is determined based on the above distribution characteristics.

[0148] It is also necessary to determine the causal propagation path between at least two candidate root causes. The causal propagation path is used to characterize the causal dependence and propagation direction between each candidate root cause.

[0149] The causal propagation relationships between candidate root causes can be pre-defined and stored in a pre-defined causal knowledge base. The causal knowledge base records the causal dependencies between each candidate root cause. For example, an audio driver error may cause the audio service to fail to start, which in turn leads to an audio service error; a camera driver error may cause the FrameServer service call to fail, which in turn leads to the FrameServer service error, etc.

[0150] Causal propagation paths can be determined based on a fault cause-effect graph. In this graph, candidate root cause nodes are connected by propagation edges, indicating that one candidate root cause may propagate to form another. The causal propagation path between at least two candidate root causes is determined based on their propagation relationship in the fault cause-effect graph. Alternatively, the causal propagation path can also be determined based on the temporal relationship of the target device information corresponding to each candidate root cause. For example, if the timestamp of the target device information corresponding to candidate root cause R1 is earlier than the timestamp of the target device information corresponding to candidate root cause R2, and a known causal propagation relationship exists between R1 and R2, then the device determines R1 as the cause. R2 is the result, and the propagation direction is R1→R2; or, when there is a propagation relationship between at least two candidate root causes, the causal propagation path can be determined according to the propagation direction; when there is no propagation relationship between at least two candidate root causes, the order of each candidate root cause is determined only based on the temporal relationship; in addition, the causal propagation path can also be determined according to the device category relationship of the target device information corresponding to each candidate root cause. For example, if the target device information corresponding to candidate root cause R1 comes from the device driver layer, and the target device information corresponding to R2 comes from the service layer, and the driver layer failure usually leads to the service layer failure, then the propagation direction can be determined as R1→R2.

[0151] After determining the temporal relationship and causal propagation path of at least two candidate root causes, the role type corresponding to each candidate root cause in the at least two candidate root causes is determined based on the temporal relationship and causal propagation path. The role type may include at least one of the following: main cause, propagation result, and accompanying phenomenon.

[0152] Specifically, if a candidate root cause is located at the beginning of the fault chain in time (i.e., its corresponding target device information has the earliest timestamp) and is located upstream in the causal propagation path (i.e., other candidate root causes are propagated from it), then the role type of this candidate root cause is determined to be the primary cause. If a candidate root cause is located at the end of the fault chain in time (i.e., its corresponding target device information has a later timestamp than the timestamp of the primary cause) and is located downstream in the causal propagation path (i.e., it is propagated from other candidate root causes), then the role type of this candidate root cause is determined to be the propagation result. If there is no causal propagation path between a candidate root cause and other candidate root causes, and the time of its corresponding target device information is close to the time of the primary cause but does not constitute a causal relationship, then the role type of this candidate root cause is determined to be an accompanying phenomenon.

[0153] Role types can be determined primarily based on causal propagation paths. When a clear causal propagation path exists, upstream candidate root causes are identified as the primary cause, and downstream candidate root causes are identified as propagation results. When the temporal relationship aligns with the causal propagation path, the determination of the role type has higher confidence. When they do not align, the causal propagation path can be used as the primary criterion, or a combination of both can be used for a comprehensive judgment. If no clear causal propagation path can be determined, user intervention should be prompted. When no clear causal propagation path exists, role types are determined based on temporal relationships. Candidate root causes located at the beginning of the fault chain in time are identified as the primary cause, and candidate root causes located at the end of the fault chain in time are identified as propagation results or accompanying phenomena.

[0154] Furthermore, the verifiability of each candidate root cause can help determine the role type. Candidate root causes with verifiable fixes are more likely to be the primary cause, while candidate root causes without independent verifiability are more likely to be propagation results. For example, an audio driver malfunction can be verified by updating the driver, while an audio service malfunction may simply be a propagation result of the driver malfunction.

[0155] When the role type of a candidate root cause is propagation result, the upstream root cause of the propagation result can be further determined, that is, the root cause that leads to the propagation result, and the role type of the upstream root cause can be determined as the main cause.

[0156] Step S68: Identify the candidate root cause with the role type as the main cause as the suspected root cause, execute the repair action matching the suspected root cause, obtain the execution result, determine the diagnosis strategy based on the execution result, perform fault diagnosis on the device, and output the root cause of the device's fault.

[0157] After determining the role type of each candidate root cause, the candidate root cause that is identified as the main cause in that role type is directly identified as a suspected root cause. Then, the root cause of the failure is determined by verifying the suspected root cause. If the verification indicates that the suspected root cause is a root cause of the failure, it can be determined that the role type of each candidate root cause that was previously identified is correct, or at least the suspected root cause that was identified as the main cause is correct. Then, the output is directly based on the role type of each candidate root cause that was determined in advance.

[0158] For example, in diagnosing audio silence faults, the role type of candidate root cause R1 (audio driver anomaly) is determined to be the main cause, and the role type of candidate root cause R2 (audio service anomaly) is determined to be the propagation result. R1 (audio driver anomaly) is identified as a suspected root cause and verified by performing repair actions that match the suspected root cause. The execution results are obtained, and a diagnostic strategy is determined based on the execution results so that the fault diagnosis of the device can be completed based on the diagnostic strategy.

[0159] Specifically, it can be as follows: in response to the execution result matching the expected state, the suspected root cause is identified as the root cause of the device failure, and the role type of the suspected root cause is determined as the main cause among the root causes of the failure; the suspected root cause is output as the main cause among the root causes of the failure, and the other candidate root causes other than the suspected root cause among at least two candidate root causes are output according to their respective role types.

[0160] When the execution result matches the expected state, a suspected root cause can be identified and confirmed as the root cause of the equipment failure. Simultaneously, based on the determined role type, the role type of the suspected root cause can be identified as the primary cause among the root causes of the failure. Specifically, when identifying a suspected root cause, the role type of each candidate root cause is determined based on temporal relationships and causal propagation paths. Candidate root causes with a primary role type are identified as suspected root causes. Therefore, when a suspected root cause is confirmed, its role type is confirmed as the primary cause among the root causes of the failure.

[0161] When confirming the root cause of a fault and its role type, a confirmation record can be generated. The confirmation record includes: the name of the root cause, the role type of the root cause, the target device information that supports the establishment of the root cause, the repair actions performed, and the matching status of the execution results with the expected state.

[0162] In addition, after identifying the suspected root cause as the root cause of the fault, the device's historical fault profile is updated. The historical fault profile includes: the type of fault in this case, the confirmed root cause of the fault and its role type, the repair actions performed in this case and the repair results, the key driver version and / or firmware version at the time of diagnosis, etc.

[0163] When outputting fault information, the suspected root cause is output as the main cause of the fault. At the same time, the other candidate root causes, excluding the suspected root cause, are output according to their respective role types.

[0164] The output format for the root cause of the fault and the corresponding role type for each root cause can be:

[0165] The output format for the main cause based on the role type is as follows: Main cause: name of the root cause of the failure, confidence level: confidence value, supporting evidence: list of evidence;

[0166] For roles where the output is a propagation result, the output format is: Propagation Result: Candidate Root Cause Name, Confidence: Confidence Value, Caused by Main Cause, Propagation Path: Propagation Path Description;

[0167] For the role type "accompanying phenomenon", the output format is: Accompanying phenomenon: candidate root cause name, confidence level: confidence value, which appears at the same time as the main cause but does not constitute the main causal path.

[0168] Furthermore, when outputting the root cause of the fault and the role type corresponding to each root cause, the fault propagation chain can also be output at the same time. The fault propagation chain starts from the main cause and displays each propagation result in sequence according to the propagation direction, forming a causal chain as shown below, such as: main cause → propagation result 1 → propagation result 2.

[0169] For example, in diagnosing audio silence faults, the candidate root cause set includes R1 (audio driver malfunction), R2 (audio service malfunction), and R3 (application audio session muted). Based on temporal relationships and causal propagation paths, it is determined that R1 is the primary cause, R2 is the propagation result, and R3 is an accompanying phenomenon. A repair action matching R1 is executed, such as updating the audio driver. If the result is a successful driver update, the driver error code changes from 10 to 0, and sound output is restored, matching the expected state, then R1 can be confirmed as the root cause of the fault. Further steps are then taken as follows... Figure 7 The output format shown is as follows. Figure 7 It includes multiple root causes of failure and the role type of each root cause.

[0170] In addition, when outputting the root cause of the failure and the role type of each root cause, the main cause and the candidate root causes corresponding to each role type can be grouped and displayed according to the role type to show the failure propagation path in a graphical way. For example, a failure propagation chain diagram can be generated, with arrows connecting the main cause and the propagation result to intuitively show the causal relationship between each candidate root cause.

[0171] In addition, when outputting the root cause of the fault and the role type of each root cause, subsequent suggestions can also be output. These suggestions may include: troubleshooting directions if the fault recurs, configuration items to be checked regularly, and updates to relevant drivers or software. Furthermore, the eliminated candidate root causes and the basis for their elimination can also be displayed simultaneously, so that users can understand the complete diagnostic process and diagnostic basis.

[0172] Furthermore, before outputting, it can be determined whether there are other unconfirmed candidate root causes. If there are other candidate root causes that have not yet been ruled out and whose confidence level is higher than a preset threshold, a prompt can be provided during output, suggesting that users pay attention to these candidate root causes or conduct further investigations.

[0173] Step S69: In response to the existence of a second role identification condition, output the root cause of the device failure.

[0174] The specific implementation of the root cause of the output device failure when a second role recognition condition exists is the same as the above embodiment, and will not be repeated here.

[0175] The fault diagnosis method disclosed in this embodiment determines the role type of each candidate root cause by using temporal relationships and causal propagation paths when multiple high-confidence candidate root causes with similar confidence levels exist. The candidate root cause whose role type is the main cause is identified as a suspected root cause, ensuring accurate differentiation between the main cause and the propagation result. This effectively avoids the problem of misjudging the propagation result or accompanying phenomena as the main cause in scenarios with multiple concurrent anomalies. In addition, by determining the causal propagation path between each candidate root cause and the role type of each candidate root cause, a foundation is laid for constructing a complete fault propagation chain.

[0176] This embodiment discloses a fault diagnosis method, the flowchart of which is as follows: Figure 8 As shown, it includes:

[0177] Step S81: Input the equipment fault information into the model to obtain a candidate root cause set generated by the model. The candidate root cause set includes at least two candidate root causes.

[0178] Step S82: Determine a candidate tool set based on each candidate root cause in the candidate root cause set, wherein the candidate tool set includes at least one candidate tool;

[0179] Step S83: Obtain the expected diagnostic benefit of each candidate tool in the candidate tool set. The expected diagnostic benefit is used to characterize the ability of the candidate tool corresponding to the expected diagnostic benefit to distinguish each candidate root cause in the candidate root cause set.

[0180] After determining the candidate root cause set and the candidate tool set based on each candidate root cause in the candidate root cause set, it is necessary to further select the target tool from the candidate tool set for execution. This is to avoid executing every candidate tool in the candidate tool set, which would result in a large number of invalid tools being executed, thus reducing the efficiency of fault diagnosis.

[0181] When selecting a target tool from the candidate tool set, the tool is not called sequentially according to a preset fixed script order, nor is it randomly selected. Instead, the expected diagnostic benefits of each candidate tool are calculated, and the target tool is selected based on the expected diagnostic benefits.

[0182] The expected diagnostic benefit of each candidate tool in the candidate tool set is obtained. The expected diagnostic benefit characterizes the ability of the candidate tool corresponding to the expected diagnostic benefit to distinguish each candidate root cause in the candidate root cause set. The expected diagnostic benefit is a quantitative indicator used to evaluate the comprehensive value of each candidate tool in the current diagnostic scenario. The higher the expected diagnostic benefit of a candidate tool, the more effectively the target device information collected by the tool can distinguish each candidate root cause in the candidate root cause set, and thus the greater its contribution to the diagnostic decision.

[0183] The expected diagnostic benefits can be determined according to the preset evaluation rules. The evaluation rules are used to quantify the value of each candidate tool in distinguishing candidate root causes. The expected diagnostic benefits of each candidate tool can be calculated and stored in advance, or they can be dynamically determined during the diagnostic process.

[0184] The expected diagnostic benefit is at least related to the candidate tool's ability to distinguish between each candidate root cause in the candidate root cause set; the higher the distinguishing ability of the candidate tool, the higher its expected diagnostic benefit. Furthermore, the determination of expected diagnostic benefit can also consider multiple factors, such as: the risk level during candidate tool execution, the time cost of the candidate tool collecting equipment information, the reliability of the equipment information collected by the candidate tool, and the number of candidate root causes that the equipment information collected by the candidate tool can distinguish.

[0185] Step S84: Select the target tool from the candidate tool set based on the expected diagnostic benefits of each candidate tool in the candidate tool set;

[0186] This can be achieved by: identifying the candidate tool with the highest expected diagnostic benefit as the target tool; or by identifying the candidate tool with an expected diagnostic benefit higher than the target benefit threshold as the target tool; or, when selecting the target tool based on the expected diagnostic benefit, also considering the complementarity between the candidate tools, such as: if the target device information collected by two or more candidate tools can verify the same candidate root cause from different perspectives, then multiple candidate tools can be selected as the target tool; or, it can be achieved by: conducting multiple rounds of target tool selection, selecting only the candidate tool with the highest expected diagnostic benefit as the target tool in each round, collecting target device information using the target tool after each round of target tool selection, updating the confidence level of the candidate root cause based on the target device information, and then recalculating the expected diagnostic benefit of each candidate tool before proceeding to the next round of target tool selection.

[0187] There can be one or more target tools, and the number of target tools is only related to the selection rules of the target tools.

[0188] Step S85: Execute the target tool to collect target device information. The target device information is used to distinguish candidate root causes in the candidate root cause set.

[0189] Step S86: Perform fault diagnosis on the equipment based on the target equipment information.

[0190] The specific implementation of the above steps is the same as that in the above embodiments, and will not be repeated here.

[0191] The fault diagnosis method disclosed in this embodiment calculates the expected diagnostic benefit of each candidate tool and selects the target tool based on the expected diagnostic benefit. This proactively selects the tool with the most diagnostic value for execution, rather than collecting all device information in a pre-set fixed script order. This significantly reduces the invocation of invalid tools, shortens the diagnosis time, and reduces system resource consumption. By characterizing the candidate tool's ability to distinguish each candidate root cause in the candidate root cause set through the expected diagnostic benefit, the method enables the selection of tools that can effectively distinguish different candidate root causes. This allows the most discriminative target device information to be obtained with only a few tools executed, thereby focusing confidence on the true root cause of the fault in a shorter time and improving diagnostic efficiency and accuracy.

[0192] Furthermore, in the fault diagnosis method disclosed in this embodiment, obtaining the expected diagnostic benefit of each candidate tool in the candidate tool set can be specifically as follows:

[0193] Determine the discriminative power of each candidate tool for each candidate root cause in the candidate root cause set; determine the uncertainty of the candidate root cause set; determine the reliability of the equipment information corresponding to each candidate tool; determine the correlation between each candidate tool and the fault information; and determine the expected diagnostic benefits based at least on discriminative power, uncertainty, reliability, and correlation.

[0194] The discriminative power of each candidate tool for each candidate root cause in the candidate root cause set is used to characterize the extent to which the device information collected by the candidate tool can distinguish different candidate root causes in the candidate root cause set. The higher the discriminative power of the candidate tool, the more effectively the device information collected by the tool can distinguish each candidate root cause. That is, the information strongly supports one candidate root cause while strongly opposing another candidate root cause, or the information is only related to a specific candidate root cause and is not related to other candidate root causes.

[0195] The discriminative power can be determined based on the correspondence between the device information collected by the candidate tools and each candidate root cause. The association between the candidate root cause and the device information is preset. Then, based on the association between the candidate root cause and the device information, the degree of support or opposition of the device information collected by each candidate tool to each candidate root cause is determined. If there is a strong association between the device information collected by a candidate tool and a candidate root cause, that is, the information has a strong support or strong opposition effect on the candidate root cause, while there is no association or a weak association with other candidate root causes, then the discriminative power of the candidate tool is high. Alternatively, the discriminative power value of each candidate tool to each candidate root cause among multiple candidate root causes can be preset. Then, the discriminative power of each candidate tool to each candidate root cause can be determined by directly querying the preset information.

[0196] Alternatively, the discriminative power can be determined based on the number of candidate root causes supported by the device information collected by the candidate tool. The fewer candidate root causes supported by a given device information, the higher the discriminative power of the tool; conversely, the more candidate root causes supported by a given device information, the lower the discriminative power of the tool. In one embodiment, the discriminative power is negatively correlated with the number of candidate root causes supported by the device information. Alternatively, the discriminative power can be determined based on the number of candidate root causes excluded by the device information collected by the candidate tool. The more candidate root causes excluded by a given device information, the higher the discriminative power of the tool.

[0197] The uncertainty of the candidate root cause set is used to characterize the degree of dispersion of the confidence distribution of each candidate root cause in the current candidate root cause set. When the confidence distribution of each candidate root cause is relatively dispersed, that is, there are obvious high-confidence candidate root causes, the uncertainty is low; when the confidence distribution of each candidate root cause is relatively concentrated, that is, the confidence of multiple candidate root causes is close, the uncertainty is high.

[0198] Specifically, uncertainty can be determined based on the variance or entropy of the confidence scores of each candidate root cause in the candidate root cause set. Calculate the variance of the confidence scores of each candidate root cause; a larger variance indicates a more dispersed confidence distribution and lower uncertainty, while a smaller variance indicates a more concentrated confidence distribution and higher uncertainty. Alternatively, uncertainty can be determined based on the difference between the maximum and second-largest confidence scores of each candidate root cause in the candidate root cause set. A larger difference indicates higher discrimination among candidate root causes and lower uncertainty, while a smaller difference indicates lower discrimination among candidate root causes and higher uncertainty.

[0199] The reliability of the device information corresponding to each candidate tool is used to characterize the credibility of the device information collected by the candidate tool. Device information from high-reliability data sources has higher credibility than device information from low-reliability data sources and should be given higher weight in diagnostic decision-making.

[0200] Specifically, the reliability level can be determined based on the data source type of the target device information. For example, device information from the hardware layer has higher reliability, device information from the system core layer has medium reliability, and device information from the application layer has relatively lower reliability. Alternatively, a reliability weight can be pre-set for each data source type so that the expected diagnostic benefits can be calculated based on the reliability weight corresponding to each data source type. Alternatively, reliability can be determined based on the method of collecting the target device information, such as device information collected through standardized system interfaces having higher reliability than device information collected through non-standard methods. Alternatively, reliability can be determined based on the consistency of the target device information, such as a high reliability of the information set if multiple independent sources of device information point to the same conclusion, or a lower reliability for each source if device information from different sources contradicts each other.

[0201] The correlation between each candidate tool and the fault information is used to characterize the degree of association between the equipment information collected by the candidate tool and the fault information input by the user. Candidate tools that are more relevant to the fault information are more likely to collect equipment information that is directly related to the current fault.

[0202] The relevance can be determined based on the consistency between the type of device information collected by the candidate tool and the type of fault information. For example, for audio-related fault information such as "computer has no sound," tools related to audio have a higher relevance, while tools related to cameras, networks, and power management have a lower relevance. Alternatively, the relevance can be determined based on the degree of matching between the keywords contained in the device information collected by the candidate tool and the keywords contained in the fault information. For example, when the fault information contains keywords such as "sound," "audio," and "speaker," tools related to these keywords have a higher relevance. Or, the relevance can be determined based on the frequency of association between the device information collected by the candidate tool and similar faults in historical diagnoses. In historical diagnoses, the higher the frequency of association between the device information collected by a tool and the current similar faults, the higher the relevance between the tool and the fault information.

[0203] After determining the discriminative power, uncertainty, reliability, and relevance, the expected diagnostic benefits of each candidate tool should be determined based on at least these four factors.

[0204] Specifically, the expected diagnostic benefit can be determined by weighting and summing the factors of discrimination power, uncertainty, reliability, and relevance. The weight values ​​of each factor can be pre-set based on their importance in tool selection. Alternatively, the expected diagnostic benefit can be positively correlated with discrimination power (the higher the discrimination power, the higher the benefit), with uncertainty, with reliability, and with relevance. In this case, the expected diagnostic benefit can be determined by multiplying the factors of discrimination power, uncertainty, reliability, and relevance together.

[0205] Furthermore, when determining the expected diagnostic benefits, it is necessary to consider not only the four factors mentioned above, but also the time cost, resource cost, execution risk, potential disturbances to the system state, and privacy sensitivity penalties of the candidate tools. The higher the values ​​of these factors, the lower the expected diagnostic benefits will be.

[0206] The fault diagnosis method disclosed in this embodiment comprehensively determines the expected diagnostic benefits of each candidate tool through four dimensions: discriminative power, uncertainty, reliability, and relevance. This makes tool selection no longer dependent on experience or a fixed order, but based on scientific calculations using multi-factor quantification. Discriminative power ensures that the tool can effectively distinguish candidate root causes; uncertainty ensures that tools with high discriminative power are selected first when the confidence level is ambiguous; reliability ensures that trusted data sources are selected first; and relevance ensures that the collected information matches the user's fault type. The four factors work together to form a complete quantitative decision-making model, ensuring the scientific nature and effectiveness of tool selection, thereby improving the accuracy of fault diagnosis.

[0207] This embodiment discloses a fault diagnosis system, the structural diagram of which is shown below. Figure 9 As shown, it includes:

[0208] The system includes a 91-unit acquisition unit, a 92-unit determination unit, a 93-unit selection unit, a 94-unit execution unit, and a 95-unit diagnosis unit.

[0209] The obtaining unit 91 is used to input the fault information of the equipment into the model to obtain a set of candidate root causes generated by the model, and the set of candidate root causes includes at least two candidate root causes.

[0210] The determining unit 92 is used to determine a set of candidate tools based on each candidate root cause in the set of candidate root causes, wherein the set of candidate tools includes at least one candidate tool;

[0211] Selection unit 93 is used to select a target tool from a set of candidate tools based at least on fault information and a set of candidate root causes;

[0212] Execution unit 94 is used to execute the target tool, which collects target device information. The target device information is used to distinguish candidate root causes in the candidate root cause set.

[0213] The diagnostic unit 95 is used to diagnose equipment faults based on target equipment information.

[0214] The fault diagnosis system disclosed in this embodiment is implemented based on the fault diagnosis method disclosed in the above embodiments, and will not be described again here.

[0215] The fault diagnosis system disclosed in this embodiment inputs fault information into a model to obtain a set of candidate root causes generated by the model. Each candidate root cause set includes at least two candidate root causes. This embodiment generates multiple candidate root causes through the model, comprehensively covering various hypothetical causes that may lead to the current fault, avoiding omission of the true root cause. A set of candidate tools is determined based on each candidate root cause in the candidate root cause set, ensuring that the selection of diagnostic tools precisely corresponds to the current candidate root cause set. This guarantees that only tools related to the current candidate root cause are selected, avoiding the collection of equipment information unrelated to the current fault and reducing system resource consumption. At least based on the fault information and the candidate root cause set, a target tool is selected from the candidate tool set. By filtering candidate tools rather than executing all tools, target equipment information for distinguishing each candidate root cause can be obtained at a low cost in the early stages of diagnosis, accelerating the diagnosis process and shortening user waiting time. By executing the target tool to collect target equipment information, and using the target equipment information to objectively judge the degree of consistency of each candidate root cause, the root cause inference has clear information basis, improving the objectivity and accuracy of the diagnosis.

[0216] This embodiment discloses an electronic device, the structural schematic diagram of which is shown below. Figure 10 As shown, it includes:

[0217] Memory 101 and processor 102.

[0218] The memory 101 is used to store computer programs;

[0219] Processor 102 is used to execute computer programs to enable the electronic device to perform the following steps:

[0220] The equipment's fault information is input into the model to obtain a set of candidate root causes generated by the model. The set of candidate root causes includes at least two candidate root causes.

[0221] A set of candidate tools is determined based on each candidate root cause in the candidate root cause set, and the set of candidate tools includes at least one candidate tool;

[0222] At least based on the fault information and the set of candidate root causes, the target tool is selected from the set of candidate tools;

[0223] The target tool is executed to collect target device information, which is used to distinguish candidate root causes in the candidate root cause set.

[0224] Fault diagnosis is performed on the equipment based on the target equipment information.

[0225] The electronic device disclosed in this embodiment is implemented based on the fault diagnosis method disclosed in the above embodiments, and will not be described again here.

[0226] The electronic device disclosed in this embodiment inputs fault information into a model to obtain a candidate root cause set generated by the model. The candidate root cause set includes at least two candidate root causes. This embodiment generates multiple candidate root causes through the model, which can comprehensively cover various hypothetical causes that may lead to the current fault and avoid missing the real root cause of the fault. Based on each candidate root cause in the candidate root cause set, a candidate tool set is determined, so that the selection of diagnostic tools corresponds precisely to the current candidate root cause set. This ensures that only tools related to the current candidate root cause are selected, avoiding the collection of device information unrelated to the current fault and reducing system resource consumption. At least based on the fault information and the candidate root cause set, a target tool is selected from the candidate tool set. By screening candidate tools instead of executing all tools, it is ensured that target device information for distinguishing each candidate root cause can be obtained at a low cost in the early stage of diagnosis, which speeds up the diagnosis process and shortens the user's waiting time. By executing the target tool to collect target device information, the target device information is used to objectively judge the degree of consistency of each candidate root cause, so that the root cause inference has clear information basis and improves the objectivity and accuracy of the diagnosis.

[0227] This application embodiment also provides a readable storage medium on which a computer program is stored. The computer program is loaded and executed by a processor to implement the steps of the above-described fault diagnosis method. The specific implementation process can be referred to the description of the corresponding part of the above embodiment, and will not be repeated in this embodiment.

[0228] This application also proposes a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above-described fault diagnosis method. Specific implementation processes can be referred to the descriptions of the corresponding embodiments above, and will not be repeated here.

[0229] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0230] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0231] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0232] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A fault diagnosis method, comprising: The fault information of the equipment is input into the model to obtain a set of candidate root causes generated by the model, wherein the set of candidate root causes includes at least two candidate root causes; A set of candidate tools is determined based on each candidate root cause in the set of candidate root causes, wherein the set of candidate tools includes at least one candidate tool; Based at least on the fault information and the candidate root cause set, a target tool is selected from the candidate tool set; The target tool is executed to collect target device information, which is used to distinguish candidate root causes in the candidate root cause set. The device is diagnosed for faults based on the target device information.

2. The method according to claim 1, wherein the fault diagnosis of the device based on the target device information includes: The confidence level of each candidate root cause in the candidate root cause set is determined based at least on the target device information, and the candidate root causes with a confidence level higher than that of other candidate root causes are identified as suspected root causes. Execute a repair action that matches the suspected root cause and obtain the execution result. The repair action is used to restore the fault corresponding to the fault information of the device. Based on the execution results, a diagnostic strategy is determined so that fault diagnosis of the device can be completed based on the diagnostic strategy.

3. The method according to claim 2, wherein determining the diagnostic strategy based on the execution result includes: Obtain the expected state corresponding to the suspected root cause, wherein the expected state is: if the suspected root cause is established, the state that the device is expected to reach when the repair action is performed; In response to the execution result matching the expected state, the suspected root cause is determined as the root cause of the device failure; In response to a mismatch between the execution result and the expected state, the confidence level of the candidate root causes in the candidate root cause set is updated based on the execution result, and the suspected root cause is re-determined based on the candidate root cause set with the updated confidence level.

4. The method according to claim 2, wherein determining the confidence level of each candidate root cause in the candidate root cause set based at least on the target device information comprises: A first factor is determined, which is used to characterize the degree of matching between the fault information of the device and each candidate root cause; A second factor is determined, which is used to characterize the time correlation between the occurrence time of the target device information and the time period corresponding to the fault information; A third factor is determined, which is used to characterize the degree of directional correlation between the error code in the target device information and each candidate root cause; A fourth factor is determined, which is used to characterize the degree of consistency among information supporting the same candidate root cause in the target device information; The confidence level of each candidate root cause is determined based on the first factor, the second factor, the third factor, and the fourth factor.

5. The method according to claim 3, wherein determining the diagnostic strategy based on the execution result further comprises: In response to the existence of a first role identification condition, the device outputs multiple root causes of failure and the role type corresponding to each root cause of failure, wherein the role type is used to characterize the role type of the candidate root cause in the failure propagation chain. In response to the existence of a second role identification condition, the root cause of the device failure is output; Wherein, the first role recognition condition indicates that there are at least two candidate root causes in the candidate root cause set, the confidence of the at least two candidate root causes is greater than the confidence of other candidate root causes in the candidate root cause set other than the two candidate root causes, and the difference between the confidence of the at least two candidate root causes is less than a first threshold. The second role recognition condition indicates that there is a first candidate root cause in the candidate root cause set, and the difference between the confidence level of the first candidate root cause and the confidence levels of other candidate root causes in the candidate root cause set other than the first candidate root cause is greater than a second threshold.

6. The method according to claim 5, in response to the presence of the first role identification condition, determining the suspected root cause, comprising: In response to the existence of a first role identification condition, based on the temporal relationship and causal propagation path of the target device information corresponding to the at least two candidate root causes, the role type corresponding to each of the at least two candidate root causes is determined, and the role type includes at least one of the following: main cause, propagation result and accompanying phenomenon; The candidate root cause with the character type as the primary cause is identified as the suspected root cause.

7. The method according to claim 6, wherein outputting multiple root causes of the device's faults and the role type corresponding to each root cause of the fault includes: In response to the execution result matching the expected state, the suspected root cause is determined as the root cause of the device failure, and the role type of the suspected root cause is determined as the primary cause among the root causes of the failure. The suspected root cause is output as the main cause among the root causes of the failure, and the other candidate root causes among the at least two candidate root causes, excluding the suspected root cause, are output according to their respective role types.

8. The method according to claim 1, wherein selecting a target tool from the candidate tool set based at least on the fault information and the candidate root cause set comprises: Obtain the expected diagnostic benefit of each candidate tool in the candidate tool set, wherein the expected diagnostic benefit is used to characterize the ability of the candidate tool corresponding to the expected diagnostic benefit to distinguish each candidate root cause in the candidate root cause set; The target tool is selected from the candidate tool set based on the expected diagnostic benefits of each candidate tool in the candidate tool set.

9. The method according to claim 8, wherein obtaining the expected diagnostic benefit of each candidate tool in the candidate tool set comprises: Determine the discriminative power of each candidate tool for each candidate root cause in the candidate root cause set; Determine the uncertainty of the candidate root cause set; Determine the reliability of the equipment information corresponding to each candidate tool; Determine the correlation between each candidate tool and the fault information; The expected diagnostic benefit is determined based at least on the discriminative power, uncertainty, reliability, and relevance.

10. An electronic device, comprising: Memory, used to store computer programs; A processor is configured to execute the computer program to enable the electronic device to perform the following steps: The fault information of the equipment is input into the model to obtain a set of candidate root causes generated by the model, wherein the set of candidate root causes includes at least two candidate root causes; A set of candidate tools is determined based on each candidate root cause in the set of candidate root causes, wherein the set of candidate tools includes at least one candidate tool; Based at least on the fault information and the candidate root cause set, a target tool is selected from the candidate tool set; The target tool is executed to collect target device information, which is used to distinguish candidate root causes in the candidate root cause set. The device is diagnosed for faults based on the target device information.

Images