A bus module self-recovery method, device, equipment and storage medium

Abstract

The present invention discloses 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 and identifies abnormal detection signals; when an abnormal detection signal is identified, the fault type is automatically diagnosed; the optimal recovery strategy is dynamically selected and combined according to the fault type; the self-recovery operation corresponding to the recovery strategy is executed, and the recovery effect is verified; if the recovery fails, the next priority recovery strategy is automatically adjusted and executed according to the fault type and the number of failures; the communication of the faulty bus module with other normal modules is isolated through a bus arbitration mechanism; the fault characteristics and recovery process are recorded, and historical data is generated for subsequent fault prediction; if the recovery fails multiple times, the system-level safety protection mechanism is triggered and an alarm is issued. The present invention can quickly and accurately identify the fault type and select the optimal recovery strategy in a targeted manner, effectively improving the system maintainability and safety of the bus module system.

Description

Technical Field

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

[0002] A bus module is a type of industrial connector used for power or data diversion, capable of outputting multiple current or data signals. Bus modules connect PLC controllers with peripheral devices, sensors, actuators, and other control objects, ensuring real-time data transmission and stable system operation. However, during actual operation, bus modules may experience communication anomalies or complete failure due to various reasons, including hardware aging, environmental interference, software errors, power supply fluctuations, connection issues, and conflicts with other modules.

[0003] Traditional bus fault handling methods typically rely on manual intervention or simple preset restart mechanisms. Manual intervention is slow to respond and difficult to adapt to the needs of large-scale, highly concurrent systems. It often takes a long time to locate the problem and implement remediation measures after a fault occurs. During this time, the system may have suffered significant performance loss or service interruption.

[0004] Existing fault detection and recovery mechanisms suffer from the following shortcomings: 1) The accuracy and real-time nature of fault detection require improvement, making false positives and missed detections more likely; 2) Recovery strategies are relatively fixed, lacking the ability to dynamically combine and optimize them based on specific fault scenarios; and 3) During the recovery process, effectively isolating the faulty module to prevent it from impacting the communication of other functioning modules is often overlooked. Therefore, reliably and efficiently implementing bus module self-recovery has become a pressing challenge for those skilled in the field. Summary of the Invention

[0005] In view of the above drawbacks, embodiments of the present invention provide a bus module self-recovery method, apparatus, device and storage medium to solve the problems existing in the prior art.

[0006] To solve the above technical problems, an embodiment of the present invention provides a bus module self-recovery method, the method comprising:

[0007] Monitor the communication status of the bus module in real time, and obtain and identify abnormal detection signals based on the preset abnormal pattern library;

[0008] When the abnormal detection signal is identified, the fault type is automatically diagnosed;

[0009] Dynamically selecting and combining the optimal recovery strategy from a predefined recovery strategy library based on the diagnosed fault type; wherein the recovery strategy library is a data structure for storing a mapping relationship between each fault type and the corresponding recovery strategy;

[0010] Execute the self-recovery operation corresponding to the recovery strategy and verify the recovery effect;

[0011] If recovery fails, automatically adjust and execute the next priority recovery strategy based on the fault type and number of failures;

[0012] During the self-recovery process, the bus arbitration mechanism is used to isolate the communication between the faulty bus module and other normal modules;

[0013] Record fault characteristics and recovery processes, and generate historical data for subsequent fault prediction;

[0014] If recovery fails multiple times, the system-level security protection mechanism will be triggered and an alarm will be issued.

[0015] Preferably, the real-time monitoring of the communication status of the bus module and acquiring and identifying abnormal detection signals based on a preset abnormal pattern library include:

[0016] Continuously monitoring the communication data frames on the bus and collecting data from the bus module;

[0017] Process the collected data stream in real time to extract key state features;

[0018] Comparing the extracted key state features with the preset abnormal pattern library;

[0019] If the degree of matching between the key state feature and the pattern in the abnormal pattern library exceeds a preset threshold, a unique abnormality detection signal is generated.

