Method and system for detecting hardware failure of a smart terminal

Abstract

The application relates to the technical field of intelligent terminal fault prediction, and discloses a hardware fault detection method and system of an intelligent terminal. The method comprises the following steps: capturing multi-dimensional hardware state signals and system event sequences in the running of the intelligent terminal in real time, performing time sequence alignment and feature fusion processing to form a hardware running state feature map. The feature map is analyzed by using a preset fault knowledge graph, the spatial distribution and severity level of potential fault components are identified, and are mapped to a fault response strategy network to generate an initial fault handling instruction set. Based on a historical evolution mode, the component deterioration track and event evolution trend are calculated, the initial instruction set is dynamically modified and the instruction sequence is rearranged, an optimized fault handling instruction set is formed, and the intelligent terminal is finally driven to execute. The application overcomes the shortcomings of inaccurate fault positioning and rigid handling strategy of the existing static threshold detection method, and realizes accurate prediction and adaptive optimized handling of hardware faults.

Description

Technical Field

[0001] This invention relates to the field of intelligent terminal fault prediction technology, specifically to a method and system for detecting hardware faults in intelligent terminals. Background Technology

[0002] Current hardware fault detection in smart terminals generally relies on preset static threshold alarm mechanisms. This method continuously monitors specific hardware parameters through sensors and triggers an alarm when the measured value exceeds a single fixed threshold. This logic based on isolated indicators forms the basis of most system health management. Its technical paradigm is essentially reactive, intervening only after the fault symptoms have reached a significant level, lacking the ability to gain insight into the correlation between faults between components and early latent faults.

[0003] Existing technical solutions have shortcomings. Static threshold mechanisms cannot effectively interpret the dynamic correlation between the state signals of different hardware components, nor can they perform collaborative analysis of changes in hardware state with the sequence of events occurring at the system level. When multiple indicators show slight anomalies, the system struggles to determine whether the problem stems from multiple independent issues or a common underlying cause, leading to ambiguous fault localization. Furthermore, handling strategies based on instantaneous states are often fixed and rigid, unable to adapt to the dynamic evolution of faults, potentially resulting in inappropriate or suboptimal maintenance actions, or even exacerbating system instability due to improper handling sequences.

[0004] The aforementioned shortcomings make it difficult for existing methods to achieve early and accurate fault prediction and adaptive optimization. Given the increasing complexity of intelligent terminal hardware systems, a method capable of understanding fault propagation relationships and dynamically adjusting handling strategies based on fault evolution trends is urgently needed. This requires technical solutions that not only identify the spatial distribution and severity of current fault points but also possess the ability to predict future fault development to guide the formulation of forward-looking maintenance instructions. Summary of the Invention

[0005] The purpose of this invention is to provide a hardware fault detection method and system for smart terminals to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides a hardware fault detection method for a smart terminal, the method comprising: Real-time capture of multi-dimensional hardware status signals and system event sequences generated by smart terminals during operation; The multi-dimensional hardware status signals and system event sequences are subjected to timing alignment and feature fusion processing to form a hardware operating status feature map. The hardware operating state feature map is analyzed using a preset fault knowledge graph to identify the spatial distribution and severity level of potential faulty components. The spatial distribution and severity level of the potential faulty components are mapped to a pre-built fault response strategy network, and an initial fault handling instruction set is output. Based on the historical evolution pattern of the hardware operating state feature map, the degradation trajectory of the potential faulty components and the evolution trend of the system event sequence are inferred. Based on the degradation trajectory and evolution trend, the initial fault handling instruction set is dynamically modified and the instruction sequence is rearranged to form an optimized fault handling instruction set; The intelligent terminal is driven to execute the specific operations contained in the optimized fault handling instruction set.

[0007] Preferably, the step of performing time-series alignment and feature fusion processing on the multi-dimensional hardware state signals and system event sequences to form a hardware operating state feature map includes: Assign timestamps to the multi-dimensional hardware status signals and mark the occurrence times of the system event sequences; Based on the system clock, the system performs alignment operations on the multi-dimensional hardware status signals with timestamps and the system event sequences with occurrence time markers to generate a synchronized data stream. Signal strength features, event frequency features, and correlation features are extracted from the synchronized data stream; The signal strength features, event frequency features, and correlation features are combined into a multi-dimensional feature vector; The multidimensional feature vectors are arranged in chronological order to construct the hardware operating state feature map.

[0008] Preferably, the step of analyzing the hardware operating state feature map using a preset fault knowledge graph to identify the spatial distribution and severity level of potential faulty components includes: Access a fault knowledge graph that stores the correlation between component failure modes and symptoms; Match the feature patterns in the hardware operating status feature graph with the symptom nodes in the fault knowledge graph; When the matching degree exceeds the set threshold, the fault mode node associated with the symptom node is activated; Based on the activated fault mode nodes, identify the hardware components in the smart terminal that may be faulty. The matching confidence of the feature patterns and the activated symptom nodes is calculated, and the severity level of the potential faulty components is determined by combining the severity defined by the fault mode nodes. Record the location information of the potentially faulty components in the logical structure of the smart terminal to form the spatial distribution.

[0009] Preferably, the method further includes the step of constructing and updating the fault knowledge graph: Collect historical data on hardware failures in smart terminals. This data includes the identification of the faulty component, the status signals at the time of the failure, system event records, and the final failure confirmation information. Mining association rules between fault symptoms and faulty components from the historical smart terminal hardware failure case data; An initial fault knowledge graph is constructed using faulty components as entities, fault symptoms as attributes, and association rules as relationships. As new smart terminal hardware failure case data is generated, the association rules are updated using an incremental learning approach, and the entities, attributes, and relationships in the initial failure knowledge graph are updated accordingly.

[0010] Preferably, the step of mapping the spatial distribution and severity level of the potential faulty components to a pre-built fault response strategy network and outputting an initial fault handling instruction set includes: The fault response strategy network contains multiple strategy nodes, each strategy node corresponding to a set of fault handling instructions and a description of the fault scenarios to which they are applicable; Calculate the spatial distribution and severity level of the potential faulty components and their matching scores with the fault scenario descriptions applicable to each policy node; Select the strategy node with the highest matching score; The fault handling instructions corresponding to the selected policy node are invoked to form the initial fault handling instruction set.

[0011] Preferably, the fault response strategy network is constructed in the following manner: Define various typical fault scenarios that may occur in smart terminals; For each typical fault scenario, formulate one or more sets of candidate fault handling instruction sequences; Test the processing efficiency of each set of candidate fault handling instruction sequences for corresponding typical fault scenarios in a simulated environment or a controlled real environment; Based on the performance evaluation results, the optimal fault handling instruction sequence is selected for each type of typical fault scenario and encapsulated as a strategy node. All policy nodes and their correspondence with fault scenario descriptions are organized into a network structure to form the fault response policy network.

