Method, device and electronic equipment for processing digital domain faults of a satellite communication system

Abstract

This application provides a method, apparatus, and electronic device for handling digital domain faults in satellite communication systems. It includes: decoupling a digital domain model according to its functions to obtain functional sub-modules; acquiring controllable parameters of the functional sub-modules; determining potential fault causes of the functional sub-modules based on the controllable parameters to obtain a complete set of root causes; injecting faults into the digital domain model using the complete set of root causes; controlling the digital domain model to simulate fault phenomena; determining fault optimization schemes corresponding to the fault phenomena; constructing a fault warehouse based on the fault optimization schemes, the complete set of root causes, and the fault phenomena; acquiring fault phenomena under digital domain model fault conditions; matching and processing fault phenomena according to the fault warehouse to obtain target fault optimization schemes corresponding to the fault phenomena for handling digital domain model faults. This solves the problem that existing technologies require extensive simulation verification of system design reliability when predicting potential problems, leading to resource waste and low efficiency.

Description

Technical Field

[0001] This application relates to the technical field of handling digital domain faults in satellite communication systems, and more specifically, to a method, system, apparatus, computer-readable storage medium, and electronic device for handling digital domain faults in satellite communication systems. Background Technology

[0002] In the design and iterative evolution of satellite communication system technology, it is usually necessary to predict and analyze potential technical problems in advance to improve the fault tolerance of the system design from the source and ensure the reliability of system operation. By digitally modeling each network element node in the communication system, simulation and verification of communication functions, processes, key technologies and algorithms can be achieved, effectively enhancing the robustness of the system design. At the same time, problems found in the operation of real communication systems can usually be reproduced in digital domain simulation systems. With the high flexibility of simulation systems and comprehensive data support, the diagnosis and handling of communication system faults can be achieved more efficiently, improving system maintenance efficiency.

[0003] Traditional simulation systems have certain limitations in handling faults in satellite communication systems. Their main function is to reproduce known faults and rely on manual analysis to locate problems. When predicting potential problems, they typically use methods such as setting key parameters like random packet loss to conduct numerous simulations to verify the reliability of the system design. This process often lacks specificity, leading to wasted resources and low efficiency. Summary of the Invention

[0004] The main objective of this application is to provide a method, system, apparatus, computer-readable storage medium, and electronic device for handling digital domain faults in satellite communication systems, so as to at least solve the problem that existing technologies require extensive simulation to verify the reliability of system designs when predicting potential problems, resulting in resource waste and inefficiency.

[0005] To achieve the above objectives, according to one aspect of this application, a method for handling digital domain faults in a satellite communication system is provided, comprising: acquiring digital domain models of each network element node in the satellite communication system; decoupling the digital domain models according to their functions to obtain multiple functional sub-modules; and acquiring controllable parameters corresponding to each functional sub-module; determining potential fault causes in the interactive or processed data of each functional sub-module based on the controllable parameters corresponding to each functional sub-module, obtaining a complete set of fault root causes, and controlling a host computer to inject faults into the digital domain model using the complete set of fault root causes to control the digital domain model to perform fault injection. Fault simulation yields fault phenomena, and at least based on these phenomena, a fault tuning scheme corresponding to the fault phenomena is determined. A fault database is constructed based on the fault tuning scheme, the complete set of fault root causes, and the fault phenomena. The fault tuning scheme is a scheme for handling faults in the digital domain model. When a fault occurs during the actual operation of the digital domain model, the fault phenomena of the digital domain model are obtained. The fault phenomena of the digital domain model are matched with the fault database to obtain a target fault tuning scheme corresponding to the fault phenomena. The target fault tuning scheme is then used to handle the faults in the digital domain model.

[0006] Optionally, during the matching process of the fault phenomena of the digital domain model according to the fault warehouse, the method further includes: determining whether the fault phenomena of the digital domain model exist in the fault warehouse; if the fault phenomena exist in the fault warehouse, obtaining the root cause of the fault phenomena through the fault warehouse, and determining the number of root causes; if the number of root causes corresponding to the fault phenomena is at least two, and there is no access data, sending the multiple root causes corresponding to the fault phenomena to the user terminal through the host computer, wherein the access data represents the operating data of the satellite communication system.

[0007] Optionally, after determining the number of root causes of the fault, the method further includes: if the number of root causes corresponding to the fault phenomenon is at least two and the access data exists, importing the access data into the digital domain model, filtering the root causes corresponding to the fault phenomenon based on the access data and the fault determination rules of each root cause to obtain a target root cause, and sending the target root cause as a fault diagnosis result to the user terminal through the host computer. The root cause of the fault includes the root cause category, the root cause value, and the fault determination rules.

[0008] Optionally, after determining whether the fault phenomenon of the digital domain model exists in the fault repository, the method further includes: if the fault phenomenon does not exist in the fault repository, sending the fault phenomenon of the digital domain model to the user terminal through the host computer to obtain the root cause of the fault and the fault tuning scheme corresponding to the fault phenomenon from the user terminal; and updating the root cause of the fault and the fault tuning scheme corresponding to the fault phenomenon to the fault repository.

[0009] Optionally, controlling the host computer to inject faults into the digital domain model using the complete set of fault root causes, thereby controlling the digital domain model to perform fault simulation to obtain fault phenomena, and determining at least the fault optimization scheme corresponding to the fault phenomena, and constructing a fault warehouse based on the fault optimization scheme, the complete set of fault root causes, and the fault phenomena, includes: controlling the host computer to sequentially inject each of the fault root causes in the complete set of fault root causes into the digital domain model, thereby controlling the digital domain model to perform fault simulation to obtain the fault phenomena corresponding to each fault root cause; determining the corresponding fault optimization scheme based on the fault phenomena and the fault root causes, and constructing the fault warehouse based on the fault phenomena, the fault root causes, and the fault optimization scheme.

[0010] Optionally, at least the fault phenomena of the digital domain model are matched according to the fault database, including: obtaining module interaction data when the digital domain model malfunctions; controlling the host computer to map the module interaction data to controllable parameter configuration information of each functional sub-module, and reproducing the fault according to the controllable parameter configuration information to obtain simulation output log information of the fault; and matching the fault phenomena of the digital domain model according to the fault database and the simulation output log information.