[0020] Preferably, when the abnormal detection signal is identified, automatically diagnosing the fault type includes:

[0021] receiving the abnormality detection signal, and parsing an abnormality mode type code of the abnormality detection signal;

[0022] Perform preliminary fault type classification based on the abnormal mode type code;

[0023] Perform in-depth diagnosis on complex or ambiguous abnormal detection signals;

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

[0025] Preferably, dynamically selecting and combining the optimal recovery strategy from a predefined recovery strategy library based on the diagnosed fault type includes:

[0026] According to the diagnosed fault type, query the predefined recovery strategy library;

[0027] Retrieving available strategies associated with the fault type from the recovery strategy library to form a strategy list;

[0028] Obtaining a weight value for each strategy in the strategy list and selecting an optimal recovery strategy based on the weight value includes:

[0029] Select the single strategy with the highest weight;

[0030] Alternatively, multiple strategies are dynamically combined according to the current system state to form the optimal recovery strategy.

[0031] Preferably, executing the self-recovery operation corresponding to the recovery strategy and verifying the recovery effect includes:

[0032] monitoring the communication status of the bus module again to check whether the abnormality detection signal disappears;

[0033] If the abnormality detection signal disappears, sending a function request signal to the faulty bus module;

[0034] Checking whether the faulty bus module can correctly respond to the function request signal;

[0035] verifying the response data of the faulty bus module;

[0036] Based on the verification results, determine whether the recovery operation is successful.

[0037] Preferably, the dynamically combining multiple strategies according to the current system state to form the optimal recovery strategy includes:

[0038] Get real-time status information of the current system;

[0039] Evaluate the utility values ​​of different strategy combinations in the strategy list based on the real-time status information and preset rules;

[0040] Obtaining the state requirements of the current system, and selecting a matching strategy combination based on the state requirements and the utility value;

[0041] The strategy combination is marked as the optimal recovery strategy to be executed in this self-recovery operation.

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

[0043] To solve the above technical problems, an embodiment of the present invention provides a bus module self-recovery device, the device comprising:

[0044] The abnormality identification module is used to monitor the communication status of the bus module in real time and obtain and identify abnormal detection signals based on the preset abnormal pattern library;

[0045] An automatic diagnosis module, configured to automatically diagnose a fault type when the abnormal detection signal is identified;

[0046] A recovery control module, configured to dynamically select and combine an optimal recovery strategy from a predefined recovery strategy library based on the diagnosed fault type; wherein the recovery strategy library is a data structure for storing a mapping relationship between each fault type and a corresponding recovery strategy;

[0047] An execution verification module is used to execute the self-recovery operation corresponding to the recovery strategy and verify the recovery effect;

[0048] Automatic adjustment module, used to automatically adjust and execute the next priority recovery strategy based on the fault type and number of failures if recovery fails;

[0049] Isolation module, during the self-recovery process, isolates the communication between the faulty bus module and other normal modules through the bus arbitration mechanism;

[0050] Storage and recording module, used to record fault characteristics and recovery process, and generate historical data for subsequent fault prediction;

[0051] The trigger control module is used to trigger the system-level safety protection mechanism and issue an alarm if multiple recovery failures occur.

[0052] 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.

[0053] 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.

[0054] 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

[0055] 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.

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

[0057] Figure 2 The present invention is a flowchart of an embodiment of the present invention for monitoring the communication status of a bus module in real time and acquiring and identifying abnormal detection signals based on a preset abnormal pattern library.

[0058] Figure 3 This is a flow chart of an embodiment of the present invention for automatically diagnosing a fault type when an abnormal detection signal is identified.

[0059] Figure 4 This is a flowchart of an embodiment of the present invention for dynamically selecting and combining optimal recovery strategies from a predefined recovery strategy library based on a diagnosed fault type.

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

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

[0062] Figure 7 It is a structural diagram of a bus module self-recovery device according to an embodiment of the present invention.

