A satellite unified diagnosis system and method based on a UDS_OBD diagnosis model and a CCSDS protocol

Abstract

The application relates to the technical field of satellite fault diagnosis, and provides a satellite unified diagnosis system based on a UDS_OBD diagnosis model and a CCSDS protocol; a ground diagnosis terminal generates a ground trigger diagnosis request and encapsulates the ground trigger diagnosis request into a CCSDS remote control package to be sent to a satellite; a satellite management process receives the CCSDS remote control package, identifies a unified diagnosis service, and then forwards the unified diagnosis service to an on-satellite unified diagnosis gateway; the on-satellite unified diagnosis gateway receives a ground diagnosis service data and / or an on-satellite autonomous diagnosis request, analyzes a unified diagnosis request header, and judges diagnosis request admission; an on-satellite unified diagnosis process processes the unified diagnosis request according to a unified diagnosis object rule table, executes reading or routines of a diagnosis object, judges faults, generates or updates diagnosis fault codes when the faults are established, generates fault frozen frames and associated telemetry, encapsulates the fault frozen frames and the associated telemetry into a CCSDS telemetry package, and then transmits the fault frozen frames and the associated telemetry to the ground diagnosis terminal.

Description

Technical Field

[0001] This invention relates to the technical field of satellite fault diagnosis, specifically to the sub-fields of spacecraft health management, satellite fault diagnosis, onboard software architecture, and satellite-to-ground communication. In particular, it relates to a unified satellite diagnostic system and method based on the UDS_OBD diagnostic model and the CCSDS protocol. Background Technology

[0002] With the rapid development of low-Earth orbit communication constellations, remote sensing constellations, navigation enhancement constellations, and commercial aerospace satellite platforms, satellite systems are gradually shifting from the traditional single-satellite customized development model to a platform-based, mass-production, and constellation-based rapid networking model. The increase in the number of satellites, the increased complexity of onboard subsystems, and the parallel operation of multiple satellites in orbit place higher demands on the efficiency of ground-based satellite health monitoring, fault location, and on-orbit maintenance. Traditional satellite fault diagnosis methods typically rely on independently defined telemetry parameters, status words, event alarms, and ground interpretation rules for each subsystem, lacking unified standards for diagnostic interfaces, fault semantics, and data formats between different subsystems. In single-satellite or small-scale satellite operation scenarios, manual interpretation of telemetry data, model-specific fault handling procedures, and customized ground tools can still meet the requirements; however, in scenarios of mass satellite production and rapid constellation networking, these methods easily lead to problems such as fragmented diagnostic interfaces, inconsistent fault information expression, heavy ground maintenance burden, difficulty in cross-subsystem fault location, and difficulty in reusing diagnostic capabilities. Therefore, there is an urgent need for a unified diagnostic architecture for satellite multi-systems that is suitable for mass production and constellation operation scenarios, in order to improve the standardization, automation and scalability of satellite fault diagnosis.

[0003] In existing technologies, the patent CN114291305A, titled "Satellite Fault Diagnosis Method," divides satellite telemetry data into stationary, periodic, and gradually changing types based on its characteristics, and performs threshold preprocessing and envelope boundary preprocessing on each type to diagnose explicit satellite faults. This method can establish corresponding fault detection methods for different types of telemetry data, but its focus is on fault diagnosis algorithms at the telemetry data level. The diagnostic objects still mainly revolve around telemetry parameters, thresholds, and envelope boundaries, and it has not formed a unified diagnostic service interface for the entire satellite multi-subsystem. The patent CN114460921A, titled "A Real-Time On-Orbit Fault Diagnosis Method and System for Satellite Attitude and Orbit Control Subsystem," targets the satellite attitude and orbit control subsystem, selects physical quantities, calculates health integral values, and uses these health integral values ​​to achieve real-time on-orbit fault diagnosis of the attitude and orbit control subsystem. This method can improve the real-time health assessment and fault diagnosis capabilities of the attitude and orbit control subsystem, but its application scope is mainly concentrated on the attitude and orbit control subsystem. It belongs to the diagnostic algorithm or evaluation method of a specific subsystem and does not solve the problem of inconsistent diagnostic interfaces between multiple heterogeneous subsystems such as power supply and distribution, thermal control, telemetry and control, data transmission, payload, and integrated electronics. The publication CN116578905A, "A Spacecraft Intelligent Autonomous Health Management System Based on Multiple-Child Body Sensing," proposes a health management system based on multiple-child body sensing to improve the spacecraft's state perception, health monitoring, and autonomous diagnosis capabilities. This type of solution focuses on the construction of a spacecraft health management system or intelligent diagnostic capabilities, which can improve the level of autonomous health management of spacecraft from a macro perspective. However, it does not standardize the diagnostic interaction relationships between ground diagnostic terminals, satellite management processes, onboard unified diagnostic gateways, and onboard unified diagnostic processes. Therefore, existing solutions have a certain foundation in fault detection algorithms, subsystem health assessment, or spacecraft health management, but they still have shortcomings in unified diagnostic architecture for batch satellite and constellation operation and maintenance, CCSDS diagnostic bearer, on-board unified diagnostic gateway, and multi-subsystem diagnostic adaptation.

[0004] Furthermore, traditional satellite management processes typically perform routine telemetry acquisition, telemetry limit violation monitoring, status word monitoring, and event logging. However, these monitoring results often manifest as telemetry limit violations, status anomalies, or event alarms, lacking a unified diagnostic object, unified diagnostic rules, and a unified fault code expression mechanism consistent with ground diagnostic requests. Therefore, existing systems often struggle to achieve isomorphic processing between on-demand ground diagnostics and onboard autonomous diagnostics, and also find it difficult to guarantee consistency between onboard autonomous monitoring conclusions and results displayed by ground diagnostic tools.

[0005] To address the aforementioned issues, a unified satellite diagnostic architecture is needed that can simultaneously support ground-triggered diagnostics and onboard autonomous diagnostics. This would allow both ground diagnostic terminals and satellite management processes to serve as sources of diagnostic requests, with both types of requests processed through a unified diagnostic object rule table. This would improve the standardization, automation, and reusability of satellite fault diagnosis. Summary of the Invention

[0006] To address the aforementioned issues, the present invention aims to provide a unified satellite diagnostic system and method based on the UDS_OBD diagnostic model and CCSDS protocol. Through a unified diagnostic architecture, the system enables on-demand ground diagnostics and on-board autonomous diagnostics to share the same set of diagnostic rules and fault code mechanisms, thereby achieving standardization and closed-loop processing of full-satellite diagnostics and effectively improving the versatility of satellite fault diagnosis and on-orbit operation and maintenance efficiency.

[0007] The above-mentioned objective of this invention is achieved through the following technical solutions: A unified satellite diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol includes a ground diagnostic terminal, a satellite service management process, an on-board unified diagnostic gateway, and an on-board unified diagnostic process. The ground diagnostic terminal is used to generate a ground-triggered diagnostic request and encapsulate the ground-triggered diagnostic request into a CCSDS remote control packet and send it to the satellite; The satellite management process is used to receive the CCSDS remote control packet, identify the unified diagnostic service, and forward it to the satellite unified diagnostic gateway. It is also used to generate a satellite autonomous diagnostic request based on the telemetry monitoring results and to access the target subsystem based on the diagnostic execution request. The on-board unified diagnostic gateway is used to receive ground diagnostic service data and / or on-board autonomous diagnostic requests, parse the unified diagnostic request header and make diagnostic request admission judgment. The onboard unified diagnostic process is used to process unified diagnostic requests according to the unified diagnostic object rule table, execute the reading or routine of diagnostic objects, determine faults, and generate or update diagnostic fault codes, generate fault freeze frames and associated telemetry when a fault is established. These are then encapsulated into CCSDS telemetry packets by the onboard unified diagnostic gateway and the satellite service management process and transmitted to the ground diagnostic terminal.

[0008] Furthermore, the unified diagnostic request includes ground-triggered diagnostic requests and on-board autonomous diagnostic requests; The ground-triggered diagnostic request is generated by the ground diagnostic terminal and sent to the satellite management process via the CCSDS remote control packet. The onboard autonomous diagnostic request is generated by the satellite management process based on telemetry data in the telemetry pool, subsystem status, event alarms, periodic health checks, or satellite mode switching conditions. Both the ground-triggered diagnostic request and the onboard autonomous diagnostic request adopt a unified diagnostic object description method, which includes a diagnostic service identifier, a target subsystem identifier, a diagnostic object type, and a diagnostic object identifier. Both are processed by the onboard unified diagnostic process according to the unified diagnostic object rule table.

[0009] Furthermore, the ground-triggered diagnostic request generated by the ground diagnostic terminal includes a diagnostic service identifier, a target subsystem identifier, a diagnostic object type, a diagnostic object identifier, a request flag, a diagnostic sequence number, and a diagnostic request payload; The diagnostic service identifier is used to indicate the operation performed on the unified diagnostic object, and the operation includes one or more of reading, writing, executing, querying, and clearing; The diagnostic object types include one or more of the following: data-type diagnostic objects, routine-type diagnostic objects, fault information-type diagnostic objects, fault record-type diagnostic objects, freeze frame-type diagnostic objects, and diagnostic parameter-type diagnostic objects.

[0010] Furthermore, the satellite management process is used to receive CCSDS remote control packets and determine whether it is a unified diagnostic service based on APID or service type. When it is identified as a unified diagnostic service, the diagnostic service data is forwarded to the satellite unified diagnostic gateway. The satellite management process is also used to perform daily telemetry monitoring, status monitoring and event monitoring, and generate onboard autonomous diagnostic requests based on the monitoring results; The satellite management process is also used to access the target subsystem based on the diagnostic execution request generated by the onboard unified diagnostic process. The access methods include one or more of the following: 1553B bus, CAN bus, RS422 interface, SpaceWire interface, shared memory interface, onboard software API, and telemetry database interface.

