Fault diagnosis and processing method, device and equipment for FSU equipment, storage medium and computer program product

Abstract

The invention relates to the technical field of fault detection, in particular to a fault diagnosis and processing method, device and equipment for FSU equipment, a storage medium and a computer program product. The method comprises the following steps: obtaining operation and maintenance data, log files and historical fault data of the FSU equipment; based on a preset large language model, performing fault analysis on the operation and maintenance data and the log file; generating a fault processing scheme based on the fault analysis result and the historical fault data; and based on the preset API, the fault processing scheme is sent to the FSU equipment, so that the fault diagnosis and processing efficiency of the FSU equipment is improved.

Description

Technical Field

[0001] The present application relates to the technical field of fault detection, and in particular to a method, apparatus, device, storage medium and computer program product for fault diagnosis and processing of FSU equipment. Background Art

[0002] With the rapid development of key infrastructure such as data centers and computer rooms, the complexity of their operating environment continues to increase, and maintaining the stability and reliability of these facilities has become an important task. In this process, FSU (Field Supervision Unit, power environment monitoring equipment) as the core component of the power and environment monitoring system undertakes important functions such as real-time monitoring, data collection and uploading. However, the fault problems in the operation of FSU equipment have gradually exposed the limitations of the traditional operation and maintenance model, which are mainly reflected in the following aspects: relying on manual experience to troubleshoot, complex faults are difficult to diagnose quickly, relying on the support of the R&D team, and low level of automation processing. As a result, there are still significant limitations when processing complex unstructured data (such as log files and natural language descriptions), and the efficiency of fault diagnosis and processing of FSU equipment is poor. Therefore, how to improve the efficiency of fault diagnosis and processing of FSU equipment has become a technical problem that needs to be solved urgently. Summary of the invention

[0003] The main purpose of the present application is to provide a method, apparatus, device, storage medium and computer program product for fault diagnosis and processing of FSU equipment, aiming to solve the technical problem of how to improve the fault diagnosis and processing efficiency of FSU equipment.

[0004] To achieve the above objectives, the present application provides a fault diagnosis and processing method for FSU equipment, the method comprising the following steps:

[0005] Obtaining operation and maintenance data, log files, and historical fault data of the FSU equipment;

[0006] Based on a preset large language model, performing fault analysis on the operation and maintenance data and the log file;

[0007] Generate a fault handling solution based on the fault analysis result and the historical fault data;

[0008] Based on a preset API, the fault handling solution is sent to the FSU device.

[0009] In one embodiment, before the step of obtaining the operation and maintenance data, log files, and historical fault data of the FSU device, the method further includes:

[0010] Based on a preset self-test cycle, sending a self-test instruction to the FSU device;

[0011] When the FSU device receives the self-check instruction, based on the self-check instruction, the device status data of the FSU device is obtained, wherein the device status data includes basic device information, system operation status, and module operation status;

[0012] Based on the preset large language model, comparing the device status data with a preset device parameter threshold;

[0013] Based on the comparison result, a device self-check report is generated, wherein the device self-check report includes module status information of the FSU device and faults to be processed.

[0014] In one embodiment, after the step of generating a device self-check report based on the comparison result, wherein the device self-check report includes the module status information of the FSU device and the fault to be processed, the step further includes:

[0015] Based on the preset large language model and the module status information, combined with a preset fault degree classification strategy, classify the fault to be processed;

[0016] If the fault to be processed is a minor fault, the preset API is called to automatically repair the fault;

[0017] If the fault to be processed is a serious fault, the FSU device is rolled back to the previous historical version based on the historical version information of the FSU device.

[0018] In one embodiment, after the step of sending the fault handling solution to the FSU device based on the preset API, the method further includes:

[0019] Obtaining the execution result of the FSU device;

[0020] Comparing the execution result with the fault handling solution;

[0021] Update the fault handling strategy based on the comparison results.

[0022] In one embodiment, the step of performing fault analysis on the operation and maintenance data and the log file based on a preset large language model includes:

[0023] Calling the preset large language model;

[0024] Preprocessing the operation and maintenance data and the log file to obtain preprocessed data, wherein the preprocessing includes one or more of formatting, data cleaning, and data normalization;

[0025] Based on the natural language processing technology of the preset large language model, keyword extraction, pattern recognition and time series analysis are performed on the preprocessed data.

[0026] In one embodiment, the step of generating a fault handling solution based on the fault analysis result and the historical fault data includes:

[0027] Based on the preset large language model, classify the fault analysis result;

[0028] comparing the operation and maintenance data with historical operation and maintenance data;

[0029] Determine the real cause of the fault based on the fault classification and comparison results;

[0030] Based on the real cause of the fault, semantic matching is performed in the historical fault data;

[0031] According to the semantic matching result, a corresponding fault handling solution is extracted from the historical fault data.

[0032] In addition, to achieve the above-mentioned purpose, the present application also proposes a fault diagnosis and processing device for FSU equipment, the fault diagnosis and processing device for FSU equipment comprising:

[0033] A data acquisition module, used to acquire operation and maintenance data, log files and historical fault data of the FSU equipment;

[0034] A fault analysis module, used for performing fault analysis on the operation and maintenance data and the log file based on a preset large language model;

[0035] A solution generation module, used to generate a fault handling solution based on the fault analysis result and the historical fault data;

[0036] The target module is used to send the fault handling solution to the FSU device based on a preset API.

[0037] In addition, to achieve the above-mentioned objectives, the present application also proposes a fault diagnosis and processing device for FSU equipment, the device comprising: a memory, a processor, and a fault diagnosis and processing program for FSU equipment stored in the memory and executable on the processor, the fault diagnosis and processing program for FSU equipment being configured to implement the steps of the fault diagnosis and processing method for FSU equipment as described above.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, on which a fault diagnosis and processing program for FSU equipment is stored. When the fault diagnosis and processing program for FSU equipment is executed by a processor, the steps of the fault diagnosis and processing method for FSU equipment described above are implemented.