[0063] Figure 8 It is a structural diagram of a bus module self-recovery device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0064] The features and exemplary embodiments of various aspects of the present invention will be described in detail below. In order to make the objects, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below in conjunction with the accompanying drawings and Examples. 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 the need for some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present invention by illustrating examples of the present invention.

[0065] It should be noted that, in this document, relational terms such as first and second, etc., are used only 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 "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0066] See Figure 1 , Figure 1 The present invention provides a bus module self-recovery method, which includes the following steps:

[0067] S1. Real-time monitoring of the communication status of the bus module, and acquisition and identification of abnormal detection signals based on a preset abnormal pattern library;

[0068] Specifically, in this embodiment, the bus module includes one of a distributed bus module, a card-type bus module, or an integrated bus module, which is not specifically limited herein.

[0069] Specifically, in this embodiment, the communication status of the bus module refers to the real-time performance of the bus module during the communication process, including parameters such as data transmission rate, data packet format, signal strength, error count, response time, timeout, bus occupancy, etc., which are not specifically limited here.

[0070] Specifically, the abnormal pattern library is configured as a data storage structure, which includes predefined characteristic patterns representing abnormal behaviors of the bus module. The characteristic patterns are established based on historical fault data, theoretical analysis, or machine models, which are not specifically limited here.

[0071] Specifically, in this embodiment, when the communication state of the bus module matches a pattern in the abnormal pattern library, the system generates an abnormality detection signal, indicating that the communication state of the bus module is abnormal.

[0072] For example, the exception pattern library defines "Node A's error counter increases from 0 to over 100 within 10 seconds" as an exception pattern. This exception pattern indicates a hardware failure or bus interference at Node A. The system calculates the rate of change of Node A's error counter in real time. If it detects that the error counter reaches 120 within 10 seconds, the system generates an exception detection signal named "NODE_A_HARDWARE_FAULT_SUSPECTED" based on the matching rules in the exception pattern library.

[0073] S2. When an abnormal detection signal is identified, the fault type is automatically diagnosed;

[0074] Specifically, in this embodiment, the system applies predefined diagnostic rules to map abnormal detection signals to specific fault types, thereby achieving automated diagnosis of fault types.

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

[0076] Furthermore, the system checks the message transmission record of node A and finds that the transmission has indeed stopped after the error counter has increased. Therefore, the system automatically diagnoses it as "node A transmitter failure".

[0077] Therefore, the present application can automatically detect fault types, avoiding the time-consuming and uncertainties of manual troubleshooting.

[0078] S3. Dynamically select and combine the optimal recovery strategy from a predefined recovery strategy library based on the diagnosed fault type; wherein the recovery strategy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery strategy;

[0079] Specifically, the predefined recovery strategy library is a data structure for storing different recovery methods and corresponding operation steps for various known fault types.

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

[0081] Specifically, in this embodiment, the system searches for a corresponding recovery strategy in the data structure of the recovery strategy library based on the determined fault type. It is worth noting that the optimal recovery strategy can be a single recovery strategy or a combination of strategies dynamically formed based on the current system state, which is not specifically limited here.

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

[0083] S4. Execute the self-recovery operation corresponding to the recovery strategy and verify the recovery effect;

[0084] Specifically, in this embodiment, the system performs specific recovery actions according to the selected recovery strategy.

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

[0086] S5. If recovery fails, automatically adjust and execute the next priority recovery strategy based on the fault type and number of failures;

[0087] Specifically, in this embodiment, if the self-recovery operation fails to restore the faulty bus module to a normal state, the system records the number of recovery failures using a failure counter. Furthermore, when the number of failed recovery attempts reaches a preset threshold, the system determines the next recovery strategy to try based on the priority order of the strategies in the recovery strategy library.