[0011] Furthermore, the onboard unified diagnostic gateway is used to receive diagnostic service data or onboard autonomous diagnostic requests from the satellite service management process, parse the unified diagnostic request header, extract the diagnostic service identifier, target subsystem identifier, diagnostic object type, diagnostic object identifier and diagnostic sequence number, and perform diagnostic request access judgment. The access determination includes service legitimacy determination, current diagnostic session status determination, security permission determination, and satellite operation mode constraint determination; The admission decision does not rely on reserved fields in the unified diagnostic request header, but is executed based on the diagnostic session status maintained on-board, the secure access status, the satellite operation mode provided by the satellite management process, and the constraints in the unified diagnostic object rule table.

[0012] Furthermore, the on-board unified diagnostic process includes a unified diagnostic service and object rule management layer and a diagnostic execution request generation layer; The unified diagnostic service and object rule management layer is used to distinguish whether the current diagnostic request is a data-type diagnostic object read request or a routine-type diagnostic object execution request based on the diagnostic service identifier and diagnostic object type, and to query the unified diagnostic object rule table based on the target subsystem identifier, diagnostic object type, and diagnostic object identifier; The diagnostic execution request generation layer is used to generate executable data read requests, subsystem real-time query requests, or routine execution requests for the space management process based on the unified diagnostic object rule table.

[0013] Furthermore, the CCSDS remote control package includes a space package master header, a unified diagnostic request header, and a unified diagnostic request payload; The space packet header is used to identify the space packet version, packet type, application process identifier, packet sequence count, and packet data length. The application process identifier is used to indicate the unified diagnostic remote control service. The unified diagnostic request header is 16 bytes long and includes a diagnostic protocol version field, a diagnostic service identifier field, a target subsystem identifier field, a diagnostic object type field, a request flag field, a diagnostic object identifier field, a diagnostic sequence number field, a payload length field, and a reserved field.

[0014] Furthermore, the unified diagnostic object rule table is used to store the access rules, conversion rules, and fault determination rules of the diagnostic object; For data-related diagnostic objects, the rule table includes at least the data source type, data source identifier, conversion formula, fault threshold, fault judgment condition, associated fault code, freeze frame configuration, and downlink telemetry configuration. For routine-type diagnostic objects, the rule table includes at least the routine local command, routine parameters, response parsing rules, fault judgment conditions, associated fault codes, freeze frame configuration, and downlink telemetry configuration. The unified diagnostic object rule table is pre-set before the satellite leaves the factory, or is added or updated on-orbit by the ground through the diagnostic rule update service.

[0015] Furthermore, when the diagnostic object type is a data-type diagnostic object, the on-board unified diagnostic process determines the data source according to the unified diagnostic object rule table; If the data source is real-time values ​​from the telemetry pool, satellite status cache, frozen frame data, or historical values ​​from the telemetry database, the onboard unified diagnostic process reads the existing data through the satellite management process. If the data source is a real-time query from a subsystem, the onboard unified diagnostic process generates a diagnostic execution request, and the satellite management process obtains the corresponding data from the target subsystem. After acquiring the data, the onboard unified diagnostic process converts the raw data into engineering values ​​or diagnostic status values ​​according to the conversion formula, and determines whether a fault has occurred based on the fault threshold and fault judgment conditions.

[0016] Furthermore, when the diagnostic object type is a routine diagnostic object, the onboard unified diagnostic process determines the routine local command, routine parameters, timeout time and response parsing rules according to the unified diagnostic object rule table, and generates a routine execution request; The satellite management process executes the corresponding routine based on the routine execution request and returns the routine response to the onboard unified diagnostic process. The onboard unified diagnostic process parses routine responses according to response parsing rules and determines whether a fault has occurred based on fault determination conditions.

[0017] Furthermore, when a fault is determined to be established, the onboard unified diagnostic process generates or updates a fault code, records the fault status, number of occurrences, occurrence time, associated diagnostic objects, and fault severity level, and automatically collects relevant telemetry, status information, operating mode, diagnostic object values, and routine execution results at the time of the fault according to the freeze frame configuration, forming a fault freeze frame. If the request flag in the unified diagnostic request, the onboard autonomous diagnostic triggering condition, or the downlink telemetry configuration indication in the rule table requires the downlink of associated telemetry, the onboard unified diagnostic process generates a unified diagnostic response or diagnostic event telemetry containing fault codes, freeze frame summaries, and associated telemetry data. This response is then encapsulated into a CCSDS telemetry packet by the onboard unified diagnostic gateway and the satellite service management process and downlinked to the ground diagnostic terminal.

[0018] Furthermore, the unified diagnostic object rule table includes one or more of the following: rule number, rule version, rule enable flag, target subsystem identifier, diagnostic object type, diagnostic object identifier, data source type, data source identifier, conversion formula number, fault judgment rule number, upper limit threshold, lower limit threshold, abnormal duration, number of fault confirmations, associated diagnostic fault code, freeze frame configuration number, downlink telemetry configuration number, routine local command number, routine parameter template number, routine response parsing rule number, execution timeout, local interface type, local resource identifier, session requirement number, security permission requirement number, satellite mode constraint number, and autonomous diagnostic trigger condition number. The unified diagnostic object rule table includes a currently effective rule area and a temporary update rule area. When the ground diagnostic terminal uploads rule update data, the on-board unified diagnostic process first writes the rule update data into the temporary update rule area, and after completing the diagnostic session check, security access permission check, rule version check and integrity verification, it switches the temporary update rule area to the currently effective rule area. When the same diagnostic object corresponds to multiple data sources, the on-board unified diagnostic process selects diagnostic data from real-time values ​​of the telemetry pool, cached values ​​of the satellite service status, frozen frame data, historical values ​​of the telemetry database, and real-time query values ​​of the subsystem based on the data source type, data validity time, or data priority in the unified diagnostic object rule table. The onboard unified diagnostic gateway or onboard unified diagnostic process arbitrates multiple diagnostic requests based on the request source, diagnostic service type, target subsystem identifier, diagnostic object type, diagnostic object risk level, and satellite operation mode. Parallel processing is allowed for data-related diagnostic objects, while mutual exclusion is used for routine-related diagnostic objects that may change the state of the target subsystem, occupy bus resources, or trigger device actions. When the unified diagnostic response or diagnostic event telemetry fails to be transmitted in real time, the on-board unified diagnostic process will temporarily store the diagnostic fault code record, freeze frame summary, associated telemetry data and transmission status flag in the on-board diagnostic storage area, and retransmit them when the fault information query service is initiated in subsequent communication windows or ground diagnostic terminals. The triggering conditions for the satellite management process to generate onboard autonomous diagnostic requests include one or more of the following events: telemetry limit violation, status word anomaly, subsystem event reporting, subsystem heartbeat timeout, periodic health check, routine post-check, satellite mode switching, and safe mode entry.

[0019] A method implemented using a satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol as described above includes the following steps: Obtain a unified diagnostic request, which includes a ground-triggered diagnostic request sent by the ground diagnostic terminal via the CCSDS remote control packet, and / or an onboard autonomous diagnostic request generated by the satellite service management process based on telemetry monitoring, event alarms, or periodic health checks. The onboard unified diagnostic gateway parses the unified diagnostic request header and extracts the diagnostic service identifier, target subsystem identifier, diagnostic object type, and diagnostic object identifier. The onboard unified diagnostic process determines whether the unified diagnostic request is a data-type diagnostic object read request or a routine-type diagnostic object execution request based on the diagnostic service identifier and the diagnostic object type. If the request is for reading a data-based diagnostic object, the unified diagnostic object rule table is queried to obtain the data source, conversion formula, fault threshold and fault judgment rule, and the corresponding diagnostic data is obtained for fault judgment. If a routine-type diagnostic object execution request is made, the unified diagnostic object rule table is queried to obtain the routine command, routine parameters, response parsing rules and fault judgment rules, and the space service management process executes the corresponding routine and returns the routine response; The onboard unified diagnostic process determines whether a fault has occurred based on fault determination rules. If a fault occurs, a diagnostic fault code is generated or updated, and a fault freeze frame is generated. The onboard unified diagnostic gateway generates unified diagnostic responses or diagnostic event telemetry, which is then encapsulated into CCSDS telemetry packets by the satellite management process and transmitted to the ground diagnostic terminal.

[0020] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) The present invention uses a unified diagnostic architecture consisting of a ground diagnostic terminal, a satellite management process, a satellite unified diagnostic gateway and a satellite unified diagnostic process to reuse the CCSDS remote telemetry system. The ground diagnostic request is sent to the satellite unified diagnostic entry point through the unified diagnostic APID, without the need to build an additional independent diagnostic communication link. At the same time, the architecture supports both ground-triggered diagnostic requests and satellite autonomous diagnostic requests, so that ground-on-demand diagnostics and satellite daily telemetry monitoring can share the same set of unified diagnostic objects, unified diagnostic rules and fault code management mechanisms, ensuring the unification of the two types of diagnostic requests from the entry point to the processing flow, as well as the consistency between ground diagnostics and satellite autonomous diagnostic conclusions.

[0021] (2) The present invention uses diagnostic service identifiers and diagnostic object types to represent operations such as reading, executing, querying, and clearing a unified diagnostic object, making the diagnostic request model more unified and improving the universality and scalability of the diagnostic interface.

[0022] (3) This invention improves the consistency and maintainability of diagnostic rules and reduces the configuration difficulty of adding new diagnostic objects by centrally managing data sources, conversion formulas, thresholds, fault judgment conditions, routine response parsing rules, associated fault codes, freeze frame configuration and downlink telemetry configuration through a unified diagnostic object rule table.

