Bus module self-recovery method, device and equipment and storage medium

Abstract

The invention discloses a bus module self-recovery method and device, equipment and a storage medium. According to the invention, the communication state of the bus module is monitored in real time, and the abnormal detection signal is identified; when an abnormal detection signal is identified, the fault type is automatically diagnosed; dynamically selecting and combining an optimal recovery strategy according to the fault type; executing a self-recovery operation corresponding to the recovery strategy, and verifying a recovery effect; if the recovery fails, automatically adjusting and executing the recovery strategy of the next priority according to the fault type and the failure frequency; isolating communication between the fault bus module and other normal modules through a bus arbitration mechanism; recording fault features and a recovery process, and generating historical data for subsequent fault prediction; and if recovery fails for multiple times, triggering a system-level security protection mechanism, and giving an alarm. According to the method, the fault type can be quickly and accurately identified, the optimal recovery strategy is selected in a targeted manner, and the system maintainability and safety of the bus module system are effectively improved.

Description

Technical Field

[0001] The present invention relates to the technical field of bus control, and particularly to a self - recovery method, device, equipment and storage medium for a bus module. Background Art

[0002] A bus module is a type of industrial connector used for power or data shunting and conversion, which can output multiple current or data signals. The role of the bus module is to connect a PLC controller with control objects such as peripheral devices, sensors, and actuators to ensure real - time data transmission and stable operation of the system. However, during actual operation, the bus module may experience failures such as communication anomalies or complete failures due to various reasons, such as hardware aging, environmental interference, software errors, power supply fluctuations, connection problems, or interaction conflicts with other modules.

[0003] Traditional bus fault handling methods usually rely on manual intervention or simple preset restart mechanisms. Manual intervention has a slow response speed and is difficult to meet the requirements of large - scale and high - concurrency systems. Often, it takes a long time to locate the problem and take repair measures after a fault occurs, during which the system may have suffered significant performance losses or service interruptions.

[0004] The fault detection and recovery mechanisms of the prior art have the following deficiencies: 1) The accuracy and real - time performance of fault detection need to be improved, and false alarms or missed detections are prone to occur; 2) The recovery strategy is relatively fixed and lacks the ability to dynamically combine and optimize according to specific fault situations; 3) During the recovery process, how to effectively isolate the faulty module to avoid affecting the communication of other normal modules is often overlooked. Therefore, the problem of how to reliably and efficiently achieve self - recovery of bus modules has become an urgent problem for those skilled in the art. Summary of the Invention

[0005] Embodiments of the present invention address the above - mentioned deficiencies and provide a self - recovery method, device, equipment and storage medium for a bus module to solve the problems existing in the prior art.

[0006] To solve the above - mentioned technical problems, an embodiment of the present invention provides a self - recovery method for a bus module, the method comprising: Real - time monitoring the communication status of the bus module, and obtaining and identifying abnormal detection signals based on a preset abnormal mode library; When the abnormal detection signal is identified, automatically diagnosing the fault type; According to the diagnosed fault type, dynamically select and combine the optimal recovery strategy from a predefined recovery strategy library; wherein, the recovery strategy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery strategy; Execute the self - recovery operation corresponding to the recovery strategy and verify the recovery effect; If the recovery fails, automatically adjust and execute the recovery strategy of the next priority according to the fault type and the number of failures; During the self-recovery process, isolate the communication between the faulty bus module and other normal modules through the bus arbitration mechanism; Record the fault characteristics and the recovery process to generate historical data for subsequent fault prediction; If the recovery fails multiple times, trigger the system-level security protection mechanism and issue an alarm.

[0007] Preferably, the real-time monitoring of the communication status of the bus module, and the obtaining and identifying of the anomaly detection signal based on the preset anomaly pattern library include: Continuously monitor the communication data frames on the bus and collect data for the bus module; Perform real-time processing on the collected data stream and extract key status features; Compare the extracted key status features with the preset anomaly pattern library; If the matching degree of the key status features and the patterns in the anomaly pattern library exceeds the preset threshold, generate a unique anomaly detection signal.

[0008] Preferably, when the anomaly detection signal is recognized, the automatic diagnosis of the fault type includes: Receive the anomaly detection signal and parse the anomaly pattern type code of the anomaly detection signal; Based on the anomaly pattern type code, perform a preliminary classification of the fault type; Perform in-depth diagnosis on the complex or ambiguous anomaly detection signal; Determine the final fault type based on the results of the preliminary judgment and in-depth diagnosis.

[0009] Preferably, according to the diagnosed fault type, dynamically select and combine the optimal recovery strategy from the predefined recovery strategy library, including: According to the diagnosed fault type, query the predefined recovery strategy library; Retrieve the available strategies associated with the fault type from the recovery strategy library to form a strategy list; Obtain the weight value of each strategy in the strategy list and select the optimal recovery strategy according to the weight value, including: Select a single strategy with the highest weight; Or, dynamically combine multiple strategies according to the current system state to form the optimal recovery strategy.