[0088] Specifically, for example, if verification fails after executing "Software Reset Node A," and the error counter remains high, indicating test communication failure, the system records the number of recovery failures for "Node A Transmitter Failure" as 1. Furthermore, based on the policy library and the number of failures, the system automatically selects "Disconnect and reconnect Node A's power supply" as the next-highest priority recovery strategy. The system performs this power operation and then performs verification again.

[0089] S6. During the self-recovery process, the communication between the faulty bus module and other normal modules is isolated through the bus arbitration mechanism;

[0090] Specifically, in this embodiment, during the self-recovery process, the system places the faulty node in a "bus-off" state, disconnecting the faulty bus module. At this point, the faulty bus module no longer participates in bus communications and does not affect the normal communication and data transmission of other nodes. Therefore, this application can prevent abnormal behaviors such as the faulty bus module continuously sending error frames or occupying the bus for extended periods after a bus contention failure, which could affect the stable operation of the entire bus.

[0091] S7. Record fault characteristics and recovery process to generate historical data for subsequent fault prediction;

[0092] Specifically, in this embodiment, the fault characteristics include the fault itself and key information of the system status when the fault occurs, including fault type, occurrence time, duration, related abnormal detection signals, communication status parameters, module identification and other information, which are not specifically limited here.

[0093] Specifically, the system stores the above-mentioned fault characteristics and recovery process information in a structured manner to form data records that can be used for subsequent analysis and query.

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

[0095] Specifically, for example:

[0096] System log: [timestamp] Abnormal signal detected: NODE_A_HARDWARE_FAULT_SUSPECTED. Error counter incremented from 0 to 120 in 10 seconds.

[0097] System record: [timestamp] Diagnosed as: Node A transmitter failure.

[0098] System record: [timestamp] Recovery strategy attempted: Software reset of node A. Result: Failed. Number of failures: 1.

[0099] System log: [timestamp] Recovery strategy attempted: Disconnect and reconnect power to node A. Result: Success. Recovery time: 15 seconds.

[0100] These records are stored in a database table containing fields such as fault ID, occurrence time, module ID, fault type, anomaly characteristics, attempted strategy 1, strategy 1 results, attempted strategy 2, and strategy 2 results. Machine learning analysis of these historical records revealed that "node A transmitter failure" always occurs under specific conditions, such as high temperature and specific loads. This prediction allows for the likelihood of recurrence under similar conditions, enabling preventive measures to be taken before the failure actually impacts the system, preventing further damage.

[0101] S8. If recovery fails multiple times, the system-level security protection mechanism is triggered and an alarm is issued.

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

[0103] 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.

[0104] Based on the above embodiment:

[0105] See Figure 2 , Figure 2 The present 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.

[0106] 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:

[0107] S11, continuously monitoring the communication data frames on the bus and collecting data from the bus module;

[0108] 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.

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

[0110] S12, processing the collected data stream in real time to extract key state features;

[0111] Specifically, in this embodiment, the system parses 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 value, error flag, etc.

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

[0113] Therefore, the present application converts the original data frames into key status features, which reduces the complexity of subsequent processing and enables the system to focus on the most relevant communication behavior indicators.

[0114] S13, comparing the extracted key state features with a preset abnormal pattern library;

[0115] Specifically, in this embodiment, the abnormal pattern library is configured to be quickly accessed, and each entry in the abnormal pattern library represents a known abnormal pattern.

[0116] 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 checking, threshold comparison, matching score, etc.

[0117] S14. If the matching degree between the key state feature and the pattern in the abnormal pattern library exceeds a preset threshold, a unique abnormality detection signal is generated.

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

[0119] See Figure 3 , Figure 3 This application provides a flowchart for automatically diagnosing the fault type when an abnormal detection signal is identified.

[0120] As a preferred embodiment, when an abnormal detection signal is identified, automatically diagnosing the fault type includes:

[0121] S21. Receive an abnormality detection signal and analyze an abnormality pattern type code of the abnormality detection signal;