[0039] In addition, to achieve the above objectives, the present application also proposes a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of the fault diagnosis and processing method for FSU equipment as described above are implemented.

[0040] This application obtains the operation and maintenance data, log files and historical fault data of the FSU equipment; performs fault analysis on the operation and maintenance data and log files based on a preset large language model; generates a fault handling plan based on the fault analysis results and historical fault data; and sends the fault handling plan to the FSU equipment based on a preset API. This application ensures the comprehensiveness of diagnostic information by integrating multi-source data (operation and maintenance data, log files, historical fault data), and uses the intelligent analysis capabilities of a large language model to parse unstructured data and quickly locate the root cause of the fault, thereby improving the accuracy and automation of diagnosis; combines real-time analysis results with historical fault data to automatically generate efficient and reliable fault handling plans, shortening the design time of the plan; automatically sends the handling plan to the FSU equipment through a preset API interface and executes it quickly, building a closed-loop process from diagnosis to processing, and improving the efficiency and accuracy of fault diagnosis and processing of FSU equipment. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a flow chart of the first embodiment of the fault diagnosis and processing method for FSU equipment of the present application;

[0042] Figure 2 This is a schematic diagram of a sub-flow in the second embodiment of the fault diagnosis and processing method for FSU equipment of the present application;

[0043] Figure 3 This is a schematic diagram of a sub-flow in the third embodiment of the fault diagnosis and processing method for FSU equipment of the present application;

[0044] Figure 4 This is a schematic diagram of the module structure of the fault diagnosis and processing device for FSU equipment in an embodiment of the present application;

[0045] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the fault diagnosis and processing method for FSU equipment in the embodiment of the present application.

[0046] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0047] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0049] It should be noted that with the rapid development of key infrastructure such as data centers and computer rooms, the complexity of their operating environment continues to increase, and maintaining the stability and reliability of these facilities has become an important task. In this process, FSU (Field Supervision Unit, power environment monitoring equipment) as the core component of the power and environment monitoring system undertakes important functions such as real-time monitoring, data collection and uploading. However, the fault problems in the operation of FSU equipment have gradually exposed the limitations of the traditional operation and maintenance model, which are mainly reflected in the following aspects: relying on manual experience to troubleshoot, complex faults are difficult to diagnose quickly, relying on the support of the R&D team, and low level of automation processing, resulting in significant limitations when processing complex unstructured data (such as log files and natural language descriptions), and the efficiency of FSU equipment fault diagnosis and processing is poor. Therefore, how to improve the efficiency of FSU equipment fault diagnosis and processing has become a technical problem that needs to be solved urgently.

[0050] The main solution of this application is: by obtaining the operation and maintenance data, log files and historical fault data of the FSU equipment; based on the preset large language model, performing fault analysis on the operation and maintenance data and log files; based on the fault analysis results and historical fault data, generating a fault handling plan; based on the preset API, sending the fault handling plan to the FSU equipment.

[0051] This application ensures the comprehensiveness of diagnostic information by integrating multi-source data (operation and maintenance data, log files, historical fault data), and uses the intelligent analysis capabilities of large language models to parse unstructured data and quickly locate the root cause of faults, thereby improving the accuracy and automation of diagnosis; combining real-time analysis results with historical fault data, it automatically generates efficient and reliable fault handling solutions, shortening the solution design time; through the preset API interface, the solution is automatically sent to the FSU device and quickly executed, building a closed-loop process from diagnosis to processing, and improving the efficiency and accuracy of fault diagnosis and processing of FSU equipment.

[0052] It should be noted that the execution subject of the method of this embodiment can be a computing service device with data processing, network communication and program running functions, or it can be the above-mentioned fault diagnosis and processing device for FSU equipment with the same or similar functions. This embodiment and the following embodiments will be described by taking the fault diagnosis and processing device for FSU equipment as an example.

[0053] Based on this, the first embodiment of the fault diagnosis and processing method of the present application for FSU equipment is proposed, please refer to Figure 1 , Figure 1This is a flow chart of the first embodiment of the fault diagnosis and processing method for FSU equipment of the present application.

[0054] In this embodiment, the method includes the following steps:

[0055] S1: Obtaining operation and maintenance data, log files, and historical fault data of the FSU device;

[0056] It should be noted that FSU (Field Supervision Unit, power environment monitoring equipment) is a key monitoring equipment used in data centers, computer rooms and other scenarios. Its main function is to collect, monitor and manage power and environmental parameters (such as temperature, humidity, power status, etc.) in real time. It is an important part of the entire power environment monitoring system. Operation and maintenance data refers to the core data generated during the operation and maintenance of the equipment, including equipment operation status (such as CPU load, memory usage, etc.), parameter configuration, alarm information, etc. These data are an important basis for analyzing the health status and operation efficiency of the equipment. The log file is the historical information recorded during the operation of the FSU equipment, which usually contains operation events, error codes, timestamps, module behavior records, etc., and is one of the key bases for troubleshooting equipment failures. Historical fault data refers to the fault-related information recorded by the FSU equipment during the past operation, including the equipment status when the fault occurred, the problem description, the fault type, the solutions taken and the processing results. These data provide an important reference for the analysis and treatment of current problems.

[0057] Specifically, the fault diagnosis and processing system for FSU equipment identifies the data sources that need to be obtained, including the real-time operating status of the FSU equipment, log files, and historical fault records. The system starts the data acquisition task through a preset periodic trigger mechanism or a diagnostic request initiated by the user. The current operation and maintenance data is obtained from the FSU device, including the real-time performance indicators of the equipment (such as load, memory usage, etc.) and status parameters (such as network connection status, module operation status, etc.). At the same time, by calling the log management module of the FSU device, the operation log file is extracted to ensure that the most recent fault events and operation records are included. Historical fault data is retrieved from the system database, covering records related to the current equipment or similar problems, to provide support for subsequent analysis.

