Fault data processing method, communication device and computer readable storage medium

Abstract

The invention provides a fault data processing method, a communication device and a computer readable storage medium, and the method comprises the steps: obtaining first operation data from N load devices associated with a first satellite at a first time; n is an integer greater than or equal to 1; generating a first rule file based on the obtained first operation data; the first rule file comprises a corresponding relation between the fault type and the fault processing mode; in response to the condition that the first rule file meets the configuration condition, sending the first rule file to first fault load equipment in the N pieces of load equipment; the first rule file is used for processing a fault corresponding to the fault type by the first fault load equipment. According to the invention, the design quality of fault management and the efficiency of fault processing can be improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a fault data processing method, a communication device, and a computer-readable storage medium. Background Technology

[0002] Non-terrestrial network (NTN) communication systems are wireless communication systems that operate above the Earth's surface. They utilize non-terrestrial elements such as satellites and high-altitude platforms (e.g., drones, balloons, airships) to provide wireless communication services. NTN communication systems offer wide coverage, are not limited by terrain, and have high reliability. They can be widely used in scenarios such as autonomous driving, smart cities, and telemedicine, providing users with more convenient and efficient communication services.

[0003] The high complexity of the aerospace environment introduces unpredictable faults into the NTN communication system, making these faults difficult to resolve. Therefore, improving the efficiency of fault handling is an urgent technical problem to be solved. Summary of the Invention

[0004] This application provides a fault data processing method, a communication device, and a computer-readable storage medium, which can improve the design quality of fault management and the efficiency of fault processing.

[0005] In a first aspect, embodiments of this application provide a fault data processing method, which can be applied to a fault management device. The method includes: acquiring first operational data from N payload devices associated with a first satellite at a first time; N being an integer greater than or equal to 1; generating a first rule file based on the acquired first operational data; the first rule file including a correspondence between fault types and fault handling methods; and, in response to the first rule file meeting configuration conditions, sending the first rule file to a first faulty payload device among the N payload devices; the first rule file is used by the first faulty payload device to handle faults corresponding to fault types.

[0006] The acquired initial operational data can be used to generate a first rule file. If the first rule file meets the configuration conditions, it can be used to handle faults corresponding to the fault type in the first fault-loaded device. This allows for the efficient generation and transmission of the first rule file to the first fault-loaded device, enabling it to handle the corresponding faults promptly and effectively. This, in turn, improves the design quality and efficiency of fault management, thereby enhancing the reliability and effectiveness of fault handling.

[0007] In one possible implementation, the method may further include: in response to the first rule file satisfying the configuration conditions, sending the first rule file to the load devices other than the first faulty load device among the N load devices.

[0008] In this way, all N payload devices associated with the first satellite can handle the faults corresponding to the fault types based on the first rule file.

[0009] In one possible implementation, the method further includes: inputting a first rule file into a fault digital twin model to simulate fault handling; the fault digital twin model is used to simulate the fault handling process between the first satellite and N payload devices; during the simulated fault handling process, in response to the fault of the target payload device being resolved, it is determined that the first rule file meets the configuration conditions; wherein, the N payload devices include the target payload device, and the fault of the target payload device is the fault corresponding to the fault type.

[0010] In this way, the fault digital twin model can be used to verify whether the fault type corresponding to the fault can be successfully resolved based on the first rule file, which helps to ensure the effectiveness of the first rule file sent to the first faulty load device.

[0011] In one possible implementation, the method further includes: acquiring reference modeling data of the payload devices associated with the sample satellite during communication between the sample satellite and the payload devices associated with the sample satellite; and constructing a fault digital twin model based on the reference modeling data.

[0012] It is evident that constructing a fault digital twin model by referencing modeling data is beneficial to improving the effectiveness of the fault digital twin model.

[0013] In one possible implementation, the reference modeling data includes one or more of the following: design document data, operation log data, operation alarm data, and communication indicator data.

[0014] In this way, based on the fault payload model, it is beneficial to simulate the operating status and behavior of payload equipment associated with the sample satellite. For example, it can simulate potential faults of these payload equipment and the process by which these payload equipment handles faults. This, in turn, helps to accurately verify the effectiveness of the first rule document.

[0015] In one possible implementation, generating a first rule file based on the acquired first operational data may include: performing machine learning based on the acquired first operational data and historical operational data prior to the first time; the first operational data includes first fault data, and / or the historical operational data includes historical fault data; and generating the first rule file based on the results of the machine learning.

[0016] It is evident that machine learning can be performed based on the first running data, or based on the first running data and historical running data, which is beneficial for generating an effective first rule file.

[0017] In one possible implementation, the first rule file also includes fault diagnosis methods and / or fault alarm methods corresponding to the fault type.

[0018] It is evident that, based on the first rule document, it is beneficial to help the payload equipment managed by the first satellite diagnose faults in the payload equipment and issue alarms, thereby improving the efficiency of fault handling.

[0019] In one possible implementation, the method further includes: acquiring second operating data from N load devices at a second time; generating a second rule file based on the acquired second operating data; and sending the second rule file to a second faulty load device among the N load devices in response to the second rule file meeting the configuration conditions.

[0020] It is evident that the fault management device can generate new rule files based on the acquired new operational data, that is, generate a second rule file based on the second operational data, in order to update and optimize the rule files in the payload devices associated with the first satellite.

[0021] In one possible implementation, the method may further include: in response to the second rule file satisfying the configuration conditions, sending the first rule file to the load devices other than the second faulty load device among the N load devices.

[0022] In this way, all N payload devices associated with the first satellite can handle the faults corresponding to the fault types based on the second rule file. This is beneficial because when any one of the N payload devices fails, the fault can be handled based on the second rule file, thereby ensuring the normal operation of the N payload devices.

[0023] In one possible implementation, the method further includes: determining a first faulty load device from N load devices based on first fault data in the acquired first operating data.

[0024] In this way, the faulty load device among N load devices can be identified, which helps to improve the efficiency of fault handling.

[0025] Secondly, embodiments of this application provide another fault data processing method, which can be applied to a first fault-loaded device. The method includes: receiving a first rule file from a fault management device; the first rule file including a correspondence between fault types and fault handling methods; and processing faults corresponding to the fault types based on the first rule file.

[0026] The first faulty payload device is one of the N payload devices associated with the first satellite. The first faulty payload device can handle faults based on the received first rule file, which helps improve the efficiency of fault handling.

[0027] In one possible implementation, the method further includes: sending first operational data to the fault management device at a first time.

[0028] It is evident that the first faulty load device can send operational data, such as the first operational data, to the fault management device, thereby facilitating feedback of its operational status to the fault management device.

[0029] In one possible implementation, the first rule file also includes fault diagnosis methods and / or fault alarm methods corresponding to the fault type.

[0030] It is evident that the first fault management device can diagnose the faults that occur based on the first rule file and issue an alarm.

[0031] In one possible implementation, the method further includes updating the rule file to the first rule file.

[0032] In this way, the first faulty load device can update its rule file, which helps to improve the effectiveness of fault handling.

[0033] In one possible implementation, processing the fault corresponding to the fault type based on the first rule file may include: in response to detecting the occurrence of the first fault, performing fault diagnosis on the first fault based on the fault diagnosis method in the first rule file, and determining the fault type corresponding to the first fault as the first fault type; the faults corresponding to the fault type include the first fault; issuing an alarm for the first fault based on the fault alarm method corresponding to the first fault type; and processing the first fault based on the fault processing method corresponding to the first fault type.