[0122] Specifically, in this embodiment, the abnormality detection signal has a standardized format for easy parsing. In the parsed signal content, there is an abnormality mode type code field, and the abnormality mode type code is used to identify the mode that triggers the abnormality signal.

[0123] S22. Perform preliminary fault type classification based on the abnormal mode type code;

[0124] Specifically, in this embodiment, the system uses the parsed "abnormal pattern type code" as a keyword to search for corresponding entries in the diagnosis rule library. Based on the matching results, the system generates a preliminary list of candidate fault types.

[0125] For example, if the exception mode code is NODE_A_HARDWARE_FAULT_SUSPECTED, the rule base preliminarily classifies it as "node hardware failure".

[0126] S23. Perform in-depth diagnosis on complex or ambiguous abnormal detection signals;

[0127] Specifically, in this embodiment, after preliminary classification, the system determines whether the abnormal detection signal requires more in-depth analysis.

[0128] Specifically, in this embodiment, complex or ambiguous anomaly detection signals include: 1) multiple candidate fault types, meaning the initial classification generates more than one possible fault type. 2) inherently ambiguous signals, meaning the anomaly pattern type code itself indicates multiple potential causes. 3) signals that require contextual information, meaning the fault type indicated by the initial classification requires specific communication status data to determine the specific cause.

[0129] Specifically, in this embodiment, deep diagnostic rules include: 1) time series analysis to identify state change trends before and after an anomaly occurs; 2) behavioral pattern analysis to determine the interaction between the faulty node and other nodes; and 3) contextual association to determine whether other related anomaly signals are occurring simultaneously.

[0130] Specifically, for example, the message sending record of node A is checked to see whether the sending stops after the error count increases, so as to distinguish "transmitter failure" from "receiver failure or bus interference".

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

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

[0133] See Figure 4 , Figure 4 This application provides a flowchart for dynamically selecting and combining the optimal recovery strategy from a predefined recovery strategy library based on the diagnosed fault type.

[0134] As a preferred embodiment, based on the diagnosed fault type, dynamically selecting and combining the optimal recovery strategy from a predefined recovery strategy library includes:

[0135] S31. Query a predefined recovery strategy library based on the diagnosed fault type;

[0136] Specifically, in this embodiment, the system uses the diagnosed fault type as a query condition for matching in a predefined recovery strategy library.

[0137] S32. Retrieve available strategies associated with the fault type from the recovery strategy library to form a strategy list;

[0138] Specifically, in this embodiment, the system performs a query operation to find matching recovery strategies and forms a strategy list for subsequent weight evaluation and selection, wherein the strategy list includes information such as the strategy identifier, description, and execution steps.

[0139] S33. Obtain the weight value of each strategy in the strategy list and select the optimal recovery strategy based on the weight value, including:

[0140] Select the single strategy with the highest weight;

[0141] Alternatively, multiple strategies can be dynamically combined based on the current system state to form the optimal recovery strategy.

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

[0143] Specifically, the system sorts the strategies in the strategy list according to a preset weight evaluation standard and selects the optimal recovery strategy based on the weight evaluation results. The optimal recovery strategy is the single strategy with the highest weight, or a composite strategy formed by dynamically combining multiple strategies based on the current system state.

[0144] See Figure 5 , Figure 5 This application provides a flowchart for executing self-recovery operations corresponding to the recovery strategy and verifying the recovery effect.

[0145] As a preferred embodiment, executing the self-recovery operation corresponding to the recovery strategy and verifying the recovery effect includes:

[0146] S41, monitor the communication status of the bus module again to check whether the abnormal detection signal disappears;

[0147] Specifically, in this embodiment, after the recovery strategy is executed, the system evaluates whether the executed recovery strategy is effective. The system continuously monitors the communication data frames on the bus and performs real-time processing and analysis on the bus communication data after the recovery operation is executed.

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

[0149] S42: If the abnormality detection signal disappears, a function request signal is sent to the faulty bus module.

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

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

[0152] S45. Determine whether the recovery operation is successful based on the verification result.