[0023] (4) The present invention can select to obtain diagnostic data from the telemetry pool, status cache, freeze frame or target subsystem in real time according to the data source type, avoiding repeated sending of subsystem query instructions to data that already exists in the satellite telemetry system, and reducing the communication overhead of the satellite bus.

[0024] (5) The present invention can automatically determine the fault after reading the data object or executing the routine object. When the fault is determined to be established, the fault code is automatically updated, the fault frame is frozen and the associated telemetry is transmitted down, forming a complete on-board diagnostic closed loop, which improves the timeliness and automation level of fault response.

[0025] (6) The present invention uses the satellite management process as the execution subject for the actual access of the subsystem and the download of CCSDS telemetry group packets, which can be adapted to satellite subsystems using different bus interfaces, communication protocols and software interfaces, and enhances the compatibility of the architecture with different satellite platforms.

[0026] (7) This invention is applicable to mass production of satellites and constellation operation scenarios. It can improve the reusability of ground diagnostic tools, the efficiency of on-orbit fault location and the standardization level of satellite health management, and reduce constellation operation and maintenance costs.

[0027] (8) The present invention, through the design of the current effective area and the temporary update area of ​​the rule table, enables the diagnostic rules to be updated on the track and avoids the impact on the existing diagnostic capabilities when the rule update fails, thereby improving the reliability and maintainability of the on-track diagnostic system.

[0028] (9) This invention can select between cache reading and real-time query through the data validity time and data source priority mechanism, thereby reducing the access burden on the target subsystem and improving the consistency of diagnostic data.

[0029] (10) The present invention prioritizes ground-triggered diagnostic requests and on-board autonomous diagnostic requests through a diagnostic request arbitration mechanism, thereby avoiding diagnostic access from interfering with the normal execution of satellite missions and ensuring the safety of satellite missions.

[0030] (12) The present invention can adapt to the intermittent visibility of the satellite-to-ground link through the diagnostic event temporary storage and retransmission mechanism, reduce the risk of loss of fault site information due to the unavailability of communication window, and improve the integrity and availability of diagnostic data. Attached Figure Description

[0031] Figure 1 This is a general block diagram of the satellite unified diagnostic system of the present invention; Figure 2 This is a unified diagnostic information flowchart for the present invention; Figure 3 This is a logical relationship diagram of the unified diagnostic object rule table for this invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0034] This invention discloses a unified satellite diagnostic system based on the UDS / OBD diagnostic model and CCSDS protocol, applicable to batch satellite and constellation-based operation scenarios. The architecture includes a ground diagnostic terminal, a satellite management process, an onboard unified diagnostic gateway, and an onboard unified diagnostic process. The ground diagnostic terminal initiates diagnostic requests, and the satellite management process generates diagnostic requests based on predefined monitoring rules. Diagnostic requests uniformly adopt a diagnostic object description method and are processed by a unified diagnostic object rule table; the rule table describes data sources, conversion rules, routine execution rules, response parsing rules, fault determination rules, associated diagnostic fault codes, freeze frame configurations, and downlink telemetry configurations. The system processes the diagnostic objects according to the rule table, generating diagnostic fault codes, freeze frames, and associated telemetry data, which are then downlinked to the ground diagnostic terminal via CCSDS telemetry packets, thereby achieving isomorphic processing of on-demand ground diagnostics and rule-triggered onboard diagnostics.

[0035] The following is an illustration through specific examples: First Embodiment like Figure 1 As shown, this embodiment provides a satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol, including a ground diagnostic terminal, a satellite service management process, an on-board unified diagnostic gateway, and an on-board unified diagnostic process. The ground diagnostic terminal is used to generate a ground-triggered diagnostic request and encapsulate the ground-triggered diagnostic request into a CCSDS remote control packet and send it to the satellite; The satellite management process is used to receive the CCSDS remote control packet, identify the unified diagnostic service, and forward it to the satellite unified diagnostic gateway. It is also used to generate a satellite autonomous diagnostic request based on the telemetry monitoring results and to access the target subsystem based on the diagnostic execution request. The on-board unified diagnostic gateway is used to receive ground diagnostic service data and / or on-board autonomous diagnostic requests, parse the unified diagnostic request header and make diagnostic request admission judgment. The onboard unified diagnostic process is used to process unified diagnostic requests according to the unified diagnostic object rule table, execute the reading or routine of diagnostic objects, determine faults, and generate or update diagnostic fault codes, generate fault freeze frames and associated telemetry when a fault is established. These are then encapsulated into CCSDS telemetry packets by the onboard unified diagnostic gateway and the satellite service management process and transmitted to the ground diagnostic terminal.

[0036] Specifically, this invention uses a ground-based diagnostic terminal and a satellite management process as two parallel sources of diagnostic requests. The ground-based diagnostic terminal generates ground-triggered diagnostic requests and uploads them to the satellite via CCSDS remote control packets. The satellite management process autonomously generates diagnostic requests based on onboard telemetry monitoring results. After both types of requests enter the satellite, they are uniformly parsed and approved by the onboard unified diagnostic gateway. Then, the onboard unified diagnostic process reads the diagnostic object or executes routines and determines faults according to the unified diagnostic object rule table, automatically generating fault codes and freeze frames when a fault is detected. Finally, the diagnostic response or diagnostic event telemetry is encapsulated into CCSDS telemetry packets by the onboard unified diagnostic gateway and the satellite management process and transmitted to the ground-based diagnostic terminal. Through the above-mentioned "dual-source entry - unified gateway - rule table driven - closed-loop output" architecture design, this invention achieves end-to-end unification of ground-based on-demand diagnostics and onboard autonomous diagnostics in terms of diagnostic objects, diagnostic rules, and fault code management mechanisms.

[0037] In this embodiment, the unified diagnostic request includes a ground-triggered diagnostic request and an onboard autonomous diagnostic request. The ground-triggered diagnostic request is generated by the ground diagnostic terminal and sent to the satellite management process via a CCSDS remote control packet. The onboard autonomous diagnostic request is generated by the satellite management process based on telemetry data in the telemetry pool, subsystem status, event alarms, periodic health checks, or satellite mode switching conditions. Both the ground-triggered diagnostic request and the onboard autonomous diagnostic request adopt a unified diagnostic object description method, both including a diagnostic service identifier, a target subsystem identifier, a diagnostic object type, and a diagnostic object identifier, and both are processed by the onboard unified diagnostic process according to the unified diagnostic object rule table.

[0038] Specifically, the unified diagnostic request in this invention does not rely solely on ground-based sources, but encompasses both ground-triggered and onboard autonomous paths, together forming a complete diagnostic request system. The ground path is initiated proactively by the ground diagnostic terminal, uplinked to the satellite management process via CCSDS remote control packets, for on-demand diagnostic task execution. The onboard path is autonomously triggered by the satellite management process based on conditions such as telemetry pool data, subsystem status, event alarms, periodic health checks, or satellite mode switching, thereby enabling timely detection and proactive diagnosis of abnormal states. It is worth emphasizing that although the two types of requests have different sources and initiation methods, they employ a completely unified diagnostic object description format—both including a diagnostic service identifier, target subsystem identifier, diagnostic object type, and diagnostic object identifier—and are processed by the same unified diagnostic object rule table after entering the onboard unified diagnostic process. It is through this dual unification of the description format and processing flow for both types of requests that this invention achieves coordinated consistency between ground-based on-demand diagnostics and onboard autonomous diagnostics, avoiding the problems of diagnostic rule splitting or redundant configuration introduced by differences in request sources.

[0039] In this embodiment, the ground-triggered diagnostic request generated by the ground diagnostic terminal includes a diagnostic service identifier, a target subsystem identifier, a diagnostic object type, a diagnostic object identifier, a request flag, a diagnostic sequence number, and a diagnostic request payload. The diagnostic service identifier is used to indicate the operation performed on the unified diagnostic object, and the operation includes one or more of reading, writing, executing, querying, and clearing. The diagnostic object type includes one or more of data-type diagnostic objects, routine-type diagnostic objects, fault information-type diagnostic objects, fault record-type diagnostic objects, freeze frame-type diagnostic objects, and diagnostic parameter-type diagnostic objects.

[0040] Specifically, the ground-triggered diagnostic request, as one of the key sources of unified diagnostic requests in this invention, employs a standardized field definition method in its data structure to ensure accurate transmission and unambiguous resolution of diagnostic commands between the diagnostic terminal and the satellite. This request includes core fields such as diagnostic service identifier, target subsystem identifier, diagnostic object type, diagnostic object identifier, request flag, diagnostic sequence number, and diagnostic request payload. The diagnostic service identifier clarifies the specific operation type performed on the unified diagnostic object in this request, including read, write, execute, query, and clear, covering typical diagnostic interaction needs in satellite on-orbit operation and maintenance. The diagnostic object type categorizes diagnostic objects into multiple classes, such as data, routine, fault information, fault record, freeze frame, and diagnostic parameter, enabling the diagnostic request to not only acquire telemetry data or execute specific diagnostic routines but also flexibly manage fault records, freeze frames, and diagnostic parameters. Through the above field design and type classification, the ground-triggered diagnostic request can carry diverse diagnostic tasks in a unified format, laying a data foundation for the subsequent standardized processing of on-board unified diagnostic processes based on rule tables.

[0041] In this embodiment, the satellite management process receives CCSDS remote control packets and determines whether they are unified diagnostic services based on APID or service type. When a unified diagnostic service is identified, the diagnostic service data is forwarded to the onboard unified diagnostic gateway. The satellite management process also performs daily telemetry monitoring, status monitoring, and event monitoring, and generates onboard autonomous diagnostic requests based on the monitoring results. The satellite management process also accesses the target subsystem based on the diagnostic execution request generated by the onboard unified diagnostic process. The access methods include one or more of the following: 1553B bus, CAN bus, RS422 interface, SpaceWire interface, shared memory interface, onboard software API, and telemetry database interface.