[0034] As can be seen, based on the first rule file, the first faulty load device can efficiently diagnose the fault type and effectively handle the fault to ensure the normal operation of the first faulty device.

[0035] In one possible implementation, the method further includes: generating fault handling log data in response to the fault being handled according to the fault type; and sending second operating data to the fault management device, the second operating data including the fault handling log data.

[0036] Specifically, the second operational data can be sent to the fault management device at a second time, or it can be sent to the fault management device after the fault has been processed. In this way, data such as the process and results of fault processing based on the first rule file can be fed back to the fault management device.

[0037] In one possible implementation, the method further includes receiving a second rule file from the fault management system device.

[0038] In one possible implementation, the method further includes: updating the rule file from the first rule file to the second rule file in response to receiving the second rule file.

[0039] In this way, updating the rule files helps to enhance resilience to failures and improve processing efficiency.

[0040] Thirdly, embodiments of this application provide a communication device that includes a module for performing the method described in the first aspect and any of its possible implementations.

[0041] Fourthly, embodiments of this application provide a communication device that includes a module for performing the method described in the second aspect and any of its possible implementations.

[0042] Fifthly, embodiments of this application provide a communication device, which includes a processor and a transceiver. The transceiver is used to send and receive information, and the processor is used to enable the communication device to implement the method as described in any of the first aspect and its possible implementations, or to implement the method as described in any of the second aspect and its possible implementations.

[0043] In a sixth aspect, embodiments of this application provide a communication device, which includes at least one processor, a memory, and an interface circuit. The memory, the interface circuit, and the at least one processor are interconnected via a line. The at least one memory stores program instructions. The program instructions are used to cause the communication device to perform the method as described in any of the first aspect and its possible implementations, or to implement the method as described in any of the second aspect and its possible implementations.

[0044] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a communication device, cause the method executed by the fault management device as described in the first aspect to be implemented; or cause the method executed by the first fault load device as described in the second aspect to be implemented.

[0045] Eighthly, embodiments of this application provide a computer program product that, when executed by a communication device, causes the method described in any of the first aspects and their possible implementations to be implemented; or causes the method described in any of the second aspects and their possible implementations to be implemented.

[0046] In a ninth aspect, an embodiment of the application provides a communication system, which includes a communication device (such as a fault management device) for performing the method described in the first aspect and a communication device (such as a first fault load device) for performing the method described in the second aspect. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of two commonly used architectures of an NTN communication system;

[0048] Figure 2 This is a schematic diagram of the architecture of a communication system applying an embodiment of this application;

[0049] Figure 3 This is a flowchart illustrating a fault data processing method provided in an embodiment of this application;

[0050] Figure 4 This is a flowchart illustrating another fault data processing method provided in an embodiment of this application;

[0051] Figure 5 This is a flowchart illustrating a fault data processing method provided in an embodiment of this application;

[0052] Figure 6 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0053] Figure 7 This is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0054] The embodiments of this application will now be described with reference to the accompanying drawings.

[0055] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. 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 includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0056] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0057] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0058] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0059] To facilitate understanding of the embodiments of this application, some terms used in the embodiments of this application will be explained below, so that those skilled in the art can understand them. This part is only for the purpose of understanding and should not be regarded as a specific limitation of this application.

[0060] 1. Non-terrestrial network (NTN) communication system

[0061] NTN communication system is a non-periodic communication system that uses satellite technology. NTN communication system is not limited to a specific mobile communication standard, but can support a variety of communication technologies, including but not limited to 4G, 5G, and 6G.

[0062] Compared to terrestrial networks, NTN communication systems have advantages such as wide coverage, long communication distance, high reliability, high flexibility, and high throughput. They are not affected by geographical environment, climate conditions, or natural disasters and have been widely used in aviation communications, maritime communications, military communications, and other fields.

[0063] An NTN communication system may include one or more terminal devices and one or more network devices. The network devices in the NTN communication system may include non-terrestrial network devices. These non-terrestrial network devices can be used to communicate with one or more terminal devices. Non-terrestrial network devices may include satellites, high-altitude platforms (HAPs), drones, hot air balloons, low-Earth orbit satellites, medium-Earth orbit satellites, high-Earth orbit satellites, etc., and are not limited thereto. An NTN communication system may also include access network equipment, core network equipment, etc., which can be referred to as network devices in a terrestrial network.

[0064] (1) System architecture of NTN communication system

[0065] Please see Figure 1 , Figure 1 These are schematic diagrams of two commonly used architectures in NTN communication systems. Both architectures can be understood as NTN-based NG-RAN architectures. Taking a 5G communication system as an example, the access network equipment in an NTN communication system can be a next-generation radio access network (NG-RAN), and the core network equipment can be a 5G core network (5G CN).

[0066] like Figure 1 As shown, an NTN communication system may include at least one terminal device and at least one network device. The terminal device can connect to the network device wirelessly. The network device may include access network devices, core network devices, etc. Figure 1 In this example, satellites are used as non-terrestrial network devices, and base stations are used as access network devices.

[0067] The wireless link between terminal equipment and access network equipment can be called the air interface, such as the NR Uu interface. The NG interface, as the interface between access network equipment and core network equipment, is mainly used for exchanging non-access stratum (NAS) signaling and user service data. The N6 interface can be the interface between core network equipment and equipment in the data network. The data network can include private networks (such as local area networks), external networks (such as the Internet), and operator-deployed proprietary networks (such as networks providing IP multimedia subsystem (IMS) services).

[0068] Specifically, such as Figure 1 The architecture shown in (A) can be called a transparent satellite architecture (e.g., RAN architecture with transparent satellite), or a transparent payload mode or a transparent forwarding mode. Figure 1 As shown in (A), the access network equipment may include base stations and RRUs, which include satellites and ground stations. The satellites are connected to the ground stations and terminal equipment via wireless links, and the ground stations are connected to equipment in the data network via base stations and core network equipment. In this architecture, the satellite primarily acts as a radio frequency repeater, responsible for radio frequency filtering, frequency conversion, and amplification, without demodulating, decoding, or routing the signal. In other words, the satellite can achieve transparent transmission and forwarding.

[0069] like Figure 1 The architecture shown in (B) can be called a regenerative payload mode or a base station onboard mode. For example... Figure 1 The satellite shown in (B) can be described as a regenerative satellite without an inter-satellite link (ISL). Figure 1 In the architecture shown in (B), the satellite acts as an access network device, possessing the processing capabilities of an access network device (such as gNB processed payload). The service link between the terminal device and the satellite is connected via the NR Uu interface, and the feeder link between the ground station and the satellite is connected via the satellite radio interface (SRI). It can be understood that the satellite is equivalent to a mobile base station, capable of directly processing the signals from the terminal device and forwarding them to the ground station or core network. The ground station, acting as a gateway, is responsible for forwarding satellite signals to the core network and interacting with the terrestrial network. In short, in this mode, the satellite possesses base station functionality, processing data before transmitting it to the terminal device.

[0070] (2) Payload equipment associated with the satellite

[0071] The payload equipment associated with a satellite, also known as the satellite's payload, refers to the instruments, equipment, or subsystems that directly perform specific satellite missions. Payload equipment can be connected to the satellite through specific connection mechanisms and interfaces, thereby helping the satellite achieve various functions.

[0072] Each satellite in an NTN communication system may be associated with one or more payload devices. These payload devices may serve different purposes to achieve different functions. For example, the payload devices of a communication satellite may include communication transponders and antennas, while the payload devices of a navigation satellite may include navigation data storage devices and data injection receivers.