[0153] Specifically, in this embodiment, after determining that the abnormality detection signal disappears, the system further determines whether the faulty bus module has restored normal communication function. It is understandable that the disappearance of the abnormality signal only indicates that the communication layer may have recovered, but it does not fully guarantee that the module is functioning normally. Therefore, the present application further initiates functional interaction with the faulty bus module to verify the communication response capability of the faulty bus module, thereby achieving more accurate recovery verification results.

[0154] See Figure 6 , Figure 6 This application provides a flowchart for dynamically combining multiple strategies based on the current system status to form the optimal recovery strategy.

[0155] As a preferred embodiment, dynamically combining multiple strategies based on the current system state to form an optimal recovery strategy includes:

[0156] S331, obtain the real-time status information of the current system;

[0157] Specifically, in this embodiment, the real-time status information of the current system includes fault object status, system resource status, related service status, historical fault information, system configuration parameters, etc., which are not specifically limited here.

[0158] For example, suppose the system diagnoses a "main I / O bus bandwidth saturation" fault. Acquiring real-time system status information involves calling the I / O bus management API to obtain information such as current bandwidth usage, queue length, number of error packets, average CPU load, memory usage, database service status, system configuration, and recent logs.

[0159] S332. Evaluate the utility values ​​of different strategy combinations in the strategy list based on the real-time status information and preset rules;

[0160] Specifically, in this embodiment, based on the diagnosed fault type, the system searches a recovery policy library for all available recovery policies. For the primary I / O bus bandwidth saturation fault, the resulting policy list includes limiting non-critical I / O requests, enabling bus power-saving mode, migrating some load to a backup bus, triggering a bus hardware reset, and increasing system cache.

[0161] Specifically, for each candidate recovery strategy, the system calculates a utility value based on real-time status information and pre-set rules. In this embodiment, the utility value is a quantitative indicator that indicates the degree of benefit of executing the recovery strategy under specific conditions. It is understood that the utility value can be a numerical value between 0 and 100, or can be ranked as high, medium, or low, and is not specifically limited here.

[0162] Specifically, for example, the four candidate strategies for the fault of main I / O bus bandwidth saturation are:

[0163] Strategy A: Limit non-critical I / O requests;

[0164] Strategy B: Enable bus energy saving mode;

[0165] Strategy C: Migrate part of the load to the backup bus;

[0166] Strategy D: trigger bus hardware reset;

[0167] Strategy E: Increase system cache.

[0168] The default rules for this fault type are set to:

[0169] Rule 1: Prioritize core business performance, taking into account the impact on critical business throughput and response time;

[0170] Rule 2: To minimize the risk of interruption, the risk of service interruption measures must be considered;

[0171] Rule 3: Reasonable resource consumption. The strategy combination should not over-consume CPU, memory, and other resources.

[0172] Rule 4: Considering recovery speed, the strategy combination that can alleviate bandwidth saturation more quickly should receive a higher score;

[0173] Rule 5: Predictability. Strategies with stable and predictable performance receive higher scores.

[0174] Specifically, take the combination of Strategy A + Strategy E as an example:

[0175] Rule 1: Limiting non-critical I / O can directly reduce the pressure on core business (+ high score); increasing cache may improve the read hit rate of core business (+ medium score);

[0176] Rule 2: No risk of disruption (+high score);

[0177] Rule 3: Strategy E consumes memory, and the current memory usage is already high (-medium score);

[0178] Rule 4: It takes time for the effects to appear, and the recovery speed is medium (+ medium score);

[0179] Rule 5: The effect is relatively stable and predictable (+ medium score);

[0180] Utility value calculation: High + High + (-Medium) + Medium + Medium = Very High (e.g., 90 points), and so on. The system calculates the utility value of each strategy combination based on the above preset rules.

[0181] S333. Obtain the state requirements of the current system and select a matching strategy combination based on the state requirements and utility values;