[0012] Preferably, the step of estimating the degradation trajectory of the potential faulty component and the evolution trend of the system event sequence based on the historical evolution pattern of the hardware operating state feature map includes: Obtain a sequence of historical hardware operating status feature maps within a predetermined time window; Perform trend analysis on the historical hardware operating status feature map sequence to extract the slope and fluctuation pattern of the status indicators of specific components; Based on the change slope and fluctuation pattern, the expected state value sequence of the potential faulty component in the future time period is extrapolated and used as the degradation trajectory. The patterns of system events embedded in the historical hardware operation state feature map sequence are analyzed to predict the distribution of system event types and their probabilities in future time periods, which serves as the evolution trend.

[0013] Preferably, the step of dynamically correcting and rearranging the initial fault handling instruction set based on the degradation trajectory and evolution trend to form an optimized fault handling instruction set includes: Assess whether the degradation trajectory indicates that the rate of failure progression exceeds the preset response capability of the initial failure handling instruction set; Assess whether the aforementioned evolutionary trend introduces new risk factors or resource constraints; If the speed of fault development exceeds the preset response capacity or new risk factors exist, the execution intensity of the instructions in the initial fault handling instruction set will be adjusted or the triggering time of the instructions will be advanced. Based on resource constraints, the execution order of instructions in the initial fault handling instruction set is rearranged to optimize resource utilization efficiency; The set of instructions whose execution intensity, triggering timing, and execution order have been adjusted is used as the optimized fault handling instruction set.

[0014] Preferably, the specific operations included in the optimized fault handling instruction set executed by the driving intelligent terminal include: The optimized fault handling instruction set is parsed and decomposed into basic operation commands that can be recognized by the smart terminal operating system or hardware driver. The basic operation commands are sent sequentially to the corresponding execution units of the smart terminal; Monitor the execution result status of the basic operation commands; Record the execution process log and return the execution result status to the monitoring node of the fault detection process. Preferably, the present invention further includes a hardware fault detection system for a smart terminal, used to implement the hardware fault detection method for a smart terminal as described above, the system comprising: The data acquisition unit is used to capture in real time the multi-dimensional hardware status signals and system event sequences generated by the smart terminal during operation; The feature processing unit is used to perform timing alignment and feature fusion processing on the multi-dimensional hardware status signals and system event sequences to form a hardware operating status feature map. The fault analysis unit is used to analyze the hardware operating state feature map using a preset fault knowledge graph to identify the spatial distribution and severity level of potential faulty components. The strategy mapping unit is used to map the spatial distribution and severity level of the potential faulty components to a pre-built fault response strategy network and output an initial fault handling instruction set. The trend prediction unit is used to infer the degradation trajectory of the potential faulty component and the evolution trend of the system event sequence based on the historical evolution pattern of the hardware operating state feature map. The instruction optimization unit is used to dynamically modify and rearrange the instruction sequence of the initial fault handling instruction set according to the degradation trajectory and evolution trend, so as to form an optimized fault handling instruction set. The instruction execution unit is used to drive the smart terminal to execute the specific operations contained in the optimized fault handling instruction set.

[0015] Compared with the prior art, the beneficial effects of the present invention are: By employing a fault knowledge graph to analyze the fused hardware operating status feature map, a leap from discrete symptom alarms to systemic fault diagnosis is achieved. Traditional methods can only output isolated over-limit alarms, while this method can identify the specific location of the root cause component and its impact range, forming a spatial distribution map including severity levels. This transforms fault localization from single-point judgment to deep semantic analysis of the overall hardware system's associated states, improving the accuracy and comprehensiveness of diagnosis. System maintenance personnel or automated programs can clearly understand the root cause of the fault and its potential impact, rather than simply receiving a bunch of unrelated alarm messages.

[0016] By inferring degradation trajectories and evolution trends based on historical evolution patterns of hardware operating state feature maps, and dynamically revising and rearranging the initial fault handling instruction set accordingly, the fault handling system gains predictability and adaptability. Conventional static handling scripts cannot cope with the uncertainty of fault development. This method analyzes the trends of state changes, predicts the path of component performance degradation and the evolution direction of system events, and thus optimizes and adjusts the preset handling instructions in real time. The sequence and content of handling actions are no longer fixed but dynamically generated based on the prediction results, ensuring a precise match between the handling strategy and the actual stage of fault development, avoiding under- or over-handling, and improving the system's robustness and recovery efficiency. Attached Figure Description

[0017] Figure 1 This is a schematic diagram illustrating the working principle of the hardware fault detection method for smart terminals described in this invention. Figure 2 A flowchart for generating a hardware operating state characteristic diagram; Figure 3 A bar chart showing the matching degree distribution of the knowledge graph for faults in intelligent terminal hardware components. Figure 4 A flowchart for policy mapping and initial instruction set generation; Figure 5 This is a comparison chart of the initial and optimized results of the fault handling command execution intensity. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Please see Figure 1 This invention provides a hardware fault detection method for smart terminals. The method includes: real-time capture of multi-dimensional hardware status signals and system event sequences generated by the smart terminal during operation. These signals and sequences are processed through time alignment and feature fusion to form a hardware operating status feature map, which serves as the basis for subsequent analysis. The hardware operating status feature map is analyzed using a pre-defined fault knowledge graph to identify the spatial distribution and severity level of potential faulty components. This step is achieved by matching feature patterns with symptom nodes in the knowledge graph. The identification results are mapped to a pre-constructed fault response strategy network to output an initial fault handling instruction set, which is generated for a specific fault scenario. Based on the historical evolution pattern of the hardware operating status feature map, the degradation trajectory of potential faulty components and the evolution trend of system event sequences are calculated, which involves trend analysis and extrapolation of historical data. Based on the degradation trajectory and evolution trend, the initial fault handling instruction set is dynamically corrected and the instruction sequence is rearranged to form an optimized fault handling instruction set, ensuring that the instruction set adapts to the dynamic changes in fault development. The smart terminal is driven to execute the specific operations contained in the optimized fault handling instruction set to complete the entire process of fault detection and handling.

[0020] Example 1: See Figure 2 In practical implementation, the operation of assigning timestamps to multi-dimensional hardware status signals relies on the underlying timing service of the smart terminal operating system. The timestamp accuracy reaches the millisecond level to precisely mark the acquisition time of each hardware status signal. The process of marking the occurrence time of system event sequences is performed synchronously with the generation of system event sequences. By hooking the system kernel's event logger, the occurrence time of each system event is recorded immediately when it is triggered. The alignment operation based on the system clock uses a globally unified clock source as a time reference to perform time normalization processing on the timestamped multi-dimensional hardware status signals and the system event sequences marked with occurrence times, generating a synchronized data stream. The generation of the synchronized data stream solves the time asynchrony problem caused by different data sources due to different acquisition frequencies and triggering mechanisms.