[0010] Preferably, execute the self-recovery operation corresponding to the recovery strategy and verify the recovery effect, including: Monitor the communication status of the bus module again and check whether the abnormal detection signal disappears; If the abnormal detection signal disappears, send a function request signal to the faulty bus module; Check whether the faulty bus module can correctly respond to the function request signal; Verify the response data of the faulty bus module; Based on the verification result, determine whether the recovery operation is successful.

[0011] Preferably, the dynamically combining multiple policies according to the current system state to form the optimal recovery policy includes: Obtain the real-time status information of the current system; According to the real-time status information and preset rules, evaluate the utility values of different policy combinations in the policy list; Obtain the state requirements of the current system, and select a matching policy combination according to the state requirements and the utility value; Mark the policy combination as the optimal recovery policy to be executed in this self-recovery operation.

[0012] Preferably, the communication data frame includes a data ID, data content, timestamp, frame length, and error flag.

[0013] To solve the above technical problems, an embodiment of the present invention provides a bus module self-recovery device, and the device includes: An abnormal recognition module, configured to monitor the communication status of the bus module in real time, and obtain and recognize an abnormal detection signal based on a preset abnormal mode library; An automatic diagnosis module, configured to automatically diagnose the fault type when the abnormal detection signal is recognized; A recovery control module, configured to dynamically select and combine an optimal recovery policy from a predefined recovery policy library according to the diagnosed fault type; wherein, the recovery policy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery policy; An execution verification module, configured to execute the self-recovery operation corresponding to the recovery policy and verify the recovery effect; An automatic adjustment module, configured to, if the recovery fails, automatically adjust and execute the next-priority recovery policy according to the fault type and the number of failures; An isolation module, during the self-recovery process, isolate the communication between the faulty bus module and other normal modules through a bus arbitration mechanism; A storage record module, configured to record the fault characteristics and the recovery process, and generate historical data for subsequent fault prediction; A trigger control module, configured to, if the recovery fails multiple times, trigger a system-level security protection mechanism and issue an alarm.

[0014] To solve the above technical problems, an embodiment of the present invention provides a bus module self-recovery device, comprising: at least one processor, at least one memory, and computer program instructions stored in the memory. When the computer program instructions are executed by the processor, the method of the first aspect of the above embodiment is implemented.

[0015] To solve the above technical problems, an embodiment of the present invention provides a storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method of the first aspect of the above embodiment is implemented.

[0016] In summary, the embodiments of the present invention provide a bus module self-recovery method, device, equipment and storage medium. The present invention monitors the communication status of the bus module in real time, obtains and identifies abnormal detection signals based on a preset abnormal pattern library, thereby realizing rapid detection of bus module faults; when the abnormal detection signal is identified, the fault type is automatically diagnosed, thereby realizing automation of fault diagnosis; according to the diagnosed fault type, the optimal recovery strategy is dynamically selected and combined from the predefined recovery strategy library, so that the present application can flexibly select a recovery strategy according to the current state of the system, so as to be able to handle various and complex system faults and improve the success rate of system fault recovery; execute the self-recovery operation corresponding to the recovery strategy, and verify the recovery effect, thereby forming an "execution-verification" closed loop, ensuring the effectiveness of the recovery measures; if the recovery fails, the next priority recovery strategy is automatically adjusted and executed according to the fault type and the number of failures, so as to improve the system's ability to deal with complex or stubborn faults; during the self-recovery process, the communication between the faulty bus module and other normal modules is isolated through the bus arbitration mechanism, This prevents abnormal behavior of faulty modules from affecting other healthy modules on the bus, improving overall system stability. It also records fault characteristics and recovery processes, generating historical data for subsequent fault prediction, enabling a shift from passive repair to active prevention. If recovery fails multiple times, a system-level safety protection mechanism is triggered, generating an alarm. Consequently, this invention can quickly and accurately identify fault types and select the optimal recovery strategy, effectively improving the maintainability and safety of the bus module system. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0018] Figure 1 The present invention is a flowchart of a bus module self-recovery method according to an embodiment of the present invention.

[0019] Figure 2 This is a flowchart for a real-time monitoring bus module to communicate status, obtain and identify abnormal detection signals based on a preset abnormal mode library in an embodiment of the present invention.

[0020] Figure 3 This is a flowchart for automatically diagnosing the fault type when an abnormal detection signal is recognized in an embodiment of the present invention.

[0021] Figure 4 This is a flowchart for dynamically selecting and combining the optimal recovery strategy from a predefined recovery strategy library according to the diagnosed fault type in an embodiment of the present invention.

[0022] Figure 5 This is a flowchart for performing the self-recovery operation corresponding to the recovery strategy and verifying the recovery effect in an embodiment of the present invention.

[0023] Figure 6 This is a flowchart for dynamically combining multiple strategies according to the current system state to form the optimal recovery strategy in an embodiment of the present invention.