[0042] Specifically, the satellite management process in this invention plays three roles: identifying and forwarding diagnostic requests, triggering autonomous diagnostics, and executing subsystem access. First, as the entry point for satellite-to-ground diagnostic commands, the satellite management process receives CCSDS remote control packets from the ground and accurately identifies the unified diagnostic service based on APID or service type, ensuring that ground diagnostic requests are correctly imported into the onboard diagnostic processing flow. Second, the satellite management process does not passively wait for ground commands but actively performs daily telemetry monitoring, status monitoring, and event monitoring. Through real-time analysis of telemetry data, subsystem status, and event alarms, it autonomously generates diagnostic requests, enabling the satellite to promptly detect and diagnose anomalies without ground intervention. Finally, the satellite management process also acts as an execution bridge between the unified diagnostic process and the target subsystem. Based on the diagnostic execution request, it accesses the target subsystem through various means such as the 1553B bus, CAN bus, RS422 interface, SpaceWire interface, shared memory interface, onboard software API, or telemetry database interface, thereby effectively connecting the logical processing capabilities of the unified diagnostic process with the physical access capabilities of each satellite subsystem. Through the coordinated efforts of these three roles, the satellite management process in this invention achieves accurate importation of ground diagnostic commands, proactive initiation of onboard diagnostic tasks, and reliable execution of diagnostic execution requests, forming a crucial link in the unified onboard diagnostic architecture.

[0043] In this embodiment, the onboard unified diagnostic gateway is used to receive diagnostic service data or onboard autonomous diagnostic requests from the satellite management process, parse the unified diagnostic request header, extract the diagnostic service identifier, target subsystem identifier, diagnostic object type, diagnostic object identifier, and diagnostic sequence number, and perform diagnostic request access judgment. The access judgment includes service legality judgment, current diagnostic session status judgment, security permission judgment, and satellite operation mode constraint judgment. The access judgment does not rely on the reserved fields in the unified diagnostic request header, but is executed according to the diagnostic session status, security access status, satellite operation mode provided by the satellite management process, and constraints in the unified diagnostic object rule table maintained onboard.

[0044] Specifically, the onboard unified diagnostic gateway acts as the "first line of defense" at the onboard diagnostic entry point, responsible for uniformly parsing and legally reviewing various diagnostic requests entering the satellite. First, diagnostic service data from the satellite management process or onboard autonomous diagnostic requests must pass through this gateway. The gateway parses the unified diagnostic request header, extracting key fields such as the diagnostic service identifier, target subsystem identifier, diagnostic object type, diagnostic object identifier, and diagnostic sequence number, transforming the raw request data into structured diagnostic service semantic information. Based on this, the gateway further performs diagnostic request access judgment. This access judgment is not a simple format check, but rather a comprehensive multi-dimensional check encompassing service legality judgment, current diagnostic session status judgment, security permission judgment, and satellite operating mode constraint judgment, ensuring that the diagnostic request is not only correctly formatted but also possesses legal execution conditions within the current satellite operating status and security context. It is worth emphasizing that all access decisions do not rely on reserved fields in the request header. Instead, they are strictly based on the real-time maintained diagnostic session status, secure access status, satellite operation mode provided by the satellite management process, and constraints in the unified diagnostic object rule table. This ensures the real-time consistency between the access decision results and the actual satellite operation status, avoiding inaccuracies caused by reliance on reserved fields or fixed configurations. Through the above parsing and access mechanism, the onboard unified diagnostic gateway provides secure, reliable, and onboard-synchronized request inputs for subsequent diagnostic processing.

[0045] In this embodiment, the on-board unified diagnostic process includes a unified diagnostic service and object rule management layer and a diagnostic execution request generation layer. The unified diagnostic service and object rule management layer is used to distinguish whether the current diagnostic request is a data-type diagnostic object read request or a routine-type diagnostic object execution request based on the diagnostic service identifier and diagnostic object type, and to query the unified diagnostic object rule table based on the target subsystem identifier, diagnostic object type, and diagnostic object identifier. The diagnostic execution request generation layer is used to generate data read requests, subsystem real-time query requests, or routine execution requests that can be executed by the satellite management process based on the unified diagnostic object rule table.

[0046] Specifically, the onboard unified diagnostic process in this invention undertakes three functions: diagnostic request identification, rule matching, and execution instruction generation. Internally, it adopts a layered design, divided into a unified diagnostic service and object rule management layer and a diagnostic execution request generation layer. The unified diagnostic service and object rule management layer is responsible for semantic recognition and rule matching of approved diagnostic requests—distinguishing between data-type diagnostic object read requests and routine-type diagnostic object execution requests based on the diagnostic service identifier and diagnostic object type. Then, using the target subsystem identifier, diagnostic object type, and diagnostic object identifier as a combined index, it queries the unified diagnostic object rule table to obtain complete rule information corresponding to the diagnostic object, such as data source, conversion formula, fault judgment conditions, or routine execution parameters. The diagnostic execution request generation layer, based on the rule information output by the rule management layer, generates executable data read requests, subsystem real-time query requests, or routine execution requests for the satellite management process according to different diagnostic object types and rule configurations, thereby transforming abstract rule definitions into concrete satellite-executable operations. Through the division of responsibilities in the above two-layer structure, the unified onboard diagnostic process decouples diagnostic logic processing from execution instruction generation. The rule management layer focuses on "what rules to check" and the execution request generation layer focuses on "how to execute". This makes the diagnostic processing flow clear and does not require modification of the diagnostic process's processing logic when the rule table content is updated.

[0047] In this embodiment, the CCSDS remote control packet includes a spatial packet master header, a unified diagnostic request header, and a unified diagnostic request payload. The spatial packet master header is used to identify the spatial packet version, packet type, application process identifier, packet sequence count, and packet data length. The application process identifier is used to indicate the unified diagnostic remote control service. The unified diagnostic request header is 16 bytes long and includes a diagnostic protocol version field, a diagnostic service identifier field, a target subsystem identifier field, a diagnostic object type field, a request flag field, a diagnostic object identifier field, a diagnostic sequence number field, a payload length field, and a reserved field.

[0048] Specifically, the CCSDS remote control packet, as the physical carrier for uplinking ground diagnostic commands, is endowed in this invention with the ability to carry standardized diagnostic request information. Its structure adopts a two-layer design—a space packet master header and a unified diagnostic request header. The space packet master header conforms to the CCSDS standard specification and includes fields such as space packet version, packet type, Application Process Identifier (APID), packet sequence count, and packet data length. The APID is set as a dedicated identifier for unified diagnostic services, enabling the satellite management process to quickly identify diagnostic services by parsing the APID in the master header when receiving remote control packets, and correctly distribute them to the onboard unified diagnostic gateway without pre-parsing the payload content. Building upon this foundation, the unified diagnostic request header, serving as the semantic carrier layer for diagnostic services, is designed as a fixed 16-byte structure. It sequentially includes the diagnostic protocol version, diagnostic service identifier, target subsystem identifier, diagnostic object type, request flag, diagnostic object identifier, diagnostic sequence number, payload length, and reserved fields. The diagnostic service identifier, target subsystem identifier, diagnostic object type, and diagnostic object identifier together constitute the complete addressing information of the unified diagnostic object, enabling the onboard unified diagnostic process to accurately locate the corresponding diagnostic rule from the rule table. The diagnostic sequence number provides a reliable matching basis for request and response pairing. Through this two-layer decoupling design of the space packet master header and the unified diagnostic request header, the CCSDS remote control packet can both utilize the standardized space packet mechanism for onboard service distribution and carry the custom diagnostic semantic information of this invention, achieving unified carrying and efficient parsing of diagnostic services without altering the CCSDS standard framework.

[0049] In this embodiment, the unified diagnostic object rule table is used to store the access rules, conversion rules, and fault determination rules of the diagnostic objects. For data-type diagnostic objects, the rule table includes at least the data source type, data source identifier, conversion formula, fault threshold, fault determination condition, associated fault code, freeze frame configuration, and downlink telemetry configuration. For routine-type diagnostic objects, the rule table includes at least the routine local command, routine parameters, response parsing rules, fault determination condition, associated fault code, freeze frame configuration, and downlink telemetry configuration. The unified diagnostic object rule table is pre-configured before the satellite leaves the factory, or it is added or updated on-orbit by the ground through the diagnostic rule update service.

[0050] When the diagnostic object type is a data-based diagnostic object, the onboard unified diagnostic process determines the data source according to the unified diagnostic object rule table. If the data source is a real-time value from the telemetry pool, a satellite status cache, frozen frame data, or a historical value from the telemetry database, the onboard unified diagnostic process reads the existing data through the satellite management process. If the data source is a real-time query from a subsystem, the onboard unified diagnostic process generates a diagnostic execution request, and the satellite management process obtains the corresponding data from the target subsystem. After obtaining the data, the onboard unified diagnostic process converts the raw data into engineering values ​​or diagnostic status values ​​according to the conversion formula, and determines whether a fault has occurred based on the fault threshold and fault judgment conditions.

[0051] When the diagnostic object type is a routine diagnostic object, the onboard unified diagnostic process determines the routine local command, routine parameters, timeout time, and response parsing rules according to the unified diagnostic object rule table, and generates a routine execution request; the satellite management process executes the corresponding routine according to the routine execution request and returns the routine response to the onboard unified diagnostic process; the onboard unified diagnostic process parses the routine response according to the response parsing rules and determines whether a fault has occurred according to the fault determination conditions.