[0011] According to another aspect of this application, a system for handling digital domain faults in a satellite communication system is provided, comprising: a controller, the controller being configured to execute any of the aforementioned methods for handling digital domain faults in a satellite communication system; a host computer, configured to input fault diagnosis-related information to a functional model processor and collect fault diagnosis results from the functional model processor, wherein the fault diagnosis-related information includes fault injection, access data import, and fault diagnosis configuration; the functional model processor, configured to receive the fault diagnosis-related information from the host computer, drive each decoupled functional sub-module to perform corresponding simulation operations according to the host computer configuration, and send the simulation output log information generated during the simulation operation, together with the fault diagnosis-related information input by the host computer, to the fault diagnosis processor, and simultaneously listen to the fault diagnosis result information reported by the fault diagnosis processor and send it to the host computer; the fault diagnosis processor, configured to receive the fault diagnosis-related information and the simulation output log information sent by the functional model processor, and perform diagnostic processing on the digital domain model based on a fault database and the fault diagnosis-related information and the simulation output log information.

[0012] According to another aspect of this application, a device for processing digital domain faults in a satellite communication system is provided, comprising: a decoupling processing unit, configured to acquire digital domain models of each network element node in the satellite communication system, decouple the digital domain models according to their functions to obtain multiple functional sub-modules, and acquire controllable parameters corresponding to each functional sub-module; and a fault injection unit, configured to determine potential fault causes in the interaction or processing data of each functional sub-module based on the controllable parameters corresponding to each functional sub-module, obtain a complete set of fault root causes, and control a host computer to inject faults into the digital domain model using the complete set of fault root causes, thereby controlling the digital domain model to perform... Fault simulation yields fault phenomena, and at least based on the fault phenomena, a fault tuning scheme corresponding to the fault phenomena is determined. A fault warehouse is constructed based on the fault tuning scheme, the complete set of fault root causes, and the fault phenomena. The fault tuning scheme is a scheme for handling faults in the digital domain model. A diagnostic processing unit is used to obtain the fault phenomena of the digital domain model when a fault occurs during the actual operation of the digital domain model, and at least based on the fault warehouse, match the fault phenomena of the digital domain model to obtain a target fault tuning scheme corresponding to the fault phenomena. The target fault tuning scheme is then used to handle the faults in the digital domain model.

[0013] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform any of the aforementioned satellite communication system digital domain fault handling methods.

[0014] According to another aspect of this application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a method for performing any of the methods for handling digital domain faults in a satellite communication system.

[0015] By applying the technical solution of this application, the digital domain model of each network element node in the satellite communication system is obtained. The digital domain model is then decoupled according to its function to obtain multiple functional sub-modules, and controllable parameters corresponding to each functional sub-module are acquired. Based on the controllable parameters of each functional sub-module, potential fault causes in the interactive or processed data of each functional sub-module are determined, resulting in a complete set of fault root causes. The host computer is then controlled to inject faults into the digital domain model using the complete set of fault root causes to control the digital domain model to simulate faults and obtain fault phenomena. At least based on the fault phenomena, a fault optimization scheme corresponding to the fault phenomena is determined. A fault warehouse is constructed based on the fault optimization scheme, the complete set of fault root causes, and the fault phenomena. The fault optimization scheme is a scheme used to handle faults in the digital domain model. When a fault occurs during the actual operation of the digital domain model, the fault phenomena of the digital domain model are acquired. At least based on the fault warehouse, the fault phenomena of the digital domain model are matched to obtain a target fault optimization scheme corresponding to the fault phenomena. The target fault optimization scheme is then used to handle the faults in the digital domain model. By decoupling the digital domain functions of a satellite communication system and obtaining the controllable parameters of each functional submodule, potential faults can be located and simulated more accurately. The acquisition of controllable parameters allows for targeted adjustment of specific variables during fault simulation to observe their impact on system performance and thus determine the root cause of the fault. The constructed fault repository is a database that records various known fault phenomena, corresponding root causes, and optimization solutions. When a system fault occurs, the corresponding solution can be quickly retrieved, significantly shortening fault handling time. This combination of technical features solves the problem of rapid location and handling of digital domain faults in satellite communication systems, improving system stability and service quality. It also addresses the issue of existing technologies requiring extensive simulations to verify system design reliability when predicting potential problems, leading to resource waste and inefficiency. Attached Figure Description

[0016] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 A hardware structure block diagram of a mobile terminal for performing a method for handling digital domain faults in a satellite communication system, according to an embodiment of this application, is shown.

[0018] Figure 2 A flowchart illustrating a method for handling digital domain faults in a satellite communication system according to an embodiment of this application is shown.

[0019] Figure 3 A flowchart illustrating a specific method for handling digital domain faults in a satellite communication system according to an embodiment of this application is shown.

[0020] Figure 4 A schematic diagram illustrating the process of decoupling the digital domain model of a communication network element according to an embodiment of this application is shown.

[0021] Figure 5 A structural block diagram of a satellite communication system digital domain fault processing apparatus provided according to an embodiment of this application is shown;

[0022] Figure 6 A schematic diagram of the structure of a satellite communication system digital domain fault handling system provided according to an embodiment of this application is shown.

[0023] The above figures include the following reference numerals:

[0024] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device; 51. Decoupling processing unit; 52. Fault injection unit; 53. Diagnostic processing unit. Detailed Implementation

[0025] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] As described in the background section, existing technologies require extensive simulations to verify the reliability of system designs when predicting potential problems, leading to resource waste and inefficiency. To address the problem of existing technologies requiring extensive simulations to verify the reliability of system designs when predicting potential problems, resulting in resource waste and inefficiency, embodiments of this application provide a method, system, apparatus, computer-readable storage medium, and electronic device for handling digital domain faults in satellite communication systems.

[0029] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0030] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a method of handling digital domain faults in a satellite communication system according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the satellite communication system digital domain fault handling method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0032] This embodiment provides a method for handling digital domain faults in a satellite communication system that runs on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] Figure 2 This is a flowchart of a method for handling digital domain faults in a satellite communication system according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0034] Step S201: Obtain the digital domain model of each network element node in the satellite communication system, decouple the digital domain model according to its function to obtain multiple functional sub-modules, and obtain the controllable parameters corresponding to each functional sub-module.

[0035] The digital domain model of each network element node in the satellite communication system includes the terminal model, satellite payload model, ground station model, and core network model.

[0036] This embodiment focuses on the digital domain portion of a satellite communication system, specifically the software and algorithms responsible for data processing and transmission. The digital domain model abstracts and models the software functions of each network element node (such as satellites and ground stations) to facilitate understanding and analysis of their working principles. Decoupling involves breaking down these complex functional models into smaller, more independent functional sub-modules, each responsible for a specific function, such as data encoding, decoding, and routing. Controllable parameters are variables that can be manually adjusted during fault simulation, such as signal strength, noise level, and data packet size. By decoupling and acquiring controllable parameters, potential faults can be located and simulated more accurately.

[0037] Specifically, the digital domain model is decoupled based on its functionality to facilitate independent control and analysis of the parameters and behaviors of each functional submodule. By filtering and combining controllable parameters, a comprehensive set of root causes of failures is formed, which helps in the labeling and identification of key issues. No specific restrictions are placed on the granularity of decoupling here. Finer granularity allows for more flexible parameter control, but may reduce model efficiency. The granularity of decoupling can be determined based on actual needs.