[0182] Specifically, in this embodiment, the system state requirement refers to the system's current target state. For example, if the system knows from the configuration that the current state requirement is "performance-first," the system will further evaluate the performance impact of each policy and, based on the "performance-first" requirement and utility value, select the policy combination that best matches performance priority.

[0183] S334: Mark the strategy combination as the optimal recovery strategy to be executed in this self-recovery operation.

[0184] Specifically, in this embodiment, the system updates an identifier pointing to the current recovery strategy to be executed, points to the optimal recovery strategy combination, encapsulates the selected strategy combination into an executable task unit or instruction sequence, and loads related system resources for execution.

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

[0186] See also Figure 7 , an embodiment of the present invention provides a bus module self-recovery device, the device comprising:

[0187] Abnormal identification module 1, 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 pattern library;

[0188] Automatic diagnosis module 2, used for automatically diagnosing the fault type when an abnormal detection signal is identified;

[0189] Recovery control module 3, for dynamically selecting and combining the optimal recovery strategy from a predefined recovery strategy library based on the diagnosed fault type; wherein the recovery strategy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery strategy;

[0190] Execution verification module 4 is used to execute the self-recovery operation corresponding to the recovery strategy and verify the recovery effect;

[0191] Automatic adjustment module 5, used to automatically adjust and execute the next priority recovery strategy according to the fault type and number of failures if recovery fails;

[0192] Isolation module 6, during the self-recovery process, isolates the communication between the faulty bus module and other normal modules through the bus arbitration mechanism;

[0193] Storage and recording module 7, used to record fault characteristics and recovery process, and generate historical data for subsequent fault prediction;

[0194] The trigger control module 8 is used to trigger the system-level safety protection mechanism and issue an alarm if the recovery fails multiple times.

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

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

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

[0198] Memory 402 may include a large-capacity memory for data or instructions. By way of example, and not limitation, memory 402 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disk, a magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 402 may include removable or non-removable (or fixed) media. Where appropriate, memory 402 may be internal or external to the data processing device. In certain embodiments, memory 402 is non-volatile solid-state memory. In certain embodiments, memory 402 includes read-only memory (ROM). Where appropriate, the ROM may be mask-programmable ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

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

[0200] In one example, the bus module self-recovery device may further include a communication interface 403 and a bus 410. Figure 8 As shown, the processor 401 , the memory 402 , and the communication interface 403 are connected via a bus 410 and communicate with each other.

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

[0202] Bus 410 includes hardware, software, or both, coupling 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 Industrial Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industrial Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel 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, bus 410 may include one or more buses. Although the embodiments of the present invention describe and illustrate specific buses, the present invention contemplates any suitable bus or interconnect.

[0203] In addition, in conjunction with a bus module self-recovery method in the above embodiment, an embodiment of the present invention may provide a computer-readable storage medium for implementation. The computer-readable storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any of the bus module self-recovery methods in the above embodiment is implemented.

[0204] It should also be noted that the exemplary embodiments described herein describe methods or systems based on a series of steps or devices. However, the present invention is not limited to the order of the steps described above. In other words, the steps may be performed in the order described in the embodiments, or in a different order, or several steps may be performed simultaneously.

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

Claims

1. A bus module self-recovery method, characterized in that: The bus module self-recovery method comprises: Monitor the communication status of the bus module in real time, and obtain and identify abnormal detection signals based on the preset abnormal pattern library; When the abnormal detection signal is identified, the fault type is automatically diagnosed; Based on the diagnosed fault type, the optimal recovery strategy is dynamically selected and combined from a predefined recovery strategy library, including: According to the diagnosed fault type, query the predefined recovery strategy library; Retrieving available strategies associated with the fault type from the recovery strategy library to form a strategy list; Obtaining a weight value for each strategy in the strategy list and selecting an optimal recovery strategy based on the weight value includes: Select the single strategy with the highest weight; Alternatively, multiple strategies are dynamically combined according to the current system state to form the optimal recovery strategy; 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 recovery fails, automatically adjust and execute the next priority recovery strategy based on the fault type and number of failures; During the self-recovery process, the bus arbitration mechanism is used to isolate the communication between the faulty bus module and other normal modules; Record fault characteristics and recovery processes, and generate historical data for subsequent fault prediction; If recovery fails multiple times, the system-level security protection mechanism will be triggered and an alarm will be issued.