[0021] In some embodiments, signal strength features, event frequency features, and correlation features are extracted from the synchronized data stream. Signal strength feature extraction quantifies analog or digital quantities in multi-dimensional hardware status signals, such as the fluctuation range of the CPU core voltage or the instantaneous reading of the memory bus load. Event frequency features are statistically analyzed based on the number of times a system event sequence occurs within a specific time window, such as the number of page fault exceptions thrown per unit time. Correlation feature mining focuses on analyzing the temporal correlation between sudden changes in hardware status signals and the occurrence of specific system events, such as whether a sudden rise in GPU temperature is immediately followed by a system event of display driver malfunction. Signal strength features, event frequency features, and correlation features are combined into a multi-dimensional feature vector. The construction process of the multi-dimensional feature vector involves feature scaling and normalization to eliminate the influence of numerical differences caused by different units. The multi-dimensional feature vector is arranged in chronological order to construct a hardware operating state feature map. The hardware operating state feature map is essentially a two-dimensional matrix data structure, where each row of the matrix corresponds to a uniform sampling time point, and each column corresponds to a feature dimension, thus comprehensively depicting the overall operating state of the smart terminal hardware over a period of time.

[0022] In practice, the allocation of timestamps for multi-dimensional hardware status signals is accomplished by registering callback functions in the hardware monitoring driver. When a sensor acquires a new hardware status signal, the driver layer generates a data packet containing a high-precision timestamp, the value of which is directly taken from the kernel's system clock counter. The process of marking the occurrence time of system event sequences is integrated into the system event tracing framework, which assigns a monotonically increasing timestamp sequence to each recorded system event. The alignment operation based on the system clock is performed in the user-space service process. The service process receives timestamped data from the driver layer and the system event tracing framework through a circular buffer, and then resamples the non-uniformly sampled data using a sliding time window-based interpolation algorithm, so that the multi-dimensional hardware status signals and the system event sequences have the same sampling points on a unified time axis, ultimately outputting a synchronized data stream.

[0023] It is understandable that the process of extracting signal strength features from synchronized data streams involves applying different feature extractors to different types of hardware status signals. For continuous analog signals, such as temperature sensor readings, the signal strength feature extractor calculates the mean, variance, and peak value within a sliding window. For discrete digital signals, such as the status register value of a power management unit, the signal strength feature extractor performs bit pattern parsing and status encoding conversion. The extraction of event frequency features relies on the classification and aggregation of system event sequences. System events are classified according to predefined event types, and the event frequency feature extractor counts the frequency of occurrence of each type of event within a fixed time interval. The mining of correlation features employs a time window-based co-occurrence analysis algorithm, which calculates the statistical correlation coefficient between specific hardware status signal features and specific system events within a preset time lag range. When combining the extracted signal strength features, event frequency features, and correlation features into a multidimensional feature vector, a feature concatenation layer is used to stitch feature values ​​from different sources into a high-dimensional vector, and this high-dimensional vector is standardized to ensure that all feature values ​​are within the same numerical range.

[0024] In practice, the process of constructing a hardware operating state feature map by arranging multidimensional feature vectors in chronological order is handled by a feature sequence assembly module. This module maintains a fixed-length first-in-first-out (FIFO) queue, with each slot storing a multidimensional feature vector at a given time point. When a new multidimensional feature vector is generated, the module pushes it to the tail of the queue and discards the oldest multidimensional feature vector at the head, thus maintaining a constant time window length for the hardware operating state feature map. The hardware operating state feature map is stored in memory as a two-dimensional array, where row indices correspond to time points and column indices correspond to feature dimensions. This data structure allows subsequent processing modules to easily apply time-series-based analysis algorithms. For example, time-series analysis can be performed on each column of the hardware operating state feature map to extract trend information, or convolution operations can be performed on the entire two-dimensional structure of the hardware operating state feature map to capture local spatiotemporal patterns.

[0025] Optionally, the timing alignment process can employ a dynamic time warping algorithm to handle original data sequences of varying lengths. Dynamic time warping can find the optimal timing alignment path between multi-dimensional hardware state signal sequences and system event sequences, thus better handling the non-linear deformations of both over time. The generation of synchronized data streams can also adopt a publish-subscribe messaging model, where different data sources act as publishers, sending timestamped data to a message middleware. The alignment service, as a subscriber, consumes data from the middleware and reassembles it into a synchronized data stream in chronological order. In addition to using statistical correlation methods, the mining of correlation features can also introduce a mutual information-based metric, which can capture the non-linear dependencies between hardware state signals and system events.

[0026] It is understandable that the quality of the hardware operating state feature map construction directly depends on the precision of the timestamps and the accuracy of the synchronization algorithm. Obtaining high-precision timestamps requires hardware support, such as using a constant timestamp counter in the central processing unit. Generating synchronized data streams requires handling common distributed system problems such as clock drift and network latency. In a single smart terminal environment, using a single clock source can avoid most of these problems. The dimensionality of the multidimensional feature vector needs to be designed according to the specific hardware configuration and monitoring requirements. Excessively high dimensionality leads to increased computational complexity and storage overhead, while excessively low dimensionality may not adequately represent the system state. The time window length of the hardware operating state feature map is a configurable parameter. The time window length needs to balance the real-time performance of fault detection with the integrity of historical patterns. A shorter time window length is beneficial for rapid response to instantaneous faults, while a longer time window length is beneficial for identifying slowly developing degradation-type faults.

[0027] In practical implementation, the feature fusion processing stage also includes filtering and dimensionality reduction of redundant features. Principal component analysis (PCA) can be applied to multidimensional feature vectors. PCA maps the original features to a low-dimensional space through linear transformation while retaining most of the variance information. This method can reduce the storage space and computational load of the hardware operating state feature map and help improve the generalization ability of the subsequent fault analysis stage. The hardware operating state feature map is finally serialized into a standard data format and persistently stored in a local file system or database. The persistently stored hardware operating state feature map can be used for offline analysis, model training, and historical data backtracking. The entire time-series alignment and feature fusion processing flow is implemented as an independent background system service. The background system service is triggered to execute at fixed time intervals, thereby continuously providing the upper-layer fault detection function with the freshest hardware operating state feature map.

[0028] Optionally, for resource-constrained smart terminal devices, a lightweight feature extraction and fusion strategy can be adopted. Signal strength features can be simplified to retain only the mean feature, event frequency features can be simplified to retain only the counts of important system events, and correlation features can be simplified to Boolean flags indicating the existence of strong correlations. The construction of the hardware operating status feature map can also adopt an incremental update method, calculating only the feature vector corresponding to newly arrived data and appending it to the end of the feature map each time, while removing expired feature vectors from the head. This incremental update method can reduce computation and memory overhead, making it suitable for long-term operation on resource-constrained embedded smart terminals. The performance indicators of the timing alignment and feature fusion processing module need to be monitored, including processing latency, CPU utilization, and memory consumption, to ensure that this module does not significantly impact the normal functioning of the smart terminal.