[0024] Figure 7 This is a schematic structural diagram of a bus module self-recovery device in an embodiment of the present invention.

[0025] Figure 8 This is a schematic structural diagram of a bus module self-recovery device in an embodiment of the present invention. Detailed implementation manners

[0026] The features and exemplary embodiments of various aspects of the present invention will be described in detail below. To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only configured to explain the present invention and are not configured to limit the present invention. For those skilled in the art, the present invention can be implemented without some of these specific details. The following description of the embodiments is only provided to provide a better understanding of the present invention by showing examples of the present invention.

[0027] It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprising", "including" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising..." does not exclude the existence of additional identical elements in the process, method, article or device comprising the element.

[0028] Please refer to Figure 1 , Figure 1 A bus module self-recovery method provided for this application, the method includes the following steps: S1. Real-time monitor the communication status of the bus module, and obtain and identify an anomaly detection signal based on a preset anomaly pattern library; Specifically, in this embodiment, the bus module includes one of a distributed bus module, a card-type bus module, or an integrated bus module, and no specific limitation is made here.

[0029] Specifically, in this embodiment, the communication status of the bus module refers to the real-time performance of the bus module during communication, including parameters such as data transmission rate, data packet format, signal strength, error count, response time, timeout situation, bus occupancy rate, etc., and no specific limitation is made here.

[0030] Specifically, the anomaly pattern library is set as a data storage structure, which contains predefined characteristic patterns representing the abnormal behaviors of the bus module. The characteristic patterns are established based on historical fault data, theoretical analysis, or machine models, and no specific limitation is made here.

[0031] Specifically, in this embodiment, when the communication status of the bus module matches the pattern in the anomaly pattern library, the system generates an anomaly detection signal, indicating that there is an abnormal situation in the communication status of the bus module.

[0032] Specifically, for example, an anomaly pattern "the error counter of node A increases from 0 to more than 100 within 10 seconds" is defined in the anomaly pattern library, and this anomaly pattern indicates a hardware fault of node A or bus interference. The system calculates the change rate of the error counter of node A in real time. When it is detected that the error counter of node A reaches 120 within 10 seconds, the system generates an anomaly detection signal named "NODE_A_HARDWARE_FAULT_SUSPECTED" according to the matching rules of the anomaly pattern library.

[0033] S2. When an abnormal detection signal is recognized, automatically diagnose the fault type; Specifically, in this embodiment, the system maps the abnormal detection signal to a specific fault type by applying predefined diagnostic rules, thereby realizing the automatic diagnosis of the fault type.

[0034] Specifically, for example, after the system receives the abnormal detection signal of "NODE_A_HARDWARE_FAULT_SUSPECTED", it queries the rule library: "If the error counter of node A rises sharply and node A has not sent any valid messages within the last 1 second, then diagnose it as 'node A transmitter failure'; if node A still sends messages but continues to report errors, then diagnose it as 'node A receiver failure or bus interference'".

[0035] Furthermore, the system checks the message sending record of node A. If it is found that node A has indeed stopped sending messages after the error counter rises. Therefore, the system automatically diagnoses it as 'node A transmitter failure'.

[0036] Therefore, this application can perform automatic detection of the fault type, avoiding the time-consuming and uncertainty of manual troubleshooting.

[0037] S3. According to the diagnosed fault type, dynamically select and combine the optimal recovery strategy from the predefined recovery strategy library; wherein, the recovery strategy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery strategy; Specifically, the predefined recovery strategy library is a data structure for storing different recovery methods and corresponding operation steps for various known fault types.

[0038] Specifically, a known fault type can correspond to one or more recovery strategies, which are not specifically limited here.

[0039] Specifically, in this embodiment, the system searches for the corresponding recovery strategy in the data structure of the recovery strategy library according to the determined fault type. It should be noted that the optimal recovery strategy can be a single recovery strategy or a strategy combination dynamically formed according to the current system state, which is not specifically limited here.

[0040] Therefore, this application can select the most effective recovery method for a specific fault type, improving the recovery success rate. In addition, the dynamic combination setting of this application enables the system to adapt to different fault scenarios and has strong compatibility.

[0041] S4. Execute the self-recovery operation corresponding to the recovery strategy and verify the recovery effect; Specifically, in this embodiment, the system performs specific recovery actions according to the selected recovery strategy.

[0042] Specifically, after performing the self-recovery operation, the recovery effect is verified by checking the communication behavior of the faulty bus module to confirm whether the bus module has restored its normal communication function.

[0043] S5. If the recovery fails, according to the fault type and the number of failures, automatically adjust and execute the recovery strategy of the next priority level; Specifically, in this embodiment, if the self-recovery operation performed fails to restore the faulty bus module to the normal state, the system records the number of recovery attempts through a failure counter. In addition, when the cumulative number of recovery failures reaches a preset threshold, the system determines the next recovery strategy to be attempted according to the priority order of the strategies in the recovery strategy library.