[0058] Furthermore, after completing data collection, the acquired data is preprocessed to ensure the quality and structure of the data: Cleaning: remove redundant and invalid information (such as duplicate records, incomplete data, etc.) to improve data accuracy; Formatting: unify the format of log files and operation and maintenance data to ensure that data from different sources can be integrated and processed, such as converting unstructured log information into JSON or table format; Classified storage: store the processed data in the corresponding database table according to the data category (operation and maintenance data, log files, historical fault data) for subsequent fault analysis calls.

[0059] This step provides multi-level and multi-angle information support for fault diagnosis by integrating operation and maintenance data, log files, and historical fault data. Real-time operation and maintenance data reflects the current status of the equipment, log files record operating events and abnormal conditions in detail, and historical fault data provides valuable references for analyzing similar problems and generating solutions. This acquisition of multi-source data avoids the problem that a single data may lead to insufficient information or analysis bias. The data processing step converts the disorganized raw data into a structured and standardized form through cleaning, formatting, and classified storage. This not only improves the availability of data, but also significantly reduces the complexity of the subsequent fault analysis stage, laying a good data foundation for fault analysis of large language models. Overall, this step accelerates the entire process of fault diagnosis and improves efficiency and accuracy.

[0060] S2: performing fault analysis on the operation and maintenance data and the log file based on a preset large language model;

[0061] It should be noted that the large language model (LLM) is a large-scale natural language processing model based on deep learning technology, which can process and analyze complex unstructured data (such as text logs). In the present invention, the large language model has the ability to analyze the operating status of the equipment, identify fault modes, and generate diagnostic information by training equipment operation records, operation and maintenance documents, and historical fault data. Fault analysis refers to the process of locating the module or cause of the fault based on the collected data through pattern recognition, feature extraction, anomaly detection and other methods. In the present invention, fault analysis is driven by the large language model, which improves the diagnostic efficiency with its powerful understanding and reasoning capabilities.

[0062] Specifically, the operation and maintenance data is directly input into the model, maintaining its original parameter structure (such as performance indicators and status identification); natural language processing (NLP) is performed on the log files to convert text information into analyzable feature data, including extraction time, event type, error description, etc.; a preliminary analysis is conducted to determine whether there are abnormal features in the data (such as parameter exceeding the standard or high frequency of error codes) to provide a reference for subsequent in-depth analysis.

[0063] Furthermore, the model combines historical training data to extract possible abnormal events and their associated modules from the logs by identifying patterns of similar problems; uses the contextual understanding ability of the large language model to analyze the causal relationship of continuous events in the logs and infer the key nodes that may cause the current failure; the model preliminarily classifies the failure (such as hardware failure, network anomaly or configuration error) based on the characteristics of the log information and operation and maintenance data, and generates diagnostic results. Finally, the fault analysis report is output in a structured form, including potential causes of the failure, impact modules and recommended solutions.

[0064] Through the deep analysis capability of the large language model, this step can quickly process massive operation and maintenance data and complex log files, avoiding the time-consuming problem of manual analysis in traditional methods. The large language model's rapid matching and causal reasoning of abnormal patterns significantly improves the efficiency and accuracy of diagnosis, especially the positioning effect of complex cross-module problems. Traditional analysis methods usually rely on fixed rules, while the present invention realizes dynamic analysis through a preset large language model. The model can adapt to a variety of operating environments and fault types. Even for abnormal situations that are not clearly defined in the rules, the model can accurately identify them through semantic understanding and pattern analysis, greatly reducing the probability of misjudgment and missed judgment. Through intelligent analysis of log files and operation and maintenance data, the large language model realizes full automation from feature extraction to root cause reasoning in the fault analysis process. This not only reduces the dependence on the experience of operation and maintenance personnel, but also provides novices with efficient and reliable auxiliary tools, further improving the overall operation and maintenance efficiency.

[0065] S3: Generate a fault handling solution based on the fault analysis result and the historical fault data.

[0066] It should be noted that the fault analysis results refer to the diagnostic information generated in the previous step based on the operation and maintenance data and log files after being parsed by the large language model, including the fault type, root cause, impact range, etc., which is the basis for the design of subsequent processing solutions. Historical fault data refers to the fault records of FSU equipment in the past, including fault description, equipment operating status, processing measures taken and effects. These data provide empirical support and data reference for the generation of fault handling solutions. Fault handling solutions refer to a series of operating steps or solutions provided for the current fault, including direct repair measures (such as module restart), adjustment measures (such as parameter optimization) and preventive suggestions (such as increasing monitoring thresholds), aiming to restore equipment functions and reduce subsequent risks.

[0067] Specifically, the natural language processing capabilities of the large language model (LLM) are used to extract cases similar to the current fault mode from historical records. Matching parameters include fault type, module information, time pattern, related indicators, etc. The matched historical cases are screened, and solutions with high success rate and short implementation time are given priority as references. Effective treatment measures are extracted from the screened historical data, and key steps and precautions are marked to lay the foundation for solution generation.

[0068] Furthermore, historical processing solutions are adjusted according to the current operating status of the device (such as load, version information, etc.). For example: if the device load is high, avoid restarting and give priority to parameter adjustment solutions; automatically match applicable commands or API interfaces for device version differences. Generate multiple alternative solutions based on different goals (such as rapid recovery, thorough repair, and prevention of recurrence). For example: temporary solutions for rapid recovery (such as shutting down abnormal modules); complete solutions to fundamentally solve the problem (such as firmware upgrades or configuration corrections); solutions to reduce the possibility of recurrence of similar problems (such as increasing monitoring thresholds).

[0069] By combining the fault analysis results and historical fault data, the system can generate highly targeted processing solutions, avoiding the inefficient process of "trial and error" problem solving in traditional methods. Dynamic adjustment and optimization ensure the adaptability of the solution, and can quickly provide effective solutions even if the equipment environment changes. Relying on the intelligent capabilities of the large language model, the entire process from generation to optimization of the processing solution is automatically completed, reducing the time cost and cognitive burden of manual participation. Especially for complex or unknown faults, historical data and existing diagnostic information can be used to quickly generate efficient solution paths, greatly shortening the fault repair time. Through the multi-solution generation mechanism, not only a temporary solution for rapid recovery is provided, but also a long-term, fundamental solution and preventive measures can be proposed. This multi-level solution design effectively reduces the risk of recurrence of similar faults and improves the long-term stability and reliability of the system.