[0038] Step S202: Based on the controllable parameters corresponding to each of the above functional sub-modules, determine the potential fault causes in the interaction or processing data of each of the above functional sub-modules, obtain a complete set of fault root causes, and control the host computer to inject faults into the digital domain model using the complete set of fault root causes, so as to control the digital domain model to simulate faults and obtain fault phenomena. At least based on the fault phenomena, determine the fault tuning scheme corresponding to the fault phenomena, and construct a fault warehouse based on the fault tuning scheme, the complete set of fault root causes and the fault phenomena. The fault tuning scheme is a scheme for handling the faults of the digital domain model.

[0039] Specifically, the root cause categories of faults are encoded, and the root causes are sequentially injected into the digital model of network elements according to different root cause codes. All possible fault scenarios are traversed and fault phenomena are recorded. The root causes and fault phenomena are associated, and fault optimization schemes are determined based on the root causes and fault phenomena. A fault warehouse is built to achieve rapid fault finding and diagnosis and accelerate the problem handling process.

[0040] Step S203: In the event of a fault occurring during the actual operation of the digital domain model, the fault phenomenon of the digital domain model is obtained, and the fault phenomenon of the digital domain model is matched with the fault database to obtain a target fault tuning scheme corresponding to the fault phenomenon. The target fault tuning scheme is then used to handle the fault of the digital domain model.

[0041] By applying steps S201, S202, and S203 in this embodiment, and decoupling the digital domain functions of the satellite communication system and obtaining the controllable parameters of each functional submodule, potential faults can be located and simulated more accurately. The acquisition of controllable parameters allows for targeted adjustment of specific variables during fault simulation to observe their impact on system performance and thus determine the root cause of the fault. The constructed fault repository is a database that records various known fault phenomena, corresponding root causes, and optimization schemes. When a system fault occurs, the corresponding solution can be quickly retrieved, significantly shortening the fault handling time. This series of technical features combined solves the problem of rapid location and handling of digital domain faults in satellite communication systems, improving system stability and service quality. It also addresses the problem of existing technologies requiring extensive simulation verification of system design reliability when predicting potential problems, leading to resource waste and inefficiency.

[0042] In the specific implementation process, during the matching and processing of the fault phenomena of the digital domain model according to the fault warehouse, the method further includes: determining whether the fault phenomena of the digital domain model exist in the fault warehouse; if the fault phenomena exist in the fault warehouse, obtaining the root cause of the fault phenomena through the fault warehouse and determining the number of root causes; if the number of root causes corresponding to the fault phenomena is at least two and there is no access data, sending the multiple root causes corresponding to the fault phenomena to the user terminal through the host computer, wherein the access data represents the operation data of the satellite communication system.

[0043] Access data refers to the actual data collected during the normal operation of the satellite communication system, such as signal quality, transmission rate, and packet loss rate. During fault diagnosis, if a fault is recorded in the fault database but lacks specific operational data for reference, multiple root causes may lead to the same fault. In this case, all possible root causes are sent to the user, who can then determine the most probable cause based on the actual situation and perform targeted optimization.

[0044] This method further improves the flexibility and accuracy of fault diagnosis. Even without specific operational data, although multiple root causes may lead to the same fault phenomenon, by presenting all possible root causes to the user, the user can quickly eliminate impossible factors based on their experience and on-site conditions, thus identifying the most likely cause and accelerating fault handling. This process is particularly suitable for complex fault scenarios requiring specialized knowledge and on-site experience for judgment, effectively compensating for the limitations of automated diagnosis in certain situations and ensuring the efficient operation of the system.

[0045] Specifically, after determining the number of the aforementioned root causes of the fault, the method further includes: when the number of the aforementioned root causes corresponding to the aforementioned fault phenomenon is at least two and the aforementioned access data exists, importing the aforementioned access data into the aforementioned digital domain model, and based on the aforementioned access data and the fault judgment rules of each of the aforementioned root causes, filtering the aforementioned root causes corresponding to the aforementioned fault phenomenon to obtain the target root cause, and sending the aforementioned target root cause as a fault diagnosis result to the aforementioned user terminal through the aforementioned host computer. The root cause of the fault includes the root cause category, the root cause value, and the aforementioned fault judgment rules.

[0046] The fault determination rules are preset logical conditions used to determine whether specific operational data indicates the existence of a certain type of fault. For example, if the signal strength is below a certain threshold, it may trigger a fault determination for signal attenuation. When specific operational data is available, we can further narrow down the scope of fault root causes based on this data and the fault determination rules to find the most likely cause of the fault.

[0047] This method, when access data is available, imports the data into a digital domain model and filters it using fault determination rules. This allows for more precise identification of the root cause of faults, avoiding blindly trying all possible optimization solutions and saving time and resources. This process relies on the accuracy and rationality of the fault determination rules, which are typically developed based on extensive experimental data and industry experience, effectively guiding the direction of fault diagnosis. For example, for signal attenuation faults, by analyzing data such as signal strength and signal-to-noise ratio, combined with preset determination rules, it can be determined whether the fault is caused by atmospheric disturbances, hardware aging, or improper software configuration. The implementation of this technical feature greatly improves the efficiency and accuracy of fault diagnosis, especially when dealing with complex faults caused by the combined effects of multiple factors.

[0048] More specifically, after determining whether the aforementioned fault phenomenon of the aforementioned digital domain model exists in the aforementioned fault repository, the method further includes: if the aforementioned fault phenomenon does not exist in the aforementioned fault repository, sending the aforementioned fault phenomenon of the aforementioned digital domain model to the aforementioned user terminal through the aforementioned host computer, so as to obtain the aforementioned root cause of the fault phenomenon and the aforementioned fault tuning scheme corresponding to the aforementioned fault phenomenon from the aforementioned user terminal; and updating the aforementioned root cause of the fault phenomenon and the aforementioned fault tuning scheme corresponding to the aforementioned fault phenomenon to the aforementioned fault repository.

[0049] When encountering unknown fault phenomena, we need to leverage the knowledge and experience of experts to identify the root cause and develop optimization plans. The user interface typically refers to the interface used by system administrators or technical professionals. They can view the fault phenomena through a host computer, analyze possible causes, and propose solutions.

[0050] This method ensures the continuous updating and improvement of the fault repository, enabling it to cope with constantly changing fault types and environmental conditions. In actual operation, satellite communication systems may encounter unprecedented fault phenomena, which may be caused by new technology applications, environmental changes, or hardware and software upgrades. By sending these unknown fault phenomena to the user end for analysis and diagnosis by professionals, not only can current faults be addressed promptly, but newly discovered root causes and optimization solutions can also be added to the fault repository, providing solutions for similar faults that may occur in the future. This mechanism promotes knowledge accumulation and sharing, improves the overall system's adaptability and fault handling capabilities, and is particularly suitable for satellite communication systems with diverse fault types and complex environmental conditions.