[0073] (3) Access network equipment

[0074] Access network equipment is an entity used to transmit or receive signals. It primarily implements functions such as wireless physical control, resource scheduling and wireless resource management, wireless access control, and mobility management, providing reliable wireless transmission protocols and data encryption protocols. This access network equipment can support both wired and wireless access.

[0075] Optionally, the access network equipment can be an access network (AN) / radio access network (RAN) device, consisting of multiple AN / RAN nodes. AN / RAN nodes can include, but are not limited to: access points (APs), enhanced node Bs (eNBs), base band units (BBUs), next-generation node Bs (gNBs), transmission reception points (TRPs), transmission points (TPs), or other access nodes, such as wireless relay nodes, wireless backhaul nodes, etc.

[0076] (4) Core network equipment

[0077] Core network equipment refers to the equipment in the core network (CN) that provides service support for terminal equipment. Core network equipment can include one or more core network elements. Taking the 5G core network as an example, the 5G core network includes access and mobility management function (AMF) network elements responsible for mobility management and access management services; session management function (SMF) network elements responsible for session management; user plane function (UPF) network elements responsible for user plane packet routing and forwarding and quality of service (QoS) control; and policy control function (PCF) network elements. These core network elements can work independently or be combined to implement certain control functions; for example, AMF, SMF, and PCF can be combined into a single core network device. Core network elements can also be called core network entities or functional entities.

[0078] 2. Failure Modes

[0079] Failure modes refer to the manifestation of a failure; they are standardized descriptions of observable or measurable failure phenomena that occur in a product. These failure modes can reflect the possible failure states that may occur at different levels of the product (such as systems, components, parts, etc.).

[0080] Failure mode analysis (FMEA) is crucial for product reliability design, fault prevention, and post-failure repair. In product design, FMEA analysis of the potential failure modes of each component and part of the system determines the severity and hazard of each failure mode, leading to the development of possible preventative and improvement measures. Furthermore, after a failure occurs, observing and measuring the failure phenomena helps identify the failure mode, enabling troubleshooting and repair.

[0081] For example, for satellite-associated payload equipment, possible failure modes include power system failure, communication equipment failure, and environmental adaptability failure. In this application's embodiments, "failure type" refers to "failure mode." Analyzing and predicting various possible failure modes of payload equipment facilitates fault diagnosis and handling, thereby improving the safety and reliability of payload equipment operation.

[0082] In such Figure 1In the NTN communication system shown, the space environment in which the satellite operates differs from the ground environment. For example, the satellite is subject to continuous radiation from various high-energy particles in space, which may cause new malfunctions in the payload equipment associated with the satellite. The types (failure modes) of these new malfunctions may differ from known malfunction types, making it difficult for relevant technicians to quickly and effectively resolve these new malfunctions based on past experience and other handling methods.