[0029] Example 2: In specific implementation, the process of parsing the hardware operating status feature map using a preset fault knowledge graph is essentially about identifying potential faulty components and their attributes in the smart terminal through graph structure matching. Accessing the fault knowledge graph, which stores the association between component fault modes and symptoms, relies on a graph database management system. The fault knowledge graph stores entity relationships in the form of nodes and edges, where nodes represent fault modes or symptoms, and edges represent association rules. The step of matching the feature patterns in the hardware operating status feature map with the symptom nodes in the fault knowledge graph is executed by a feature matching engine. The feature matching engine receives the hardware operating status feature map as input and converts it into a graph query language, such as traversing the symptom nodes in the fault knowledge graph and calculating similarity scores. When the matching degree exceeds a set threshold, the fault mode node associated with that symptom node is activated. The set threshold is a fixed value, such as 0.85, set by the system administrator based on historical accuracy. The matching degree is calculated based on the cosine similarity between feature vectors. Based on the activated fault mode nodes, potentially faulty hardware components in the smart terminal are identified. Hardware component identifiers are extracted from metadata stored in the fault mode nodes; for example, the fault mode node "CPU overheating" is associated with the entity "Central Processing Unit". The matching confidence score between the feature patterns and activated symptom nodes is calculated. This score is evaluated using a Bayesian probability model and combined with the severity defined in the fault mode node (stored as an enumerated value such as "high", "medium", or "low" in the node attributes) to determine the severity level of the potential faulty component. The location information of the potential faulty components within the smart terminal's logical structure is recorded, forming a spatial distribution. This location information is obtained from the smart terminal's device tree or hardware configuration file, such as recording the physical coordinates or logical address of the central processing unit on the motherboard.

[0030] In some embodiments, the construction and updating of the fault knowledge graph is implemented through a separate graph management service. The process of collecting historical smart terminal hardware fault case data involves batch importing data from a fault log database. The case data includes fault component identifiers such as "memory module serial number," status signals at the time of the fault such as "voltage reading," system event records such as "kernel exception code," and final fault confirmation information such as "repair report." Association rules between fault symptoms and fault components are mined from the historical smart terminal hardware fault case data. The association rule mining uses the FP-growth algorithm to find frequent itemsets, such as the rule "When voltage fluctuation exceeds 5% and temperature exceeds 80°C, the probability that the faulty component is the battery is 90%." Using faulty components as entities, fault symptoms as attributes, and association rules as relations, an initial fault knowledge graph is constructed. The construction process uses the graph database API to create nodes and edges; for example, the entity "battery" is connected to the attribute "high voltage fluctuation" through the relation "cause." As new smart terminal hardware failure case data is generated, the association rules are updated using an incremental learning approach. Incremental learning is implemented through online machine learning algorithms, such as using a random forest model to dynamically adjust the rule confidence and update the entities, attributes, and relationships in the initial failure knowledge graph accordingly. Update operations include adding new nodes, modifying edge weights, or deleting outdated entries.

[0031] In a practical implementation, a specific example of accessing the fault knowledge graph involves a smartphone device. The hardware operating status feature graph contains feature patterns such as an average CPU core temperature of 75°C, a GPU load rate of 95%, and a system event "graphics driver timeout" frequency of 10 times per minute. The fault knowledge graph stores a symptom node "high temperature, high load," which is connected to the fault mode node "GPU overheating." The feature matching engine calculates the matching degree between the feature patterns in the hardware operating status feature graph and the symptom node "high temperature, high load," using the following formula:

[0032] in: It is the match score. It refers to the number of feature dimensions. It is the i-th feature value in the hardware operating state feature map. It is the expected value of the i-th feature stored in the symptom node. This indicates taking the maximum of the two values. (When the match score...) When the threshold of 0.85 is exceeded, the engine activates the symptom node "High Temperature and High Load" and traverses the edges to the fault mode node "GPU Overheating". Based on the fault mode node "GPU Overheating", the potential faulty component is identified as the graphics processor, and the matching confidence score is calculated using Bayes' theorem to be 0.92. Combined with the severity defined as "High" in the node, the severity level is set to High. Location information is obtained from the logical structure mapping of the smartphone, and the location of the graphics processor is recorded as "Motherboard Northbridge Region", forming a spatial distribution.

[0033] Understandably, matching degree calculation can integrate multiple feature dimensions. For example, in the smartphone example, feature dimensions include temperature, load rate, and event frequency. The matching degree formula ensures a balanced contribution from each dimension. The fault knowledge graph is updated weekly, with new case data coming from fault reports synchronized from the cloud. Incremental learning algorithms retrain the association rule model and automatically update the edge weights in the graph. Graph query optimization uses indexing techniques to accelerate node matching, such as creating a B-tree index for the feature values ​​of symptom nodes. In the severity level determination process, the mapping between matching confidence and severity enumeration values ​​is completed through a predefined mapping table; for example, a confidence level of 0.9 or higher corresponds to "high" severity.

[0034] Optionally, symptom node matching can employ a multi-threshold strategy, setting different thresholds for different symptom nodes to accommodate feature variability. For example, a threshold of 0.8 could be set for temperature-related symptoms, and 0.9 for load-related symptoms. The construction of the fault knowledge graph can incorporate a version control mechanism, saving a snapshot of the graph with each update for easy rollback of error corrections. Spatial distribution records can be extended to three-dimensional coordinates, including the stacked position of components within the smart terminal, such as recording the Z-axis depth in a multi-layered motherboard.

[0035] In practical implementation, the fault knowledge graph is stored using the Resource Description Framework standard. Entities and relationships are stored as triples, such as the triple <battery, has symptoms, voltage fluctuations>. When the feature patterns of the hardware operating status feature graph are matched with symptom nodes, the feature values ​​are normalized to the [0,1] interval to avoid the influence of dimensions, such as dividing the temperature value by the maximum allowable temperature of 100°C. After activating a fault mode node, the system checks the inference path between nodes. For example, if "GPU overheating" and "memory leak" are activated simultaneously, it infers that a compound fault may exist. A time decay factor is introduced into the matching confidence calculation, with higher weights for recent matches. For example, an exponential decay function is used to adjust for the influence of historical data. After the severity level is determined, the spatial distribution information is encapsulated into a JSON object containing the component ID, location coordinates, and severity level for subsequent policy mapping.

[0036] It's understandable that the size of the fault knowledge graph may vary depending on the type of smart terminal; for example, a graph for a tablet computer would contain more touchscreen-related fault patterns. During incremental learning updates, new case data undergoes quality filtering to remove incomplete or abnormal records, ensuring the graph's reliability. The feature dimension weights in the matching formula can be dynamically adjusted based on feature importance scoring, such as through information gain algorithms. Spatial distribution records are integrated with the smart terminal's CAD model to achieve visualized fault localization.