[0051] Furthermore, the host computer injects faults into the digital domain model using the complete set of fault root causes to control the digital domain model to perform fault simulation and obtain fault phenomena. It then determines a fault optimization scheme corresponding to each fault phenomenon based on the fault phenomena, and constructs a fault warehouse based on the fault optimization scheme, the complete set of fault root causes, and the fault phenomena. This includes: controlling the host computer to sequentially inject each of the fault root causes from the complete set of fault root causes into the digital domain model to control the digital domain model to perform fault simulation and obtain the fault phenomena corresponding to each fault root cause; determining the corresponding fault optimization scheme based on the fault phenomena and the fault root causes; and constructing the fault warehouse based on the fault phenomena, the fault root causes, and the fault optimization scheme.

[0052] This approach involves introducing faults into the system and observing its response to verify its robustness and fault tolerance. In this technical solution, each root cause in the complete set of root causes is injected into the digital domain model to simulate various possible fault scenarios. The fault phenomena under these scenarios are then analyzed to determine effective optimization schemes.

[0053] This method, through fault injection and simulation, enables comprehensive testing and understanding of the fault behavior of digital domain models in a controlled environment, which is crucial for building a comprehensive and effective fault repository. Fault injection not only helps us discover potential design flaws and vulnerabilities but also verifies the effectiveness of existing tuning solutions and even discovers new tuning strategies. The constructed fault repository is a dynamic and ever-growing knowledge base containing various fault phenomena, corresponding root causes, and tuning solutions, providing valuable references for future fault diagnosis. The implementation of this technical feature not only solves the challenge of fault diagnosis but also promotes fault prevention and system optimization, improving the overall performance and reliability of satellite communication systems.

[0054] Furthermore, at least the above-mentioned fault phenomena of the above-mentioned digital domain model are matched according to the above-mentioned fault database, including: obtaining the module interaction data when the above-mentioned digital domain model fails; controlling the above-mentioned host computer to map the above-mentioned module interaction data into the controllable parameter configuration information of each of the above-mentioned functional sub-modules, and reproducing the fault according to the above-mentioned controllable parameter configuration information to obtain the simulation output log information of the above-mentioned fault; and matching the above-mentioned fault phenomena of the above-mentioned digital domain model according to the above-mentioned fault database and the above-mentioned simulation output log information.

[0055] In this context, module interaction data refers to the data and signals transmitted between functional sub-modules in the digital domain model, such as the transmission path and encoding method of data packets. By mapping this data to controllable parameter configuration information, fault scenarios can be reproduced in fault simulations, allowing for further analysis of the causes of the faults.

[0056] The application of this technical feature enables the accurate reproduction of fault scenarios based on actual module interaction data, improving the accuracy and efficiency of fault diagnosis. When a fault occurs, collecting and analyzing module interaction data allows us to understand the specific environment and conditions under which the fault occurred, providing crucial information for fault simulation. Mapping this data to controllable parameter configuration information means that we can precisely control the behavior of each functional submodule in fault simulation, thereby reproducing the fault phenomenon and obtaining detailed simulation output log information. Comparing this information with records in the fault repository helps to quickly locate the cause of the fault and take effective optimization measures. This process fully utilizes the value of actual operating data, avoids blind guessing and trial and error, and greatly improves the efficiency and success rate of fault handling, making it particularly suitable for scenarios with complex fault phenomena and many changing influencing factors.

[0057] In summary, the technical solution provided in this application achieves rapid location and effective handling of digital domain faults in satellite communication systems through decoupling of the digital domain model, fault injection, fault simulation, fault repository construction, and a dynamic update mechanism for fault diagnosis. This combination of technical features not only solves the problems of low efficiency and poor accuracy in traditional fault diagnosis methods but also promotes fault prevention and system optimization, improving the overall performance and reliability of satellite communication systems. Furthermore, by continuously updating the fault repository, this technical solution can cope with constantly changing fault types and environmental conditions, exhibiting strong adaptability and scalability, and providing solid technical support for the long-term stable operation of satellite communication systems.

[0058] Furthermore, this embodiment also includes an adaptive fault injection strength and frequency adjustment mechanism. Traditional methods often employ fixed-strength and-frequency fault injection during fault injection and simulation, which can easily lead to insufficient fault detection in certain sensitive areas or unnecessary waste of simulation resources in some non-critical areas. Therefore, this embodiment introduces an adaptive fault injection strength and frequency adjustment mechanism. Specifically, this mechanism dynamically adjusts fault injection parameters based on historical fault records and system operation statistics, such as increasing the fault strength and frequency in high-risk areas and reducing the resource consumption for fault injection in low-risk areas. The specific steps include:

[0059] 1) Data analysis and evaluation: Collect and analyze past fault records, and combine them with system operation logs to determine which functional modules or parameter settings are prone to failure and which are less affected.

[0060] 2) Adaptive Strategy Formulation: Based on the above evaluation results, an adaptive fault injection strategy is formulated, including increasing the injection intensity and frequency in high-risk areas and appropriately reducing the complexity of fault injection in low-risk areas.

[0061] 3) Strategy Execution and Feedback: During fault simulation testing, fault injection is executed according to an adaptive strategy while monitoring changes in system performance metrics. If a new fault is detected or system performance significantly degrades, the strategy is adjusted, and fault injection is executed again until the optimal fault injection parameter configuration is found.

[0062] By adaptively adjusting the intensity and frequency of fault injection, potential faults can be located more accurately, avoiding blind testing and significantly improving diagnostic efficiency. Furthermore, by rationally allocating fault injection resources, unnecessary simulations in low-risk areas are reduced, improving overall resource utilization.

[0063] This embodiment also includes a machine learning-based fault prediction and early warning system. In satellite communication systems, faults often exhibit certain patterns and precursors. This embodiment proposes using historical fault data to train a machine learning model to predict potential fault trends and issue early warnings before faults occur, allowing for proactive measures to prevent systemic failures. The system can monitor the system's operational status in real time. Once a pattern similar to a known fault is detected, an early warning process is immediately initiated, notifying maintenance personnel to take preventative measures. Specifically, it includes the following steps:

[0064] 1) Data preparation: Collect a large amount of historical fault data, including fault phenomena, root causes, and fault handling results, to train machine learning models.

[0065] 2) Model training: Use supervised learning methods, such as support vector machines (SVM) and neural networks, to train a predictive model that can identify fault modes.