[0083] Typically, payload equipment associated with a satellite feeds back fault data to relevant technicians. These technicians can analyze this data to determine how to handle the fault and subsequently improve the payload equipment's hardware and / or software. When a difficult-to-locate fault occurs in a running payload, the fault handling method (referred to as fault handling rules) needs to be designed into the payload equipment's firmware version (essentially, hard-coded into the payload equipment's code). After upgrading the payload equipment's firmware, live network verification is also required. For example, the fault handling method can be applied to the payload equipment and tested in space by launching a satellite to verify its effectiveness. However, implementing this method is costly and has low feasibility. Furthermore, some faults may require multiple firmware upgrades to be fully resolved, resulting in significant time consumption and low efficiency.

[0084] It is evident that fault management in NTN communication systems faces significant challenges.

[0085] In view of this, embodiments of this application provide a fault data processing method, a communication device, and a computer-readable storage medium, which can conveniently and quickly formulate reliable fault handling rule files through machine learning, and can simply and directly configure the rule files into the payload equipment of an operating satellite, thereby effectively handling faults of payload equipment in the NTN communication system.

[0086] First, the system architecture of the communication system in the embodiments of this application will be introduced.

[0087] For example, please refer to Figure 2 , Figure 2 This is a schematic diagram of the architecture of a communication system according to an embodiment of this application. The communication system includes a non-terrestrial network and a terrestrial network. The non-terrestrial network may include multiple payload devices, which are associated with the same satellite. The terrestrial network may include a fault management device. Data exchange is possible between the satellite and the fault management device, and between the payload devices and the fault management device. The connection methods between devices in the terrestrial network and devices in the non-terrestrial network can be referred to as follows: Figure 1 The relevant descriptions of the NTN communication system shown are not repeated here.

[0088] also, Figure 2 The number and type of payload devices included in the architecture shown are merely examples, and the embodiments of this application are not limited thereto. Figure 2 The communication system shown may also include other terminal equipment. The communication system may also include more or fewer payload devices that communicate with the fault management equipment. For example, it may also include multiple payload devices associated with other satellites. For simplicity, they are not described one by one in the accompanying drawings. Optional, such as Figure 2 The communication system shown may also include other network devices, such as Figure 1 The network equipment shown includes access network equipment, core network equipment, etc. For details, please refer to [example...]. Figure 1 The description of the NTN communication system shown is not repeated here.

[0089] The payload equipment associated with the satellite can be considered a type of non-terrestrial network equipment. For example, payload equipment associated with the satellite may include various types of equipment such as base stations, routers, and optical communication equipment. To ensure the normal operation of the payload equipment and thus the safe operation of the satellite associated with it, faults occurring in the payload equipment need to be resolved promptly and effectively.

[0090] Optionally, the payload device may include a module for detecting and handling faults within the payload device; this module can be called a fault diagnosis center. For example, the fault diagnosis center can monitor the payload device's operating status and data, and detect whether a fault has occurred. When a fault is detected, the fault diagnosis center can process it based on its configured rule file. This rule file may include fault types and corresponding fault handling methods (also called fault handling rules). The rule file can be a configuration table. In this way, the version of the rule file is decoupled from the firmware version of the payload device. In other words, fault handling methods and other related content do not need to be hard-coded into the payload device's implementation code, but can be stored in the payload device through the rule file. This allows fault management rules to be easily modified and updated online. In other words, the rule file does not need to be updated along with the payload device's firmware version. Typically, the payload device's firmware version is updated infrequently, such as once a month, while the online update frequency of the rule file can be increased to once a week or once a day. This improves the payload device's ability to respond to faults.

[0091] When the load device is temporarily unable to resolve these faults, it can send its operating data to the fault management device, which will then analyze the faults and develop solutions, thereby enabling the faults in the load device to be successfully handled.

[0092] The fault management device can be viewed as a type of terrestrial network equipment, and can also be a network management device or a network management center. For example, the fault management device can be a network management device in an operation support system (OSS). The fault management device establishes connections with various devices in the communication system, and through these connections, it can perform monitoring and control functions on each device, such as recording and collecting various data from the communication system. In this embodiment, the fault management device can obtain operational data from the payload equipment in the communication system and can also transmit the operational data to the data learning module.

[0093] The fault management device may include a data learning module. This module can be used for machine learning. It can process and analyze the operational data of the payload devices; furthermore, it can perform machine learning based on this operational data to generate rule files for fault handling, and then perform model validation on the generated rule files to verify their effectiveness. If the rule file is determined to be effective after fault handling simulation, the fault handling device can send the rule file to the payload devices in the communication system. In this way, the payload devices can handle the faults according to the received rule files.

[0094] Optionally, the terrestrial network of the communication system may also include a data learning device. The data learning device can be considered a terminal device. It can acquire the aforementioned operational data from the fault management device and perform machine learning based on this data to generate a rule file. After generating the rule file, the data learning device can perform model validation on the generated rule file and, after determining its validity, send the rule file to the fault management device.

[0095] Through such Figure 2 The system architecture shown can improve the design quality of fault management and the efficiency of fault handling.

[0096] Next, a fault data processing method provided by an embodiment of this application will be described by way of example with reference to the accompanying drawings.

[0097] Please see Figure 3 , Figure 3 This is a flowchart illustrating a fault data processing method provided in an embodiment of this application. This fault data processing method can be applied to, for example... Figure 2 The communication system shown. Exemplarily, the method may include, but is not limited to, the following steps:

[0098] S301, at the first moment, the fault management equipment obtains the first operational data from the N payload devices associated with the first satellite.

[0099] Where N is an integer greater than or equal to 1. The first satellite may include communication satellites. If classified according to the type of communication service, the first satellite may include fixed communication satellites, mobile communication satellites, television broadcasting satellites, maritime communication satellites, tracking and data relay satellites, etc.

[0100] The payload devices associated with the first satellite may include base stations, routers, optical communication equipment, and other similar devices. Each of the N payload devices associated with the first satellite records its own operational data during operation, such as operational logs and fault data. The fault management device can periodically acquire the initial operational data of each of the N payload devices associated with the first satellite according to a preset acquisition frequency. Correspondingly, each of the N payload devices can send its operational data to the fault management device according to a preset acquisition frequency. In other words, the fault management device can periodically acquire operational data from each of the N payload devices associated with the first satellite.

[0101] The "first time" refers to the time when the fault management device performs this acquisition operation according to the preset acquisition frequency. For example, assuming the preset acquisition frequency is to acquire operating data once every 5 minutes, and the last time the fault management device acquired operating data was at 12:00, then the first time could be 12:05.

[0102] Optionally, the first operational data of a payload device may include the device's operational data. If the payload device has experienced a failure, its first operational data may include failure data. Failure data may include, but is not limited to, device status information, operating parameters, error codes, timestamps, and associated maintenance records. Optionally, the first operational data of a payload device may include partial operational data from its associated satellites. In this way, the fault management device can better understand the health status and operational performance of each payload device based on its first operational data.

[0103] In one possible implementation, the fault management device can periodically acquire operational data from multiple payload devices associated with the second satellite and multiple payload devices associated with the third satellite. The second and third satellites can be satellites of similar type or function to the first satellite, and they have established communication connections with the fault management device.

[0104] S302, the fault management device generates a first rule file based on the acquired first operating data.

[0105] The first rule file includes the correspondence between fault types and fault handling methods; in other words, it includes the correspondence between fault modes and fault handling methods. Optionally, the first rule file may also include the fault diagnosis method and / or fault alarm method corresponding to the fault type. The first rule file can be used by the first fault-loaded equipment to handle faults corresponding to the fault types.

[0106] Optionally, the fault management device can determine the first fault data from the acquired first operating data. Optionally, based on the first fault data, it can determine which of the N load devices have failed. These failed load devices can be referred to as the first faulty load devices.

[0107] In one possible implementation, the fault management device can perform machine learning based on the acquired first operational data and historical operational data prior to the first time. Further, based on the results of the machine learning, a first rule file is generated. The first operational data includes first fault data, and / or the historical operational data includes historical fault data. The historical operational data prior to the first time can be historical operational data obtained by the fault management device from N load devices prior to the first time, and this historical operational data can be stored in the fault management device. The first fault data includes fault data from each of the N load devices. Similarly, the historical fault data can include fault data sent by one or more load devices prior to the first time.

[0108] In one possible implementation, the fault management device can clean, denoise, format, and standardize the acquired initial operational data to better facilitate machine learning.

[0109] In one possible implementation, the first rule file can be stored in the form of a configuration table. For example, the first rule file may record multiple aspects such as fault logs, fault diagnosis methods, fault alarm methods, and fault handling methods corresponding to each fault type. For example, a first rule file in configuration table form can be shown in Table 1.

[0110] Table 1 Example of a rule file

[0111] Troubleshooting process Fault type corresponding handling rules Fault type X chip multi-bit failure Fault Log Fault identifier, location and number of multi-bit failures Fault diagnosis methods The number of times multiple bits in the same data unit fail is ≥ M. Fault alarm content Alarm identifier, X chip multi-bit event alarm Troubleshooting methods (Chip isolation / chip reset / board reset)

[0112] As shown in Table 1, for the fault type "X chip multi-bit failure" in the payload device, the corresponding fault log can include a fault identification document (ID), the location of the multi-bit failure, and the number of times it occurred. A multi-bit failure refers to the simultaneous occurrence of errors or failures in two or more bits within a single data unit (such as a byte, codeword, or larger data block). The fault diagnosis method for this fault type is as follows: when the number of times the same data unit in the X chip experiences multi-bit failures is greater than or equal to M, a "X chip multi-bit failure" fault is identified. The value of M can be set to a threshold N according to actual needs to adapt to different operating environments or hardware states. For example, M can be set to an integer such as 3 or 4. After diagnosing a "X chip multi-bit failure" fault in the payload device, the payload device can issue an alarm based on the corresponding fault alarm method. This helps maintenance personnel quickly identify and handle the fault, reducing its impact on the payload device. For example, an alarm message can be sent, including the alarm identification number and the alarm content such as "X chip multi-bit event alarm". Furthermore, the load device can handle the fault based on the corresponding fault handling method. For example, the chip that has the fault can be isolated, reset, or the board can be reset, which helps to resolve the fault in a timely manner and ensure the normal operation of the load device.

[0113] In one possible implementation, the fault management device may include a data learning module. After acquiring the first set of operational data, the data learning module can perform machine learning based on the first set of operational data to generate a first rule file.

[0114] Optionally, the data learning module can be a module for offline learning. In this way, when the amount of initial running data is small, or when the amount of faulty data in the initial running data is small, offline learning is more beneficial for generating more accurate rule files based on a larger amount of running data after more running data is acquired.

[0115] In another possible implementation, the fault management device can be connected to a data learning device. After acquiring the first operational data, the fault management device can send the first operational data to the data learning device, which can then perform machine learning based on the first operational data to generate a first rule file. Optionally, the data learning device can also acquire historical operational data prior to the first time point from the fault management device and perform machine learning based on the first operational data and the historical operational data to generate the first rule file. Optionally, the data learning device can be a device for offline learning.

[0116] S303, in response to the first rule file meeting the configuration conditions, the fault management device sends the first rule file to the first faulty load device among the N load devices. Accordingly, the first faulty load device receives the first rule file from the fault management device.

[0117] The first rule file satisfies the configuration conditions if it has been verified that faults corresponding to the fault types recorded in the first rule file can be successfully resolved based on the first rule file. This ensures the effectiveness of the first rule file. The fault digital twin model can be used to simulate the fault handling process between the first satellite and N payload devices.

[0118] Optionally, the first rule file can be input into the fault digital twin model for fault handling simulation. During the simulated fault handling process, in response to the resolution of the fault in the target load device, it is determined that the first rule file meets the configuration conditions. Here, the N load devices include the target load device, and the fault in the target load device is the fault corresponding to the fault type.

[0119] A digital twin (DT) is a digital model built in virtual space using modeling techniques that closely resembles a physical product and reflects its state and behavior in real time. A digital twin not only includes the product's physical attributes but also incorporates its operational data and fault information, providing strong support for product fault prediction, performance optimization, and operation and maintenance management.

[0120] A fault digital twin model is a digital twin model for load equipment, used to simulate the physical properties and operating status of the load equipment. In the fault digital twin model, the process of simulating fault handling based on the first rule file can be seen as a process of model verification of the first rule file. The fault digital twin model can simulate the normal operation, fault occurrence, and fault handling processes of the load equipment, thereby verifying whether faults can be effectively handled based on the first rule file.

[0121] In traditional R&D processes, determining the validity of generated rule documents, such as the first rule document, requires extensive physical prototype manufacturing and testing, which is costly and time-consuming. Launching satellites for in-space testing is not only expensive but also carries the risk of satellite damage or failure due to design flaws or unforeseen factors, potentially impacting the space environment. However, using fault digital twin models allows for multiple trials and optimizations in a virtual environment, significantly reducing R&D costs and avoiding the high costs of physical prototype manufacturing and testing. Furthermore, fault digital twin models can be flexibly adjusted to support future technology upgrades and expansions.

[0122] In one possible implementation, a fault digital twin model can be constructed based on reference modeling data. Optionally, the reference modeling data can be obtained during communication between the sample satellite and the payload equipment associated with the sample satellite. Through the fault digital twin model, the physical properties and operational status of the payload equipment associated with the sample satellite can be simulated. For example, it can simulate the process of handling faults when certain faults occur in the payload equipment associated with the sample satellite during operation in a space environment.

[0123] Optionally, the number of sample satellites can be one or more. Optionally, the sample satellites may include a first satellite, and the payload devices associated with the sample satellites may include N payload devices associated with the first satellite. In this way, the fault digital twin model can more accurately simulate the N payload devices associated with the first satellite, which can improve the reliability of model verification of rule documents such as the first rule file through the fault digital twin model.

[0124] Optionally, the reference modeling data may include one or more of the following: design document data, operation log data, operation alarm data, and communication indicator data of the payload equipment associated with the sample satellite.

[0125] Optionally, design document data may include failure mode design documents (i.e., failure type design documents), FMEA design documents, etc. These design documents can describe in detail the possible failure types, causes, impacts, and preventive measures of the payload equipment associated with the sample satellite. Operation log data refers to the operational status data collected by logging points during the operation of the payload equipment associated with the sample satellite, such as operation logs, performance parameters, alarm information, etc. Optionally, operational alarm data can be determined from the operation log data. Optionally, communication indicator data refers to key performance indicator (KPI) data, used to evaluate the overall performance and operational efficiency of the payload equipment associated with the sample satellite. For example, communication indicator data may include various indicators such as spatial resolution, on-orbit lifetime, failure rate, and spectral range.

[0126] In one possible implementation, in response to the first rule file meeting the configuration conditions, the fault management device can also send the first rule file to N payload devices associated with the first satellite, excluding the first faulty payload device. In this way, these payload devices that are not currently experiencing faults can also be configured with the first rule file to address potential future faults.

[0127] Optionally, the step of simulating fault handling for the first rule file can be implemented by the data learning module in the fault management device. Alternatively, the step of simulating fault handling for the first rule file can be implemented by the data learning device connected to the fault management device.

[0128] In one possible implementation, the fault management device can also send a first rule file to payload devices associated with the second satellite, the third satellite, and other payload devices. The second and third satellites are satellites that have established communication connections with the fault management device and are within its communication range. If the second and third satellites have similar or identical functions to the first satellite, the payload devices associated with the second and third satellites are highly likely to be eligible for the first rule file. Upon receiving the first rule file, these payload devices can check its applicability. This helps ensure the safe operation of more payload devices.

[0129] S304, the first fault-loaded device processes the fault corresponding to the fault type based on the first rule file.

[0130] After receiving the first rule file from the fault management device, the first fault load device can promptly handle the fault based on the first rule file when it detects a fault. Optionally, the N load devices may include one or more first fault load devices.

[0131] In one possible implementation, in response to the first faulty load device detecting a first fault, the first fault can be diagnosed based on the fault diagnosis method in the first rule file. For example, the characteristics of the first fault are compared with the fault diagnosis methods corresponding to each fault type recorded in the first rule file to determine the fault type corresponding to the first fault. An alarm is then issued for the first fault based on the fault alarm method corresponding to the first fault type. For example, a fault alarm message can be sent to a fault management device, carrying the device identification information of the first faulty load device where the first fault occurred, as well as the time and location of the first fault. Further, the first faulty load device can handle the first fault based on the fault handling method corresponding to the first fault type. For example, if the fault type corresponding to the first fault is "Multi-bit failure of chip X" as shown in Table 1, then chip isolation or other processing can be performed on the chip.

[0132] In one possible implementation, the first fault-loaded device, in response to the fault being processed according to the fault type, can generate fault processing log data and send second operational data to the fault management device. The second operational data includes the fault processing log data. Optionally, the fault processing log data may include basic fault processing information (such as timestamp, device number, and location), fault description information (such as fault type and the impact of the fault), the fault processing flow (such as the fault processing method used, the time consumed in processing the fault, and whether new problems were generated after processing), and a device performance evaluation report after fault processing.

[0133] Optionally, the first fault-load device may send second operational data to the fault management device after handling the fault. Alternatively, the first fault-load device may also send the second operational data to the fault management device at a second time. The second time refers to a time determined based on the first time, according to a preset acquisition frequency. For example, if the preset acquisition frequency is 5 minutes, and the first time is 12:05, then the second time could be 12:10.

[0134] In one possible implementation, the fault management device can acquire second operational data from each of the N load devices at a second time. Further, a second rule file can be generated based on the acquired second operational data. In response to the second rule file meeting configuration conditions, the second rule file is sent to the second faulty load device among the N load devices. Thus, the second faulty load device can use the second rule file to handle the corresponding fault.

[0135] Thus, the second operating data from the first faulty load device among the N load devices includes fault handling log data; the second operating data from the load devices other than the first faulty load device among the N load devices does not include fault handling logs.

[0136] Optionally, the fault management device can determine the second faulty load device from N load devices based on the second fault data in the acquired second operating data. In other words, the second faulty load device is the load device that has failed, determined from the acquired second operating data. The number of second faulty load devices may include one or more.

[0137] In one possible implementation, in response to the second rule file meeting the configuration conditions, the fault management device can send the second rule file to each of the N load devices.

[0138] In one possible implementation, each of the N load devices can update its rule file to the first rule file after receiving it. Optionally, upon receiving a second rule file, each of the N load devices can update its rule file from the first rule file to the second rule file. This improves the frequency and efficiency of rule file updates, enabling the load devices to take effective measures to handle faults and thus ensuring the normal operation of the load devices.

[0139] Optionally, the fault management device can periodically send rule files that meet the configuration conditions to the first faulty load device among the N load devices, or to each of the N load devices, so that these load devices can update their rule files in a timely manner. This facilitates the timely detection and handling of faults by the load devices.

[0140] Optionally, one of the N load devices may include a module or unit for handling faults, referred to as a fault diagnosis center. The fault diagnosis center may include a configuration table for configuring rule files. Upon receiving a first rule file, the fault diagnosis center can update the rule file to the first rule file. Upon receiving a second rule file, the fault diagnosis center can update the rule file from the first rule file to the second rule file. Thus, when a fault occurs in a load device, it can be handled according to the rule files configured in the fault diagnosis center.

[0141] In this way, the version of the rule file for each of the N payload devices is decoupled from the firmware version. In other words, fault handling methods and other related content do not need to be hard-coded into the payload device's implementation code; instead, they can be stored in the payload device through rule files. This allows the rule files in the payload devices to be easily modified and updated online. In other words, the version of the rule file does not need to be updated along with the firmware version of the payload device. Typically, the firmware version of the payload device is updated infrequently, such as once a month, while the online update frequency of the rule files can be increased to once a week or once a day. This helps the payload devices quickly identify and resolve potential faults, thereby preventing these faults from developing into more serious ones, and ensuring the stability and reliability of the first satellite and the N payload devices associated with it.

[0142] Through the embodiments of this application, the fault management device can periodically acquire operational data from N payload devices associated with a first satellite, such as acquiring first operational data from each of the N payload devices at a first time, and acquiring second operational data from each of the N payload devices at a second time. The fault management device can generate a rule file based on the acquired operational data. Through a fault digital twin model, fault handling simulation can be performed on the generated rule file to ensure its validity. The fault management device can send the rule file to the N payload devices or to a faulty payload device among the N payload devices, enabling these payload devices to update their rule files online. In this way, these payload devices can efficiently handle faults based on the updated rule files. Therefore, the embodiments of this application can generate valid rule files and can conveniently and efficiently update the rule files in the payload devices, enabling the payload devices to handle faults efficiently, thereby contributing to ensuring the safe operation of the satellite and the payload devices associated with it.

[0143] Please see Figure 4 , Figure 4 This is a flowchart illustrating another fault data processing method provided in an embodiment of this application. Figure 4 As shown, this fault data processing method can be applied to, for example... Figure 2The communication system shown. Exemplarily, the method may include, but is not limited to, the following steps:

[0144] S401, the fault management equipment immediately obtains the first operational data from the N payload devices associated with the first satellite.

[0145] Where N is an integer greater than or equal to 1. For a detailed implementation of S401, please refer to [reference needed]. Figure 3 The description in S301 will not be repeated here.

[0146] S402, the fault management device generates a first rule file based on the acquired first operating data.

[0147] The first rule file includes the correspondence between fault types and fault handling methods. Specifically, the implementation of S402 can be found in... Figure 3 The description in S301 shown will not be repeated here.

[0148] S403, the fault management device inputs the first rule file into the fault digital twin model to perform fault handling simulation in order to determine whether the first rule file meets the configuration conditions.

[0149] During the simulated fault handling process, in response to the resolution of the fault in the target load device, it can be determined that the first rule file meets the configuration conditions.

[0150] For details, please refer to, such as Figure 3 The relevant description in S302.

[0151] S404, in response to the first rule file meeting the configuration conditions, the fault management device sends the first rule file to the first faulty load device among the N load devices. Accordingly, the first faulty load device receives the first rule file from the fault management device.

[0152] Optionally, the fault management device may also send a first rule file to the other load devices among the N load devices, excluding the first faulty load device.

[0153] S405, the first faulty load device updates the rule file to the first rule file.

[0154] This allows the rule file in the first faulty load device to be updated.

[0155] S406, the first fault-loaded device processes the fault based on the first rule file; in response to the fault being processed according to the fault type, fault processing log data is generated.

[0156] S407, the first faulty load device sends second operational data (including fault handling log data) to the fault management device. Correspondingly, the fault management device receives the second operational data from the first faulty load device.

[0157] Optionally, in S408, the fault management device acquires second operational data from N payload devices associated with the first satellite at a second time.

[0158] Among them, the second operating data of the first faulty load device among the N load devices can be obtained when executing S407.

[0159] Optionally, the execution order of S407 and S408 can be arbitrary, and this application does not limit it.

[0160] S409, the fault management device generates a second rule file based on the acquired second operating data.

[0161] S410, in response to the second rule file meeting the configuration conditions, the fault management device sends the second rule file to the first fault load device. Accordingly, the first fault load device receives the second rule file from the fault management device.

[0162] The fault management device can input the second rule file into the fault digital twin model to simulate fault handling and determine whether the second rule file meets the configuration conditions. If the fault of the load device in the fault digital twin model can be successfully resolved based on the second rule file, then the second rule file can be determined to meet the configuration conditions.

[0163] Optionally, in response to the second rule file meeting the configuration conditions, the fault management device may send the second rule file to the second faulty load device among the N load devices. The second faulty load device may be the same device as the first faulty device, or it may be a different device.

[0164] Optionally, in response to the second rule file meeting the configuration conditions, the fault management device may also send the second rule file to the other load devices among the N load devices, excluding the first faulty load device.

[0165] Optionally, if the second rule file does not meet the configuration conditions, the second rule file will not be sent to each of the N load devices.

[0166] S411, the first fault-loaded device updates the rule file from the first rule file to the second rule file.

[0167] In this way, the first faulty load device can update the rule file again to handle the fault more effectively. Based on this, the efficiency of fault handling can be improved.

[0168] According to the embodiments of this application, the fault management device can periodically acquire operational data from N payload devices associated with the first satellite and generate rule files based on the acquired operational data. Through a fault digital twin model, fault handling simulations can be performed on the generated rule files to ensure their effectiveness. The fault management device can send the rule files to the N payload devices or to faulty payload devices among the N payload devices, enabling these payload devices to update their rule files online. In this way, these payload devices can efficiently handle faults based on the updated rule files. Therefore, the embodiments of this application can improve the efficiency of fault handling, thereby contributing to ensuring the safe operation of the satellite and its associated payload devices.

[0169] For example, please refer to Figure 5 , Figure 5 This is a flowchart illustrating another fault data processing method provided in an embodiment of this application. Figure 5 As shown, the fault management device can periodically acquire operational data from multiple payload devices associated with the same satellite. The data learning module within the fault management device can perform machine learning (also known as data training) based on the acquired operational data to generate rule files. Through a fault digital twin model, the fault management device can simulate fault handling on the generated rule files to ensure their validity. Once the rule files are deemed valid, the fault management device can send them to multiple payload devices. This allows these payload devices to periodically update their rule files, and the version of the rule files on the payload devices does not need to be updated along with the firmware version of the payload devices, greatly improving the efficiency of rule file updates. This, in turn, enhances the payload devices' ability to respond to faults and ensures their safe operation.

[0170] In one possible implementation, the technical solutions provided in this application can be applied to various communication systems, such as NTN communication systems, Long Term Evolution (LTE) systems, New Radio (NR) systems, Public Land Mobile Network (PLMN) systems, LTE-Advanced (LTE-A) systems, Device-to-Device (D2D) communication systems, Machine-to-Machine (M2M) communication systems, Internet of Things (IoT), Narrow Band Internet of Things (NB-IoT), Integrated Sensing and Communication Systems, Frequency Division Duplex (FDD) systems, Time Division Duplex (TDD) systems, Wireless Projection Communication Systems, Integrated Access and Backhaul (IAB) Communication Systems, and communication systems evolved after 5G (e.g., 6G communication systems), or can be non-3rd Generation Partnership Project (3GPP) systems. This can refer to a project (3GPP) communication system, or a system that can integrate NTN with other networks, etc., without any restrictions.

[0171] The following describes the communication device involved in the embodiments of this application.

[0172] Please see Figure 6 , Figure 6 This is a schematic diagram of a communication device provided in an embodiment of this application. The communication device may include a transceiver unit 610 and a processing unit 620. The transceiver unit 610 may be a device that has signal input (receiving) or output (transmitting) for transmitting signals with other devices or other components in a device.

[0173] The processing unit 620 can be a device with processing capabilities, and may include one or more processors. The processor can be a general-purpose processor or a dedicated processor. The processor can be a baseband processor or a central processing unit (CPU). The baseband processor can be used to process communication protocols and communication data, while the CPU can be used to control the device (e.g., a host node, relay node, or chip), execute software programs, and process data from the software programs.

[0174] The communication device can be used in fault management equipment or first fault load equipment. Specifically, the communication device can be a fault management equipment or a first fault load equipment, or it can be a device used in fault management equipment or first fault load equipment, such as a chip.

[0175] When the communication device is used in a fault management device, the communication device includes:

[0176] The transceiver unit 610 is used to acquire first operational data from N payload devices associated with the first satellite at the first time; N is an integer greater than or equal to 1.

[0177] The processing unit 620 is used to generate a first rule file based on the acquired first operating data; the first rule file includes the correspondence between fault types and fault handling methods.

[0178] The transceiver unit 610 is also used to send the first rule file to the first faulty load device among the N load devices in response to the first rule file meeting the configuration conditions; the first rule file is used by the first faulty load device to handle the fault corresponding to the fault type.

[0179] In one possible implementation, the transceiver unit 610 is further configured to send the first rule file to the load devices other than the first faulty load device among the N load devices in response to the first rule file meeting the configuration conditions.

[0180] In one possible implementation, the processing unit 620 is further configured to input the first rule file into the fault digital twin model to perform fault handling simulation; the fault digital twin model is used to simulate the fault handling process between the first satellite and N payload devices; during the simulated fault handling process, in response to the fault of the target payload device being resolved, it is determined that the first rule file meets the configuration conditions; wherein, the N payload devices include the target payload device, and the fault of the target payload device is the fault corresponding to the fault type.

[0181] In one possible implementation, the transceiver unit 610 is also used to acquire reference modeling data of the payload device associated with the sample satellite during communication between the sample satellite and the payload device associated with the sample satellite; and to construct a fault digital twin model based on the reference modeling data.

[0182] In one possible implementation, the reference modeling data includes one or more of the following: design document data, operation log data, operation alarm data, and communication indicator data.

[0183] In one possible implementation, the processing unit 620 is further configured to perform machine learning based on the acquired first running data and historical running data prior to the first time; the first running data includes first fault data, and / or the historical running data includes historical fault data; and generate a first rule file based on the results of the machine learning.

[0184] In one possible implementation, the first rule file also includes fault diagnosis methods and / or fault alarm methods corresponding to the fault type.

[0185] In one possible implementation, the transceiver unit 610 is further configured to acquire second operating data from N load devices at a second time; the processing unit 620 is further configured to generate a second rule file based on the acquired second operating data; and in response to the second rule file satisfying the configuration conditions, send the second rule file to the second faulty load device among the N load devices.

[0186] In one possible implementation, the transceiver unit 610 is further configured to send the first rule file to the load devices other than the second faulty load device among the N load devices in response to the second rule file meeting the configuration conditions.

[0187] In one possible implementation, the processing unit 620 is further configured to determine a first faulty load device from N load devices based on the first fault data in the acquired first operating data.

[0188] Alternatively, when the communication device is used for the first failed load device, the communication device includes:

[0189] The transceiver unit 610 is used to receive a first rule file from the fault management device; the first rule file includes the correspondence between fault types and fault handling methods.

[0190] The processing unit 620 is used to process faults corresponding to fault types based on the first rule file.

[0191] In one possible implementation, the transceiver unit 610 is also used to send first operating data to the fault management device at the first moment.

[0192] In one possible implementation, the first rule file also includes fault diagnosis methods and / or fault alarm methods corresponding to the fault type.

[0193] In one possible implementation, the processing unit 620 is also used to update the rule file to the first rule file.

[0194] In one possible implementation, the processing unit 620 is further configured to, in response to detecting the occurrence of a first fault, perform fault diagnosis on the first fault based on the fault diagnosis method in the first rule file, determine the fault type corresponding to the first fault as a first fault type; the fault corresponding to the fault type includes the first fault; issue an alarm for the first fault based on the fault alarm method corresponding to the first fault type; and perform fault handling on the first fault based on the fault handling method corresponding to the first fault type.

[0195] In one possible implementation, the processing unit 620 is further configured to generate fault processing log data in response to the fault being processed according to the fault type; the transceiver unit 610 is configured to send second operating data to the fault management device, the second operating data including the fault processing log data.

[0196] In one possible implementation, transceiver unit 610 is used to receive a second rule file from the fault management system device.

[0197] In one possible implementation, the processing unit 620 is further configured to update the rule file from the first rule file to the second rule file in response to receiving the second rule file.

[0198] Please see Figure 7 , Figure 7 This is a schematic diagram of another communication device provided in an embodiment of this application. It is understood that the communication device includes, for example, modules, units, elements, circuits, or interfaces, which are appropriately configured together to execute this solution. The communication device may be a RAN node, terminal, core network equipment, or other network equipment, or it may be a component (e.g., a chip) within these devices, used to implement the methods described in the method embodiments.

[0199] like Figure 7 As shown, the communication device may include one or more processors 710, which may also be referred to as processing units, and can implement certain control functions. The processor 710 may be a general-purpose processor or a dedicated processor, for example, a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, while the central processing unit can be used to control the communication device (e.g., base station, baseband chip, terminal, terminal chip, DU or CU, etc.), execute software programs, and process data from the software programs.

[0200] In an alternative design, processor 710 may include program 711 (sometimes referred to as code or instructions) that can be run on processor 710 to cause the communication device to perform the methods described in the method embodiments.

[0201] In another alternative design, the processor 710 may include a transceiver unit for implementing receive and transmit functions. For example, this transceiver unit may be a transceiver circuit, an interface, an interface circuit, or a communication interface. The transceiver circuit, interface, or interface circuit for implementing receive and transmit functions may be separate or integrated. The aforementioned transceiver circuit, interface, or interface circuit can be used for reading and writing code / data, or it can be used for transmitting or relaying signals.

[0202] In another possible design, the communication device may include a circuit that can perform the functions of sending, receiving, or communicating in the aforementioned method embodiments.

[0203] Optionally, the communication device may include one or more memories 720 storing a program 721 (sometimes referred to as code or instructions). The program 721 may be run on the processor 710, causing the communication device to perform the methods described in the above method embodiments.

[0204] Optionally, the processor 710 may include an AI module 712, and / or the memory 720 may include an AI module 722. The AI ​​module is used to implement AI-related functions. The AI ​​module can be implemented through software, hardware, or a combination of both. For example, the AI ​​module may include a RIC module. Furthermore, the AI ​​module may be a near real-time RIC or a non-real-time RIC.

[0205] Optionally, data may also be stored in the processor 710 and / or the memory 720. The processor and memory can be configured separately or integrated together. For example, the correspondence described in the above method embodiments can be stored in the memory or in the processor.

[0206] Optionally, the communication device may also include a transceiver 730 and / or an antenna 740. The processor 710, sometimes referred to as a processing unit, controls the communication device (e.g., a RAN node or terminal). The transceiver 730, sometimes referred to as a transceiver unit, transceiver, transceiver circuit, or simply a transceiver, is used to implement the transmission and reception functions of the communication device via the antenna 740.

[0207] Optionally, the communication device can be used to execute the embodiments of this application. Figure 3 or Figure 4 Any method described.

[0208] In one embodiment, the communication device can be a fault management device, a device within a fault management device, or a device compatible with a fault management device. When the computer program instructions stored in the memory 720 are executed, the processor 710 performs the operations performed by the processing unit 620 in the above embodiments. The transceiver 730 performs the operations performed by the transceiver unit 610 in the above embodiments, and the transceiver 730 is also used to send information to other communication devices besides the communication device. The fault management device or the device within the fault management device can also be used to perform the operations described above. Figure 3 or Figure 4 Any method executed by the fault management device in the method embodiment will not be described in detail here.

[0209] In one embodiment, the communication device may be a first fault load device, or a device within the first fault load device, or a device compatible with the first fault load device. When the computer program instructions stored in the memory 720 are executed, the processor 710 controls the transceiver 730 to perform the operations performed by the transceiver unit 610 in the above embodiment. The transceiver 730 is also used to receive information from other communication devices besides the communication device. The first fault load device or the device within the first fault load device may also be used to perform the above... Figure 3 or Figure 4 Any method executed by the first faulty load device in the method embodiment will not be described in detail here.

[0210] The processors and transceivers described in this application can be implemented on integrated circuits (ICs), analog ICs, radio frequency interface chips (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), printed circuit boards (PCBs), electronic devices, etc.

[0211] The communication device described in the above embodiments may be a fault management device or a first fault load device, but the scope of the device described in this application is not limited thereto, and the structure of the communication device may vary. Figure 7 The device has limitations. It can be a standalone device or part of a larger device.

[0212] For example, the communication device could be:

[0213] (1) A standalone integrated circuit (IC), or chip, or chip system, or subsystem:

[0214] (2) A collection of one or more ICs, optionally, the collection of ICs may include a storage component for storing data and / or instructions;

[0215] (3) ASIC, such as modem (mobile station modem, MSM);

[0216] (4) Modules that can be embedded in other devices.

[0217] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a communication device, can implement the method provided in the above-described method embodiments.

[0218] This application also provides a computer program product that, when run on a computer or processor, causes a communication device to perform one or more steps of any of the methods described above. If the constituent modules of the aforementioned devices are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.

[0219] This application provides a chip, including a processor, for calling and executing instructions stored in a memory, causing a communication device on which the chip is installed to perform any of the methods described above.

[0220] This application embodiment also provides another chip, including: an input interface, an output interface, and a processing circuit. The input interface, the output interface, and the processing circuit are connected via internal connection paths. The processing circuit is used to execute any of the methods described above. Optionally, the chip also includes a memory. The input interface, the output interface, the processor, and the memory are connected via internal connection paths. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute any of the methods described above.

[0221] This application also provides a chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform any of the methods described above. This chip system may be composed of chips or may include chips and other discrete devices.

[0222] This application also provides a communication system, which includes a fault management device and N payload devices associated with a first satellite. For detailed description, please refer to... Figure 3 or Figure 4 The method shown in the method embodiment.

[0223] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0224] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0225] In summary, the above description is merely an embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the disclosure of this application should be included within the scope of protection of this application.

