Satellite constellation GNSS receiver on-orbit failure diagnosis system
By establishing an inter-satellite transmission mechanism for health status data within the satellite constellation, and combining expert knowledge and machine learning methods, the problems of insufficient accuracy and real-time performance in satellite fault diagnosis have been solved, enabling rapid fault detection and handling.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-26
- Publication Date
- 2026-04-07
AI Technical Summary
Existing satellite fault diagnosis technologies do not fully utilize the on-orbit historical data of other similar satellites in the constellation, resulting in insufficient accuracy and real-time performance in fault diagnosis, making it difficult to respond quickly to external faults and affecting the normal operation of satellites.
Establish an on-orbit fault diagnosis system for GNSS receivers in a satellite constellation. By integrating expert knowledge and machine learning methods, achieve inter-satellite transmission of health status data and fault diagnosis. Utilize the PMU units on satellites A, B, and L for fault detection and location.
It improves the accuracy and real-time performance of satellite fault diagnosis, reduces the bandwidth pressure on space-ground networks, and enhances the ability to handle faults autonomously in orbit.
Smart Images

Figure CN116794686B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application belongs to the field of fault diagnosis, and more particularly relates to a satellite constellation GNSS receiver on-orbit fault diagnosis system. BACKGROUND
[0002] Traditional satellite fault management is generally when the satellite is in the ground station control area, a communication link is established with the ground station, the monitoring data is downloaded and analyzed by the ground station, the abnormal reason is analyzed by the control personnel and the designer, and finally the fault disposal instruction is uploaded to complete the satellite fault recovery. However, due to the limited control resources, long information transmission and response period of the ground-sky link, it is difficult to quickly respond to the fault occurring outside the station, which may seriously affect the normal operation of the satellite. Therefore, the on-orbit fault diagnosis system can automatically detect faults and push fault disposal programs by moving data analysis, fault diagnosis calculation and data storage from the ground system to the near-state monitoring data source of the space-based load management unit, quickly solving the fault and recovering the effective load to the normal state, which can effectively reduce the network bandwidth pressure of the earth and improve the real-time response ability of satellite fault positioning and autonomous disposal in orbit.
[0003] The existing satellite fault diagnosis technology only considers the on-orbit operation data of the satellite, and does not fully utilize the on-orbit historical data of other similar satellites in the constellation, resulting in a waste of a large amount of valuable information. SUMMARY
[0004] By fusing similar satellite fault data, cross-domain fault diagnosis technology research can be carried out to improve the accuracy of fault diagnosis, which is an important development direction of spacecraft health management technology. How to establish a health state data exchange mechanism in the fault diagnosis system in accordance with the space-based interstellar communication protocol is the premise of realizing cross-domain fault diagnosis, therefore, the present application proposes a satellite constellation GNSS receiver on-orbit fault diagnosis system.
[0005] The purpose of the present application is to solve the above-mentioned shortcomings in the prior art, and to provide a satellite constellation GNSS receiver on-orbit fault diagnosis system, to establish a health state data interstellar transmission mechanism of the satellite constellation on-orbit fault diagnosis system, and to improve the on-orbit fault diagnosis and disposal effect by fusing expert knowledge and machine learning methods to meet the requirements of on-orbit fault diagnosis accuracy and real-time performance.
[0006] To achieve the above purpose, the present application provides the following technical scheme:
[0007] An on-orbit fault diagnosis system for GNSS receivers in a satellite constellation is disclosed. The system is used to perform on-orbit fault diagnosis on GNSS receivers deployed on a satellite constellation consisting of three satellites: A, B, and L. The satellite constellation is used for space-based orbit determination and autonomous navigation of spacecraft in the Earth-Moon space, and carries various experimental payloads to manage the on-board payloads. It also conducts inter-satellite / satellite-to-ground networking communication and provides on-board computing resources for navigation missions.
[0008] The system has built-in PMU units deployed on satellites A, B, and L. Each PMU unit includes two configuration items: a main control unit and a data management unit. The main control unit and the data management unit communicate with each other via an EMI bus. The main control software interacts with the GNSS receiver via a CAN bus.
[0009] The system includes:
[0010] Local satellite health data processing unit, local satellite fault diagnosis unit, inter-satellite health data processing unit, inter-satellite fault diagnosis unit;
[0011] The local satellite health data processing unit is used to receive the local satellite GNSS receiver payload working parameter data sent by the PMU main control software, parse the working parameter data according to the PMU and payload CAN bus communication protocol, and then extract key health status-related parameters such as satellite status, number of tracked satellites, number of positioning satellites, and maximum and minimum carrier-to-noise ratio of the antenna according to the diagnostic algorithm requirements, and then send the extracted parameters to the local satellite fault diagnosis unit.
[0012] The local satellite fault diagnosis unit is used to receive the local satellite GNSS receiver payload health characterization data after engineering parameter analysis and parameter extraction, automatically detect and locate faults based on the fault diagnosis model, and put the fault classification results into the PMU engineering parameter storage disk.
[0013] The inter-satellite health data processing unit is used to access and read the health characterization data of the inter-satellite GNSS receiver payload, parse the health characterization data according to the inter-satellite communication protocol, and then send the parsed data to the inter-satellite fault diagnosis unit.
[0014] The inter-satellite fault diagnosis unit is used to receive the parsed inter-satellite GNSS receiver payload health characterization data, automatically detect and locate faults based on the on-orbit fault diagnosis model, and put the fault classification results into the PMU parameter storage disk.
[0015] Preferably, in the local satellite fault diagnosis unit and the inter-satellite fault diagnosis unit, the knowledge-driven fault diagnosis model forms fault mode interpretation rules and outputs fault mode inference results based on the fault diagnosis configuration file and multiple judgment logics corresponding to the fault mode, while the data-driven fault diagnosis model predicts the fault mode category based on the trained and debugged machine learning classification model.
[0016] Preferably, the on-orbit fault diagnosis software of the local satellite health data processing unit communicates with the PMU through an input identifier and a health data interface, identifies the input data category as local satellite GNSS receiver operating parameter data, and parses and extracts health characterization data related to the health status of the local satellite GNSS receiver, specifically:
[0017] Input: GNSS receiver operating parameters of this satellite;
[0018] Processing: Based on the PMU and GNSS payload CAN bus communication protocol, analyze the operating parameter data of the local satellite GNSS receiver and extract health characterization data;
[0019] Output: Processed local GNSS receiver payload health characterization data.
[0020] Preferably, the local satellite fault diagnosis unit receives the parsed local satellite GNSS receiver payload health characterization data, performs fault classification, and sends the local satellite GNSS receiver fault diagnosis results to the PMU, specifically as follows:
[0021] Input: Processed local GNSS receiver payload health characterization data;
[0022] Solution: Use a fault diagnosis model to classify faults;
[0023] Output: Fault diagnosis results for the local satellite GNSS receiver.
[0024] Preferably, the on-orbit fault diagnosis software of the inter-satellite health data processing unit communicates with the PMU through an input identifier and a health data interface, identifying the input data category as inter-satellite GNSS receiver data, specifically:
[0025] Input: Health characterization data of inter-satellite GNSS receivers, or fault diagnosis results data from other satellites;
[0026] Processing: Based on the inter-satellite / satellite-to-ground data frame format definition, if the access reads GNSS receiver operating parameter data, the inter-satellite GNSS receiver health characterization data is parsed; if the access reads fault diagnosis result data of another satellite, the fault diagnosis model is skipped and sent directly to the PMU.
[0027] Output: Parsed inter-satellite GNSS receiver payload health characterization data, or fault diagnosis results data from other satellites.
[0028] Preferably, the inter-satellite fault diagnosis unit receives the parsed inter-satellite GNSS receiver payload health characterization data, performs fault classification, and sends the inter-satellite GNSS receiver fault diagnosis results to the PMU, specifically as follows:
[0029] Input: Parsed inter-satellite GNSS receiver payload health characterization data;
[0030] Solution: Use an on-orbit fault diagnosis model to classify faults;
[0031] Output: Fault diagnosis results for inter-satellite GNSS receivers.
[0032] Preferably, the local GNSS receiver payload data and the inter-satellite GNSS receiver payload health characterization data transmitted from other satellites are input to the on-orbit fault diagnosis unit via the PMU for data processing and fault diagnosis. The fault diagnosis results are then output to the PMU as its working parameters and subsequently transmitted to the satellite service platform.
[0033] Preferably, the external interface of the system includes:
[0034] System and PMU diagnostic input unit interface; system and PMU diagnostic output unit interface; system and satellite data management unit remote control soft interface; system and satellite data management unit telemetry soft interface; system and satellite data management unit configuration item parameter soft interface.
[0035] Preferably, the diagnostic input unit interface includes GNSS receiver operating parameter data of A, B, or L local satellite, including GNSS receiver health characterization data transmitted between satellites, or fault diagnosis results transmitted between satellites.
[0036] The system's diagnostic output unit interface with the PMU includes results from both knowledge-driven and data-driven fault diagnosis methods. The PMU sends polling commands to the system in a point-to-point communication mode. Only after receiving this command can the system send corresponding data to the point and poll the output flag. When the flag is 0, it indicates that the unit calculation is incomplete and there is no data output. When the flag is 1, it indicates that the unit calculation is complete and there is data output. Then, the category of the output diagnostic result is identified. When the category is 0, it indicates a fault diagnosis result of the local GNSS receiver; when the category is 1, it indicates an inter-satellite GNSS receiver fault diagnosis result; and when the category is 2, it indicates an inter-satellite GNSS receiver fault diagnosis result data transmitted through another satellite.
[0037] Preferably, the fault diagnosis execution process is as follows:
[0038] In local satellite mode, the data management system creates a fault diagnosis system thread. This thread is blocked by a semaphore. Whenever the PMU master control software receives GNSS operational parameter data reaching a preset value, it first writes the data to disk, then copies the data to a dedicated memory buffer for the fault diagnosis system. The semaphore block is then released, and the buffer is passed as a parameter to the local satellite algorithm interface. Once the algorithm interface completes its operation, the returned result is stored in the PMU operational parameter disk and sent down to the ground via a downlink task. Simultaneously, inter-satellite health characterization data is returned for use as a parameter in the inter-satellite mode algorithm. Then, the local satellite fault diagnosis operation of the GNSS on-orbit fault diagnosis system ends, and the thread enters a blocked state, waiting for the next semaphore release.
[0039] In inter-satellite mode, the data management system assembles the inter-satellite health characterization data generated after calculation in this satellite mode into a satellite-to-ground frame and sends it to another satellite through the K payload. In inter-satellite mode, it is agreed that the ground injects the PMU's own command to initiate the transmission only when there is a link between the two satellites and on-orbit communication resources. Each time the ground initiates the transmission, a satellite-to-ground frame with a specific number is generated. After the algorithm interface completes its operation, the returned result is put into the PMU's parameter storage.
[0040] Technical effects and advantages of the present invention: Compared with traditional technologies, the on-orbit fault diagnosis system for GNSS receivers provided by the present invention establishes an inter-satellite transmission mechanism for health status data of the on-orbit fault diagnosis system. At the same time, by integrating expert knowledge and machine learning methods, it addresses the requirements for accuracy and real-time performance of on-orbit fault diagnosis, thereby improving the effectiveness of on-orbit fault diagnosis and handling. Attached Figure Description
[0041] Figure 1 This is an interactive diagram of the satellite constellation system of the present invention;
[0042] Figure 2 This is a diagram of the on-orbit fault diagnosis unit architecture of the present invention;
[0043] Figure 3 This is an interface diagram of the on-orbit fault diagnosis system of the present invention;
[0044] Figure 4 This is a data flow interaction diagram for the configuration item 0 of the on-orbit fault diagnosis unit of the present invention;
[0045] Figure 5 This is an architecture diagram of the anomaly detection and alarm unit in an embodiment of the present invention;
[0046] Figure 6 This is a flowchart of the data parsing process of the present invention;
[0047] Figure 7 This is a schematic diagram of the PMU interface in an embodiment of the present invention;
[0048] Figure 8 This is a flowchart of the fault diagnosis and processing procedure in the local satellite mode of this invention embodiment;
[0049] Figure 9 The following is a flowchart illustrating the specific implementation strategy of inter-satellite verification, taking B→L satellite as an example in this embodiment of the invention. Detailed Implementation
[0050] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.
[0051] This invention provides, for example Figures 1-4 An on-orbit fault diagnosis system for a satellite constellation GNSS receiver is proposed. The system is used to diagnose a satellite constellation consisting of three satellites: A, B, and L. The satellite constellation is used for space-based orbit determination and autonomous navigation of spacecraft in the Earth-Moon space. It also carries various experimental payloads, manages the on-board payloads, and conducts inter-satellite / satellite-to-ground networking communication to provide on-board computing resources for navigation missions.
[0052] The system has built-in PMU units deployed on satellites A, B, and L. Each PMU unit includes two configuration items: a main control unit and a data management unit. The main control software is responsible for CAN bus information processing, while the data management software is responsible for data management and storage. The main control and data management configuration items communicate via EMI bus, and the main control software interacts with the GNSS receiver via CAN bus.
[0053] The fault diagnosis system performs on-orbit fault diagnosis for the GNSS receivers deployed on the three satellites, both locally and between satellites. The data management software is run by a separate thread within the Zynq board chip.
[0054] The system includes:
[0055] Local satellite real-time health characterization data processing unit, local satellite real-time fault diagnosis unit, inter-satellite health data transmission and processing unit, inter-satellite fault diagnosis unit;
[0056] The local satellite real-time health characterization data processing unit is used to receive local satellite GNSS receiver payload health characterization data sent by PMU in real time, parse and preprocess the health characterization data according to the communication protocol, and then send the processed data to the local satellite real-time fault diagnosis unit.
[0057] like Figure 7As shown, the local satellite fault diagnosis unit is used to receive the local satellite GNSS receiver payload health characterization data after engineering parameter analysis and parameter extraction, automatically detect and locate faults based on the fault diagnosis model, and store the fault classification results in the PMU engineering parameter storage disk; specifically, see Appendix Figure 8 In local satellite mode, the data management system creates a fault diagnosis system thread. This thread is blocked by semaphores. Whenever the PMU master control software receives 128KB of GNSS engineering parameter data, it first writes the data to disk, then copies the data to a dedicated memory buffer for the fault diagnosis system. The semaphore blocking is then released, and the buffer is passed as a parameter to the local satellite algorithm interface. Once the algorithm interface completes its operation, it places a 32-byte return result into the PMU engineering parameter storage disk and sends it down to the ground with the downlink task. Simultaneously, it returns 110 bytes of inter-satellite health characterization data for use as a parameter in the inter-satellite mode algorithm. In local satellite mode, the carrier management system does not process this 110-byte inter-satellite health characterization data; only the inter-satellite mode processes it.
[0058] Then the local fault diagnosis operation of the GNSS on-orbit fault diagnosis system ends, and the thread enters a blocked state to wait for the next semaphore to be unblocked; that is, after the PMU is powered on, the GNSS on-orbit fault diagnosis system thread runs once every 128KB of GNSS working parameters are received.
[0059] The inter-satellite health data processing unit is used to access and read the health characterization data of the inter-satellite GNSS receiver payload, parse the health characterization data according to the inter-satellite communication protocol, and then send the parsed data to the inter-satellite fault diagnosis unit.
[0060] The inter-satellite fault diagnosis unit is used to receive the parsed inter-satellite GNSS receiver payload health characterization data, automatically detect and locate faults based on the on-orbit fault diagnosis model, and put the fault classification results into the PMU parameter storage disk.
[0061] Specifically, in inter-satellite mode, the data management system assembles the 110-byte inter-satellite health characterization data array generated in this satellite mode into a 128B satellite-to-ground frame with APID=99H, and transmits it to another satellite via the K payload. In inter-satellite mode, it is agreed that the transmission is initiated by the ground-based PMU (Power Management Unit) under the premise that there is a link between the two satellites and on-orbit communication resources. Each time the ground initiates a transmission, a satellite-to-ground frame with a specific number is generated. After the algorithm interface completes its operation, it returns a 4-byte value and stores it in the PMU's parameter storage.
[0062] Taking B→L star as an example, see appendix. Figure 9 The specific implementation strategy for inter-satellite verification of the on-orbit fault diagnosis system is as follows:
[0063] Deploy on-orbit fault diagnosis systems in the PMU data management configuration items of satellites B and L;
[0064] Once the ground confirms that the link between satellite B and satellite L is established, the ground control system sends a PMU uploading command to satellite B.
[0065] After receiving the instruction, the B satellite PMU forwards it to the on-orbit fault diagnosis system, which outputs the inter-satellite health data to be forwarded to the L satellite and the B satellite GNSS fault diagnosis results.
[0066] The B-satellite data management system combines inter-satellite health data and B-satellite GNSS fault diagnosis results into a 128B inter-satellite packet, which is then transmitted to the L-satellite via the K payload. The K payload is carried on three satellites and is used to send and receive application data from other payloads, enabling inter-satellite / inter-planetary payload communication.
[0067] After receiving the inter-satellite packet, the L satellite PMU forwards the inter-satellite health data to the on-orbit fault diagnosis system on the L satellite.
[0068] After the L-satellite fault diagnosis algorithm completes its calculation, it outputs a 4-byte L-satellite GNSS fault diagnosis result and outputs the L-satellite PMU. The PMU then puts the L-satellite and B-satellite GNSS fault diagnosis results into the working parameter disk and sends them down to the ground with the data transmission task.
[0069] Finish.
[0070] The specific number of bytes in the above examples is only for illustrative purposes. In a specific project, the specific number of bytes can be set according to the actual needs of the project.
[0071] Based on the above, the functions of the on-orbit fault diagnosis system are as follows:
[0072] The on-orbit fault diagnosis unit for GNSS receivers is deployed in the Payload Management Unit (PMU) of satellites A, B, and L, and mainly performs three types of functions:
[0073] Function 1: Local GNSS receiver fault diagnosis.
[0074] The on-orbit fault diagnosis module deployed on the PMUs of satellites B and L enables real-time on-orbit fault diagnosis of the local GNSS receiver, and the diagnosis results are stored and transmitted to the ground in data transmission mode.
[0075] Function 2: Transmission of health characterization data and fault diagnosis of inter-satellite GNSS receivers.
[0076] L→B Data Transmission and Fault Diagnosis. After confirming the L-satellite and B-satellite link establishment sequence on the ground, the ground control system sends a PMU uploading command to L-satellite. Upon receiving this command, the L-satellite PMU triggers the L-satellite on-orbit fault diagnosis unit, outputting key telemetry data from the L-satellite GNSS precise orbit determination and timing receiver. The carrier receiver assembles this data into an inter-satellite packet and transmits it to B-satellite via the Ka link. The B-satellite carrier receiver determines the type of the inter-satellite packet, identifies it, and transmits it to the B-satellite on-orbit fault diagnosis unit. Key telemetry data is extracted for fault diagnosis, and the diagnosis results are stored and then transmitted to the ground in data transmission mode.
[0077] B→L Data Transmission and Fault Diagnosis. After confirming the link establishment sequence between B and L satellites on the ground, the ground control system sends a PMU uploading command to B satellite. Upon receiving this command, the B satellite PMU triggers the B satellite on-orbit fault diagnosis unit, outputting key telemetry data from the B satellite's weak GNSS signal navigation receiver. The carrier receiver assembles this data into an inter-satellite packet and transmits it to L satellite via the Ka link. The L satellite carrier receiver determines the type of the inter-satellite packet, identifies it, and transmits it to the L satellite on-orbit fault diagnosis unit. Key telemetry data is extracted for fault diagnosis, and the diagnosis results are stored and then transmitted to the ground in data transmission mode.
[0078] Function 3: Inter-satellite GNSS receiver fault diagnosis result exchange and processing. Inter-satellite fault diagnosis result exchange facilitates real-time monitoring of the health status of each payload on the ground.
[0079] The L satellite PMU transmits the fault diagnosis results to the B satellite via the inter-satellite link, which then sends them to the ground.
[0080] The fault diagnosis results from satellites B and L are transmitted to satellite A via inter-satellite links and then downlinked to the ground.
[0081] The functions of each module in the on-orbit fault diagnosis system are as follows:
[0082] Real-time health indicator data processing of this satellite
[0083] The system receives real-time health characterization data (key digital and analog telemetry data) of the local GNSS receiver payload sent by the PMU, parses and preprocesses the health characterization data according to the communication protocol, and then sends the processed data to the local real-time fault diagnosis unit.
[0084] Real-time fault diagnosis for this satellite
[0085] The system receives and analyzes real-time health characterization data from the local GNSS receiver payload. Based on an on-orbit fault diagnosis model, it automatically detects and locates faults, and sends the fault classification results to the PMU. The knowledge-driven fault diagnosis model, based on a fault diagnosis configuration file and multiple judgment criteria corresponding to each fault mode, forms fault mode interpretation rules and outputs fault mode inference results. The data-driven fault diagnosis model, based on a trained and debugged machine learning classification model, predicts the fault model category.
[0086] Inter-satellite health data exchange and processing
[0087] The system accesses and reads health characterization data (key digital and analog telemetry data) from the inter-satellite GNSS receiver payload, parses and preprocesses the health characterization data according to the communication protocol, and then sends the processed data to the inter-satellite fault diagnosis unit. In addition, it receives and transmits inter-satellite transmitted fault diagnosis results data to the PMU.
[0088] Inter-satellite fault diagnosis
[0089] The system receives and analyzes the health characterization data of the inter-satellite GNSS receiver payload, automatically detects and locates faults based on an on-orbit fault diagnosis model, and sends the fault classification results to the PMU. Specifically, the knowledge-driven fault diagnosis model, based on the fault diagnosis configuration file and multiple judgment logics corresponding to the fault mode, forms fault mode interpretation rules and outputs fault mode inference results. The data-driven fault diagnosis model, based on a trained and debugged machine learning classification model, predicts the fault model category.
[0090] It should be noted in this embodiment that the system's external interfaces include:
[0091] System and PMU diagnostic input unit interface; system and PMU diagnostic output unit interface; system and satellite data management unit remote control soft interface; system and satellite data management unit telemetry soft interface; system and satellite data management unit configuration item parameter soft interface.
[0092] Diagnostic Input Unit Interface
[0093] Interface content: Real-time health data of this satellite and inter-satellite health data (delay, manual injection commands from the ground). Specifically, this includes GNSS receiver health data for both B and L satellites, including GNSS receiver operating parameter data related to health status, or fault diagnosis results transmitted between satellites. It also includes GNSS receiver telemetry message frames received by the PMU, including complete data blocks of single-frame and composite-frame types.
[0094] The PMU initiates the transmission of input messages to this system, according to the following conventions:
[0095] Based on the PMU polling message frames, the system responds with a single frame or a composite frame depending on the message frame type.
[0096] The system only receives the PMU-initiated command and data block injection message frames without responding.
[0097] Based on the satellite-to-ground / inter-satellite data frame format definition, the source ID is identified by analyzing the data source flag, clarifying the data source and destination, and reading the data field. Valid health data is read from the data field at a frequency of 1 MB / time (data received from the PMU), and diagnostic calculations are completed within 10 minutes. The input flag is polled; when the flag is 1, it indicates data input, and the input data category is identified. When the category is 0, the data source is the local satellite GNSS receiver data interface; when the category is 1, the data source is the inter-satellite GNSS receiver operating parameter data from the K-link payload data interface; when the category is 2, the data source is the inter-satellite GNSS receiver fault diagnosis result data from the K-link payload data interface.
[0098] Engineering parameter data
[0099] When the input data category is 0 or 1, the obtained health data is the health characterization data of the local or inter-satellite GNSS receiver payload.
[0100] Diagnostic results data
[0101] When the input data category is 2, that is, the obtained health data is the fault diagnosis result data of the inter-satellite GNSS receiver, it is directly transmitted to the diagnosis result interface and the output flag is marked.
[0102] Diagnostic output unit interface
[0103] Interface content: Fault diagnosis results. This includes results from both knowledge-driven and data-driven fault diagnosis methods.
[0104] The PMU sends polling commands to the system in point-to-point communication mode. The system can only send corresponding data to the point after receiving this command. The output flag is polled; when the flag is 0, it indicates that the unit calculation is incomplete and there is no data output. When the flag is 1, it indicates that the unit calculation is complete and there is data output. Then, the category of the output diagnostic result is identified: when the category is 0, it represents a fault diagnosis result for the local GNSS receiver; when the category is 1, it represents an inter-satellite fault diagnosis result for the inter-satellite GNSS receiver; and when the category is 2, it represents inter-satellite GNSS receiver fault diagnosis result data transmitted via the K-band.
[0105] Remote control soft interface
[0106] Interface content: Enable control. This allows you to enable / disable the system via commands. Data types can be request / response messages, and the interface type can be a REST API.
[0107] Telemetry soft interface
[0108] Interface content includes: heartbeat, input count (count of received data and commands), output count (number of fault diagnosis calculations), program running status (idle / calculating / requires refactoring), reset count, and dog bark count. Data types can be request / response messages, and the interface type can be a REST API.
[0109] Configuration Item Parameters Soft Interface
[0110] Interface content: Instruction injection information.
[0111] As the system is reconfigured, updated data is injected into the ground-based fault diagnosis model or fault knowledge, which is then uploaded to the PMUs of each satellite to achieve on-orbit fault diagnosis unit updates.
[0112] Example 1
[0113] The on-orbit fault diagnosis system is developed using embedded systems and deployed in C code on the PMU data computing board Zynq. The operating environment is a Debian GNU / Linux system with a GCC compiler. The main stages of GNSS on-orbit fault diagnosis include:
[0114] In-orbit data acquisition and analysis.
[0115] Communication with the PMU is achieved through input identifiers and data interfaces. The input data category is identified as payload operational parameter data. Health characterization data related to the health status of the local GNSS receiver is extracted and analyzed in real time. Based on the inter-satellite / satellite-to-ground data frame format definition, valid operational parameter data is obtained. Combined with the communication protocol, the health characterization data of the local GNSS receiver is analyzed in real time. The data analysis process is detailed in [link to documentation]. Figure 6 Then, data preprocessing is carried out.
[0116] Integrated fault diagnosis model.
[0117] An integrated fault diagnosis system that combines expert systems and AI algorithms is used to obtain diagnostic results from the parsed data using fault rules and AI fault diagnosis methods. The final fault diagnosis results are mainly based on diagnostic rules based on prior knowledge, supplemented by diagnostic rules based on AI.
[0118] The above specifically refers to:
[0119] Fault diagnosis criteria and corresponding handling procedures are established as a GNSS receiver fault contingency plan within the expert system knowledge base. Knowledge-driven GNSS fault diagnosis covers four types of known fault rules: power supply faults, communication interface faults, positioning and orbit determination faults, and timing faults.
[0120] Fault diagnosis based on machine learning
[0121] Considering the limitations of the payload management unit's computational and storage capabilities, and to avoid overly complex models, only four typical fault modes outside the receiver's contingency plan library are selected: ephemeris fault, pseudorange error fault, satellite reception anomaly, and PVT uniformity anomaly. These four types of faults cover four common application fault and anomaly situations of GNSS receivers from the transmitter, transmission path, and receiver, respectively. All four types of faults can be simulated on the ground, facilitating subsequent fault identification, classification, and pre-recommendation of handling solutions through diagnostic model methods. In practical applications, the intelligent fault diagnosis model uses the GNSS receiver's operating parameters as input to diagnose faults.
[0122] Ephemeris malfunction
[0123] Satellite ephemeris determines various parameters of a spacecraft, such as time, coordinates, azimuth, and velocity, based on the mathematical relationships between the six orbital parameters according to Kepler's laws. It boasts extremely high accuracy, precisely calculating, predicting, depicting, and tracking the time, position, velocity, and other operational status of satellites and spacecraft. This information is broadcast to users via ephemeris. If the ephemeris fails to receive timely updates, users will not receive updated satellite parameters, leading to a decrease in navigation accuracy.
[0124] Occasional missing navigation ephemeris data has little impact on receivers in use, as expired ephemeris data can be used. However, if the missing data is for an extended period, the accuracy will diverge until it becomes unusable.
[0125] pseudorange error fault
[0126] Pseudorange refers to the distance measured during satellite positioning. Due to unavoidable clock discrepancies between the GNSS system and the receiver, and the influence of various factors during signal propagation, the distance measured directly using this method does not equal the true distance between the satellite and the receiver. Therefore, the calculated distance is called pseudorange. Because of the non-ideal characteristics of navigation signals, receivers with different technical specifications will produce deviations in the magnitude and direction of their pseudorange measurements, known as pseudorange error. The measurement fluctuations and inaccuracies caused by this error constitute pseudorange error faults.
[0127] Satellite reception anomaly
[0128] Satellite reception anomalies refer to situations where severe interference or obstruction affects the normal reception of radio signals, preventing the receiver from receiving the expected number of satellite signals. A reduction in the number of satellites received significantly impacts the reliability of received data and Autonomous Integrity Monitoring (RAIM), lowering the data's credibility.
[0129] PVT uniformity abnormality
[0130] Ideally, the positioning and other operational information transmitted to the user by the GNSS receiver after receiving the signal should be uniformly distributed in terms of time, location, and velocity. There should be no large jumps, data loss, high delays, or continuous output of the same value. If such situations occur, the reliability of the data provided by the GNSS receiver will be significantly reduced, and this is considered a system failure.
[0131] Taking the supervised Support Vector Machine (SVM) algorithm as an example, key health monitoring parameters are used as model inputs. The SVM is trained using fault or sub-health data simulated by a simulator. After training, the SVM can diagnose four types of faults and normal states. Developers use embedded unit engineering to parse GNSS receiver health status data, implement and deploy the SVM fault diagnosis model in C language, analyze and process the monitoring data, and achieve on-orbit fault diagnosis functionality.
[0132] Data-driven fault diagnosis rules include: input data normalization, feature selection, and fault diagnosis.
[0133] (1) Input data 0-1 normalization
[0134]
[0135] Note: After data normalization, data of the same dimension will be limited to the range of 0-1, which can speed up the gradient descent to find the optimal solution; make features have the same measurement scale; and eliminate the adverse effects caused by singular sample data, etc.
[0136] (2) Feature selection
[0137] Feature selection primarily involves choosing features that have a relatively small or even ineffective impact on the model. In this task, two methods are used for feature selection: ① manual feature selection combining failure mode, mechanism, and impact analysis; ② feature selection based on recursive feature elimination (RFE).
[0138] Among the GNSS features that are manually removed are: count information, time information, data with particularly large values that are difficult to determine the range, and data that does not change over time.
[0139] Feature selection based on RFE (Recursive Forward Selection) builds upon manual selection by using machine learning to select the optimal set of features most relevant to the fault and the optimal number of features. Combining the SVM algorithm as a base classifier, SVM-RFE is a sequential backward selection algorithm based on the maximum margin principle of SVM. It trains the model on samples, scores and sorts each feature, removes the feature with the lowest score, retrains the model with the remaining features, performs the next iteration, and finally selects the required number of features.
[0140] The key GNSS features ultimately selected through the above two methods include approximately 11 parameters such as satellite status, number of tracked satellites, number of positioning satellites, and the highest and lowest carrier-to-noise ratio of the antenna.
[0141] (3) Fault Diagnosis
[0142] The collected engineering parameter data is analyzed, and effective features are selected and normalized. The normalized features are then transmitted to the fault diagnosis module based on struct-svm to obtain five types of prediction results: ephemeris fault, pseudorange error fault, satellite reception anomaly, PVT uniformity anomaly, and normal.
[0143] Finally, it should be noted that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make substitutions for some of the technical features. Any modifications, substitutions, or improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. An on-orbit fault diagnosis system for a satellite constellation GNSS receiver, characterized in that, The system is used to perform on-orbit fault diagnosis of GNSS receivers deployed on a satellite constellation consisting of three satellites: A, B, and L. The satellite constellation is used for space-based orbit determination and autonomous navigation of spacecraft in the Earth-Moon space, and carries a variety of experimental payloads to manage the on-board payloads. It also conducts inter-satellite / satellite-to-ground networking communication and provides on-board computing resources for navigation missions. The system has a built-in payload management unit (PMU) deployed on satellites A, B, and L. The PMU unit includes two configuration items: main control and data management. The main control and data management configuration items communicate with each other via EMI bus. The main control software interacts with the GNSS receiver via CAN bus. The system includes: Local satellite health data processing unit, local satellite fault diagnosis unit, inter-satellite health data processing unit, inter-satellite fault diagnosis unit; The local satellite health data processing unit is used to receive the local satellite GNSS receiver payload working parameter data sent by the PMU main control software, parse the working parameter data according to the PMU and payload CAN bus communication protocol, and then extract the key satellite status, number of tracked satellites, number of positioning satellites, and antenna maximum and minimum carrier-to-noise ratio health status parameters according to the diagnostic algorithm requirements, and then send the extracted parameters to the local satellite fault diagnosis unit. The local satellite fault diagnosis unit is used to receive the local satellite GNSS receiver payload health characterization data after engineering parameter analysis and parameter extraction, automatically detect and locate faults based on the fault diagnosis model, and put the fault classification results into the PMU engineering parameter storage disk. The inter-satellite health data processing unit is used to access and read the health characterization data of the inter-satellite GNSS receiver payload, parse the health characterization data according to the inter-satellite communication protocol, and then send the parsed data to the inter-satellite fault diagnosis unit. The inter-satellite fault diagnosis unit is used to receive the parsed inter-satellite GNSS receiver payload health characterization data, automatically detect and locate faults based on the on-orbit fault diagnosis model, and put the fault classification results into the PMU parameter storage disk.
2. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 1, characterized in that: In the local satellite fault diagnosis unit and the inter-satellite fault diagnosis unit, the knowledge-driven fault diagnosis model forms fault mode interpretation rules and outputs fault mode inference results based on the fault diagnosis configuration file and multiple judgment logics corresponding to the fault mode. The data-driven fault diagnosis model predicts the fault mode category based on the trained and debugged machine learning classification model.
3. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 1, characterized in that: The on-orbit fault diagnosis software of the local satellite health data processing unit communicates with the PMU through input identifiers and health data interfaces. It identifies the input data category as local satellite GNSS receiver operating parameter data, parses and extracts health characterization data related to the health status of the local satellite GNSS receiver, specifically: Input: GNSS receiver operating parameters of this satellite; Processing: Based on the PMU and GNSS payload CAN bus communication protocol, analyze the operating parameter data of the local satellite GNSS receiver and extract health characterization data; Output: Processed local GNSS receiver payload health characterization data.
4. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 1, characterized in that: The local satellite fault diagnosis unit receives the parsed local satellite GNSS receiver payload health characterization data, performs fault classification, and sends the local satellite GNSS receiver fault diagnosis results to the PMU, specifically as follows: Input: Processed local GNSS receiver payload health characterization data; Solution: Use a fault diagnosis model to classify faults; Output: Fault diagnosis results for the local satellite GNSS receiver.
5. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 1, characterized in that: The on-orbit fault diagnosis software of the inter-satellite health data processing unit communicates with the PMU through input identifiers and health data interfaces, identifying the input data category as inter-satellite GNSS receiver data, specifically: Input: Health characterization data of inter-satellite GNSS receivers, or fault diagnosis results data from other satellites; Processing: Based on the inter-satellite / satellite-to-ground data frame format definition, if the access reads GNSS receiver operating parameter data, the inter-satellite GNSS receiver health characterization data is parsed; if the access reads fault diagnosis result data of another satellite, the fault diagnosis model is skipped and sent directly to the PMU. Output: Parsed inter-satellite GNSS receiver payload health characterization data, or fault diagnosis results data from other satellites.
6. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 1, characterized in that: The inter-satellite fault diagnosis unit receives the parsed inter-satellite GNSS receiver payload health characterization data, performs fault classification, and sends the inter-satellite GNSS receiver fault diagnosis results to the PMU, specifically: Input: Parsed inter-satellite GNSS receiver payload health characterization data; Solution: Use an on-orbit fault diagnosis model to classify faults; Output: Fault diagnosis results for inter-satellite GNSS receivers.
7. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 1, characterized in that: The local GNSS receiver payload data and the inter-satellite GNSS receiver payload health characterization data transmitted from other satellites are input to the on-orbit fault diagnosis unit via the PMU for data processing and fault diagnosis. The fault diagnosis results are then output to the PMU as its working parameters and subsequently transmitted to the satellite service platform.
8. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 1, characterized in that: The external interfaces of the system include: System and PMU diagnostic input unit interface; system and PMU diagnostic output unit interface; system and satellite data management unit remote control soft interface; system and satellite data management unit telemetry soft interface; system and satellite data management unit configuration item parameter soft interface.
9. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 8, characterized in that: The diagnostic input unit interface includes GNSS receiver operating parameter data of A, B, or L local satellite, including GNSS receiver health characterization data transmitted between satellites, or fault diagnosis results transmitted between satellites. The system's diagnostic output unit interface with the PMU includes results from both knowledge-driven and data-driven fault diagnosis methods. The PMU sends polling commands to the system in a point-to-point communication mode. Only after receiving this command can the system send corresponding data to the point and poll the output flag. When the flag is 0, it indicates that the unit calculation is incomplete and there is no data output. When the flag is 1, it indicates that the unit calculation is complete and there is data output. Then, the category of the output diagnostic result is identified. When the category is 0, it indicates a fault diagnosis result of the local GNSS receiver; when the category is 1, it indicates an inter-satellite GNSS receiver fault diagnosis result; and when the category is 2, it indicates an inter-satellite GNSS receiver fault diagnosis result data transmitted through another satellite.
10. The on-orbit fault diagnosis system for a satellite constellation GNSS receiver according to claim 1, characterized in that, The fault diagnosis process is as follows: In local satellite mode, the data management system creates a fault diagnosis system thread. This thread is blocked by a semaphore. Whenever the PMU master control software receives GNSS operational parameter data reaching a preset value, it first writes the data to disk, then copies the data to a dedicated memory buffer for the fault diagnosis system. The semaphore block is then released, and the buffer is passed as a parameter to the local satellite algorithm interface. Once the algorithm interface completes its operation, the returned result is stored in the PMU operational parameter disk and sent down to the ground via a downlink task. Simultaneously, inter-satellite health characterization data is returned for use as a parameter in the inter-satellite mode algorithm. Then, the local satellite fault diagnosis operation of the GNSS on-orbit fault diagnosis system ends, and the thread enters a blocked state, waiting for the next semaphore release. In inter-satellite mode, the data management system assembles the inter-satellite health characterization data generated after calculation in this satellite mode into a satellite-to-ground frame and sends it to another satellite through the K payload. In inter-satellite mode, it is agreed that the ground injects the PMU's own command to initiate the transmission only when there is a link between the two satellites and on-orbit communication resources. Each time the ground initiates the transmission, a satellite-to-ground frame with a specific number is generated. After the algorithm interface completes its operation, the returned result is put into the PMU's parameter storage.
Citation Information
Patent Citations
Satellite in-orbit fault white box type ground parallel diagnosis system and method
CN115494525A
System and method for wireless collaborative verification of global navigation satellite system measurements
US20140232595A1