[0070] S4: Based on a preset API, the fault handling solution is sent to the FSU device.

[0071] It should be noted that API (Application Programming Interface) is a standardized interface for communication between systems and devices. The preset API refers to a pre-defined, function-specific calling interface for FSU devices, which supports the issuance and execution of control commands (such as module restart, parameter modification, etc.) to implement the automated processing solution.

[0072] Specifically, the processing scheme is parsed into executable operation instructions (such as device restart, parameter adjustment, module switching, etc.), and specific parameters required for execution (such as time, target module) are attached. According to the different operation steps in the scheme, the corresponding API interface is selected. For example: restarting the device calls the "Restart API"; configuration modification calls the "ConfigUpdateAPI"; the information required to call the API is encapsulated into a standardized request data packet to ensure the integrity and security of the transmission process.

[0073] Furthermore, the API request is passed to the control module of the device by interacting with the FSU device through HTTP, HTTPS or other communication protocols. After receiving the API request, the FSU device performs the corresponding processing operation according to the instruction. For example, restarting the abnormal module, rolling back to a stable version, optimizing device parameters, etc. After completing the instruction, the FSU device will feedback the execution result (such as success / failure status, execution time, etc.) to the fault diagnosis and processing system for the FSU device, providing a basis for subsequent closed-loop verification.

[0074] Through the preset API interface, the system can quickly and accurately send the generated fault handling solution to the target device, realizing the automation of the entire process of fault repair. This mechanism eliminates the delay of traditional manual command issuance, ensures that the solution can be executed in real time, and forms a closed-loop control through the feedback information of the device, further improving the execution efficiency and reliability. The use of the preset API interface ensures the standardization and efficiency of communication between the system and the device. Even for FSU devices of different models, commands can be issued and executed through a unified API call, which enhances the compatibility and promotion applicability of the solution. Through the automated generation and issuance of instructions, the system avoids input errors, operation omissions and other problems that may occur in manual operations, thereby reducing the risks in the processing process and improving the accuracy and consistency of fault handling. The instant issuance of instructions through the API significantly shortens the fault response time. When an abnormality occurs in key equipment, this rapid response can effectively reduce equipment downtime and improve the overall stability and operating efficiency of the system.

[0075] This embodiment obtains the operation and maintenance data, log files and historical fault data of the FSU equipment; performs fault analysis on the operation and maintenance data and log files based on a preset large language model; generates a fault handling solution based on the fault analysis results and historical fault data; and sends the fault handling solution to the FSU equipment based on a preset API. This embodiment ensures the comprehensiveness of diagnostic information by integrating multi-source data (operation and maintenance data, log files, historical fault data), and uses the intelligent analysis capabilities of the large language model to parse unstructured data and quickly locate the root cause of the fault, thereby improving the accuracy and automation of diagnosis; combines real-time analysis results with historical fault data to automatically generate efficient and reliable fault handling solutions, shortening the solution design time; automatically sends the solution to the FSU equipment through a preset API interface and executes it quickly, building a closed-loop process from diagnosis to processing, and improving the efficiency and accuracy of fault diagnosis and processing of FSU equipment.

[0076] Based on the above first embodiment, a second embodiment of the present application for the fault diagnosis and processing method of FSU equipment is proposed. Figure 2 , Figure 2 This is a schematic diagram of a sub-flow in the second embodiment of the fault diagnosis and processing method for FSU equipment of the present application.

[0077] like Figure 2 As shown, in this embodiment, before step S1, the following steps are also included:

[0078] S1a: Based on a preset self-test cycle, a self-test instruction is sent to the FSU device;

[0079] S1b: After the FSU device receives the self-test instruction, based on the self-test instruction, the device status data of the FSU device is obtained, where the device status data includes basic device information, system operation status, and module operation status;

[0080] S1c: Based on the preset large language model, comparing the device state data with a preset device parameter threshold;

[0081] S1d: Generate a device self-check report based on the comparison result, where the device self-check report includes module status information of the FSU device and faults to be processed.

[0082] It should be noted that the preset self-check cycle refers to the periodic time interval set in advance according to the needs of equipment operation, which is used to automatically trigger the self-check task of the FSU equipment to ensure real-time monitoring of the equipment status and early fault detection. The self-check instruction is a control command sent by the fault diagnosis and processing system for the FSU equipment to the FSU equipment, instructing the equipment to start the self-check process and return the operation status data, including the execution range, detection parameters and threshold requirements. The equipment status data is the operation status information collected by the FSU equipment during the self-check process, mainly including: basic equipment information: such as manufacturer information, MAC address, IP address and other equipment identification information; system operation status: such as CPU load, memory usage, disk utilization and other key performance indicators; module operation status: such as the operation status and error records of the SSH module, FTP module and data processing module. The preset equipment parameter threshold refers to the operating parameter range (such as load upper limit, memory usage threshold, etc.) set in advance according to the best practices, expert experience or documentation of equipment operation, which is used to evaluate whether the equipment operation status is normal. The equipment self-check report is a report file generated by the system after the self-check is completed, which contains the current module status information of the equipment, the detection results and the list of faults to be handled.

[0083] Specifically, an instruction is sent to the FSU device through an API interface or a control protocol, including self-check parameters (such as modules to be checked, monitoring indicators) and threshold requirements. After receiving the self-check instruction, the FSU device starts the self-check process and collects basic device information, system operation status (such as CPU load, memory usage, etc.) and module operation status (such as the activity status of SSH and FTP modules) one by one. After the device completes data collection, it transmits the device status data back to the fault diagnosis and processing system for the FSU device in real time.

[0084] Furthermore, the collected device status data is compared with the preset device parameter thresholds item by item, for example, whether the current CPU load exceeds the upper limit and whether the module status is abnormal. The large language model extracts potential abnormal information and preliminarily locates the faulty module through natural language processing and pattern recognition technology. Based on the analysis results, a device self-test report is generated, which includes the current module status information of the device (such as whether the module is running normally) and the identified faults to be handled (such as module abnormalities or parameter exceeding the standard). The report is presented in a structured form, which makes it easy for maintenance personnel to quickly understand the health status of the equipment and the matters that need to be handled.