Claims

1. A fault data processing method, characterized in that, The method includes: At the first moment, the first operational data is obtained from each of the N payload devices associated with the first satellite; N is an integer greater than or equal to 1. Based on the acquired first operational data, a first rule file is generated; the first rule file includes the correspondence between fault types and fault handling methods; In response to the first rule file meeting the configuration conditions, the first rule file is sent to the first faulty load device among the N load devices; the first rule file is used by the first faulty load device to handle the fault corresponding to the fault type.

2. The method according to claim 1, characterized in that, The method further includes: The first rule file is input into the fault digital twin model to simulate fault handling; the fault digital twin model is used to simulate the fault handling process between the first satellite and the N payload devices; During the simulated fault handling process, in response to the fault of the target load device being resolved, it is determined that the first rule file meets the configuration conditions; The N load devices include the target load device, and the fault of the target load device is the fault corresponding to the fault type.

3. The method according to claim 2, characterized in that, The method further includes: During the communication between the sample satellite and the payload equipment associated with the sample satellite, reference modeling data of the payload equipment associated with the sample satellite is acquired; The fault digital twin model is constructed based on the reference modeling data.

4. The method according to claim 3, characterized in that, The reference modeling data includes one or more of the following: design document data, operation log data, operation alarm data, and communication indicator data.