[0052] When a fault is determined to be established, the onboard unified diagnostic process generates or updates a fault code, records the fault status, number of occurrences, occurrence time, associated diagnostic objects, and fault severity level, and automatically collects relevant telemetry, status information, operating mode, diagnostic object values, and routine execution results at the time of the fault according to the freeze frame configuration, forming a fault freeze frame. If the request flag in the unified diagnostic request, the onboard autonomous diagnostic trigger condition, or the downlink telemetry configuration in the rule table indicates that associated telemetry needs to be downlinked, the onboard unified diagnostic process generates a unified diagnostic response or diagnostic event telemetry containing the fault code, freeze frame summary, and associated telemetry data, which is encapsulated into a CCSDS telemetry packet by the onboard unified diagnostic gateway and the satellite service management process and downlinked to the ground diagnostic terminal.

[0053] Specifically, the unified diagnostic object rule table centrally stores the access methods, conversion rules, and fault determination rules for each diagnostic object. For data-based diagnostic objects, the onboard unified diagnostic process determines the data source (telemetry pool, status cache, freeze frame, or real-time query from subsystems) based on the rule table, obtains the data, converts it using conversion formulas to obtain the engineering value, and then determines whether a fault exists based on the fault threshold and determination conditions. For routine-based diagnostic objects, the local commands, parameters, and response parsing rules are determined based on the rule table. The onboard management process executes the routine, parses the response, and determines the fault. Once a fault is established, the onboard unified diagnostic process generates a fault code, collects a freeze frame, and downloads the associated telemetry data according to the configuration, completing the diagnostic loop.

[0054] In this embodiment, the unified diagnostic object rule table includes one or more of the following: rule number, rule version, rule enable flag, target subsystem identifier, diagnostic object type, diagnostic object identifier, data source type, data source identifier, conversion formula number, fault judgment rule number, upper limit threshold, lower limit threshold, abnormal duration, number of fault confirmations, associated diagnostic fault code, freeze frame configuration number, downlink telemetry configuration number, routine local command number, routine parameter template number, routine response parsing rule number, execution timeout, local interface type, local resource identifier, session requirement number, security permission requirement number, satellite mode constraint number, and autonomous diagnostic trigger condition number. The unified diagnostic object rule table includes a currently effective rule area and a temporary update rule area. When the ground diagnostic terminal uploads rule update data, the on-board unified diagnostic process first writes the rule update data into the temporary update rule area, and after completing the diagnostic session check, security access permission check, rule version check and integrity verification, it switches the temporary update rule area to the currently effective rule area. When the same diagnostic object corresponds to multiple data sources, the on-board unified diagnostic process selects diagnostic data from real-time values ​​of the telemetry pool, cached values ​​of the satellite service status, frozen frame data, historical values ​​of the telemetry database, and real-time query values ​​of the subsystem based on the data source type, data validity time, or data priority in the unified diagnostic object rule table. The onboard unified diagnostic gateway or onboard unified diagnostic process arbitrates multiple diagnostic requests based on the request source, diagnostic service type, target subsystem identifier, diagnostic object type, diagnostic object risk level, and satellite operation mode. Parallel processing is allowed for data-related diagnostic objects, while mutual exclusion is used for routine-related diagnostic objects that may change the state of the target subsystem, occupy bus resources, or trigger device actions. When the unified diagnostic response or diagnostic event telemetry fails to be transmitted in real time, the on-board unified diagnostic process will temporarily store the diagnostic fault code record, freeze frame summary, associated telemetry data and transmission status flag in the on-board diagnostic storage area, and retransmit them when the fault information query service is initiated in subsequent communication windows or ground diagnostic terminals. The triggering conditions for the satellite management process to generate onboard autonomous diagnostic requests include one or more of the following events: telemetry limit violation, status word anomaly, subsystem event reporting, subsystem heartbeat timeout, periodic health check, routine post-check, satellite mode switching, and safe mode entry.

[0055] Specifically, the rule table uses the diagnostic object as the core index, configuring each diagnostic object with complete fields including data source type, conversion formula, fault judgment rules, associated fault codes, freeze frame configuration, downlink telemetry configuration, and routine execution parameters. It also includes control information such as session requirements, security permissions, satellite mode constraints, and autonomous triggering conditions. Furthermore, the rule table employs a dual-zone design with a currently active zone and a temporary update zone, enabling the diagnostic rules to be safely updated in orbit. Based on this, the system ensures the flexibility of diagnostic data acquisition, the security of diagnostic access, and the reliable preservation and retransmission of diagnostic information when the satellite-to-ground link is not visible through mechanisms such as multiple data source priority selection, multiple diagnostic request arbitration, and temporary storage and retransmission of diagnostic events, thus forming a complete on-board diagnostic closed-loop system.

[0056] In this invention, the UDS / OBD diagnostic model is mainly used to form a unified diagnostic service semantics and diagnostic object description method, while the CCSDS protocol is mainly used to carry diagnostic requests and responses between the satellite and the ground. The two are not simply combined side-by-side, but rather adapted to satellite environments through a unified on-board diagnostic gateway, a unified on-board diagnostic process, and a unified diagnostic object rule table, enabling both ground-based on-demand diagnostic requests and on-board autonomous diagnostic requests to enter the same diagnostic processing flow.

[0057] Second Embodiment This embodiment further explains the overall architecture of the present invention and the details of each structure, as follows: (1) Overall Architecture like Figure 1 As shown, this embodiment provides a satellite unified diagnostic system based on the UDS / OBD diagnostic model and CCSDS protocol, including a ground diagnostic terminal, a satellite service management process, an on-board unified diagnostic gateway, and an on-board unified diagnostic process.

[0058] The ground diagnostic terminal generates ground-triggered diagnostic requests based on a diagnostic dictionary. These requests include a diagnostic service identifier, target subsystem identifier, diagnostic object type, diagnostic object identifier, request flag, diagnostic sequence number, and diagnostic request payload. The ground diagnostic terminal encapsulates the ground-triggered diagnostic request into a CCSDS remote control packet, where the APID in the CCSDS space packet's master header is set to the unified diagnostic APID.

[0059] After receiving the CCSDS remote control packet, the satellite management process performs a validity check on the packet and determines whether it is a unified diagnostic service based on the APID. If it is a unified diagnostic service, the diagnostic service data is forwarded to the onboard unified diagnostic gateway. The satellite management process also performs daily telemetry monitoring and status monitoring. When telemetry limits are exceeded, status words are abnormal, events are alarmed, periodic health check conditions are met, or satellite mode is switched, an onboard autonomous diagnostic request is generated.

[0060] The onboard unified diagnostic gateway receives ground-based diagnostic service data and / or onboard autonomous diagnostic requests, parses the unified diagnostic request header, extracts the diagnostic service identifier, target subsystem identifier, diagnostic object type, diagnostic object identifier, and diagnostic sequence number, and performs diagnostic request access judgment. When the access judgment is successful, the onboard unified diagnostic gateway generates an internal diagnostic request and sends it to the onboard unified diagnostic process.

[0061] The unified onboard diagnostic process comprises a unified diagnostic service and object rules management layer and a diagnostic execution request generation layer. The unified diagnostic service and object rules management layer categorizes diagnostic requests into data-type diagnostic object read requests or routine-type diagnostic object execution requests based on the diagnostic service identifier and diagnostic object type, and queries the unified diagnostic object rules table. The diagnostic execution request generation layer generates data read requests, subsystem query requests, or routine execution requests that can be executed by the satellite management process based on the rules table.

[0062] In this embodiment, the onboard unified diagnostic process does not directly drive various subsystem bus interfaces. Instead, it accesses the target subsystem through the satellite management process. This design is because different subsystems on the satellite platform typically employ different local communication methods, access cycles, and timing constraints. If the unified diagnostic process directly accesses all interfaces, it would require maintaining multiple sets of bus drivers and subsystem access states. By using the satellite management process as a subsystem access proxy, existing satellite telemetry acquisition, command scheduling, and subsystem status management capabilities can be reused, while avoiding resource conflicts caused by diagnostic access bypassing satellite task scheduling.

[0063] For ground-triggered diagnostic requests, the satellite management process primarily handles CCSDS remote control packet reception, service identification, and diagnostic service data forwarding. For onboard autonomous diagnostic requests, the satellite management process also monitors trigger conditions and generates requests. Both types of requests, upon entering the onboard unified diagnostic gateway, are converted into internal diagnostic requests and processed by the onboard unified diagnostic process according to the unified diagnostic object rule table.

[0064] (2) Unified source of diagnostic requests In this embodiment, the unified diagnostic request includes ground-triggered diagnostic requests and onboard autonomous diagnostic requests.

[0065] Ground-triggered diagnostic requests are generated by the ground diagnostic terminal and uplinked to the satellite via CCSDS remote control packets. These requests are used by the ground to read diagnostic objects on demand, execute routine objects, query fault information, read freeze frames, or modify diagnostic parameters.

[0066] The onboard autonomous diagnostic request is generated by the satellite management process. The satellite management process determines whether autonomous diagnostics needs to be triggered based on telemetry data in the telemetry pool, subsystem status, event alarms, periodic health checks, or satellite mode switching conditions. When the triggering conditions are met, the satellite management process generates an onboard autonomous diagnostic request and sends it to the onboard unified diagnostic gateway or the onboard unified diagnostic process.

[0067] Both ground-triggered diagnostic requests and onboard autonomous diagnostic requests use the same unified diagnostic object description method. Therefore, regardless of whether the diagnostic request originates from the ground or from the satellite management process, it is processed by the onboard unified diagnostic process using the unified diagnostic object rule table.