[0085] Through the preset self-check cycle, the system regularly triggers self-check tasks, avoiding the limitations of passive fault response and realizing real-time monitoring of equipment health status. This active monitoring mechanism can detect potential problems earlier and reduce the risk of failure. The self-check task covers comprehensive data collection of basic equipment information, system operation status and module operation status. This multi-dimensional data support can provide sufficient basis for subsequent analysis and ensure more accurate positioning of equipment problems. The collected equipment status data is analyzed using a large language model and compared with the preset threshold to quickly find out-of-limit parameters or abnormal modules. Compared with traditional rule-based methods, the intelligent analysis of the large language model significantly improves the efficiency and accuracy of anomaly detection, especially in complex conditions. The self-check report clearly presents the health status and pending fault information of the equipment in a structured form, helping maintenance personnel to quickly understand equipment problems and take targeted measures, further shortening the fault response time and improving operation and maintenance efficiency.

[0086] Based on the first embodiment above, in this embodiment, after step S1d, the following steps are further included:

[0087] S1da: Classifying the to-be-processed fault based on the preset large language model and the module status information in combination with a preset fault degree classification strategy;

[0088] S1db: If the fault to be processed is a minor fault, call the preset API for automatic repair;

[0089] S1dc: If the fault to be processed is a serious fault, the FSU device is rolled back to the previous historical version based on the historical version information of the FSU device.

[0090] It should be noted that module status information refers to the operating status data of each functional module of the FSU device, including but not limited to whether the module is working normally, whether the performance indicators (such as load, delay) meet the standards, and whether an error event occurs. The preset fault degree classification strategy is a classification standard based on fault characteristics (such as fault impact scope, severity, and recovery difficulty), which divides the faults to be processed into minor faults and major faults. Minor faults usually affect local functions and are easy to repair; major faults may cause equipment downtime or system instability, and more complex recovery measures are required. Historical version information refers to the version snapshot recorded during the operation of the FSU device, including system configuration, module status, and operating parameters, etc., which is used to restore the device to a previous stable state when necessary. Automatic repair refers to performing repair operations on minor faults by calling preset API interfaces, such as restarting modules, adjusting parameters, or repairing specific logical errors. Rollback refers to the operation of restoring the device to the previous historical version, which is mainly used for handling major faults to ensure that the device can quickly recover to a stable operating state.

[0091] Specifically, the large language model is used to analyze the module status information and extract fault features (such as error codes, parameter overruns, module response, etc.); based on the preset fault severity classification strategy, the faults are divided into minor faults and major faults. If the fault only affects the function of individual modules or the parameters are slightly overrun (such as the load is slightly higher than the threshold), it is classified as a minor fault; if the fault affects multiple modules or may cause the device to fail completely (such as the module is completely unavailable or the memory usage is abnormal), it is classified as a major fault; a fault classification report is generated, indicating the fault category and the recommended repair strategy.

[0092] Furthermore, minor fault repair: call the preset API interface to automatically perform repair operations. For example, restart the abnormal module, adjust the over-limit parameters or reload the configuration file; the handling of minor faults aims to minimize the impact on the operation of the device, and usually does not require manual intervention. Severe fault rollback: retrieve the historical version information of the FSU device and select the most recent stable version as the rollback target; trigger the rollback mechanism through the API to restore the device status and configuration to the historical version to ensure that the device quickly returns to normal operation. After the rollback is completed, record the relevant information and generate a rollback report.

[0093] By combining a large language model and module status information, the system can accurately distinguish between minor faults and major faults. This classification avoids the risk of over-handling minor problems or underestimating major problems, thereby optimizing resource utilization and repair efficiency. For minor faults, the system implements automated repairs through APIs without manual intervention, significantly shortening the fault repair time and reducing the risk of equipment downtime. Especially in a multi-device operating environment, automated repairs can handle multiple minor problems at the same time, improving overall operating efficiency. For major faults, rolling back through historical version information can quickly restore the device to a stable state, avoiding the trial and error time and uncertainty that may be caused by traditional repair methods. The rollback mechanism improves the reliability and stability of the system in critical scenarios. Faults are classified and handled as minor or major, optimizing resource allocation. Minor problems can reduce interference to the overall system through quick repairs, and major problems can ensure system stability through rollbacks, forming a hierarchical and efficient fault repair process.

[0094] This embodiment obtains the operation and maintenance data, log files and historical fault data of the FSU equipment; performs fault analysis on the operation and maintenance data and log files based on a preset large language model; generates a fault handling solution based on the fault analysis results and historical fault data; and sends the fault handling solution to the FSU equipment based on a preset API. This embodiment ensures the comprehensiveness of diagnostic information by integrating multi-source data (operation and maintenance data, log files, historical fault data), and uses the intelligent analysis capabilities of the large language model to parse unstructured data and quickly locate the root cause of the fault, thereby improving the accuracy and automation of diagnosis; combines real-time analysis results with historical fault data to automatically generate efficient and reliable fault handling solutions, shortening the solution design time; automatically sends the solution to the FSU equipment through a preset API interface and executes it quickly, building a closed-loop process from diagnosis to processing, and improving the efficiency and accuracy of fault diagnosis and processing of FSU equipment.

[0095] Based on the above second embodiment, a third embodiment of the present application for a method for diagnosing and handling a fault of an FSU device is proposed. Figure 3 , Figure 3 This is a schematic diagram of a sub-flow in the third embodiment of the fault diagnosis and processing method for FSU equipment of the present application.

[0096] In this embodiment, after step S4, the method further includes:

[0097] S4a: Obtain the execution result of the FSU device;

[0098] S4b: Compare the execution result with the fault handling solution;

[0099] S4c: Update the fault handling strategy based on the comparison result.