5. The method according to any one of claims 1-4, characterized in that, The step of generating a first rule file based on the acquired first runtime data includes: Machine learning is performed based on the acquired first operational data and historical operational data prior to the first time; the first operational data includes first fault data, and / or the historical operational data includes historical fault data; Based on the results of machine learning, the first rule file is generated.

6. The method according to any one of claims 1-5, characterized in that, The first rule file also includes the fault diagnosis method and / or fault alarm method corresponding to the fault type.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: At the second time, second operating data is acquired from the N load devices respectively; Based on the acquired second operational data, a second rule file is generated; In response to the second rule file satisfying the configuration conditions, the second rule file is sent to the second faulty load device among the N load devices.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Based on the first fault data in the acquired first operating data, the first faulty load device is determined from the N load devices.

9. A fault data processing method, characterized in that, The method includes: Receive a first rule file from the fault management device; the first rule file includes the correspondence between fault types and fault handling methods; Based on the first rule file, the faults corresponding to the fault types are processed.

10. The method according to claim 9, characterized in that, The method further includes: sending first operating data to the fault management device at a first time.

11. The method according to claim 9 or 10, characterized in that, The method further includes updating the rule file to the first rule file.

12. The method according to any one of claims 9-11, characterized in that, The first rule file also includes the fault diagnosis method and / or fault alarm method corresponding to the fault type.