[0066] 3) Feedback and Model Updates: Feedback the results of each warning and the actual fault situation to the model to continuously optimize the model's predictive capabilities.

[0067] By applying a machine learning-based fault prediction and early warning system, warnings can be issued before faults occur, giving maintenance personnel ample time to take countermeasures and avoid system downtime. Furthermore, through proactive prevention and rapid response, the overall availability and service quality of the satellite communication system are significantly improved.

[0068] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the method for handling digital domain faults in satellite communication systems will be described in detail below with reference to specific embodiments.

[0069] This embodiment relates to a specific method for handling digital domain faults in a satellite communication system, such as... Figure 3 As shown, the specific steps include the following:

[0070] Step 1: As Figure 4 As shown, the digital model of communication system network elements is decoupled according to function, forming different functional sub-modules. Controllable parameters related to faults in each functional sub-module are extracted, and based on various parameter combinations, a complete fault root cause set (RCS) is formed. Specifically, this includes:

[0071] Step 1.1: Decouple the digital model of communication network elements according to their functions.

[0072] Specifically, the upper-layer protocol stack of the digital model can be decoupled according to different protocol layers, and the physical layer of the digital model can be decoupled according to different channels.

[0073] Step 1.2: Filter the controllable parameters of each submodule to uncover potential fault causes in the interaction or processing data of each submodule (including but not limited to fault causes related to abnormal protocol parameters and abnormal network element node behavior), forming a fault root cause dataset with single source and multiple combinations, and integrating it into the complete fault root cause set RCS = {rcs1, rcs2, ..., rcs}. N}

[0074] Specifically, abnormal protocol parameters can be caused by reasons including, but are not limited to, abnormal transmit / receive power values ​​and abnormal message field values.

[0075] Specifically, abnormal behavior of network element nodes may be caused by reasons including but not limited to stopping sending, delaying sending, stopping receiving, delaying receiving, and message dropping.

[0076] Each single-source root cause RCS i , by a root cause category rcsType i A root cause value rcsValue i A decision rule rcsRule i Composition. Among them:

[0077] i) Fault Root Cause Category rcsType i Indicates the type of fault, such as abnormal transmit / receive power, message transmission delay, etc.

[0078] ii) Fault root cause value rcsValue i This indicates a specific abnormal value under a specified fault type, such as a specific transmit / receive power value, message transmission delay time, etc.; specifically, rcsValue i It can be an array or a string of values ​​of different categories, such as the initial transmit power value PtxValue1 and subsequent transmit power values ​​PtxValue2.

[0079] iii) Judgment rule rcsRule i Typically specified by technical experts, these represent manually set boundary values ​​or reasonableness judgment rules, such as the minimum transmit power value MinPtxTH. A normal access procedure consists of an uplink random access request (RandomAccessRequest) and a downlink random access response (RandomAccessResponse) signaling, and the time difference between the two signaling messages should be greater than or equal to MinRaDurationTime and less than or equal to MaxRaDurationTime.

[0080] Each multivariate combination of root causes of failure (rcs) i Composed of multiple (rcsType) j rcsValuej () consists of pairs. For example, rcs i If the root cause of the fault is "abnormal transmit power + abnormal receive power + consecutive failures to receive random access response messages", then this RCS... i Composed of 3 pairs (rcsType) j rcsValue j The composition is as follows:

[0081] (rcsType0, rcsValue0) = ("Abnormal transmission power", 0dBm);

[0082] (rcsType1, rcsValue1) = ("Abnormal Receive Power", 0dBm);

[0083] (rcsType2, rcsValue2) = ("Random access response message reception failure", 2 times).

[0084] Step 2: The host computer injects faults into the digital model based on the complete set of root causes (RCS). The digital model then simulates faults and records information to build a fault repository. This specifically includes:

[0085] Step 2.1: Based on the complete set of root cause categories (RCS), for each root cause category, rcsType i Encode the fault injection codewords, and each fault injection codeword uniquely corresponds to a type of fault root cause.

[0086] Specifically, the host computer can simultaneously analyze the root cause of the fault (RCS). i The corresponding fault root cause category and fault root cause value are injected and configured. Alternatively, only the fault root cause category can be configured, and the specific fault root cause value or multiple fault root cause values ​​are specified by the pre-agreed fault injection codeword value. During the simulation operation, the digital model loads the fault root cause value from the configuration script file under the specified path, or inputs the fault root cause value through the command line or other methods to further support the digital model in simulating or reproducing the injected fault.

[0087] For example:

[0088] 0x0001 indicates an abnormal transmission power, and the transmission power value is directly configured by the host computer;

[0089] 0x0002 indicates an abnormal receive power, and the receive power value is directly configured by the host computer;

[0090] 0x0003 indicates abnormal transmit power and abnormal receive power, and both transmit power and receive power values ​​are directly configured by the host computer;

[0091] ...

[0092] 0x1001 indicates an abnormal transmission power, and the transmission power value is configured by the script file;

[0093] ...

[0094] 0x2001 indicates an abnormal transmission power, and the transmission power value is entered by the user via the command line;

[0095] ...

[0096] Step 2.2: Inject a fault root cause (RCS) into the digital model of the communication network element via the host computer. i The model simulates or reproduces injected faults and records specific root causes (rcs) of the faults. i Fault phenomena corresponding to model operation under injection conditions (ufr) i (Such as access failure, registration failure, etc.), analyze solutions in advance. i (Suggestions such as increasing transmission power can be left blank), forming a fault form data [ufr] i rcs i , fr i ].

[0097] Generally, multiple network element node digital models can be instantiated in a single simulation, and fault injection configuration and simulation data recording can be performed in parallel.

[0098] Typically, there is no direct one-to-one correspondence between the root cause of a fault and the fault symptom. Multiple root causes may correspond to the same fault symptom, such as sending an abnormality or receiving an abnormality, which may both lead to access failure; or one root cause may correspond to multiple fault symptoms, such as sending an abnormality leading to access failure or registration failure.

[0099] Step 2.3: Traverse the RCS, repeat step 2.2 to complete all root cause injections and fault simulations, summarize all fault form data, and form a fault repository.

[0100] Step 3: When diagnosing faults that have occurred in actual communication equipment or digital models, first check if the current fault phenomenon exists in the existing fault form set. If it does not exist, update the new fault phenomenon to the fault repository, and supplement the fault root cause and optimization solution suggestions in the subsequent root cause analysis; if it exists, retrieve the corresponding optimization solution and fault cause, and return it to the user through the host computer to support problem localization and resolution.