[0044] Specifically, for example, after verifying the failure after performing "software reset node A", if the error counter is still high and the communication test fails, the system records the number of recovery failures of "node A transmitter failure" as 1. Further, according to the strategy library and the number of failures, the system automatically selects "disconnect and reconnect the power supply of node A" as the recovery strategy of the next priority level. The system executes this power operation and then verifies again.

[0045] S6. During the self-recovery process, isolate the communication between the faulty bus module and other normal modules through the bus arbitration mechanism; Specifically, in this embodiment, during the self-recovery process, the system places the faulty node in the "bus-off" state to disconnect the faulty bus module. At this time, the faulty bus module no longer participates in the bus communication and will not affect the normal communication and data transmission of other nodes. Therefore, the present application can avoid abnormal behaviors such as the continuous sending of error frames by the faulty bus module and the long-term occupation of the bus after the bus competition fails, which affect the stable operation of the entire bus.

[0046] S7. Record the fault characteristics and the recovery process to generate historical data for subsequent fault prediction; Specifically, in this embodiment, the fault characteristics include the fault itself and the key information of the system state when the fault occurs, including information such as the fault type, occurrence time, duration, related abnormal detection signals, communication status parameters, module identification, etc., which are not specifically limited here.

[0047] Specifically, the system stores the above-mentioned fault characteristics and recovery process information in a structured manner to form a data record for subsequent analysis and query.

[0048] Furthermore, the present application also uses statistical analysis and machine learning methods to identify the patterns, trends or early signs of fault occurrence to predict possible future faults and achieve preventive maintenance.

[0049] Specifically, for example: System Record: [Timestamp] Detected an abnormal signal: NODE_A_HARDWARE_FAULT_SUSPECTED. The error counter increased from 0 to 120 in 10 seconds.

[0050] System Record: [Timestamp] Diagnosed as: Node A transmitter failure.

[0051] System Record: [Timestamp] Attempted recovery strategy: Software reset Node A. Result: Failed. Number of failure attempts: 1.

[0052] System Record: [Timestamp] Attempted recovery strategy: Disconnect and reconnect the power supply of Node A. Result: Success. Recovery time: 15 seconds.

[0053] These records are stored in a database table with fields: Fault ID, Occurrence Time, Module ID, Fault Type, Abnormal Characteristics, Attempted Strategy 1, Strategy 1 Result, Attempted Strategy 2, Strategy 2 Result, etc. By analyzing these historical records through machine learning, it is found that "Node A transmitter failure" always occurs under specific conditions such as high temperature and specific load, and it is predicted that it may occur again under similar conditions, so preventive measures can be taken before the fault really affects the system to prevent the expansion of fault losses.

[0054] S8. If the recovery fails multiple times, trigger the system-level security protection mechanism and issue an alarm.

[0055] Specifically, in this embodiment, when the failure count counter for the fault type reaches another preset threshold, the system generates an alarm message containing necessary information and sends the alarm to the specified recipient or monitoring system through the configured communication channel.

[0056] In summary, the present application provides a bus module self-recovery method, which realizes rapid detection of bus module faults by real-time monitoring of the communication status of the bus module, acquiring and identifying abnormal detection signals based on a preset abnormal pattern library; when an abnormal detection signal is identified, the fault type is automatically diagnosed, thereby realizing automation of fault diagnosis; according to the diagnosed fault type, the optimal recovery strategy is dynamically selected and combined from a predefined recovery strategy library, so that the present application can flexibly select a recovery strategy according to the current state of the system, so as to be able to handle various and complex system faults and improve the success rate of system fault recovery; execute the self-recovery operation corresponding to the recovery strategy, and verify the recovery effect, thereby forming an "execution-verification" closed loop, ensuring the effectiveness of the recovery measures; if the recovery fails, the next priority recovery strategy is automatically adjusted and executed according to the fault type and the number of failures, so as to improve the system's ability to cope with complex or stubborn faults; in the self-recovery process, the communication between the faulty bus module and other normal modules is isolated through the bus arbitration mechanism, This prevents abnormal behavior of faulty modules from affecting other healthy modules on the bus, improving overall system stability. It also records fault characteristics and recovery processes, generating historical data for subsequent fault prediction, enabling a shift from passive repair to active prevention. If recovery fails multiple times, a system-level safety protection mechanism is triggered, generating an alarm. Consequently, this invention can quickly and accurately identify fault types and select the optimal recovery strategy, effectively improving the maintainability and safety of the bus module system.

[0057] Based on the above embodiment: See Figure 2 , Figure 2 This application provides a flow chart for real-time monitoring of the communication status of a bus module and acquiring and identifying abnormal detection signals based on a preset abnormal pattern library.

[0058] As a preferred embodiment, real-time monitoring of the communication status of the bus module and obtaining and identifying abnormal detection signals based on a preset abnormal pattern library include: S11, continuously monitoring the communication data frames on the bus and collecting data from the bus module; Specifically, in this embodiment, when data is transmitted on the bus, the system triggers an interrupt or updates the polling state. The capture logic records the state information of the data frame, and the captured raw data frame is stored in the memory buffer, thereby realizing the collection of bus module communication data.