[0037] Optionally, the graph access interface provides a RESTful API, allowing remote querying and updates. Symptom node matching supports fuzzy logic to handle uncertain feature values, such as using a membership function to handle the case where temperature is "approximately high". Severity level determination can incorporate a machine learning classifier, inputting confidence scores and feature values ​​into the classification model to output a level. The graph update rollback mechanism is implemented through transaction logs to ensure data consistency.

[0038] In practical implementation, the example of constructing the initial fault knowledge graph is based on historical fault data from a smartwatch. The collected case data includes 1000 fault records, and association rule mining generates rules such as "When the battery voltage is below 3.3V, the probability of the faulty component being the battery is 85%". The initial fault knowledge graph contains 50 entity nodes and 200 edges, stored using the Neo4j graph database. During incremental learning and updates, new case data is processed in a streaming manner, with a rule update triggered every 100 new records, for example, updating the rule confidence from 85% to 88%. During the matching process, the hardware operating status feature map comes from the smartwatch's sensor data. The feature pattern matches the symptom node "low voltage," with a matching score of 0.88, exceeding the threshold of 0.85. This activates the fault mode node "battery aging," determining the severity level as medium, and the location information is recorded as "watch back cover battery compartment."

[0039] See Figure 3 This chart is a visual representation of the fault matching logic, displaying the matching degree values ​​between five hardware components—CPU, GPU, battery, memory, and screen—and symptom nodes in the fault knowledge graph in bar chart form. The orange dashed line in the chart represents the matching threshold; components exceeding the threshold are marked with red bars, while those below the threshold are distinguished by gray bars. The matching degree represents the degree of fit between the hardware's operating state characteristics and the fault symptoms in the knowledge graph; components exceeding the threshold are identified as potentially faulty components. This chart intuitively quantifies the fault correlation degree of each component, helping operations and maintenance personnel quickly focus on high-risk components. It is a key result visualization in the fault knowledge graph analysis process, providing data support for the selection of subsequent fault handling strategies.

[0040] Example 3: See Figure 4In practical implementation, the process of mapping the spatial distribution and severity levels of potential faulty components to a pre-constructed fault response strategy network and outputting an initial fault handling instruction set hinges on automating fault response through similarity calculation and strategy selection. The fault response strategy network is a graph-like data structure containing multiple strategy nodes. Each strategy node stores a set of fault handling instruction sequences and their corresponding fault scenario descriptions. Fault scenario descriptions are represented as feature vectors; for example, a scenario vector describing a battery fault might include dimensions such as voltage anomalies and temperature increases. The matching score between the spatial distribution and severity levels of potential faulty components and the applicable fault scenario descriptions for each strategy node is calculated. The matching score calculation uses a similarity metric based on Euclidean distance, expressed by the formula:

[0041] in: It is the matching score, with a value range of (0,1]. It refers to the number of feature dimensions. It is the weight coefficient of the j-th feature. It is the j-th characteristic value of the potentially faulty component. It is the j-th feature value of the strategy node scenario description, and the weighted Euclidean distance is calculated within the square root. The strategy node with the highest matching score is selected by traversing all strategy nodes and comparing the matching scores. The fault handling instructions corresponding to the selected strategy node are called to form an initial fault handling instruction set. The initial fault handling instruction set is an ordered list of commands. For example, instructions for battery faults may include "reduce charging current" and "start cooling fan".

[0042] In some embodiments, the fault response strategy network is constructed through offline training and testing. Various typical fault scenarios that may occur in smart terminals are defined, based on historical fault data analysis. For example, typical fault scenarios for smartphones include battery swelling, memory leakage, and display flickering. For each typical fault scenario, one or more candidate fault handling instruction sequences are developed. These sequences are designed by domain experts and cover response measures of varying severity. For example, for a battery swelling scenario, candidate instruction sequences might include "reducing charging power" or "completely stopping charging." The processing performance of each set of candidate fault handling instruction sequences for the corresponding typical fault scenarios is tested in a simulated or controlled real-world environment using a hardware-in-the-loop simulation platform. Performance evaluation metrics include fault recovery time, resource consumption rate, and system stability score. Based on the performance evaluation results, the optimal fault handling instruction sequence is selected for each typical fault scenario. The selection criteria are based on performance scores, such as selecting the sequence with the shortest recovery time. This sequence is then encapsulated as a strategy node. The encapsulation process includes storing the instruction sequence and scenario description vector into the node data structure. All policy nodes and their correspondence with fault scenario descriptions are organized into a network structure to form a fault response policy network. The network structure is stored in a graph database, and the similarity of scenarios is represented by the connection between nodes.

[0043] It is understandable that the weight coefficient w_j in the matching score formula can be optimized through machine learning, adjusted based on historical data to reflect feature importance. The selection of policy nodes may set a minimum score threshold, for example, selecting only when S > 0.8, otherwise triggering default processing. The initial fault handling instruction set consists of atomic operations and parameters, such as "reduce charging current to 500mA". The construction of the fault handling policy network is periodically updated, for example, retesting candidate instruction sequences quarterly to adapt to hardware iterations. Optionally, cosine similarity can be integrated as an alternative for matching score calculation to handle high-dimensional sparse features. The policy node network can support a hierarchical structure, with parent nodes representing general scenarios and child nodes representing specific variants. When testing processing performance, fault injection is simulated in a controlled real-world environment using laboratory equipment to ensure safety. Policy node encapsulation can contain metadata, such as the version number of the instruction sequence and the applicable device model.

[0044] In implementation, the fault response strategy network is stored in JSON format. Each strategy node contains a unique ID, a scenario description vector, a list of instruction sequences, and a performance score. The calculation of matching scores is performed by a strategy engine module, which loads network data and calculates the scores of all nodes in parallel to improve efficiency. After selecting the highest-scoring strategy node, the system verifies the compatibility of the instruction sequences, such as checking if the current system version of the tablet supports the instruction. After the initial fault handling instruction set is generated, it is temporarily stored in a memory buffer, awaiting subsequent optimization. When building the network, the definition of typical fault scenarios references international fault classification standards to ensure comprehensive coverage. Testing of candidate fault handling instruction sequences uses automated scripts. The scripts simulate fault occurrences and monitor instruction execution results; performance evaluation results are stored in a database for comparison.

[0045] Optionally, for resource-constrained devices, the matching score calculation can be simplified by using Manhattan distance instead of Euclidean distance. The policy node network can be partitioned for storage, loading only frequently used parts into memory. Performance evaluation during network construction includes energy consumption metrics, selecting green processing strategies. Instruction sequence calls are implemented via function pointers or message passing to ensure low latency. In a specific implementation, another example targets a smartwatch device. The spatial distribution of potentially faulty components indicates that the heart rate sensor is located at the "center of the back of the watch," with a severity level of "medium" and an encoding of 2. In the fault response policy network, policy node C is described as a sensor fault, with a feature vector of [signal noise = 0.6, power consumption = 0.7, severity level = 2]. Its matching score is calculated to be 0.89, higher than other nodes. Therefore, policy node C is selected, and the instruction sequences "calibrate sensor" and "increase sampling interval" are invoked to form the initial fault handling instruction set. When constructing this network, typical fault scenarios include sensor drift. Candidate instruction sequence testing is performed on a simulated watch. Performance evaluation is based on calibration accuracy and battery impact; the optimal sequence is selected and encapsulated as a node.