[0100] It should be noted that the execution result of the FSU device refers to the feedback information returned by the FSU device after executing the fault handling solution, including whether the execution is successful, the execution time, and the device status after execution. For example, the success status of the module restart, whether the load has returned to normal, and whether the memory usage rate has dropped to a reasonable range. The comparison result refers to the analysis conclusion drawn after comparing the actual execution result of the device with the expected result of the fault handling solution, which is mainly used to determine whether the fault has been resolved or whether the repair effect meets expectations. The fault handling strategy is a high-level rule and logic used to guide the system to generate a fault handling solution, including processing priority, method selection (such as automatic repair or manual intervention), and optimization strategy.

[0101] Specifically, the execution result data returned by the receiving device includes the operation completion status (success / failure), execution time, device status parameters (such as load, module status, error code), etc. The acquired data is preprocessed, such as removing redundant information, verifying data integrity, and formatting log output for subsequent comparison and analysis.

[0102] Furthermore, compare whether the device status parameters have returned to the normal range. For example: if the module load is expected to be restored to below 70% in the processing plan, and the execution result shows that the load is 65%, the repair is judged to be successful. If the execution result does not meet expectations (such as the module is still abnormal, the parameters exceed the standard), it is considered a repair failure. If the execution fails, find the cause of the abnormality through log analysis and comparison, such as API call failure, parameter setting error, or device response timeout. Archive the current effective processing plan and successful cases to optimize the processing strategy for similar faults in the future and improve the accuracy and reliability of fault handling plan generation. If the execution result does not meet expectations, the system records the cause of failure (such as module response timeout or insufficient processing steps) and adjusts the processing strategy. For example: modify the adjustment range of parameter values. Replace the current repair method (such as changing from restarting the module to rolling back the configuration). The updated strategy will be used to generate a more efficient processing plan and reduce the probability of repeated failures.

[0103] By comparing the execution results with the expected effects of the fault handling solutions, the system can dynamically adjust and optimize the handling strategies, forming a complete closed-loop mechanism from analysis, execution to feedback. This mechanism ensures the controllability and reliability of the repair process, avoiding repeated attempts and waste of resources in fault handling. By collecting and analyzing the execution results, the system continuously enriches and improves the fault handling strategy library, and builds an intelligent optimization mechanism based on actual data. With the accumulation of data, the system can quickly generate more efficient solutions when dealing with similar faults, significantly improving processing efficiency and accuracy. In the case of repair failure, by comparing the execution results with the expected effects, the system can quickly locate the root cause of the problem (such as insufficient operation steps or unsatisfied execution conditions), and generate improved repair strategies to avoid further expansion and recurrence of the problem. Through automated feedback and strategy optimization mechanisms, the system significantly reduces the reliance of fault handling on manual experience, realizes self-improvement and dynamic adjustment of processing strategies, and promotes the intelligent and automated development of operation and maintenance.

[0104] Based on the above second embodiment, in this embodiment, step S2 includes:

[0105] S21: calling the preset large language model;

[0106] S22: preprocessing the operation and maintenance data and the log file to obtain preprocessed data, wherein the preprocessing includes one or more of formatting, data cleaning, and data normalization;

[0107] S23: Based on the natural language processing technology of the preset large language model, keyword extraction, pattern recognition and time series analysis are performed on the preprocessed data.

[0108] It should be noted that preprocessed data refers to data that has been preprocessed (such as formatting, data cleaning and normalization) and converted into standardized data that is easier to analyze and can be directly input into the model. Natural language processing technology is an artificial intelligence technology that focuses on analyzing and understanding text data. It is used to extract keywords, identify abnormal patterns and analyze time series relationships to support intelligent processing of complex data.

[0109] Specifically, convert the unstructured text data in the log files (such as error descriptions, operation events) into semi-structured or structured formats (such as JSON or tabular format) to facilitate subsequent analysis. Remove invalid or redundant information, such as duplicate log records, meaningless blank lines, or data in the wrong format, to ensure data quality and integrity. Perform unit conversion and range standardization on the data, for example, unify the load data of different modules to the same scale to eliminate the impact of data distribution differences on the analysis results. The preprocessed data is passed as input to the large language model to provide a high-quality input basis for subsequent key analysis.

[0110] Furthermore, important information is extracted from the log text, such as error codes, module names, and exception descriptions. For example, "Error500" or "ModuleTimeout" is used as a keyword to facilitate the subsequent location of the problem module. Combine historical data with operation and maintenance records to identify abnormal patterns in current data. For example: detect abnormal fluctuations in equipment parameters (such as continuous load exceeding the standard); extract repetitive patterns of specific events from the log (such as error codes that occur multiple times). Analyze the timestamp data in the log file to determine the order of events and their relevance. For example: determine whether the overload of a module has caused subsequent module failures; analyze the time interval between events to determine the periodic characteristics of the problem. The analysis results are generated into a structured fault report for subsequent fault classification and processing solution generation.

[0111] Through preprocessing operations such as formatting, data cleaning and normalization, complex and messy raw data is converted into high-quality input with unified standards. This not only improves the consistency and readability of the data, but also provides a more accurate basis for the analysis of the large language model, reducing the possibility of misjudgment and omission. The large language model can efficiently extract key information from unstructured text (such as log files) and quickly discover potential fault modes in combination with pattern recognition technology. Compared with traditional rule matching methods, the self-learning and reasoning capabilities of the model can cope with complex and diverse fault characteristics, significantly improving the intelligent level of fault identification. By analyzing the time sequence and dependencies of events in the log, the system can identify the trigger point of the fault and its chain effect. For example, it can identify how the high load of a certain module of the device gradually leads to a decline in system performance, thereby providing a more accurate basis for solving the problem. The multi-dimensional analysis method that combines keyword extraction, pattern recognition and time series analysis can quickly locate fault characteristics and generate accurate diagnostic information, shortening the time of traditional manual troubleshooting and improving the efficiency of fault analysis.

[0112] Based on the above second embodiment, in this embodiment, step S3 includes:

[0113] S31: classifying the fault analysis result based on the preset large language model;