[0059] Specifically, in this embodiment, the system adds a high-precision timestamp to each captured data frame to facilitate subsequent accurate key state feature extraction.

[0060] S12, processing the collected data stream in real time to extract key state features; Specifically, in this embodiment, the system analyzes the content of the data frame according to the bus protocol specification, and extracts structured information from the original data frame, such as frame ID, data length, specific data field values, error flags, etc.

[0061] Furthermore, based on the parsed structured data, a feature calculation engine is started. The feature calculation engine is used to calculate in real time the key state features reflecting the communication state. Among them, the key state features include data transmission rate, packet format, signal strength, etc.

[0062] Therefore, this application converts the original data frame into key state features, reducing the complexity of subsequent processing and enabling the system to focus on the most relevant communication behavior metrics.

[0063] S13. Compare the extracted key state features with a preset abnormal pattern library; Specifically, in this embodiment, the abnormal pattern library is set to be quickly accessible, and each entry in the abnormal pattern library represents a known abnormal pattern.

[0064] Specifically, in this embodiment, the engine algorithm in the abnormal pattern library compares the extracted key state features with each pattern definition in the pattern library. The comparison items include condition check, threshold comparison, matching degree score, etc.

[0065] S14. If the matching degree of the key state features with the patterns in the abnormal pattern library exceeds the preset threshold, generate a unique abnormal detection signal.

[0066] Specifically, in this embodiment, after the comparison process ends, a matching degree result is obtained, and the system determines whether the matching degree result exceeds the preset threshold. When the matching degree exceeds the threshold, the system triggers the signal generation logic to generate a unique abnormal detection signal.

[0067] Please refer to Figure 3 , Figure 3 which is a flowchart for automatically diagnosing the fault type when an abnormal detection signal is recognized provided by this application.

[0068] As a preferred embodiment, when an abnormal detection signal is recognized, automatically diagnosing the fault type includes: S21. Receive the abnormal detection signal and parse the abnormal pattern type code of the abnormal detection signal; Specifically, in this embodiment, the abnormal detection signal has a standardized format for easy parsing. In the parsed signal content, there is an abnormal pattern type code field, and the abnormal pattern type code is used to identify the pattern that triggers the abnormal signal.

[0069] S22. According to the abnormal pattern type code, conduct a preliminary classification of the fault type; Specifically, in this embodiment, the system uses the "abnormal mode type code" parsed out as a keyword to search for corresponding entries in the diagnostic rule library. Based on the matching results, the system generates a preliminary list of candidate fault types.

[0070] For example, if the abnormal mode code is NODE_A_HARDWARE_FAULT_SUSPECTED, the rule library initially classifies it as "node hardware fault".

[0071] S23. Perform in-depth diagnosis on complex or ambiguous anomaly detection signals; Specifically, in this embodiment, after the initial classification, the system determines whether the anomaly detection signal requires more in-depth analysis.

[0072] Specifically, in this embodiment, complex or ambiguous anomaly detection signals include: 1) Multiple candidate fault types, that is, more than one possible fault type is generated after the initial classification. 2) The signal itself is ambiguous, that is, the abnormal mode type code itself indicates multiple potential causes. 3) Context information is required, that is, the fault type pointed to by the initial classification needs to be combined with specific communication status data to determine the specific cause.

[0073] Specifically, in this embodiment, the in-depth diagnosis rules include: 1) Perform time series analysis on the state change trend before and after the occurrence of the anomaly. 2) Behavior pattern analysis to judge the interaction behavior between the faulty node and other nodes. 3) Context association to judge whether there are other related anomaly signals occurring simultaneously, etc.

[0074] Specifically, for example, check the message sending record of node A to see if it stops sending after the error count increases to distinguish between "transmitter fault" and "receiver fault or bus interference".

[0075] S24. Determine the final fault type based on the results of the preliminary judgment and in-depth diagnosis.

[0076] Specifically, in this embodiment, based on the preliminary judgment and in-depth diagnosis, the system obtains a more accurate fault cause and status description, thereby confirming the final fault type.

[0077] Please refer to Figure 4 , Figure 4 which is a flowchart for dynamically selecting and combining the optimal recovery strategy from a predefined recovery strategy library according to the diagnosed fault type provided by this application.

[0078] As a preferred embodiment, dynamically selecting and combining the optimal recovery strategy from a predefined recovery strategy library according to the diagnosed fault type includes: S31. Query the predefined recovery policy library according to the diagnosed fault type; Specifically, in this embodiment, the system uses the diagnosed fault type as a query condition for matching in the predefined recovery policy library.

[0079] S32. Retrieve the available policies associated with the fault type from the recovery policy library to form a policy list; Specifically, in this embodiment, the system performs a query operation to find the matching recovery policies and forms a policy list for subsequent weight evaluation and selection. Among them, the policy list contains information such as the identifier, description, and execution steps of the policy.