[0046] Example 4: In specific implementation, the process of extrapolating the degradation trajectory of potential faulty components and the evolution trend of system event sequences based on the historical evolution pattern of hardware operating state feature maps is centered on trend analysis and predictive modeling of time-series data. The operation of obtaining the historical hardware operating state feature map sequence within a predetermined time window is implemented through a circular buffer. The circular buffer continuously stores the hardware operating state feature maps of the most recent N sampling periods. The time window size T can be dynamically configured according to the fault type; for example, a shorter window, such as 60 minutes, is set for rapidly developing faults, while a longer window, such as 7 days, is set for slowly deteriorating faults. Trend analysis is performed on the historical hardware operating state feature map sequence. The trend analysis uses an exponential smoothing method to extract the slope and fluctuation pattern of changes in specific component state indicators. The slope is obtained by calculating the first derivative of the time series using linear regression, and the fluctuation pattern is quantified by calculating the standard deviation and autocorrelation coefficient within the sliding window. Based on the slope and fluctuation pattern, the expected state value sequence of potential faulty components in the future time period is extrapolated as the degradation trajectory. The extrapolation process uses a prediction model with confidence intervals, such as applying the Holt-Winters seasonality model for multi-step prediction. The system event occurrence patterns embedded in the historical hardware operation state feature map sequence are analyzed. The analysis uses a hidden Markov model to capture the state transition probabilities between events and predicts the distribution of system event types and their occurrence probabilities in the future time period as an evolution trend.

[0047] In some embodiments, the storage of historical hardware operating state feature map sequences employs a block compression format to reduce storage overhead, with each feature map block containing a timestamp and a feature matrix. The specific implementation of trend analysis includes a feature extraction pipeline that independently calculates trend parameters for each component state metric, such as calculating the hourly average rate of change for CPU temperature. The extrapolation formula for the degradation trajectory is expressed as:

[0048] in: It is the predicted state value k time points in the future. It is the horizontal component of the current time t. It is the trend slope component at the current time t. It is the seasonal adjustment component at the next k time points. This refers to the prediction step size. The analysis of the patterns in system events establishes a state transition matrix for each event type, where each matrix element represents the conditional probability of transitioning from the current event type to the next.

[0049] In a practical implementation, a specific example involves the battery assembly of a laptop computer. The predetermined time window is set to 24 hours. The historical hardware operating status characteristic sequence includes hourly sampled battery health indicators, including internal resistance, cycle count, and voltage stability. Trend analysis calculates that the slope of the battery internal resistance indicator changes by 0.5 milliohms per hour, and the fluctuation pattern shows a standard deviation of 2.1 milliohms and a positive autocorrelation. Extrapolation yields the degradation trajectory for the next 8 hours, predicting that the battery internal resistance will rise from the current 85 milliohms to 89 milliohms (see Table 1 for specific predicted values).

[0050] Table 1: Predicted Values ​​of Battery Internal Resistance

[0051] Analysis of the patterns of system events shows that there is a 70% probability of an "abnormal charging" event following a "sudden drop in power" event during battery degradation. The probability of an "abnormal charging" event occurring within the next 8 hours is predicted to be 65%, and the probability of a "temperature alarm" event is predicted to be 30%.

[0052] It is understandable that the setting of the time window size T needs to consider the characteristics of hardware components. For example, the degradation window for a mechanical hard drive can be set to several weeks, while the window for memory components can be set to several hours. In trend analysis, robust regression methods can be used to calculate the slope of change to reduce the impact of outliers. Extrapolation of degradation trajectories requires periodic adjustments to the prediction model parameters using actual observations to achieve adaptive prediction. Predicting the evolution trend of system events can integrate external variables, such as the impact of ambient temperature on the event trigger probability. Optionally, historical sequence storage can use a time-series database instead of a circular buffer to support more complex query analysis. Trend analysis can introduce abrupt change detection algorithms to identify turning points in accelerated degradation. Degradation trajectory prediction can be combined with physical models, such as battery aging equations, to enhance prediction reliability. Event evolution prediction can use long short-term memory networks to capture long-term dependencies.

[0053] In practical implementation, the acquisition of hardware operating status feature map sequences is achieved through a data management service, which periodically loads feature map data within a specified time range from persistent storage. The trend analysis module works independently for each feature dimension, such as analyzing the trend characteristics of indicators like temperature, voltage, and load. The calculation of the slope of change uses the least squares method to fit the time series, obtaining the coefficients of the linear trend term. The analysis of fluctuation patterns includes periodic detection, using Fast Fourier Transform to identify potential periodic components. The extrapolation of the degradation trajectory is performed every 15 minutes, with each extrapolation updating the model parameters using the latest historical data. The analysis of system event occurrence patterns maintains an event graph model, where model nodes represent event types, edge weights represent transition probabilities, and prediction is performed by calculating the probability distribution of future event sequences through graph traversal.

[0054] In some embodiments, the predictive model parameters are learned from historical data through maximum likelihood estimation; for example, the smoothing parameters of the Holt-Winters model are determined by optimizing the fitting error. Confidence intervals are calculated based on the historical distribution of the prediction error, using a t-distribution or bootstrap method to estimate the interval range. Predictions of event evolution trends support conditional probability calculations, such as predicting the probability of the next event being "application crash" given that an "out of memory" event has occurred. The entire prediction process is integrated into the early warning module of the fault management system, providing data support for instruction optimization. It is understood that the accuracy of degradation trajectories depends on the quality and length of historical data, and interpolation methods are used to fill in missing data. System event prediction needs to consider causal relationships between events, not just temporal correlations. Uncertainty in the prediction results should be passed on to subsequent processing stages to guide risk perception decision-making. The model update frequency needs to balance computational overhead and prediction timeliness. Optionally, for multi-component systems, degradation trajectory prediction can consider the mutual influence between components, using a multivariate time series model. Event evolution prediction can introduce a prioritization mechanism, focusing on the prediction accuracy of high-impact events. Visualizing forecast results can help operations and maintenance personnel understand trends, but automated systems use numerical results directly for decision-making.