[0101] Specifically, when retrieving the root cause RCS based on the fault phenomenon UFR, it is also necessary to use the fault root cause judgment rules rcsRule in the RCS for in-depth verification and confirmation. When the fault phenomenon to be diagnosed exists in the existing fault database, the corresponding root cause is not unique. If there is no other accessible data, the possible root cause set RcsSet is returned to the host computer for further location and analysis by the user. If there is other accessible data, the accessed data can be imported into the digital model, and the judgment is made based on the rcsRule corresponding to each rcsType in RcsSet. The rcsType items (one or more) that do not meet the rcsRule are filtered out as the fault diagnosis results and returned to the host computer for the user.

[0102] Furthermore, if the fault is to be diagnosed in the digital model of the communication system, the host computer can perform the diagnosis configuration after the fault occurs. After the functional model unit receives the diagnosis configuration instruction, each functional decoupling submodule will report the last interactive data information during the current operation, such as the last sent and received messages, all current maintenance timers or status information, etc., to assist the user in fault diagnosis.

[0103] Step 4: Optionally, when diagnosing a fault, if there is information such as module interaction data at the time of the fault, the host computer can map the interaction data information into the controllable parameter configuration information of each functional sub-module, or the host computer can instruct the digital model to load the module interaction data at the time of the fault stored on the specified path to reproduce the fault. At this time, more detailed simulation output log information can be collected to further assist in fault analysis and improve the fault database.

[0104] Specifically, when reproducing a fault, the data obtained from the fault reproduction can be verified using rcsRule. For cases that do not meet the rcsRule, the root cause rcs (one or more) of the fault corresponding to the rcsRule is used as the diagnostic result and reported.

[0105] The embodiments of this application achieve the following technical effects:

[0106] 1) Decoupling and Parameter Extraction: This embodiment performs functional decoupling planning during the design phase of the digital domain model of satellite communication network element nodes (such as terminal model, satellite payload model, ground station model, core network model, etc.). This facilitates independent control and analysis of the parameters and behaviors of each functional sub-module. By filtering and combining controllable parameters, a comprehensive set of fault root causes is formed, which helps in the labeling and identification of key issues. No specific restrictions are placed on the granularity of decoupling here. A finer granularity allows for more flexible parameter control, but may reduce model efficiency. The granularity of decoupling can be determined based on actual needs.

[0107] 2) Fault Injection and Fault Repository Construction: The root cause of the fault is coded and the root cause is injected into the digital model of the network element according to different root cause codes. All possible fault scenarios are traversed and the fault phenomena are recorded. The root cause and fault phenomena are associated to build a fault repository, realize the rapid fault finding and diagnosis, and accelerate the problem handling process.

[0108] 3) Automated retrieval and expansion of the fault repository: Provides rules for determining the root cause of faults, supports automatic retrieval of the root cause of faults based on fault phenomena and related data, supports the identification of new fault phenomena, and updates the fault repository to continuously accumulate fault knowledge.

[0109] 4) Based on 2), when injecting faults, the configuration methods for fault values ​​include, but are not limited to: direct configuration by the host computer, configuration through a script file, and inputting command lines.

[0110] 5) Typical fault diagnosis usually involves post-incident processing, i.e., reproducing, locating, and analyzing faults that have already occurred. This embodiment, however, proactively identifies potential root causes of faults, sets rules for determining root causes, and actively injects potential root causes to build a pre-incident fault repository. This allows for the verification of the rationality of protocol design and technical solutions before actual communication system problems occur, thus avoiding problems in advance. Furthermore, based on established protocol systems and technical solutions, it enables more targeted pre-simulation and observation of specific faults, reducing subsequent manual intervention and accelerating fault diagnosis efficiency.

[0111] 6) This embodiment has good scalability and can be applied to digital domain modeling and fault diagnosis in other fields.

[0112] This application also provides a device for handling digital domain faults in a satellite communication system. It should be noted that this device can be used to execute the method for handling digital domain faults in a satellite communication system provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0113] The following describes the device for handling digital domain faults in a satellite communication system provided in the embodiments of this application.

[0114] Figure 5 This is a schematic diagram of a digital domain fault handling apparatus for a satellite communication system according to an embodiment of this application. Figure 5 As shown, the device includes:

[0115] The decoupling processing unit 51 is used to obtain the digital domain model of each network element node in the satellite communication system, decouple the digital domain model according to its function, obtain multiple functional sub-modules, and obtain the controllable parameters corresponding to each functional sub-module.

[0116] The fault injection unit 52 is used to determine the potential fault causes in the interaction or processing data of each of the above-mentioned functional sub-modules according to the controllable parameters corresponding to each of the above-mentioned functional sub-modules, obtain a complete set of fault root causes, and control the host computer to inject faults into the digital domain model using the complete set of fault root causes, so as to control the digital domain model to simulate faults and obtain fault phenomena, and at least determine the fault optimization scheme corresponding to the fault phenomena based on the fault phenomena, and construct a fault warehouse based on the fault optimization scheme, the complete set of fault root causes and the fault phenomena, wherein the fault optimization scheme is a scheme for handling the faults of the digital domain model.

[0117] The diagnostic processing unit 53 is used to obtain the fault phenomenon of the digital domain model when a fault occurs during the actual operation of the digital domain model, at least match the fault phenomenon of the digital domain model with the fault database, obtain the target fault tuning scheme corresponding to the fault phenomenon, and use the target fault tuning scheme to perform fault handling on the digital domain model.

[0118] In this embodiment, the decoupling processing unit is used to obtain the digital domain model of each network element node in the satellite communication system, decouple the digital domain model according to its function, obtain multiple functional sub-modules, and obtain the controllable parameters corresponding to each functional sub-module. The fault injection unit is used to determine the potential fault causes in the interaction or processing data of each functional sub-module based on the controllable parameters corresponding to each functional sub-module, obtain a complete set of fault root causes, and control the host computer to use the complete set of fault root causes to inject faults into the digital domain model, so as to control the digital domain model to simulate faults and obtain fault phenomena, and at least root cause. Based on the aforementioned fault phenomena, a corresponding fault tuning scheme is determined. A fault database is constructed based on this scheme, the complete set of root causes, and the fault phenomena. The fault tuning scheme is used to handle faults in the digital domain model. A diagnostic processing unit, when a fault occurs during the actual operation of the digital domain model, acquires the fault phenomena of the digital domain model, matches these phenomena against the fault database, obtains the corresponding target fault tuning scheme, and uses this scheme to handle the fault in the digital domain model. By decoupling the digital domain functions in the satellite communication system and acquiring the controllable parameters of each functional submodule, potential faults can be more accurately located and simulated. Acquiring controllable parameters allows for targeted adjustment of specific variables during fault simulation to observe their impact on system performance and thus determine the root cause of the fault. The constructed fault database records various known fault phenomena, corresponding root causes, and tuning schemes. When a system fault occurs, the corresponding solution can be quickly retrieved, significantly shortening the fault handling time. This combination of technical features solves the problem of rapid location and handling of digital domain faults in satellite communication systems, improving system stability and service quality. It also addresses the issue of existing technologies requiring extensive simulations to verify system design reliability when predicting potential problems, leading to resource waste and inefficiency.