[0080] S33. Obtain the weight value of each policy in the policy list and select the optimal recovery policy based on the weight value, including: Select a single policy with the highest weight; Or, dynamically combine multiple policies according to the current system state to form an optimal recovery policy.

[0081] Specifically, in this embodiment, for each policy in the policy list, the system obtains the corresponding weight value. Among them, the weight value represents a comprehensive consideration of the policy's priority, success rate, and execution time metrics.

[0082] Specifically, the system sorts the policies in the policy list according to the preset weight evaluation criteria. According to the weight evaluation results, the system selects the optimal recovery policy. Among them, the optimal recovery policy is a single policy with the highest weight or a composite policy formed by dynamically combining multiple policies according to the current system state.

[0083] Please refer to Figure 5 , Figure 5 which is a flowchart for performing the self - recovery operation corresponding to the recovery policy provided by this application and verifying the recovery effect.

[0084] As a preferred embodiment, performing the self - recovery operation corresponding to the recovery policy and verifying the recovery effect includes: S41. Monitor the communication status of the bus module again and check whether the anomaly detection signal has disappeared; Specifically, in this embodiment, after the recovery policy is executed, the system evaluates whether the executed recovery policy is effective. The system continuously listens to the communication data frames on the bus and performs real - time processing and analysis on the bus communication data after the recovery operation.

[0085] Specifically, the system compares the currently monitored communication status of the bus module with the status before the recovery operation. If the anomaly detection signal is no longer detected, it is determined that the anomaly detection signal has disappeared.

[0086] S42. If the anomaly detection signal disappears, send a function request signal to the faulty bus module.

[0087] S43. Check whether the faulty bus module can correctly respond to the function request signal.

[0088] S44. Verify the response data of the faulty bus module.

[0089] S45. Determine whether the recovery operation is successful according to the verification result.

[0090] Specifically, in this embodiment, after determining that the anomaly detection signal disappears, the system further determines whether the faulty bus module has restored normal communication functions. It can be understood that the disappearance of the anomaly signal only indicates that the communication layer may have been restored, but does not fully guarantee the normal operation of the module. Therefore, this application further initiates a functional interaction with the faulty bus module to verify the communication response ability of the faulty bus module, so as to obtain a more accurate recovery verification effect.

[0091] Please refer to Figure 6 , Figure 6 , which is a flowchart of forming an optimal recovery strategy by dynamically combining multiple strategies according to the current system state provided by this application.

[0092] As a preferred embodiment, dynamically combining multiple strategies according to the current system state to form an optimal recovery strategy includes: S331. Obtain the real-time status information of the current system; Specifically, in this embodiment, the real-time status information of the current system includes the status of the faulty object, the status of system resources, the status of related services, historical fault information, system configuration parameters, etc., which are not specifically limited herein.

[0093] Specifically, for example, assume that the system diagnoses a fault of "main I / O bus bandwidth saturation". When obtaining the real-time status information of the current system, it includes: calling the management API of the I / O bus to obtain the current bandwidth utilization rate, queue length, number of error packets, average CPU load, memory utilization rate, database service status, system configuration, recent logs, etc.

[0094] S332. Evaluate the utility values of different strategy combinations in the strategy list according to the real-time status information and preset rules; Specifically, in this embodiment, according to the diagnosed fault type, the system finds all available recovery strategies from the recovery strategy library. Among them, for the fault of main I / O bus bandwidth saturation, the formed strategy list includes restricting non-critical I / O requests, enabling the bus power-saving mode, migrating part of the load to the standby bus, triggering a bus hardware reset, and increasing the system cache.

[0095] Specifically, for each candidate recovery strategy, the system calculates a utility value based on real-time status information and preset rules. In this embodiment, the utility value is a quantitative indicator representing the benefit degree of executing the recovery strategy under a specific state. It can be understood that the utility value can be a numerical value from 0 to 100, or a ranking of high, medium, or low, which is not specifically limited herein.

[0096] Specifically, for example, the 4 candidate strategies for the failure of the main I / O bus bandwidth saturation are as follows: Strategy A: Limit non-critical I / O requests; Strategy B: Enable the bus power-saving mode; Strategy C: Migrate part of the load to the standby bus; Strategy D: Trigger the bus hardware reset; Strategy E: Increase the system cache.

[0097] The preset rules for this type of failure are set as: Rule 1: Give priority to ensuring the performance of core services, and consider the impact on the throughput and response time of critical services; Rule 2: Minimize the interruption risk, and consider the risk of service interruption measures; Rule 3: Rationality of resource consumption. The strategy combination should not excessively consume other resources such as CPU and memory; Rule 4: Consideration of the recovery speed. The strategy combination that can relieve the bandwidth saturation faster should obtain a higher score; Rule 5: Predictability. The combination with stable and predictable strategy effects scores higher.