[0068] (3) Standardize the format of remote diagnostic packages In this embodiment, the unified diagnostic remote control packet format is shown in Table 1. This unified diagnostic remote control packet consists of a spatial packet master header, a unified diagnostic request header, a unified diagnostic request payload, and a checksum. The spatial packet master header is used for packet identification and application process distribution at the CCSDS layer; the unified diagnostic request header carries the semantics of diagnostic services and diagnostic objects; and the diagnostic request payload carries specific service parameters.

[0069] Table 1. Standard Diagnostic Remote Control Package Format

[0070]

[0071]

[0072]

[0073] (4) Standardize the format of diagnostic telemetry packages In this embodiment, the format of the unified diagnostic telemetry packet is shown in Table 2. This unified diagnostic telemetry packet consists of a space packet master header, a unified diagnostic response header, and a unified diagnostic response payload.

[0074] Table 2. Standard Diagnostic Telemetry Package Format

[0075]

[0076]

[0077]

[0078]

[0079] (5) Unified diagnostic object rule table In this embodiment, the unified diagnostic object rule table is shown in Table 3. The unified diagnostic object rule table is used to uniformly manage the access method, data source, conversion rules, routine execution method, fault judgment rules, associated diagnostic fault codes, freeze frame configuration, and downlink telemetry configuration of diagnostic objects.

[0080] Table 3. Rules for Unified Diagnostic Subjects

[0081]

[0082]

[0083]

[0084] The unified diagnostic object rule table is pre-configured before the satellite leaves the factory. Each rule table entry is indexed by the target subsystem identifier, diagnostic object type, and diagnostic object identifier to avoid conflicts between diagnostic objects with the same name or type in different subsystems. The rule table is stored in the onboard non-volatile memory. After the onboard unified diagnostic process starts, it loads the currently valid version of the rule table into the memory rule cache. When a diagnostic request arrives, the onboard unified diagnostic process first queries the memory rule cache for the corresponding rule; if the rule cache verification fails, the rule version is inconsistent, or the corresponding rule does not exist, the onboard unified diagnostic process can reload the rule table from the non-volatile memory or return a negative response indicating that the object is not supported.

[0085] When an on-orbit rule table update is required, the ground diagnostic terminal sends rule update data through the diagnostic rule update service. The onboard unified diagnostic gateway first performs diagnostic session checks, security access permission checks, data length checks, and integrity checks on the rule update request. If the checks pass, the onboard unified diagnostic process writes the update data to the temporary rule area, without directly overwriting the currently effective rule area. Once the rule number, target subsystem identifier, diagnostic object identifier, rule version, and checksum have all passed checks, the temporary rule area is switched to the currently effective rule area. If the checks fail, the original rule table remains in effect, and the reason for the rule update failure is returned via the unified diagnostic response.

[0086] For newly added subsystems or payload devices, the ground-based diagnostic rule configuration tool can assign new target subsystem identifiers and diagnostic object identifiers, and add corresponding rule table entries. If existing conversion formulas and fault determination rules can cover the new diagnostic object, there is no need to modify the software logic of the unified diagnostic process on the satellite. If the new diagnostic object requires new conversion formulas or fault determination rules, these can be supplemented by expanding the conversion formula table or fault determination rule table, and the expanded rule data and the unified diagnostic object rule table can be uploaded to the satellite. In this way, the present invention can expand new diagnostic objects without changing the main process of unified diagnostic processing.

[0087] like Figure 3 The diagram shown illustrates the logical relationship of the unified diagnostic object rule table of this invention. The unified diagnostic object rule table uses the diagnostic object identifier as the core index and groups rules according to the target subsystem identifier and diagnostic object type, establishing a mapping relationship between diagnostic objects and data sources, conversion rules, fault determination rules, associated diagnostic fault codes, freeze frame configurations, downlink telemetry configurations, and routine execution rules. The configuration items in the rule table are interconnected, collectively forming a complete diagnostic object description and fault closed-loop processing logic.

[0088] (6) Data-related diagnostic object processing flow When a data-type diagnostic object request generated by a ground diagnostic terminal or the satellite management process enters the satellite unified diagnostic process, the unified diagnostic service and object rule management layer queries the unified diagnostic object rule table based on the target subsystem identifier, diagnostic object type, and diagnostic object identifier to obtain the data source type, data source identifier, conversion formula, fault threshold, fault judgment rule, associated diagnostic fault code, freeze frame configuration, and downlink telemetry configuration.

[0089] If the data source type represents real-time values ​​from the telemetry pool, the onboard unified diagnostic process reads the corresponding telemetry value from the telemetry pool through the satellite management process; if the data source type represents state cache, the corresponding state is read from the satellite state cache; if the data source type represents frozen frame data, it is read from the frozen frame storage area; if the data source type represents real-time query from a subsystem, the diagnostic execution request generation layer generates a diagnostic execution request, and the satellite management process obtains the corresponding data through the target subsystem's local interface.

[0090] For the same data type diagnostic object, there may be simultaneous real-time values ​​from the telemetry pool, cached values ​​from the satellite service status, frozen frame data, historical telemetry values, and real-time query values ​​from the subsystem. This embodiment determines the data retrieval strategy by using the data source type, data validity time, and request flag in the unified diagnostic object rule table. If the request flag in the unified diagnostic request allows the use of cached data, and the data timestamp in the telemetry pool or status cache does not exceed the valid time window, the onboard unified diagnostic process prioritizes using existing data to reduce the number of accesses to the target subsystem. If the request flag indicates mandatory real-time diagnostics, or if existing data exceeds the valid time window, the diagnostic execution request generation layer generates a real-time query request for the subsystem, and the satellite service management process accesses the target subsystem to obtain the current data.

[0091] When values ​​from multiple data sources are inconsistent, the onboard unified diagnostic process selects data according to the data priority configured in the unified diagnostic object rule table. For fault analysis scenarios, the fault time data recorded in the fault freeze frame takes precedence over subsequently updated telemetry pool data; for real-time status confirmation scenarios, the subsystem's real-time query value takes precedence over historical telemetry values; for routine health check scenarios, real-time telemetry pool values ​​or onboard status cache values ​​can be used preferentially. If all data sources are invalid, the onboard unified diagnostic process returns a negative response and can trigger a supplementary query according to the rule configuration.

[0092] After acquiring the raw data, the onboard unified diagnostic process generates engineering values ​​or diagnostic status values ​​according to the conversion formula. Subsequently, the onboard unified diagnostic process determines whether a fault has occurred based on the fault thresholds and fault determination rules in the rule table. The fault determination rules include one or more of the following: above the upper limit, below the lower limit, out of range, abnormal status bit, multiple consecutive abnormalities, and abnormal duration exceeding the threshold.

[0093] If no fault occurs, a normal diagnostic response containing the diagnostic object value is generated. If a fault occurs, an associated diagnostic fault code is generated or updated, the relevant telemetry frames at the time of the fault are automatically frozen, and a diagnostic response or event telemetry containing the diagnostic fault code, a summary of the frozen frames, and associated telemetry data is generated according to the downlink telemetry configuration.

[0094] (7) Processing flow for routine-type diagnostic objects This embodiment illustrates the execution and fault determination process of routine-type diagnostic objects.

[0095] When a routine diagnostic object request generated by a ground diagnostic terminal or the satellite management process enters the onboard unified diagnostic process, the unified diagnostic service and object rule management layer queries the unified diagnostic object rule table based on the target subsystem identifier, diagnostic object type, and diagnostic object identifier to obtain the routine local command, routine parameters, routine response parsing rules, routine timeout time, fault judgment rules, associated diagnostic fault codes, freeze frame configuration, and downlink telemetry configuration.

[0096] The diagnostic execution request generation layer generates a routine execution request based on the rule table and sends it to the space management process. The space management process executes the corresponding routine based on the routine execution request via the 1553B bus, CAN bus, RS422 interface, SpaceWire interface, shared memory interface, onboard software interface, or telemetry database interface, and returns a routine response.

[0097] The onboard unified diagnostic process parses routine responses according to routine response parsing rules to obtain routine execution status, routine return codes, and routine result data. If the routine executes successfully and does not meet the fault determination conditions, a normal diagnostic response is generated. If the routine fails to execute, times out, or the return code does not meet the expected value, a fault is determined, an associated diagnostic fault code is generated or updated, the fault time frame is automatically frozen, and associated telemetry is downlinked according to the downlink telemetry configuration.

[0098] (8) Triggering autonomous diagnosis of the star service management process This embodiment describes the process by which the celebrity management process autonomously initiates a diagnostic request.

[0099] The satellite management process periodically monitors the telemetry pool, subsystem status words, subsystem heartbeats, satellite event table, and satellite operating modes. When it detects telemetry limit violations, status word anomalies, event alarms, subsystem heartbeat timeouts, periodic health checks expiring, or the satellite entering safe mode, the satellite management process generates an onboard autonomous diagnostic request based on autonomous diagnostic trigger rules.

[0100] The onboard autonomous diagnostic request includes a diagnostic service identifier, a target subsystem identifier, a diagnostic object type, and a diagnostic object identifier. The onboard autonomous diagnostic request can be a data-type diagnostic object read request or a low-risk routine-type diagnostic object execution request. After entering the onboard unified diagnostic process, this request is processed through the unified diagnostic object rule table, just like ground-triggered diagnostic requests.

[0101] When an onboard autonomous diagnostic request triggers a fault determination, the onboard unified diagnostic process generates or updates a diagnostic fault code, generates a fault freeze frame, and transmits a diagnostic event telemetry down to the ground through the satellite management process.

[0102] (9) Diagnostic fault code update and fault freeze frame In this embodiment, diagnostic fault codes are not implemented as an independent fault management system, but rather as fault result identifiers within a unified diagnostic process, used in conjunction with fault freeze frames and associated telemetry downlink mechanisms. The onboard unified diagnostic process can generate, update, maintain, restore, or clear diagnostic fault code records based on the fault determination results. For ground-triggered diagnostic requests, diagnostic fault code records can be downlinked along with the unified diagnostic response; for onboard autonomous diagnostic requests, diagnostic fault code records can be downlinked as part of the diagnostic event telemetry.