[0119] As an optional solution, the device further includes a first determining unit, a second determining unit, and a first transmitting unit; the first determining unit is used to determine whether the fault phenomenon of the digital domain model exists in the fault warehouse during the matching process of the fault phenomenon of the digital domain model according to the fault warehouse; the second determining unit is used to obtain the root cause of the fault phenomenon corresponding to the fault phenomenon through the fault warehouse and determine the number of the root causes of the fault when the fault phenomenon exists in the fault warehouse; the first transmitting unit is used to transmit multiple root causes of the fault phenomenon corresponding to the fault phenomenon to the user terminal through the host computer when the number of root causes of the fault phenomenon is at least two and there is no access data, wherein the access data represents the operation data of the satellite communication system.

[0120] In an optional embodiment, the apparatus further includes a filtering processing unit, configured to, after determining the number of the aforementioned root causes of the fault, and when the number of the aforementioned root causes corresponding to the aforementioned fault phenomenon is at least two and the aforementioned access data exists, import the aforementioned access data into the aforementioned digital domain model, perform filtering processing on the aforementioned root causes of the fault phenomenon based on the aforementioned access data and the fault determination rules of each of the aforementioned root causes of the fault, obtain the target root cause of the fault, and send the aforementioned target root cause of the fault as a fault diagnosis result to the aforementioned user terminal through the aforementioned host computer, wherein the root cause of the fault includes the fault root cause category, the fault root cause value, and the aforementioned fault determination rules.

[0121] In one optional embodiment, the apparatus further includes a second sending unit and an updating unit. The second sending unit is used to, after determining whether the fault phenomenon of the digital domain model exists in the fault repository, send the fault phenomenon of the digital domain model to the user terminal via the host computer if the fault phenomenon does not exist in the fault repository, so as to obtain the root cause of the fault and the fault tuning scheme corresponding to the fault phenomenon from the user terminal. The updating unit is used to update the root cause of the fault and the fault tuning scheme corresponding to the fault phenomenon to the fault repository.

[0122] In one optional scheme, the fault injection unit includes a first control module and a construction module; the first control module is used to control the host computer to sequentially inject each of the fault root causes in the complete set of fault root causes into the digital domain model, so as to control the digital domain model to perform fault simulation and obtain the fault phenomena corresponding to each of the fault root causes; the construction module is used to determine the corresponding fault tuning scheme based on the fault phenomena and the fault root causes, and construct the fault warehouse according to the fault phenomena, the fault root causes and the fault tuning scheme.

[0123] In one optional scheme, the diagnostic processing unit includes an acquisition module, a second control module, and a matching processing module; the acquisition module is used to acquire module interaction data when the above-mentioned digital domain model malfunctions; the second control module is used to control the host computer to map the above-mentioned module interaction data into controllable parameter configuration information of each of the above-mentioned functional sub-modules, and reproduce the fault according to the above-mentioned controllable parameter configuration information to obtain the simulation output log information of the above-mentioned fault; the matching processing module is used to perform matching processing on the above-mentioned fault phenomena of the above-mentioned digital domain model according to the above-mentioned fault database and the above-mentioned simulation output log information.

[0124] The aforementioned satellite communication system digital domain fault handling device includes a processor and a memory. The decoupling processing unit, fault injection unit, and diagnostic processing unit are all stored as program units in the memory. The processor executes these program units stored in the memory to achieve the corresponding functions. All of the above modules are located in the same processor; alternatively, the modules may be located in different processors in any combination.

[0125] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, the problem of existing technologies requiring extensive simulations to verify the reliability of system designs when predicting potential problems, leading to resource waste and inefficiency, can be addressed.

[0126] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0127] This embodiment also includes a system for handling digital domain faults in a satellite communication system, comprising:

[0128] A controller, wherein the controller is used to execute at least one of the above-described methods for handling digital domain faults in a satellite communication system;

[0129] The host computer is used to input fault diagnosis-related information to the functional model processor and collect fault diagnosis results from the functional model processor. The fault diagnosis-related information includes fault injection, access data import, and fault diagnosis configuration.

[0130] Specifically, such as Figure 6 The host computer is responsible for inputting fault diagnosis-related information such as fault injection, diagnostic configuration, and other data import into the functional model processor, and for collecting fault diagnosis results from the functional model processor.

[0131] The aforementioned functional model processor is used to receive the aforementioned fault diagnosis related information from the aforementioned host computer, drive each decoupled functional sub-module to perform corresponding simulation operations according to the aforementioned host computer configuration, and send the simulation output log information generated during the simulation operation along with the aforementioned fault diagnosis related information input by the aforementioned host computer to the fault diagnosis processor. At the same time, it listens to the fault diagnosis result information reported by the fault diagnosis processor and sends it to the aforementioned host computer.

[0132] Specifically, such as Figure 6 As shown, the functional model processor includes an OMC control module and decoupled functional sub-modules. It is used to receive configuration information such as fault injection from the host computer, drive each decoupled functional sub-module to perform corresponding simulation operations according to the host computer configuration, and send the detailed log information generated during the simulation operation along with the host computer input information to the fault diagnosis processor. At the same time, it listens for the fault diagnosis result information reported by the fault diagnosis processor and sends it to the host computer.

[0133] The aforementioned fault diagnosis processor is used to receive the aforementioned fault diagnosis-related information and the aforementioned simulation output log information sent by the aforementioned functional model processor, and to perform diagnostic processing on the aforementioned digital domain model based on the fault database and the aforementioned fault diagnosis-related information and the aforementioned simulation output log information.

[0134] Specifically, such as Figure 6 As shown, the fault diagnosis processor receives host computer input information and simulation operation log information from the functional model processor. When the host computer input information is fault injection, it records the fault phenomena under the root cause category of the fault, extracts and correlates fault features from these causal information, and builds a fault database for fault prevention. When the host computer input information is diagnostic configuration, it collects the last interaction data information of each sub-functional module in the functional model processor under the current operating state, such as the last sent and received signaling messages and specific message field values, for fault location and control during simulation operation. When the host computer input information is module interaction data (such as test data collected from the actual system), it collects the functional model processor operation information driven by the module interaction data. If a fault is identified, it records the fault phenomena and updates the fault database as needed, thereby enabling the reproduction, location, and resolution of faults that have occurred in the test system.

[0135] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device containing the computer-readable storage medium to perform the method for handling digital domain faults in the satellite communication system.