[0098] Specifically, taking the combination of Strategy A + Strategy E as an example: Rule 1: Limiting non-critical I / O can directly relieve the pressure on core services (+ high score); Increasing the cache may improve the hit rate of core service reads (+ medium score); Rule 2: No interruption risk (+ high score); Rule 3: Strategy E consumes memory, and the current memory occupancy is already relatively high (- medium score); Rule 4: It takes time for the effect to appear, and the recovery speed is medium (+ medium score); Rule 5: The effect is relatively stable and predictable (+ medium score); Utility value calculation: High + High + (- Medium) + Medium + Medium = Very High (such as 90 points), and so on. The system calculates the utility values of each strategy combination according to the above preset rules.

[0099] S333. Obtain the status requirements of the current system, and select a strategy combination that matches them according to the status requirements and utility values; Specifically, in this embodiment, the state requirement of the system refers to the current target state of the system. For example, the system learns from the configuration that the current state requirement is "performance first". The system further evaluates the impact of each policy on performance, and combines the "performance first" requirement and the utility value to select the policy combination that best matches performance first.

[0100] S334. Mark the policy combination as the optimal recovery policy to be executed in this self-recovery operation.

[0101] Specifically, in this embodiment, the system updates an identifier pointing to the currently pending recovery policy to point to the optimal policy combination, encapsulates the selected policy combination into an executable task unit or instruction sequence, and loads relevant system resources to execute.

[0102] As a preferred embodiment, the communication data frame includes a data ID, data content, timestamp, frame length, and error flag.

[0103] Please refer to Figure 7 , this embodiment of the present invention provides a bus module self-recovery device, which includes: Abnormality recognition module 1, which is used to monitor the communication status of the bus module in real time, and obtain and identify abnormal detection signals based on a preset abnormal mode library; Automatic diagnosis module 2, which is used to automatically diagnose the fault type when an abnormal detection signal is recognized; Recovery control module 3, which is used to dynamically select and combine the optimal recovery policy from a predefined recovery policy library according to the diagnosed fault type; where the recovery policy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery policy; Execution verification module 4, which is used to execute the self-recovery operation corresponding to the recovery policy and verify the recovery effect; Automatic adjustment module 5, which is used to automatically adjust and execute the next-priority recovery policy according to the fault type and the number of failures if the recovery fails; Isolation module 6, which isolates the communication between the faulty bus module and other normal modules through a bus arbitration mechanism during the self-recovery process; Storage and recording module 7, which is used to record the fault characteristics and the recovery process, and generate historical data for subsequent fault prediction; Trigger control module 8, which is used to trigger the system-level security protection mechanism and issue an alarm if the recovery fails multiple times.

[0104] In addition, a bus module self-recovery method according to an embodiment of the present invention described in Figure 1 can be implemented by a network bus module self-recovery device. Figure 7 shows a schematic hardware structure diagram of a bus module self-recovery device provided by an embodiment of the present invention.

[0105] The bus module self-recovery device may include a processor 401 and a memory 402 storing computer program instructions.

[0106] Specifically, the processor 401 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention.

[0107] The memory 402 may include a mass memory for data or instructions. By way of example and not limitation, the memory 402 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. In a suitable case, the memory 402 may include removable or non-removable (or fixed) media. In a suitable case, the memory 402 may be internal or external to the data processing device. In a specific embodiment, the memory 402 is a non-volatile solid state memory. In a specific embodiment, the memory 402 includes a read-only memory (ROM). In a suitable case, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or a flash memory, or a combination of two or more of these.

[0108] The processor 401 reads and executes the computer program instructions stored in the memory 402 to implement any one of the bus module self-recovery methods in the above embodiments.

[0109] In one example, the bus module self-recovery device may further include a communication interface 403 and a bus 410. Among them, as Figure 8 shown, the processor 401, the memory 402, and the communication interface 403 are connected through the bus 410 and complete communication with each other.

[0110] The communication interface 403 is mainly used to implement communication between the various modules, devices, units, and / or devices in the embodiments of the present invention.