[0103] Fault freeze frames are generated based on freeze frame configurations in the unified diagnostic object rule table. Freeze frame configurations can specify the associated telemetry data to be collected, state variables, satellite operating modes, target subsystem states, diagnostic object values, routine execution results, and diagnostic rule versions. Fault freeze frames can be stored in the onboard diagnostic storage area and can be downloaded to ground diagnostic terminals via unified diagnostic response, diagnostic event telemetry, or fault information query services.

[0104] To adapt to limited onboard storage resources, freeze frames can be configured for either full freeze or summary freeze. For critical faults such as entering safe mode, power supply and distribution anomalies, or thermal control anomalies, a more complete set of associated telemetry data can be collected according to the freeze frame configuration. For general anomalies, only the diagnostic object value, key status words, time information, and freeze frame number can be recorded. The ground diagnostic terminal can further initiate a freeze frame read service based on the freeze frame number to obtain more complete fault site data.

[0105] It should be noted that this embodiment focuses on the coordination between diagnostic fault codes, unified diagnostic object rule table, fault freeze frames, and associated telemetry downlinks; the specific encoding method of diagnostic fault codes, state machine management strategy, fault priority determination, and complex fault association logic can be configured separately according to task needs, and this invention does not impose specific limitations on them.

[0106] (10) Unified diagnostic information flow like Figure 2 As shown, the unified diagnostic information flow in this embodiment includes: Obtain a unified diagnostic request, the source of which includes the ground diagnostic terminal and the satellite management process; If the request originates from a ground diagnostic terminal, the ground diagnostic terminal sends the diagnostic request via the CCSDS remote control packet, and the satellite management process distributes the diagnostic service data to the satellite unified diagnostic gateway based on the unified diagnostic application process identifier. If the request originates from the satellite management process, the satellite management process generates an onboard autonomous diagnostic request based on telemetry monitoring, event alarms, or periodic health check conditions. The onboard unified diagnostic gateway parses the diagnostic request header and completes the diagnostic request admission judgment. The onboard unified diagnostic process categorizes requests into data object reading or routine object execution based on the diagnostic service identifier and the type of diagnostic object. For data objects, the onboard unified diagnostic process queries the rule table to obtain the data source, conversion formula and fault threshold, retrieves data from the telemetry pool, status cache or target subsystem, and determines whether there is a fault. For routine objects, the onboard unified diagnostic process queries the rule table to obtain the routine command and response parsing rules. The onboard management process then executes the routine and determines whether there is a fault based on the routine response. If the fault is confirmed, update the diagnostic fault code, freeze the fault frame, and download the associated telemetry data. The onboard unified diagnostic gateway generates diagnostic responses or event telemetry, which are then encapsulated into CCSDS telemetry packets by the satellite management process and transmitted to the ground diagnostic terminal.

[0107] (11) Diagnostic request judgment mechanism During satellite operation, ground-triggered diagnostic requests and onboard autonomous diagnostic requests may arrive simultaneously, and they may both target the same subsystem. To avoid diagnostic access affecting normal satellite operations, in this embodiment, the onboard unified diagnostic gateway or onboard unified diagnostic process evaluates multiple diagnostic requests.

[0108] The judgment criteria include the request source, diagnostic service type, target subsystem identifier, diagnostic object type, diagnostic object risk level, satellite current operating mode, and session and permission constraints in the unified diagnostic object rule table. For data-type diagnostic objects that only read status or telemetry data, the onboard unified diagnostic process allows multiple requests to be processed in parallel; for routine-type diagnostic objects that may change subsystem status, occupy bus resources, or trigger device actions, a mutual exclusion execution mode is adopted, allowing only one related routine to execute at the same time for the same target subsystem.

[0109] When a regular ground query request conflicts with an onboard safety protection-related autonomous diagnostic request, the safety protection-related autonomous diagnostic request shall be executed first. When a periodic health check request conflicts with a ground-specified diagnostic request, the periodic health check request may be delayed. When multiple ground diagnostic requests access the same target subsystem at the same time, they may be processed in order of diagnostic sequence number, service type, or request priority.

[0110] For diagnostic requests that are delayed, rejected, or pending, the onboard unified diagnostic process generates a unified diagnostic response that includes the response status, negative response code, or reason for the pending status, and feeds it back to the ground diagnostic terminal via CCSDS telemetry packets. This judgment mechanism prevents diagnostic requests from interfering with normal onboard mission scheduling, subsystem bus access, and safety mode control.

[0111] (12) Mechanism for temporary storage and retransmission of diagnostic events During satellite operation, the telemetry, tracking, and command (TT&C) link is often invisible, or the current telemetry downlink bandwidth is insufficient to transmit complete diagnostic results in real time. To avoid the loss of fault site information, the onboard unified diagnostic process can temporarily store diagnostic event telemetry, diagnostic fault code records, freeze frame summaries, and associated telemetry data in the onboard diagnostic storage area, and then transmit them when subsequent arcs are idle.

[0112] The onboard diagnostic storage area stores at least the diagnostic sequence number, diagnostic fault code summary, freeze frame number, associated diagnostic object identifier, event occurrence time, and downlink status flag. If the diagnostic event telemetry has been successfully downlinked, the corresponding record can be marked as downlinked; if it has not been successfully downlinked, it remains in a pending downlink state. When the satellite enters a subsequent communication window, or when the ground diagnostic terminal initiates a fault information query service, the satellite management process encapsulates the pending diagnostic event telemetry into a CCSDS telemetry packet and downlinks it.

[0113] For situations with limited storage space, the onboard diagnostic storage area can be configured with an overwrite strategy based on the severity of the fault, the time of occurrence, and whether it has been transmitted. High-severity fault records that have not been transmitted are retained first; low-severity fault records that have been transmitted can be overwritten when the storage area is full. Through this mechanism, even if the satellite-to-ground link is unavailable when a fault occurs, diagnostic results and fault location information can still be obtained in subsequent communication windows.

[0114] Third Embodiment This embodiment provides a method executed by a satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol as described in the first embodiment, including the following steps: Obtain a unified diagnostic request, which includes a ground-triggered diagnostic request sent by the ground diagnostic terminal via the CCSDS remote control packet, and / or an onboard autonomous diagnostic request generated by the satellite service management process based on telemetry monitoring, event alarms, or periodic health checks. The onboard unified diagnostic gateway parses the unified diagnostic request header and extracts the diagnostic service identifier, target subsystem identifier, diagnostic object type, and diagnostic object identifier. The onboard unified diagnostic process determines whether the unified diagnostic request is a data-type diagnostic object read request or a routine-type diagnostic object execution request based on the diagnostic service identifier and the diagnostic object type. If the request is for reading a data-based diagnostic object, the unified diagnostic object rule table is queried to obtain the data source, conversion formula, fault threshold and fault judgment rule, and the corresponding diagnostic data is obtained for fault judgment. If a routine-type diagnostic object execution request is made, the unified diagnostic object rule table is queried to obtain the routine command, routine parameters, response parsing rules and fault judgment rules, and the space service management process executes the corresponding routine and returns the routine response; The onboard unified diagnostic process determines whether a fault has occurred based on fault determination rules. If a fault occurs, a diagnostic fault code is generated or updated, and a fault freeze frame is generated. The onboard unified diagnostic gateway generates unified diagnostic responses or diagnostic event telemetry, which is then encapsulated into CCSDS telemetry packets by the satellite management process and transmitted to the ground diagnostic terminal.

[0115] A computer-readable storage medium stores computer code that, when executed, performs the methods described above. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0116] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0117] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0118] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A unified satellite diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol, characterized in that, This includes ground diagnostic terminals, satellite management processes, onboard unified diagnostic gateways, and onboard unified diagnostic processes. The ground diagnostic terminal is used to generate a ground-triggered diagnostic request and encapsulate the ground-triggered diagnostic request into a CCSDS remote control packet and send it to the satellite; The satellite management process is used to receive the CCSDS remote control packet, identify the unified diagnostic service, and forward it to the satellite unified diagnostic gateway. It is also used to generate a satellite autonomous diagnostic request based on the telemetry monitoring results and to access the target subsystem based on the diagnostic execution request. The on-board unified diagnostic gateway is used to receive ground diagnostic service data and / or on-board autonomous diagnostic requests, parse the unified diagnostic request header and make diagnostic request admission judgment. The onboard unified diagnostic process is used to process unified diagnostic requests according to the unified diagnostic object rule table, execute the reading or routine of diagnostic objects, determine faults, and generate or update diagnostic fault codes, generate fault freeze frames and associated telemetry when a fault is established. These are then encapsulated into CCSDS telemetry packets by the onboard unified diagnostic gateway and the satellite service management process and transmitted to the ground diagnostic terminal.

2. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 1, characterized in that, The unified diagnostic request includes ground-triggered diagnostic requests and on-board autonomous diagnostic requests; The ground-triggered diagnostic request is generated by the ground diagnostic terminal and sent to the satellite management process via the CCSDS remote control packet. The onboard autonomous diagnostic request is generated by the satellite management process based on telemetry data in the telemetry pool, subsystem status, event alarms, periodic health checks, or satellite mode switching conditions. Both the ground-triggered diagnostic request and the onboard autonomous diagnostic request adopt a unified diagnostic object description method, which includes a diagnostic service identifier, a target subsystem identifier, a diagnostic object type, and a diagnostic object identifier. Both are processed by the onboard unified diagnostic process according to the unified diagnostic object rule table.

3. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 1, characterized in that, The ground-triggered diagnostic request generated by the ground diagnostic terminal includes a diagnostic service identifier, a target subsystem identifier, a diagnostic object type, a diagnostic object identifier, a request flag, a diagnostic sequence number, and a diagnostic request payload. The diagnostic service identifier is used to indicate the operation performed on the unified diagnostic object, and the operation includes one or more of reading, writing, executing, querying, and clearing; The diagnostic object types include one or more of the following: data-type diagnostic objects, routine-type diagnostic objects, fault information-type diagnostic objects, fault record-type diagnostic objects, freeze frame-type diagnostic objects, and diagnostic parameter-type diagnostic objects.

4. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 1, characterized in that, The satellite service management process is used to receive CCSDS remote control packets and determine whether it is a unified diagnostic service based on APID or service type. When it is identified as a unified diagnostic service, the diagnostic service data is forwarded to the satellite unified diagnostic gateway. The satellite management process is also used to perform daily telemetry monitoring, status monitoring and event monitoring, and generate onboard autonomous diagnostic requests based on the monitoring results; The satellite management process is also used to access the target subsystem based on the diagnostic execution request generated by the onboard unified diagnostic process. The access methods include one or more of the following: 1553B bus, CAN bus, RS422 interface, SpaceWire interface, shared memory interface, onboard software API, and telemetry database interface.

5. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 1, characterized in that, The onboard unified diagnostic gateway is used to receive diagnostic service data or onboard autonomous diagnostic requests from the satellite service management process, parse the unified diagnostic request header, extract the diagnostic service identifier, target subsystem identifier, diagnostic object type, diagnostic object identifier and diagnostic sequence number, and perform diagnostic request access judgment. The access determination includes service legitimacy determination, current diagnostic session status determination, security permission determination, and satellite operation mode constraint determination; The admission decision does not rely on reserved fields in the unified diagnostic request header, but is executed based on the diagnostic session status maintained on-board, the secure access status, the satellite operation mode provided by the satellite management process, and the constraints in the unified diagnostic object rule table.

6. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 1, characterized in that, The on-board unified diagnostic process includes a unified diagnostic service and object rule management layer and a diagnostic execution request generation layer. The unified diagnostic service and object rule management layer is used to distinguish whether the current diagnostic request is a data-type diagnostic object read request or a routine-type diagnostic object execution request based on the diagnostic service identifier and diagnostic object type, and to query the unified diagnostic object rule table based on the target subsystem identifier, diagnostic object type, and diagnostic object identifier; The diagnostic execution request generation layer is used to generate executable data read requests, subsystem real-time query requests, or routine execution requests for the space management process based on the unified diagnostic object rule table.

7. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 1, characterized in that, The CCSDS remote control package includes a space package master header, a unified diagnostic request header, and a unified diagnostic request payload. The space packet header is used to identify the space packet version, packet type, application process identifier, packet sequence count, and packet data length. The application process identifier is used to indicate the unified diagnostic remote control service. The unified diagnostic request header is 16 bytes long and includes a diagnostic protocol version field, a diagnostic service identifier field, a target subsystem identifier field, a diagnostic object type field, a request flag field, a diagnostic object identifier field, a diagnostic sequence number field, a payload length field, and a reserved field.

8. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 1, characterized in that, The unified diagnostic object rule table is used to store the access rules, conversion rules, and fault determination rules of diagnostic objects; For data-related diagnostic objects, the rule table includes at least the data source type, data source identifier, conversion formula, fault threshold, fault judgment condition, associated fault code, freeze frame configuration, and downlink telemetry configuration. For routine-type diagnostic objects, the rule table includes at least the routine local command, routine parameters, response parsing rules, fault judgment conditions, associated fault codes, freeze frame configuration, and downlink telemetry configuration. The unified diagnostic object rule table is pre-set before the satellite leaves the factory, or is added or updated on-orbit by the ground through the diagnostic rule update service.

9. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 8, characterized in that, When the diagnostic object type is a data-type diagnostic object, the on-board unified diagnostic process determines the data source according to the unified diagnostic object rule table. If the data source is real-time values ​​from the telemetry pool, satellite status cache, frozen frame data, or historical values ​​from the telemetry database, the onboard unified diagnostic process reads the existing data through the satellite management process. If the data source is a real-time query from a subsystem, the onboard unified diagnostic process generates a diagnostic execution request, and the satellite management process obtains the corresponding data from the target subsystem. After acquiring the data, the onboard unified diagnostic process converts the raw data into engineering values ​​or diagnostic status values ​​according to the conversion formula, and determines whether a fault has occurred based on the fault threshold and fault judgment conditions.

10. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 8, characterized in that, When the diagnostic object type is a routine diagnostic object, the onboard unified diagnostic process determines the routine local command, routine parameters, timeout time and response parsing rules according to the unified diagnostic object rule table, and generates a routine execution request. The satellite management process executes the corresponding routine based on the routine execution request and returns the routine response to the onboard unified diagnostic process. The onboard unified diagnostic process parses routine responses according to response parsing rules and determines whether a fault has occurred based on fault determination conditions.

11. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 9 or 10, characterized in that, When a fault is determined to be established, the onboard unified diagnostic process generates or updates a fault code, records the fault status, number of occurrences, occurrence time, associated diagnostic objects, and fault severity level, and automatically collects relevant telemetry, status information, operating mode, diagnostic object values, and routine execution results at the time of the fault according to the freeze frame configuration, forming a fault freeze frame. If the request flag in the unified diagnostic request, the onboard autonomous diagnostic triggering condition, or the downlink telemetry configuration indication in the rule table requires the downlink of associated telemetry, the onboard unified diagnostic process generates a unified diagnostic response or diagnostic event telemetry containing fault codes, freeze frame summaries, and associated telemetry data. This response is then encapsulated into a CCSDS telemetry packet by the onboard unified diagnostic gateway and the satellite service management process and downlinked to the ground diagnostic terminal.

12. The satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol according to claim 1, characterized in that, The unified diagnostic object rule table includes one or more of the following: rule number, rule version, rule enable flag, target subsystem identifier, diagnostic object type, diagnostic object identifier, data source type, data source identifier, conversion formula number, fault judgment rule number, upper limit threshold, lower limit threshold, abnormal duration, number of fault confirmations, associated diagnostic fault code, freeze frame configuration number, downlink telemetry configuration number, routine local command number, routine parameter template number, routine response parsing rule number, execution timeout, local interface type, local resource identifier, session requirement number, security permission requirement number, satellite mode constraint number, and autonomous diagnostic trigger condition number. The unified diagnostic object rule table includes a currently effective rule area and a temporary update rule area. When the ground diagnostic terminal uploads rule update data, the on-board unified diagnostic process first writes the rule update data into the temporary update rule area, and after completing the diagnostic session check, security access permission check, rule version check and integrity verification, it switches the temporary update rule area to the currently effective rule area. When the same diagnostic object corresponds to multiple data sources, the on-board unified diagnostic process selects diagnostic data from real-time values ​​of the telemetry pool, cached values ​​of the satellite service status, frozen frame data, historical values ​​of the telemetry database, and real-time query values ​​of the subsystem based on the data source type, data validity time, or data priority in the unified diagnostic object rule table. The onboard unified diagnostic gateway or onboard unified diagnostic process arbitrates multiple diagnostic requests based on the request source, diagnostic service type, target subsystem identifier, diagnostic object type, diagnostic object risk level, and satellite operation mode. Parallel processing is allowed for data-related diagnostic objects, while mutual exclusion is used for routine-related diagnostic objects that may change the state of the target subsystem, occupy bus resources, or trigger device actions. When the unified diagnostic response or diagnostic event telemetry fails to be transmitted in real time, the on-board unified diagnostic process will temporarily store the diagnostic fault code record, freeze frame summary, associated telemetry data and transmission status flag in the on-board diagnostic storage area, and retransmit them when the fault information query service is initiated in subsequent communication windows or ground diagnostic terminals. The triggering conditions for the satellite management process to generate onboard autonomous diagnostic requests include one or more of the following events: telemetry limit violation, status word anomaly, subsystem event reporting, subsystem heartbeat timeout, periodic health check, routine post-check, satellite mode switching, and safe mode entry.

13. A method executed by a satellite unified diagnostic system based on the UDS_OBD diagnostic model and CCSDS protocol as described in any one of claims 1-12, characterized in that, Includes the following steps: A unified diagnostic request is obtained, which includes a ground-triggered diagnostic request sent by the ground diagnostic terminal through the CCSDS remote control packet, and / or an onboard autonomous diagnostic request generated by the satellite management process based on telemetry monitoring, event alarms, or periodic health checks; the onboard unified diagnostic gateway parses the unified diagnostic request header and extracts the diagnostic service identifier, target subsystem identifier, diagnostic object type, and diagnostic object identifier; The onboard unified diagnostic process determines whether the unified diagnostic request is a data-type diagnostic object read request or a routine-type diagnostic object execution request based on the diagnostic service identifier and the diagnostic object type. If it is a data-type diagnostic object read request, the unified diagnostic object rule table is queried to obtain the data source, conversion formula, fault threshold and fault judgment rule, and the corresponding diagnostic data is obtained for fault judgment. If a routine-type diagnostic object execution request is made, the unified diagnostic object rule table is queried to obtain the routine command, routine parameters, response parsing rules and fault judgment rules, and the space service management process executes the corresponding routine and returns the routine response; The onboard unified diagnostic process determines whether a fault has occurred based on fault determination rules. If a fault occurs, a diagnostic fault code is generated or updated, and a fault freeze frame is generated. The onboard unified diagnostic gateway generates unified diagnostic responses or diagnostic event telemetry, which is then encapsulated into CCSDS telemetry packets by the satellite management process and transmitted to the ground diagnostic terminal.

Images