[0055] Example 5: In specific implementation, the process of dynamically correcting and rearranging the instruction sequence of the initial fault handling instruction set based on the degradation trajectory and evolution trend, and driving its execution, is centered on adaptively optimizing the fault response strategy based on predictive data. The core of this process is to assess whether the degradation trajectory indicates that the fault development speed exceeds the preset response capability of the initial fault handling instruction set. This assessment is completed by comparing the slope of the degradation trajectory with a preset threshold. For example, if the degradation trajectory shows that the battery internal resistance increases by 1 milliohm per hour while the preset response capability threshold is 0.5 milliohms per hour, it is determined that the capability is exceeded. The process also assesses whether the evolution trend introduces new risk factors or resource constraints. New risk factors include predicted system events such as high-temperature alarms that may exacerbate hardware stress, and resource constraints include CPU utilization predictions indicating future resource shortages. If the fault development speed exceeds the preset response capability or new risk factors exist, the execution intensity of the instructions in the initial fault handling instruction set is adjusted or the triggering timing of the instructions is advanced. For example, the execution intensity of the "reduce charging current" instruction is adjusted from 50% to 70%, or the triggering timing of the "start fan" instruction is advanced from when the temperature reaches 80°C to 75°C. Based on resource constraints, the execution order of instructions in the initial fault handling instruction set is rearranged to optimize resource utilization efficiency. For example, instructions with high computational load are moved to periods of low system load for execution. The set of instructions with adjusted execution intensity, triggering timing, and execution order is then used as the optimized fault handling instruction set.

[0056] The system drives the intelligent terminal to execute the specific operations contained in the optimized fault handling instruction set. It parses and optimizes the fault handling instruction set, decomposing it into basic operation commands that can be recognized by the intelligent terminal's operating system or hardware driver. For example, the "reduce charging current" instruction is decomposed into "set the power management register address 0x1234 to 0x5A". These basic operation commands are sent sequentially to the corresponding execution units of the intelligent terminal, with the sending process implemented through system calls or hardware abstraction layer interfaces. The system monitors the execution status of the basic operation commands, using status register reads or callback functions to check if command execution was successful. An execution process log is recorded, and the execution status is returned to the monitoring node of the fault detection process. The log records include timestamps, command content, and execution results for auditing and backtracking.

[0057] In some embodiments, the comparison between the degradation trajectory and the preset response capability is evaluated using quantitative indicators. The slope of the degradation trajectory is obtained by calculating the first derivative of the time series using linear regression, and the preset response capability threshold is derived based on statistical analysis of historical fault handling data. A risk probability model is used to assess new risk factors introduced by the evolution trend. The model outputs a risk score for each predicted event, and resource constraint assessment is based on the predicted value of system resource utilization. The formula for adjusting the instruction execution intensity is expressed as:

[0058] in: It is the adjusted instruction execution strength. It is the initial instruction execution strength. It is the strength adjustment coefficient. This is the normalized risk increment of the degradation trajectory. The advance timing of the instruction trigger is based on the prediction of the event occurrence time of the evolution trend. For example, if the high temperature event is predicted to occur 2 hours earlier, then the corresponding instruction trigger timing will be 2 hours earlier.

[0059] In a specific implementation, an example involves the battery assembly of a smartphone. The initial fault handling instruction set includes instruction A "reduce screen brightness to 50%", instruction B "close background applications", and instruction C "limit charging current to 1A". The degradation trajectory shows that the battery temperature rises at a rate of 5°C per hour, exceeding the preset threshold of 3°C per hour. The evolution trend predicts that a "CPU overload" event will occur within the next hour, and the system memory usage will reach 90%. After assessment, it was determined that the fault development speed exceeded the response capacity and there were memory resource constraints. The instruction execution intensity was adjusted: the intensity of instruction A was increased from 50% to 70%, and the intensity of instruction C was adjusted from 1A to 0.8A; the triggering time of instruction B was advanced, and it was executed immediately instead of waiting for the temperature threshold; the instruction sequence was rearranged to B, C, A to prioritize memory release. After the optimized fault handling instruction set was formed, it was parsed into basic operation commands: instruction B was decomposed into "terminate process com.example.app", instruction C was decomposed into "write power chip register 0x5678 value to 0x30", and instruction A was decomposed into "set display backlight parameter level=30". Commands are sent sequentially to the process management unit, power management unit, and display driver unit. The execution results of each command are monitored, logs are recorded, and the status is returned to the monitoring node.

[0060] It is understandable that the assessment process may integrate multiple degradation indicators, such as simultaneously considering the degradation trajectories of temperature and voltage, and using a weighted average to calculate the overall risk. The adjustment coefficient λ in the instruction execution intensity adjustment formula can be dynamically configured according to the fault type, with a larger coefficient used for high-risk faults. Instruction sequence rearrangement considers dependencies to ensure that instructions with order constraints are not incorrectly rearranged. Parsing of basic operation commands requires verifying the legality and security of the commands to avoid executing harmful operations. Optionally, moving average filtering can be used to smooth noise when assessing degradation trajectories to avoid misjudgments. Evolution trend assessment can introduce a confidence threshold, considering new risks only when the prediction confidence is higher than 80%. Instruction adjustments can support gradual modifications, such as increasing intensity in stages to avoid system oscillations. Command sending can employ a transaction mechanism to ensure that a set of commands either all succeed or are rolled back. In some embodiments, monitoring the execution result status includes timeout handling, such as considering a command failure if no response is received within 5 seconds after sending. Logs are recorded in a structured format. After returning the execution status to the monitoring node, the monitoring node can trigger a retry mechanism or report to a higher-level system.

[0061] See Figure 5This chart, a grouped bar chart, compares the initial and optimized execution strengths of three fault handling commands: reducing screen brightness, limiting charging current, and closing background applications. When the degradation trajectory shows that the fault is developing faster than expected and the evolution trend introduces new resource constraints, the command strength needs to be dynamically adjusted. Increasing the screen brightness reduction ratio and the extent to which background applications are closed is to accelerate resource consumption control; tightening the charging current limit is to adapt to the rapid development of battery degradation. This chart visually presents the specific extent of command optimization, is a key result visualization of the dynamic command correction process, clearly reflects the adjustment logic of the handling strategy from the initial preset to adapting to the fault trend, and provides quantitative evidence for verifying the rationality of the optimized commands.

[0062] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A hardware fault detection method for a smart terminal, characterized in that, The method includes the following steps: Real-time capture of multi-dimensional hardware status signals and system event sequences generated by smart terminals during operation; The multi-dimensional hardware status signals and system event sequences are subjected to timing alignment and feature fusion processing to form a hardware operating status feature map. The hardware operating state feature map is analyzed using a preset fault knowledge graph to identify the spatial distribution and severity level of potential faulty components. The spatial distribution and severity level of the potential faulty components are mapped to a pre-built fault response strategy network, and an initial fault handling instruction set is output. Based on the historical evolution pattern of the hardware operating state feature map, the degradation trajectory of the potential faulty components and the evolution trend of the system event sequence are inferred. Based on the degradation trajectory and evolution trend, the initial fault handling instruction set is dynamically modified and the instruction sequence is rearranged to form an optimized fault handling instruction set; The intelligent terminal is driven to execute the specific operations contained in the optimized fault handling instruction set.