[0114] S32: Compare the operation and maintenance data with historical operation and maintenance data;

[0115] S33: Determine the real cause of the fault according to the fault classification result and the comparison result;

[0116] S34: Based on the real cause of the fault, semantic matching is performed in the historical fault data;

[0117] S35: extracting a corresponding fault handling solution from the historical fault data according to the semantic matching result.

[0118] It should be noted that the fault analysis results are preliminary conclusions generated in the early diagnosis, including information such as equipment operating status, abnormal modules and potential fault types, which are used for subsequent classification and further fault location. Historical operation and maintenance data is data that records the normal or abnormal status of the equipment in previous operations, including system performance parameters (such as load, memory usage), module behavior records and operation history. Semantic matching is a natural language processing technology used to find records similar to the current fault characteristics in historical fault data, and understand the similarity of fault descriptions through semantic analysis, which is not limited to keyword matching.

[0119] Specifically, key features such as module status, exception code, and impact range are extracted from the fault analysis results. The fault features are input into the large language model, and the faults are classified into different types (such as hardware failures, software errors, network problems, or configuration anomalies) in combination with historical data and the model training knowledge base. Classification results are generated, and the fault type and corresponding priority are marked to provide a reference for subsequent cause location.

[0120] Furthermore, the current equipment operating parameters (such as load, memory usage) are compared with historical normal operation data item by item to find excessive or abnormal trends. Through the patterns recorded in the historical operation and maintenance data (such as periodic fluctuations, module dependencies), possible fault causes (such as chain reactions between specific modules) are located. The most likely real cause of the fault is derived by combining the fault classification results with the abnormalities found by comparison. For example: if the classification result is "hardware failure" and the comparison finds that the load of a certain module is continuously too high, it may be an overload problem caused by insufficient hardware performance. Use a large language model to semantically match the real cause of the fault with the description in the historical fault data. For example: match the current "module load is too high" with a similar description in the historical fault record "CPU load abnormality causes module response timeout". The matching results are sorted by semantic similarity score, and the historical record with the highest score is selected. Extract verified and effective processing solutions from the matched historical fault records. The processing solution includes operation steps (such as adjusting parameters, restarting modules) and execution conditions. If multiple historical records are matched successfully, the most suitable processing solution is selected in combination with the current operating status.

[0121] By classifying the fault analysis results through a large language model, combined with training data and historical knowledge base, the faults can be quickly and accurately classified into different types. This intelligent classification mechanism greatly reduces the subjectivity of manual judgment and provides a clear direction for fault cause location. By comparing the current operation and maintenance data with the historical operation and maintenance data in multiple dimensions, the system can quickly identify abnormal points and locate the real fault cause in combination with the fault classification results. Compared with relying solely on analysis results, adding historical data comparison can more comprehensively restore the full picture of the problem and improve the accuracy of cause location. Semantic matching based on a large language model can not only match keywords, but also identify similar problems with different descriptions. For example, "module response timeout" and "module stuck" can be identified as the same type of fault. This capability enables the system to make full use of the experience of historical fault records and quickly find effective solutions. By extracting historical processing solutions that are highly relevant to the current problem, the system can directly call verified solutions to avoid wasting time redesigning solutions. Especially in emergency faults, reusing historical solutions significantly shortens the repair time and improves fault handling efficiency. Combining fault classification, operation and maintenance data comparison and historical experience matching, the system can dynamically adjust the fault handling logic. By continuously reusing and optimizing processing solutions, the system gradually establishes an efficient processing mechanism that adapts to different operating environments, promoting the intelligent development of fault diagnosis and processing.

[0122] This embodiment obtains the operation and maintenance data, log files and historical fault data of the FSU equipment; performs fault analysis on the operation and maintenance data and log files based on a preset large language model; generates a fault handling solution based on the fault analysis results and historical fault data; and sends the fault handling solution to the FSU equipment based on a preset API. This embodiment ensures the comprehensiveness of diagnostic information by integrating multi-source data (operation and maintenance data, log files, historical fault data), and uses the intelligent analysis capabilities of the large language model to parse unstructured data and quickly locate the root cause of the fault, thereby improving the accuracy and automation of diagnosis; combines real-time analysis results with historical fault data to automatically generate efficient and reliable fault handling solutions, shortening the solution design time; automatically sends the solution to the FSU equipment through a preset API interface and executes it quickly, building a closed-loop process from diagnosis to processing, and improving the efficiency and accuracy of fault diagnosis and processing of FSU equipment.

[0123] The present application also provides a fault diagnosis and processing device for FSU equipment, please refer to Figure 4 , Figure 4 This is a schematic diagram of the module structure of the fault diagnosis and processing device for FSU equipment in an embodiment of the present application, including:

[0124] The data acquisition module 401 is used to acquire the operation and maintenance data, log files and historical fault data of the FSU equipment;

[0125] A fault analysis module 402 is used to perform fault analysis on the operation and maintenance data and the log file based on a preset large language model;

[0126] A solution generation module 403 is used to generate a fault handling solution based on the fault analysis result and the historical fault data;

[0127] The target module 404 is used to send the fault handling solution to the FSU device based on a preset API.

[0128] The fault diagnosis and processing device for FSU equipment provided in the embodiment of the present application adopts the fault diagnosis and processing method for FSU equipment in the above embodiment, which can solve the technical problem of how to improve the efficiency of fault diagnosis and processing of FSU equipment. Compared with the prior art, the beneficial effects of the fault diagnosis and processing device for FSU equipment provided in the embodiment of the present application are the same as the beneficial effects of the fault diagnosis and processing method for FSU equipment provided in the above embodiment, and the other technical features of the fault diagnosis and processing device for FSU equipment are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0129] The present application provides a fault diagnosis and processing device for FSU equipment, and the fault diagnosis and processing device for FSU equipment includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the fault diagnosis and processing method for FSU equipment in the above-mentioned embodiment.