[0111] The bus 410 includes hardware, software, or both, and couples the components of the bus module self - recovery device to each other. By way of example and not limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front - Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI - Express (PCI - X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses or a combination of two or more of these. Where appropriate, the bus 410 may include one or more buses. Although embodiments of the present invention describe and illustrate specific buses, the present invention contemplates any suitable bus or interconnect.

[0112] In addition, in combination with a bus module self - recovery method in the above - mentioned embodiments, embodiments of the present invention can be implemented by providing a computer - readable storage medium. Computer program instructions are stored on the computer - readable storage medium; when the computer program instructions are executed by a processor, any one of the bus module self - recovery methods in the above - mentioned embodiments is implemented.

[0113] It should also be noted that the exemplary embodiments mentioned in the present invention describe some methods or systems based on a series of steps or devices. However, the present invention is not limited to the order of the above - mentioned steps. That is, the steps can be executed in the order mentioned in the embodiments, can be different from the order in the embodiments, or several steps can be executed simultaneously.

[0114] The above is only the specific implementation manner of the present invention. Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be repeated here. It should be understood that the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of various equivalent modifications or substitutions, and these modifications or substitutions should all be covered within the protection scope of the present invention.

Claims

1. A bus module self - recovery method, characterized in that, The described self - recovery method for a bus module includes: Real - time monitor the communication status of the bus module, obtain and identify an anomaly detection signal based on a preset anomaly pattern library; When the anomaly detection signal is identified, automatically diagnose the fault type; According to the diagnosed fault type, dynamically select and combine the optimal recovery strategy from a predefined recovery strategy library; wherein, the recovery strategy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery strategy; Execute the self - recovery operation corresponding to the recovery strategy and verify the recovery effect; If the recovery fails, automatically adjust and execute the next - priority recovery strategy according to the fault type and the number of failures; During the self - recovery process, isolate the communication between the faulty bus module and other normal modules through a bus arbitration mechanism; Record the fault characteristics and the recovery process to generate historical data for subsequent fault prediction; If the recovery fails multiple times, trigger the system - level security protection mechanism and issue an alarm.

2. The self - recovery method of a bus module according to claim 1, wherein, The real - time monitor the communication status of the bus module, obtain and identify an anomaly detection signal based on a preset anomaly pattern library includes: Continuously listen to the communication data frames on the bus and collect data for the bus module; Perform real - time processing on the collected data stream and extract key status features; Compare the extracted key status features with the preset anomaly pattern library; If the matching degree between the key status features and the patterns in the anomaly pattern library exceeds a preset threshold, generate a unique anomaly detection signal.

3. A self-recovery method for a bus module according to claim 2, characterized in that, The when the anomaly detection signal is identified, automatically diagnose the fault type includes: Receive the anomaly detection signal and parse the anomaly pattern type code of the anomaly detection signal; Based on the anomaly pattern type code, conduct a preliminary classification of the fault type; For complex or ambiguous anomaly detection signals, conduct in - depth diagnosis; Based on the results of the preliminary judgment and in - depth diagnosis, determine the final fault type.

4. A self-recovery method for a bus module according to claim 1, characterized in that, The according to the diagnosed fault type, dynamically select and combine the optimal recovery strategy from a predefined recovery strategy library includes: According to the diagnosed fault type, query the predefined recovery strategy library; Retrieve the available strategies associated with the fault type from the recovery strategy library to form a strategy list; Obtain the weight value of each strategy in the strategy list and select the optimal recovery strategy based on the weight value, including: Select the single strategy with the highest weight; Or, dynamically combine multiple strategies according to the current system state to form the optimal recovery strategy.

5. A self-recovery method for a bus module according to claim 1, characterized in that The execute the self - recovery operation corresponding to the recovery strategy and verify the recovery effect includes: Monitor the communication status of the bus module again and check whether the anomaly detection signal disappears; If the anomaly detection signal disappears, send a function request signal to the faulty bus module; Check whether the faulty bus module can correctly respond to the function request signal; Verify the response data of the faulty bus module; According to the verification result, judge whether the recovery operation is successful.

6. A self-recovery method for a bus module according to claim 4, characterized in that The according to the current system state dynamically combine multiple strategies to form the optimal recovery strategy includes: Obtain the real - time state information of the current system; Evaluate the utility values of different policy combinations in the policy list according to the real-time status information and preset rules; Obtain the status requirements of the current system, and select a matching policy combination according to the status requirements and the utility values; Mark the policy combination as the optimal recovery policy to be executed in this self-recovery operation.

7. A self-recovery method for a bus module according to claim 2, characterized in that, The communication data frame includes a data ID, data content, timestamp, frame length, and error flag.

8. A bus module self-recovery device, characterized in that, The device includes: An anomaly recognition module for real-time monitoring of the communication status of the bus module and obtaining and recognizing anomaly detection signals based on a preset anomaly pattern library; An automatic diagnosis module for automatically diagnosing the fault type when the anomaly detection signal is recognized; A recovery control module for dynamically selecting and combining the optimal recovery policy from a predefined recovery policy library according to the diagnosed fault type; wherein, the recovery policy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery policy; An execution verification module for executing the self-recovery operation corresponding to the recovery policy and verifying the recovery effect; An automatic adjustment module for automatically adjusting and executing the next-priority recovery policy according to the fault type and the number of failure times if the recovery fails; An isolation module for isolating the communication between the faulty bus module and other normal modules through a bus arbitration mechanism during the self-recovery process; A storage recording module for recording the fault characteristics and the recovery process to generate historical data for subsequent fault prediction; A trigger control module for triggering a system-level security protection mechanism and issuing an alarm if the recovery fails multiple times.

9. A bus module self-recovery device, characterized in that, Includes: At least one processor, at least one memory, and computer program instructions stored in the memory, which implement the method according to any one of claims 1-7 when the computer program instructions are executed by the processor.

10. A storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, the method according to any one of claims 1-7 is implemented.

Images