2. The hardware fault detection method for a smart terminal as described in claim 1, characterized in that, The step of performing time-series alignment and feature fusion processing on the multi-dimensional hardware state signals and system event sequences to form a hardware operating state feature map includes: Assign timestamps to the multi-dimensional hardware status signals and mark the occurrence times of the system event sequences; Based on the system clock, the system performs alignment operations on the multi-dimensional hardware status signals with timestamps and the system event sequences with occurrence time markers to generate a synchronized data stream. Signal strength features, event frequency features, and correlation features are extracted from the synchronized data stream; The signal strength features, event frequency features, and correlation features are combined into a multi-dimensional feature vector; The multidimensional feature vectors are arranged in chronological order to construct the hardware operating state feature map.

3. The hardware fault detection method for a smart terminal as described in claim 1, characterized in that, The step of analyzing the hardware operating state feature map using a preset fault knowledge graph to identify the spatial distribution and severity level of potential faulty components includes: Access a fault knowledge graph that stores the correlation between component failure modes and symptoms; Match the feature patterns in the hardware operating status feature graph with the symptom nodes in the fault knowledge graph; When the matching degree exceeds the set threshold, the fault mode node associated with the symptom node is activated; Based on the activated fault mode nodes, identify the hardware components in the smart terminal that may be faulty. The matching confidence of the feature patterns and the activated symptom nodes is calculated, and the severity level of the potential faulty components is determined by combining the severity defined by the fault mode nodes. Record the location information of the potentially faulty components in the logical structure of the smart terminal to form the spatial distribution.

4. The hardware fault detection method for a smart terminal as described in claim 3, characterized in that, The method also includes the step of constructing and updating the fault knowledge graph: Collect historical data on hardware failures in smart terminals. This data includes the identification of the faulty component, the status signals at the time of the failure, system event records, and the final failure confirmation information. Mining association rules between fault symptoms and faulty components from the historical smart terminal hardware failure case data; An initial fault knowledge graph is constructed using faulty components as entities, fault symptoms as attributes, and association rules as relationships. As new smart terminal hardware failure case data is generated, the association rules are updated using an incremental learning approach, and the entities, attributes, and relationships in the initial failure knowledge graph are updated accordingly.

5. The hardware fault detection method for a smart terminal as described in claim 1, characterized in that, The step of mapping the spatial distribution and severity level of the potential faulty components to a pre-built fault response strategy network and outputting an initial fault handling instruction set includes: The fault response strategy network contains multiple strategy nodes, each strategy node corresponding to a set of fault handling instructions and a description of the fault scenarios to which they are applicable; Calculate the spatial distribution and severity level of the potential faulty components and their matching scores with the fault scenario descriptions applicable to each policy node; Select the strategy node with the highest matching score; The fault handling instructions corresponding to the selected policy node are invoked to form the initial fault handling instruction set.

6. The hardware fault detection method for a smart terminal as described in claim 5, characterized in that, The fault response strategy network is constructed in the following manner: Define various typical fault scenarios that may occur in smart terminals; For each typical fault scenario, formulate one or more sets of candidate fault handling instruction sequences; Test the processing efficiency of each set of candidate fault handling instruction sequences for corresponding typical fault scenarios in a simulated environment or a controlled real environment; Based on the performance evaluation results, the optimal fault handling instruction sequence is selected for each type of typical fault scenario and encapsulated as a strategy node. All policy nodes and their correspondence with fault scenario descriptions are organized into a network structure to form the fault response policy network.

7. The hardware fault detection method for a smart terminal as described in claim 1, characterized in that, The calculation of the degradation trajectory of the potential faulty component and the evolution trend of the system event sequence based on the historical evolution pattern of the hardware operating state feature map includes: Obtain a sequence of historical hardware operating status feature maps within a predetermined time window; Perform trend analysis on the historical hardware operating status feature map sequence to extract the slope and fluctuation pattern of the status indicators of specific components; Based on the change slope and fluctuation pattern, the expected state value sequence of the potential faulty component in the future time period is extrapolated and used as the degradation trajectory. The patterns of system events embedded in the historical hardware operation state feature map sequence are analyzed to predict the distribution of system event types and their probabilities in future time periods, which serves as the evolution trend.

8. The hardware fault detection method for a smart terminal as described in claim 1, characterized in that, Based on the degradation trajectory and evolution trend, the initial fault handling instruction set is dynamically modified and the instruction sequence is rearranged to form an optimized fault handling instruction set, including: Assess whether the degradation trajectory indicates that the rate of failure progression exceeds the preset response capability of the initial failure handling instruction set; Assess whether the aforementioned evolutionary trend introduces new risk factors or resource constraints; If the speed of fault development exceeds the preset response capacity or new risk factors exist, the execution intensity of the instructions in the initial fault handling instruction set will be adjusted or the triggering time of the instructions will be advanced. Based on resource constraints, the execution order of instructions in the initial fault handling instruction set is rearranged to optimize resource utilization efficiency; The set of instructions whose execution intensity, triggering timing, and execution order have been adjusted is used as the optimized fault handling instruction set.

9. The hardware fault detection method for a smart terminal as described in claim 1, characterized in that, The specific operations included in the optimized fault handling instruction set executed by the driving intelligent terminal include: The optimized fault handling instruction set is parsed and decomposed into basic operation commands that can be recognized by the smart terminal operating system or hardware driver. The basic operation commands are sent sequentially to the corresponding execution units of the smart terminal; Monitor the execution result status of the basic operation commands; Record the execution process log and return the execution result status to the monitoring node of the fault detection process.

10. A hardware fault detection system for a smart terminal, used to implement the hardware fault detection method for a smart terminal as described in any one of claims 1 to 9, characterized in that, The system includes: The data acquisition unit is used to capture in real time the multi-dimensional hardware status signals and system event sequences generated by the smart terminal during operation; The feature processing unit is used to perform timing alignment and feature fusion processing on the multi-dimensional hardware status signals and system event sequences to form a hardware operating status feature map. The fault analysis unit is used to analyze the hardware operating state feature map using a preset fault knowledge graph to identify the spatial distribution and severity level of potential faulty components. The strategy mapping unit is used to map the spatial distribution and severity level of the potential faulty components to a pre-built fault response strategy network and output an initial fault handling instruction set. The trend prediction unit is used to infer the degradation trajectory of the potential faulty component and the evolution trend of the system event sequence based on the historical evolution pattern of the hardware operating state feature map. The instruction optimization unit is used to dynamically modify and rearrange the instruction sequence of the initial fault handling instruction set according to the degradation trajectory and evolution trend, so as to form an optimized fault handling instruction set. The instruction execution unit is used to drive the smart terminal to execute the specific operations contained in the optimized fault handling instruction set.

Images