[0130] Reference below Figure 5 , Figure 5 The schematic diagram of the device structure of the hardware operating environment involved in the method for diagnosing and processing the fault of the FSU device in the embodiment of the present application shows a schematic diagram of the structure of the device for diagnosing and processing the fault of the FSU device suitable for implementing the embodiment of the present application. The device for diagnosing and processing the fault of the FSU device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5The fault diagnosis and processing device for FSU equipment shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0131] like Figure 5 As shown, the fault diagnosis and processing device for FSU equipment may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. Various programs and data required for the operation of the fault diagnosis and processing device for FSU equipment are also stored in the RAM 1004. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 may allow the fault diagnosis and processing device for FSU equipment to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a fault diagnosis and processing device for FSU equipment with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0132] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0133] The fault diagnosis and processing device for FSU equipment provided by the present application adopts the fault diagnosis and processing method for FSU equipment in the above embodiment, which can solve the technical problem of how to improve the efficiency of fault diagnosis and processing of FSU equipment. Compared with the prior art, the beneficial effects of the fault diagnosis and processing device for FSU equipment provided by the present application are the same as the beneficial effects of the fault diagnosis and processing method for FSU equipment provided by the above embodiment, and other technical features in the fault diagnosis and processing device for FSU equipment are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0134] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0135] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0136] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the fault diagnosis and processing method for FSU equipment in the above-mentioned embodiment.

[0137] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0138] The computer-readable storage medium may be included in the fault diagnosis and processing device for FSU equipment; or it may exist independently without being assembled into the fault diagnosis and processing device for FSU equipment. The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the fault diagnosis and processing device for FSU equipment, the fault diagnosis and processing device for FSU equipment: obtains the operation and maintenance data, log files and historical fault data of the FSU equipment; performs fault analysis on the operation and maintenance data and the log files based on a preset large language model; generates a fault processing plan based on the fault analysis results and the historical fault data; and sends the fault processing plan to the FSU equipment based on a preset API. The computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof. The programming languages ​​include object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0139] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0140] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0141] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned fault diagnosis and processing method for FSU equipment, and can solve the technical problem of how to improve the efficiency of fault diagnosis and processing of FSU equipment. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the fault diagnosis and processing method for FSU equipment provided by the above-mentioned embodiment, and will not be repeated here.

[0142] An embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above-mentioned fault diagnosis and processing method for FSU equipment.

[0143] The computer program product provided in this application can solve the technical problem of how to improve the efficiency of fault diagnosis and processing of FSU equipment. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiment of this application are the same as the beneficial effects of the fault diagnosis and processing method for FSU equipment provided in the above embodiment, which will not be repeated here.

[0144] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent processing scope of the present application.

Claims

1. A fault diagnosis and processing method for FSU equipment, characterized in that: The method comprises: Obtaining operation and maintenance data, log files, and historical fault data of the FSU equipment; Based on a preset large language model, performing fault analysis on the operation and maintenance data and the log file; Generate a fault handling solution based on the fault analysis result and the historical fault data; Based on a preset API, the fault handling solution is sent to the FSU device.

2. The method according to claim 1, characterized in that Before the step of obtaining the operation and maintenance data, log files and historical fault data of the FSU device, the method further includes: Based on a preset self-test cycle, sending a self-test instruction to the FSU device; After the FSU device receives the self-check instruction, based on the self-check instruction, the device status data of the FSU device is obtained, wherein the device status data includes basic device information, system operation status, and module operation status; Based on the preset large language model, comparing the device status data with a preset device parameter threshold; Based on the comparison result, a device self-check report is generated, wherein the device self-check report includes module status information of the FSU device and faults to be processed.

3. The method according to claim 2, characterized in that After the step of generating a device self-test report based on the comparison result, the method further includes: Based on the preset large language model and the module status information, combined with a preset fault degree classification strategy, classify the fault to be processed; If the fault to be processed is a minor fault, the preset API is called to automatically repair the fault; If the fault to be processed is a serious fault, the FSU device is rolled back to the previous historical version based on the historical version information of the FSU device.

4. The method according to claim 1, characterized in that After the step of sending the fault handling solution to the FSU device based on the preset API, the method further includes: Obtaining the execution result of the FSU device; Comparing the execution result with the fault handling solution; Update the fault handling strategy based on the comparison results.

5. The method according to claim 1, characterized in that The step of performing fault analysis on the operation and maintenance data and the log file based on the preset large language model includes: Calling the preset large language model; Preprocessing the operation and maintenance data and the log file to obtain preprocessed data, wherein the preprocessing includes one or more of formatting, data cleaning, and data normalization; Based on the natural language processing technology of the preset large language model, keyword extraction, pattern recognition and time series analysis are performed on the preprocessed data.

6. The method according to claim 1, characterized in that The step of generating a fault handling solution based on the fault analysis result and the historical fault data includes: Based on the preset large language model, classify the fault analysis result; comparing the operation and maintenance data with historical operation and maintenance data; Determine the real cause of the fault based on the fault classification and comparison results; Based on the real cause of the fault, semantic matching is performed in the historical fault data; According to the semantic matching result, a corresponding fault handling solution is extracted from the historical fault data.

7. A fault diagnosis and processing device for FSU equipment, characterized in that: The device comprises: A data acquisition module, used to acquire operation and maintenance data, log files and historical fault data of the FSU equipment; A fault analysis module, used for performing fault analysis on the operation and maintenance data and the log file based on a preset large language model; A solution generation module, used to generate a fault handling solution based on the fault analysis result and the historical fault data; The target module is used to send the fault handling solution to the FSU device based on a preset API.

8. A computer device, characterized in that: The device includes: a memory, a processor, and a fault diagnosis and processing program for FSU equipment stored in the memory and executable on the processor, wherein the fault diagnosis and processing program for FSU equipment is configured to implement the steps of the fault diagnosis and processing method for FSU equipment according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium stores a fault diagnosis and processing program for the FSU device, and when the fault diagnosis and processing program for the FSU device is executed by the processor, the steps of the fault diagnosis and processing method for the FSU device according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the fault diagnosis and processing method for FSU equipment according to any one of claims 1 to 6 are implemented.

Images