2. A bus module self-recovery method according to claim 1, characterized in that: The real-time monitoring of the communication status of the bus module and the acquisition and identification of abnormal detection signals based on a preset abnormal pattern library include: Continuously monitoring the communication data frames on the bus and collecting data from the bus module; Process the collected data stream in real time to extract key state features; Comparing the extracted key state features with the preset abnormal pattern library; If the degree of matching between the key state feature and the pattern in the abnormal pattern library exceeds a preset threshold, a unique abnormality detection signal is generated.

3. A bus module self-recovery method according to claim 2, characterized in that: When the abnormal detection signal is identified, automatically diagnosing the fault type includes: receiving the abnormality detection signal, and parsing an abnormality mode type code of the abnormality detection signal; Perform preliminary fault type classification based on the abnormal mode type code; Perform in-depth diagnosis on complex or ambiguous abnormal detection signals; Determine the final fault type based on the results of preliminary judgment and in-depth diagnosis.

4. A bus module self-recovery method according to claim 1, characterized in that: The executing the self-recovery operation corresponding to the recovery strategy and verifying the recovery effect includes: monitoring the communication status of the bus module again to check whether the abnormality detection signal disappears; If the abnormality detection signal disappears, sending a function request signal to the faulty bus module; Checking whether the faulty bus module can correctly respond to the function request signal; verifying the response data of the faulty bus module; Based on the verification results, determine whether the recovery operation is successful.

5. A bus module self-recovery method according to claim 4, characterized in that: The dynamically combining multiple strategies according to the current system state to form the optimal recovery strategy includes: Get real-time status information of the current system; Evaluate the utility values ​​of different strategy combinations in the strategy list based on the real-time status information and preset rules; Obtaining the state requirements of the current system, and selecting a matching strategy combination based on the state requirements and the utility value; The strategy combination is marked as the optimal recovery strategy to be executed in this self-recovery operation.

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

7. A bus module self-recovery device, characterized in that: The device comprises: The abnormality identification module is used to monitor the communication status of the bus module in real time and obtain and identify abnormal detection signals based on the preset abnormal pattern library; An automatic diagnosis module, configured to automatically diagnose a fault type when the abnormal detection signal is identified; The recovery control module is used to dynamically select and combine the optimal recovery strategy from a predefined recovery strategy library based on the diagnosed fault type, including: According to the diagnosed fault type, query the predefined recovery strategy library; Retrieving available strategies associated with the fault type from the recovery strategy library to form a strategy list; Obtaining a weight value for each strategy in the strategy list and selecting an optimal recovery strategy based on the weight value includes: Select the single strategy with the highest weight; Alternatively, multiple strategies are dynamically combined according to the current system state to form the optimal recovery strategy; wherein the recovery strategy library is a data structure for storing the mapping relationship between each fault type and the corresponding recovery strategy; An execution verification module is used to execute the self-recovery operation corresponding to the recovery strategy and verify the recovery effect; Automatic adjustment module, used to automatically adjust and execute the next priority recovery strategy based on the fault type and number of failures if recovery fails; Isolation module, during the self-recovery process, isolates the communication between the faulty bus module and other normal modules through the bus arbitration mechanism; Storage and recording module, used to record fault characteristics and recovery process, and generate historical data for subsequent fault prediction; The trigger control module is used to trigger the system-level safety protection mechanism and issue an alarm if multiple recovery failures occur.

8. A bus module self-recovery device, characterized in that: include: 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 to 6 when the computer program instructions are executed by the processor.

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

Images