13. The method according to claim 12, characterized in that, The step of processing the faults corresponding to the fault types based on the first rule file includes: In response to the detection of a first fault, the fault diagnosis is performed on the first fault based on the fault diagnosis method in the first rule file, and the fault type corresponding to the first fault is determined to be a first fault type; the faults corresponding to the fault type include the first fault. Based on the fault alarm method corresponding to the first fault type, an alarm is triggered for the first fault. Based on the fault handling method corresponding to the first fault type, the first fault is handled.

14. The method according to any one of claims 9-13, characterized in that, The method further includes: In response to the fault being processed according to the fault type, fault processing log data is generated; Send second operational data to the fault management device, the second operational data including the fault handling log data.

15. The method according to claim 14, characterized in that, The method further includes: Receive a second rule file from the fault management device.

16. The method according to claim 15, characterized in that, The method further includes: In response to receiving the second rule file, the rule file is updated from the first rule file to the second rule file.

17. A communication device, characterized in that, The communication device includes a module for implementing the method as described in any one of claims 1-8, or includes a module for implementing the method as described in any one of claims 9-16.

18. A communication device, characterized in that, The communication device includes a processor and a transceiver, the transceiver being used to send and receive information, and the processor being used to enable the communication device to implement the method as described in any one of claims 1-8, or to implement the method as described in any one of claims 9-16.

19. A communication device, characterized in that, The communication device includes at least one processor, a memory, and an interface circuit. The memory, the interface circuit, and the at least one processor are interconnected via a line. The at least one memory stores program instructions. The program instructions are used to cause the communication device to perform the method as described in any one of claims 1-8, or to perform the method as described in any one of claims 9-16.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a communication device, implements the method as described in any one of claims 1-8, or the method as described in any one of claims 9-16.

Images