[0136] This invention provides a processor for running a program, wherein the program executes the method for handling digital domain faults in a satellite communication system.

[0137] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements at least the steps of the above-described method for handling digital domain faults in a satellite communication system. The device described herein may be a server, PC, PAD, mobile phone, etc.

[0138] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform the steps of initializing a method for handling digital domain faults in a satellite communication system, as described above.

[0139] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0140] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0141] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1A device that provides the functions specified in one or more boxes.

[0142] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0143] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0144] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0145] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0146] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0147] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0148] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method of handling a digital domain fault in a satellite communication system, characterized by, include: The digital domain model of each network element node in the satellite communication system is obtained. The digital domain model is decoupled according to its function to obtain multiple functional sub-modules. The controllable parameters corresponding to each functional sub-module are obtained. Based on the controllable parameters corresponding to each functional sub-module, potential fault causes in the interactive or processed data of each functional sub-module are determined to obtain a complete set of fault root causes. The host computer is then controlled to inject faults into the digital domain model using the complete set of fault root causes to control the digital domain model to simulate faults and obtain fault phenomena. At least based on the fault phenomena, a fault optimization scheme corresponding to the fault phenomena is determined. A fault warehouse is constructed based on the fault optimization scheme, the complete set of fault root causes, and the fault phenomena. The fault optimization scheme is a scheme for handling faults in the digital domain model. In the event of a fault occurring during the actual operation of the digital domain model, the fault phenomenon of the digital domain model is obtained, and the fault phenomenon of the digital domain model is matched with the fault database to obtain a target fault tuning scheme corresponding to the fault phenomenon. The target fault tuning scheme is then used to handle the fault of the digital domain model.

2. The method of claim 1, wherein, In the process of matching the fault phenomena of the digital domain model according to the fault warehouse, the method further includes: Determine whether the fault phenomenon of the digital domain model exists in the fault warehouse; If the fault phenomenon exists in the fault warehouse, the root cause of the fault phenomenon is obtained through the fault warehouse, and the number of the root causes is determined. When there are at least two root causes corresponding to the fault phenomenon and no access data is available, the multiple root causes corresponding to the fault phenomenon are sent to the user terminal through the host computer, wherein the access data represents the operation data of the satellite communication system.

3. The method of claim 2, wherein, After determining the number of root causes of the failure, the method further includes: When there are at least two root causes corresponding to the fault phenomenon and the access data exists, the access data is imported into the digital domain model. Based on the access data and the fault determination rules for each root cause, the root causes corresponding to the fault phenomenon are filtered to obtain the target root cause. The target root cause is then sent to the user terminal as a fault diagnosis result through the host computer. The root cause includes the root cause category, the root cause value, and the fault determination rules.

4. The method of claim 2, wherein, After determining whether the fault phenomenon of the digital domain model exists in the fault repository, the method further includes: If the fault phenomenon does not exist in the fault repository, the fault phenomenon of the digital domain model is sent to the user terminal through the host computer to obtain the root cause of the fault and the fault tuning scheme corresponding to the fault phenomenon from the user terminal. Update the root cause of the fault and the fault optimization scheme corresponding to the fault phenomenon to the fault repository.

5. The method of claim 1, wherein, The host computer controls the digital domain model to inject faults using the complete set of fault root causes, thereby controlling the digital domain model to simulate faults and obtain fault phenomena. It then determines a fault optimization scheme corresponding to the fault phenomena, and constructs a fault repository based on the fault optimization scheme, the complete set of fault root causes, and the fault phenomena, including: The host computer is controlled to inject each of the fault root causes in the complete set of fault root causes into the digital domain model in sequence, so as to control the digital domain model to perform fault simulation and obtain the fault phenomenon corresponding to each fault root cause. Based on the fault phenomenon and the fault root cause, a corresponding fault tuning scheme is determined, and the fault repository is constructed according to the fault phenomenon, the fault root cause and the fault tuning scheme.

6. The method of claim 1, wherein, At least the fault phenomena of the digital domain model are matched according to the fault database, including: Obtain module interaction data when the digital domain model malfunctions; The host computer is controlled to map the interactive data of the modules into controllable parameter configuration information of each functional sub-module, and to reproduce the fault according to the controllable parameter configuration information in order to obtain the simulation output log information of the fault. The fault phenomena of the digital domain model are matched and processed based on the fault repository and the simulation output log information.

7. A system for handling digital domain faults in a satellite communication system, characterized by include: A controller, the controller being configured to execute the method for handling digital domain faults in a satellite communication system as described in any one of claims 1 to 6; The host computer is used to input fault diagnosis-related information to the functional model processor and collect fault diagnosis results from the functional model processor. The fault diagnosis-related information includes fault injection, access data import, and fault diagnosis configuration. The functional model processor is used to receive the fault diagnosis related information from the host computer, drive each decoupled functional sub-module to perform corresponding simulation operations according to the host computer configuration, and send the simulation output log information generated during the simulation operation together with the fault diagnosis related information input by the host computer to the fault diagnosis processor. At the same time, it listens for the fault diagnosis result information reported by the fault diagnosis processor and sends it to the host computer. The fault diagnosis processor is used to receive the fault diagnosis-related information and the simulation output log information sent by the functional model processor, and perform diagnostic processing on the digital domain model based on the fault database and the fault diagnosis-related information and the simulation output log information.

8. A device for handling a digital domain fault in a satellite communication system, characterized in that include: The decoupling processing unit is used to obtain the digital domain model of each network element node in the satellite communication system, decouple the digital domain model according to its function, obtain multiple functional sub-modules, and obtain the controllable parameters corresponding to each functional sub-module. The fault injection unit is used to determine potential fault causes in the interaction or processing data of each functional sub-module based on the controllable parameters corresponding to each functional sub-module, obtain a complete set of fault root causes, and control the host computer to inject faults into the digital domain model using the complete set of fault root causes, so as to control the digital domain model to simulate faults and obtain fault phenomena. The unit also determines a fault optimization scheme corresponding to the fault phenomena based at least on the fault phenomena, and constructs a fault warehouse based on the fault optimization scheme, the complete set of fault root causes, and the fault phenomena. The fault optimization scheme is a scheme for handling faults in the digital domain model. The diagnostic processing unit is used to, when a fault occurs in the actual operation of the digital domain model, obtain the fault phenomenon of the digital domain model, at least match the fault phenomenon of the digital domain model according to the fault database, obtain a target fault tuning scheme corresponding to the fault phenomenon, and use the target fault tuning scheme to perform fault handling on the digital domain model.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the computer-readable storage medium to perform the satellite communication system digital domain fault handling method according to any one of claims 1 to 6.

10. An electronic device, comprising: include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a method for handling digital domain faults in a satellite communication system as described in any one of claims 1 to 6.

Images