An internal communication management system for deep space probe satellites

Abstract

This invention provides an internal communication management system for a deep space exploration satellite, belonging to the field of communication transmission technology. It includes a communication management unit, a satellite integrated electronic subsystem, and multiple payloads. The communication management unit connects to the satellite integrated electronic subsystem via a 1553B bus and connects to each payload via an RS422 bus and a SerDes bus, respectively. The link layer of the communication management unit responds to data block transmission commands received via the 1553B bus, dynamically switching between master-slave mode and point-to-point mode. In master-slave mode, it polls multiple payloads; in point-to-point mode, it establishes a direct link with a designated payload to transmit scientific data. The command layer organizes mission commands into command frames and sends them to the payloads, parses the response frames returned by the payloads, and interacts with the satellite integrated electronic subsystem via data frames. While the SerDes bus is transmitting data in point-to-point mode, the communication management unit suspends response to all commands except for reset commands until the current data transmission is complete.

Description

Technical Field

[0001] This invention belongs to the field of communication transmission technology, specifically relating to a multi-channel heterogeneous bus communication management system and its communication method applied in remote detection scenarios, and particularly to a high-speed data transmission control scheme based on a multi-bus architecture to achieve dynamic switching between master-slave polling and point-to-point direct connection modes. Background Technology

[0002] Deep space exploration missions (such as lunar, Mars, and asteroid exploration) place extremely high demands on the reliability, real-time performance, and accuracy of data transmission of satellite platforms. As a crucial hub connecting the payload and the satellite's integrated electronic subsystems, the performance of the satellite's internal communication management system directly impacts the quality of scientific mission execution and the success or failure of the exploration mission.

[0003] Currently, the "RS422+1553B" bus architecture is mainly used in spaceborne data communication. The 1553B bus boasts high reliability and deterministic latency, making it widely used in military spacecraft and satellite platforms. The RS422 bus employs differential signal transmission, offering strong anti-interference capabilities and long transmission distances, typically configured for transmission rates below 1 Mbps in spaceborne applications. However, the 1553B bus relies on a bus controller (BC) for centralized scheduling, resulting in a concentrated bus load and limited system scalability. Furthermore, the RS422 bus often employs a simple polling protocol with one master and multiple slaves when building multi-node systems, lacking robust link management and error recovery mechanisms, leading to low bus efficiency in complex multi-payload interaction scenarios. Moreover, limited by the transmission rates of 1553B and RS422, the existing architecture struggles to meet the transmission requirements of high-speed scientific data (such as high-resolution image data), and existing communication protocols lack effective support for high-speed data links (such as serial high-speed buses).

[0004] Meanwhile, existing satellite internal communication protocols are mostly flat in design with unclear hierarchical divisions, mixing low-level physical transmission with high-level application logic. This leads to problems such as uncertain command response delays, untimely status monitoring, poor system scalability, and difficulties in software development and maintenance. In particular, for the complex scientific mission scheduling requirements of deep space exploration, existing solutions struggle to achieve efficient and unified management of multi-payload coordination, real-time status feedback, and high-precision attitude and orbit control information exchange. When high-speed point-to-point data transmission is required, existing systems cannot effectively manage other concurrent commands during transmission, easily leading to bus conflicts or data integrity risks.

[0005] In summary, existing technologies lack a satellite internal communication management system that can simultaneously handle high-speed data transmission, high-reliability control, hierarchical protocol management, and a robust bus resource scheduling mechanism, making it difficult to meet the stringent requirements of deep space exploration missions for communication systems. Summary of the Invention

[0006] To address the shortcomings and deficiencies of existing technologies, this invention provides an internal communication management system and method for deep space exploration satellites. The system innovatively integrates three heterogeneous buses in hardware: a 1553B bus connecting to the satellite's integrated electronic subsystem for transmitting highly reliable platform-level commands and status information; an RS422 bus connecting to multiple payloads for transmitting routine control commands and status information; and a SerDes high-speed serial bus connecting to payloads specifically for transmitting high-speed scientific data. In software, the system runs a four-layer communication protocol stack from bottom to top, comprising a physical layer, a link layer, a command layer, and an application layer. The link layer can dynamically switch between master-slave mode and point-to-point mode in response to data block transmission commands received via the 1553B bus. In master-slave mode, the system polls each payload at a preset period via the RS422 bus; in point-to-point mode, it establishes an exclusive direct link with a designated payload via the SerDes bus. The command layer, as the core, is responsible for organizing mission instructions into command frames for transmission, parsing payload response frames, and exchanging data frames with the satellite integrated electronic subsystem. Crucially, during point-to-point data transmission on the SerDes bus, the entire communication management unit suspends responses to all instructions except reset commands to ensure the integrity and real-time performance of high-speed data transmission.

[0007] This invention further provides several preferred solutions, such as: ensuring the above-mentioned instruction pause mechanism by setting mode status flags and increasing interrupt priority; assigning a unique 1-byte ID number to each payload on the RS422 bus; setting an instruction retransmission mechanism at the link layer that includes single retransmission and error reporting; adopting a dual-machine cold backup autonomous switching mechanism based on a weighted health assessment model with latency judgment; defining a unified structure for all communication frames that includes a fixed frame header of 0xEB90; implementing a scheduling algorithm at the application layer that supports priority preemption, time slice rotation, and timeout task degradation retry; specifying a synchronization and frame delimitation method for the SerDes bus based on specific control characters; and supporting a dual-redundancy architecture for the 1553B bus and on-orbit dynamic configuration of the RS422 bus baud rate.

[0008] The specific technical solution adopted by this invention to solve its technical problem is as follows: This invention provides an internal communication management system for a deep space exploration satellite, including a communication management unit, a satellite integrated electronic subsystem, and multiple payloads. The communication management unit is connected to the satellite integrated electronic subsystem via a 1553B bus, and to each payload via an RS422 bus and a SerDes bus. This three-bus heterogeneous architecture provides the foundation for the system to simultaneously exchange 1553B commands and status in the control plane, obtain the routine status of multiple payloads via RS422 polling in the low-speed data plane, and establish dedicated high-bandwidth links via SerDes in the high-speed data plane.

[0009] The communication management unit operates a four-layer communication protocol stack, consisting of the physical layer, link layer, command layer, and application layer from bottom to top. This explicit layered design decouples the underlying physical transmission characteristics from the higher-level task scheduling logic, reducing software complexity and improving maintainability.

[0010] The link layer dynamically switches between master-slave and point-to-point modes in response to data block transmission commands received via the 1553B bus. This mechanism ensures that the initiation of high-speed data transmission is arbitrated by the highly reliable 1553B link, avoiding mode conflicts. In master-slave mode, the communication management unit polls multiple payloads at a preset period via the RS422 bus, suitable for acquiring conventional engineering data and low-bandwidth scientific data. In point-to-point mode, the communication management unit establishes a direct link with a designated payload via the SerDes bus to transmit high-speed scientific data, providing a high-throughput channel for large data blocks.

[0011] The command layer is used to organize mission instructions into command frames and send them to the payload, parse the response frames returned by the payload, and interact with the satellite integrated electronic subsystem through data frames. Therefore, upper-layer applications only need to focus on the mission logic, without needing to worry about specific frame encapsulation and physical link differences.

[0012] Specifically, during point-to-point data transmission on the SerDes bus, the communication management unit suspends response to all commands except the reset command until the current data transmission is complete. This design ensures the exclusivity of the high-speed data link and the integrity of the transmission process, preventing bus contention or abnormal data frame interruptions caused by other commands, and fully guaranteeing the complete transmission of large-volume scientific data such as images.

[0013] As a preferred implementation of instruction masking, the communication management unit sets a mode status flag when controlling the SerDes bus to enter point-to-point mode. After the link layer detects the flag, it automatically buffers or discards subsequent non-reset instructions until the data transmission is completed and the flag is cleared. At the same time, the interrupt priority of the SerDes bus is raised to the highest level in the system to ensure the immediate response of the high-speed link in hardware.

[0014] In master-slave mode, the communication management unit acts as the sole master, polling each payload sequentially at a preset period. Each payload is assigned a unique 1-byte ID number, which can accurately locate the communication object and meet the expansion requirements of deep space exploration missions for the number of payloads.

[0015] To improve the reliability of single communications, the link layer implements a command retransmission mechanism: when the communication management unit issues a command and does not receive a correct response from the payload within a preset timeout period, or if the received response frame has a verification error, the command is automatically retransmitted. If a correct response is still not received after retransmission, the communication error count and error type are recorded and reported, while maintaining subsequent communication capability with the corresponding payload. This mechanism achieves a trade-off between error isolation and recovery under limited onboard resources, avoiding both continuous retransmission consuming the bus and completely blocking the payload due to individual errors.

[0016] The system's long-term reliability is ensured through a dual-machine cold backup design. The communication management unit employs a weighted health assessment model, comprehensively evaluating the communication error rate and bus occupancy rate of the three buses, as well as the processor load rate and instruction parsing error rate of the controller. When the overall health rate falls below a preset health threshold and the duration exceeds a preset duration threshold, an autonomous switchover is triggered. During the autonomous switchover process, the primary controller writes a list of incomplete transactions to non-volatile memory, and the backup controller takes over bus control and resumes execution from the point of interruption, ensuring that critical tasks are not lost or duplicated.

[0017] Regarding the data interaction format, the command frame, response frame, and data frame adopt a unified frame structure, which includes a 2-byte fixed frame header (0xEB90), a 1-byte frame type identifier, a 1-byte address field, a 2-byte data field length, a variable-length data field, and a 2-byte checksum field. The frame type identifier 0x01 indicates a command frame, 0x02 indicates a response frame, and 0x03 indicates a data frame. This unified frame format simplifies the processing logic of the link layer and the command layer and facilitates data integrity assurance through the checksum field.

[0018] The application layer has a built-in task queue management module that employs a priority-based preemptive scheduling algorithm combined with time-slice round-robin scheduling. Priorities are categorized from high to low as interrupt level, scientific task level, and background maintenance level. High-priority tasks can preempt the execution rights of low-priority tasks. Tasks of the same priority are scheduled using time-slice round-robin scheduling, balancing the immediate response of urgent tasks with fairness among tasks of equal priority. When a task times out, it is forcibly terminated and retried according to a preset strategy. This preset strategy includes retrying in a queue of the same priority or retrying in a downgraded queue to prevent a single task from creating an infinite loop and blocking the entire scheduling sequence.

[0019] In terms of physical layer design, the SerDes bus adopts 8b / 10b encoding, uses the K28.5 character for link synchronization, K28.2 / K27.7 characters to identify the start of a data frame, and K29.7 / K30.7 characters to identify the end of a data frame. It utilizes mature industry encoding and decoding standards to reduce bit error rate and implementation complexity. Meanwhile, the 1553B bus employs a dual-redundancy architecture to ensure the survivability of critical control links; the RS422 bus baud rate can be dynamically configured on-orbit via commands to adapt to the varying bandwidth and anti-interference requirements of different mission phases.

[0020] Correspondingly, the present invention also provides a method for managing internal communication of a deep space exploration satellite, comprising the following steps: the communication management unit interacts with the satellite integrated electronic subsystem for platform-level information via a 1553B bus, interacts with the payload for control and status information via an RS422 bus, and transmits high-speed scientific data with the payload via a SerDes bus; a four-layer communication protocol stack is run, wherein the link layer responds to data block transmission instructions received via the 1553B bus and dynamically switches between master-slave mode and point-to-point mode; in master-slave mode, multiple payloads are polled via the RS422 bus, and in point-to-point mode, a direct link is established with a designated payload via the SerDes bus; the command layer organizes mission instructions into command frames and sends them to the payload, parses the response frames returned by the payload, and interacts with the satellite integrated electronic subsystem for information via data frames; while the SerDes bus is transmitting data in point-to-point mode, the communication management unit suspends response to all instructions except for the reset instruction until the current data transmission is completed.

[0021] The aforementioned systems and methods, through heterogeneous bus collaboration, protocol layering, dynamic mode switching, and command masking during transmission, achieve high reliability, high bandwidth, and high manageability in communication while meeting the stringent resource constraints of deep space exploration. Compared to existing technologies, this invention and its preferred solution, through a three-bus heterogeneous fusion architecture, simultaneously meet the dual requirements of high-reliability control and high-speed data transmission for deep space exploration missions; adopting a hierarchical protocol stack design clarifies the functional boundaries of each layer, reduces the difficulty of system development and maintenance, and improves scalability; through a cross-bus instruction-triggered mode dynamic switching mechanism, it achieves an organic combination of centralized management of multiple payloads and high-speed transmission of critical tasks; the instruction shielding mechanism during point-to-point transmission effectively solves the conflict between high-speed data transmission and concurrent instruction processing, ensuring data integrity; through reliability designs such as dual-machine cold backup, instruction retransmission, and hierarchical scheduling, it significantly improves the system's fault tolerance and operational stability, enabling it to adapt to the complex and harsh space environment of deep space exploration. Attached Figure Description

[0022] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments: Figure 1 This is an overall architecture diagram of the internal communication management system of a deep space exploration satellite in an embodiment of the present invention; Figure 2 This is a schematic diagram of the four-layer protocol stack in an embodiment of the present invention; Figure 3 This is a topology diagram showing the combination of link layer master-slave mode and point-to-point mode in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of the command frame, response frame, and data frame in an embodiment of the present invention; Figure 5 This is a flowchart of the communication management method in an embodiment of the present invention. Detailed Implementation

[0023] To make the features and advantages of the present invention more apparent and understandable, specific embodiments are described below in detail: It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0024] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0025] This invention provides an internal communication management system and method for deep space exploration satellites, aiming to solve the technical problems of low communication rate, ambiguous protocol layers, and insufficient real-time performance and reliability in existing technologies. The system hardware adopts a three-bus design architecture of RS422+1553B+SerDes, and the protocol architecture constructs a four-layer structure of physical layer, link layer, command layer, and application layer, realizing efficient and reliable communication management between the satellite platform and the payload.

[0026] In terms of hardware architecture, the payload is connected to the internal communication management system of the deep space exploration satellite via an RS422 bus to achieve command and status interaction; the payload is directly connected to the communication management system via a SerDes bus to complete the transmission of high-speed scientific data; and the communication management system is connected to the satellite's integrated electronic subsystem via a 1553B bus to achieve the interaction of highly reliable control commands and critical status information.

[0027] In terms of protocol design, this scheme constructs a clearly hierarchical four-layer protocol stack. The physical layer is used to establish physical connections between the payload, communication management system, and satellite integrated electronic subsystem, completing the transmission of control, status, and data between the satellite platform and the payload. The link layer, located between the physical layer and the command layer, is used to complete the parallel-to-serial conversion of communication frames at the transmitting end and the serial-to-parallel conversion at the receiving end, and to perform frame delimiting and error control on the bit stream transmitted by the physical layer. Specifically, the transmission links for command and status information between the communication management system and the satellite integrated electronic subsystem, and between the communication management system and the payload, adopt the standard universal asynchronous transceiver protocol, with a baud rate adjustable between 115200bps and 1Mbps; the transmission link for scientific data adopts a high-speed serial transmission protocol with a line rate of 2.0Gbps. The link layer also includes a mode switching controller, which dynamically switches between master-slave mode and point-to-point mode during communication based on conditions such as task type: the master-slave mode adopts a one-master-multiple-slave design architecture, with the communication management system as the master and the scientific payload as the slave, sending command frames to each payload and receiving response frames through polling; the point-to-point mode is used to establish a direct communication link for high-speed scientific data between the communication management system and a specific payload.

[0028] This scheme uses frames as the smallest transmission unit. The frame structure includes a frame header, frame type identifier, data field, checksum field, and frame trailer. According to mission function, frames are divided into command frames, response frames, and data frames: command frames are issued by the communication management system and contain the target payload address, command code, parameter fields, and checksum information; response frames are returned by the payload and contain the source payload address, status code, return parameter fields, and checksum information; data frames are used for information exchange between the communication management system and the satellite integrated electronic subsystem and contain data type identifier, timestamp, data body, and checksum information.

[0029] As the core layer of the protocol, the command layer undertakes the core functions of frame generation and parsing: organizing CPU commands into command frames and sending them to the payload through the link layer to execute scientific tasks; parsing response frames from the payload to determine that the payload has received the correct command packets, thereby improving system reliability; interacting with the satellite integrated electronic subsystem through data frames to extract key information, monitor the payload's operating status, and complete information exchange including guidance, navigation and control information, and yaw angle information, while simultaneously receiving high-speed scientific data from the payload.

[0030] The application layer, located at the top of the protocol stack, contains a task queue management module. This module caches command frames awaiting delivery and dynamically adjusts the scheduling strategy based on priority. By organizing and sending command frames to the lower layers and receiving and parsing response frames, the application layer schedules top-level scientific tasks and monitors the status of the entire system's payload. It also facilitates the interaction and processing of scientific data.

[0031] Based on the above system, this solution also provides a method for managing internal communication of a deep space exploration satellite. The specific process is as follows: The application layer generates mission instructions and sends them to the command layer; the command layer organizes the mission instructions into command frames, performs parallel-to-serial conversion at the link layer, and then sends them to the target payload through the physical layer; after the payload executes the mission, it returns a response frame, which is then converted from serial to parallel by the physical layer and link layer, and parsed by the command layer to extract status information; upon receiving the response frame, the command layer performs verification and frame parsing, and if command execution failure is detected, it decides whether to retransmit according to a preset strategy; the command layer interacts with the satellite's integrated electronic subsystem via data frames to exchange GNC information, yaw angle information, and transmit scientific data; the application layer adjusts the mission scheduling and payload status monitoring strategies based on the parsed status information and interaction information, and processes the payload scientific data. Throughout the communication process, the link layer dynamically switches between master-slave mode and point-to-point mode according to the mission type.

[0032] This solution utilizes a three-bus converged architecture of RS422, 1553B, and SerDes to balance the dual requirements of high-speed data transmission and high-reliability control. The four-layer protocol architecture ensures clear functionality and interfaces for each layer, facilitating system expansion, maintenance, and reuse, and reducing software development complexity. The core design of the instruction layer enables unified management of instruction and data streams, improving the real-time performance of task scheduling and the accuracy of load status monitoring. The combined master-slave and point-to-point communication modes support centralized polling control of multiple loads while ensuring independent and reliable communication of critical links. A standardized frame structure coupled with a verification mechanism ensures the accuracy and traceability of communication.

[0033] The implementation of the present invention will be further illustrated and described below with reference to the accompanying drawings. This section, in conjunction with preferred embodiments, provides supplementary descriptions of the specific implementation logic of the aforementioned functional modules. It should be understood that the configurable parameters, thresholds, and numerical ranges in these embodiments are merely illustrative examples and are not intended to limit the scope of protection of the present invention. Those skilled in the art can make adaptive adjustments based on the actual needs of aerospace missions within the framework disclosed in this invention.

[0034] I. System Hardware Architecture like Figure 1 As shown, this embodiment provides an internal communication management system for a deep space exploration satellite. The communication management system, as the core component, connects the satellite integrated electronic subsystem, the satellite GNC subsystem, the satellite overall circuit subsystem, and multiple payloads. Its hardware architecture adopts a "RS422+1553B+SerDes" three-bus design.

[0035] RS422 Bus Link: The RS422 bus uses differential signal transmission, offering strong anti-interference capabilities. The baud rate can be dynamically configured on-orbit via commands. This bus is used to establish a low-speed control and status information connection between the communication management system and the payload, transmitting payload configuration parameters, non-real-time control commands, control commands, guidance and navigation control (GNC) information, yaw angle (the angle between the satellite's optical axis and the orbital plane normal), and satellite platform status information.

[0036] SerDes bus link: At the transmitting end, the SerDes bus converts the low-speed parallel data inside the chip bit by bit into a high-speed serial data stream on differential lines using a high-speed clock. At the receiving end, it recovers the clock from the high-speed serial stream and restores the data to parallel format, thus realizing the conversion of parallel data into a high-speed serial code stream for transmission. This bus is used for the transmission of scientific business data such as high-definition imaging and spectral detection.

[0037] 1553B Bus Link: The deep space exploration satellite's internal communication management system is connected to the satellite's integrated electronic subsystem via the 1553B bus, employing a dual-redundant bus architecture (Bus A and Bus B) with a communication rate standard of 1 Mbps. This bus is used to establish the connection between the communication management system and the satellite platform, primarily for issuing core commands at the satellite platform level, summarizing status across subsystems, and exchanging information between key platforms.

[0038] The deep space exploration satellite's internal communication management system adopts a dual-machine cold backup design. This system combines the real-time link status of three buses, bus occupancy, and controller health status for comprehensive joint judgment, and adopts a dual mode of manual intervention and autonomous switching: when the primary controller experiences communication abnormalities, bus driver failures, or command parsing failures, it feeds back status information to the ground via the bus and waits for ground commands for manual intervention; after the abnormal response time is exceeded, customized switching logic is triggered to autonomously complete the transfer of bus usage rights, temporary storage of unfinished transactions, and smooth transition of communication links, avoiding data corruption and command loss during switching in multi-bus parallel scenarios.

[0039] As a preferred implementation of this solution, the above comprehensive joint judgment can adopt a weighted health assessment model, specifically implemented as follows: 1. Health parameter collection The system collects multiple parameters in real time, including the link status of the three buses (such as communication error rate), bus occupancy rate, and controller health (including at least processor load rate, instruction parsing error rate, etc.), and normalizes each parameter.

[0040] 2. Overall Health Score Calculation Each parameter is assigned a configurable weight, and the overall health score is obtained through weighted summation. The initial values ​​of the weights can be set via ground injection and optimized based on on-orbit testing. For example, in a preferred embodiment, the overall health score H can be defined as: H = 1-Σ(W i ×E i ) Among them, W i E is the normalized weight of the i-th parameter. i This is the normalized current value of the parameter. The weight configuration assigns higher weights to parameters that have a greater impact on bus communication quality and core controller functions.

[0041] 3. Autonomous switching determination Configureable health thresholds (e.g., a value within the range of 0.70 to 0.85) and duration thresholds (e.g., a value within the range of 30 to 60 seconds). When H is below the health threshold and the duration exceeds the preset duration threshold, an autonomous handover process is triggered; when H is between the health threshold and the warning threshold, the system only sends a warning message to the ground without triggering a handover.

[0042] 4. Switching Process Upon triggering an autonomous switchover, the primary controller immediately ceases issuing new commands, writes a list of incomplete transactions (which can be stored in an internal command queue maintained by the primary controller, the capacity of which can be determined based on a maximum of 32 pending commands) to non-volatile memory, and sends the switchover command and the transaction list to the backup controller via hardwired or bus. After power-on initialization, the backup controller takes over all bus control, reads the incomplete transactions from the non-volatile memory, and resumes execution from the point of interruption, completing a smooth transition of the communication link.

[0043] II. Implementation of the Four-Layer Protocol Stack like Figure 2 As shown, the system communication protocol consists of four parts: physical layer, link layer, command layer, and application layer. Data exchange between these layers occurs through standard interfaces. Addressing the inconsistencies in transmission rates, timing mechanisms, and protocol specifications among RS422, 1553B, and SerDes buses, this system, based on a layered design, plans its overall task design according to the type of information to be exchanged. By adding cross-layer collaborative constraints, it overcomes problems such as timing conflicts, inconsistent formats, and resource preemption caused by parallel operation of heterogeneous buses.

[0044] 1. Physical layer The physical layer is primarily responsible for establishing physical connections between the payload, the deep space exploration satellite's internal communication management system, and the satellite's integrated electronic subsystem, completing the transmission of differential signals. Based on the overall space mission plan, this layer adopts a hardware topology design to provide physical link support for communication protocols. In this embodiment, the RS422 physical layer uses AM26LV31 drivers and AM26LV32 receivers, supporting 3.3V power supply, with low power consumption, suitable for spaceborne applications. The SerDes bus uses the TLK2711 high-speed serial transceiver, implementing 8b / 10b encoding internally to complete the transmission of scientific data. The 1553B physical layer uses a standard 1553B transceiver, conforming to the MIL-STD-1553B specification, and features transformer isolation and dual redundant channel switching capabilities.

[0045] As the preferred implementation of this solution, the 8b / 10b encoding implemented internally by the TLK2711 chip conforms to the IEEE 802.3 standard. The system utilizes this encoding characteristic to complete link synchronization and frame delimitation. The control characters K28.5, K28.2 / K27.7, K29.7 / K30.7, etc., described in the above data stream transmission process are comma characters and control characters in the 8b / 10b encoding. The chip automatically maintains operational inconsistencies to ensure DC balance and provides encoding error indications through status outputs for the FPGA to handle link errors.

[0046] 2. Link Layer The link layer is located between the physical layer and the command layer. It mainly completes the parallel-to-serial conversion of communication frames at the sending end and the serial-to-parallel conversion at the receiving end, and also completes frame delimitation, verification and retransmission mechanisms.

[0047] In this embodiment, the transmission links between the deep space exploration satellite's internal communication management system and the satellite's integrated electronic subsystem, as well as between the deep space exploration satellite's internal communication management system and the payload, all adopt the standard universal asynchronous transmission protocol. Specific parameter configurations are as follows: a) RS422 link: 8 data bits, 1 stop bit, odd parity, baud rate is configured according to the load type; b) SerDes link: A single link can achieve 2Gbps serial code stream transmission, and the data rate can be dynamically adjusted by the duty cycle of K code and D code. c) 1553B link: follows the 1553B protocol specification and includes information such as synchronization header, data bits and parity bits.

[0048] The 1553B link is a normally active link with the highest priority. It receives commands from the satellite platform in the form of CCSDS source packets, communicating in the data format of remote control packets. The CCSDS source packets in this system are variable-length, with a maximum length of 256 bytes. Each data segment of the remote control source packet consists of a packet identifier, packet sequence control, command data field, and a data field for switch commands, defined as follows: 1) Package markings Version number: 3 bits, "000" indicates the CCSDS version (information packet); Type: 1 bit set to "1" indicates a remote control package; Secondary header flag: 1 bit is set to "0"; Application process identifier: 11 bits are used to identify different application processes, and the specific rules are the same as those for telemetry source packets.

[0049] 2) Packet sequence control Segmentation flag: 2 bits, 00 for continuation, 01 for first packet, 10 for last packet, 11 for independent packet; Packet sequence count: 14 bits modulo 2 14 It adds value independently to each application process.

[0050] Packet length: 16 bits, records the length of the remote control user data field (in bytes) excluding the master head, C = number of bytes - 1.

[0051] 3) Instruction Data Field Data type: Uplink data for payload and controller.

[0052] Length field: The actual length of the injected valid data (in bytes), C = number of bytes - 1.

[0053] Valid data: Valid data that is actually injected into the system.

[0054] 4) Data field of switch commands Immediate command: immediately parsed and executed by the controller (without timecode, processed immediately); Delay instruction: An instruction executed periodically by the controller system software; Macro instruction sequence: A sequence of instructions executed by the controller system software; On the other hand, the status of each byte point is fed back to the satellite platform. The data packet is a variable-length data packet, consisting of a synchronization identifier, data type, length field, time code / processing identifier, packet sequence number, data field, and checksum. The definitions of each part are as follows: 1) Synchronization flag: 2 bytes; 2) Data type: 1 byte. Different payload data types are assigned different data type identifiers, such as 0x01 for payload I and 0x02 for camera II. The assignable range is 0~255. 3) Length field: 2 bytes, which is the number of bytes in the time code, packet sequence number, and data field minus 1; 4) Timecode / Processing Identifier: The high 4 bytes represent the seconds count, and the low 2 bytes represent the millisecond count within those seconds. If the payload does not require a timecode, it can define custom processing identifiers and other information.

[0055] 5) Packet serial number: Start from 0000 and increment sequentially by 1 up to FFFF, then start from 0000 again; 6) Data domain: payload scientific data, engineering telemetry data; 7) Checksum: Accumulate checksums.

[0056] The RS422 link is a configurable link that can be independently turned on or off for the corresponding payload according to the space mission plan, and establish real-time information exchange between the platform and the scientific payload. The SerDes link is the second-level link with the lowest priority. The management system is the receiver and the payload is the transmitter. When the payload resolves the instruction information from the RS422 bus and it is valid, the transmission of scientific data is initiated. The data stream transmission process is as follows.

[0057] 1) After the system completes the power-on or hardware reset, it automatically sends the synchronization code D5.6 / K28.5 to achieve autonomous synchronization of link data.

[0058] 2) Configure the control signals tklsb and tkmsb to a high level, and then send the transmission frame start code K28.2 / K27.7 as the data frame transmission start flag.

[0059] 3) Pull the control signals tklsb and tkmsb low to the same level to enter the effective data transmission stage; the first two bytes of the effective data segment are defined as the data type identifier field, with the high byte first, to distinguish different payload data types.

[0060] 4) After all valid data has been serially transmitted, the control signals tklsb and tkmsb are set to high level again, and the frame end identifier code K29.7 / K30.7 is sent to indicate the end of single frame data transmission and complete the transmission process of a complete frame of data.

[0061] 5) The receiver uses the TLK2711 chip. Driven by the recovery clock rxclk, the chip automatically executes the comma character detection mechanism to achieve accurate matching of the received data boundary and synchronously recover the parallel data signal and control signal.

[0062] 6) The receiving end detects the control signals rklsb and rkmsb and their corresponding data content in real time. When rklsb and rkmsb are both high and the data is matched with 0x5CFB, the receiving end determines that the current received content is the start information of the transmission frame and identifies the formal start of the transmission frame.

[0063] 7) When the control signals rklsb and rkmsb are both detected to be low, the first byte of the current valid data is extracted as the data type. Based on this data type, the FPGA buffers the subsequent valid data into the corresponding configured FIFO buffer unit. At the same time, the received valid data is summed and the result is compared with the last 16-bit check field of the valid data. If the sum matches the last 16-bit check field, the data transmission is considered to be error-free. If the comparison result does not match, the data transmission process is considered to be abnormal.

[0064] As a preferred implementation of this solution, the configuration of the above FIFO buffer units can be flexibly set according to the data reception rate and system processing capabilities. In this embodiment, since the SerDes line rate is 2.0Gbps and the TLK2711 parallel interface width is selectable, the FPGA internally configures an independent FIFO for each payload data reception channel, with its width matching the width of the parallel interface (e.g., 16-bit or 32-bit), and its depth at least sufficient to buffer the maximum length of one frame of data. Based on the maximum data field length of 65535 bytes in the frame structure, and considering the pipeline characteristics of system data processing and burst transmission requirements, the designed FIFO depth can be a safe value, such as 4096×32 bits (i.e., 16KB). This capacity is sufficient to accommodate most data packets in practical application scenarios while also taking into account FPGA resource utilization.

[0065] The FIFO's read / write clocks are synchronized with the TLK2711 receive clock and the FPGA system clock, respectively, and near-full / near-empty thresholds are set to implement flow control signals to the load (such as pause / resume transmission). These thresholds can also be configured via registers and fine-tuned according to different data transmission modes. The FIFO is cleared when the system is reset or the link loses synchronization.

[0066] 8) When the control signals rklsb and rkmsb are both high and the matching data is 0xFDFE, it is determined that the current received content is the end-of-frame identifier information of the transmission frame, and the reception of a single transmission frame is identified as finished.

[0067] 9) During the transmission of the entire frame, if either rklsb or rkmsb is detected to be in a high-level state, it is determined that the current transmission link is malfunctioning and the link data is out of sync. The corresponding received data is marked as invalid 0x00 and is marked as a data transmission error. The system enters a waiting state until the next synchronization code is sent and the link synchronization and communication connection are re-established.

[0068] 3. Link Layer Communication Mode like Figure 3 As shown, communication between the link layers adopts a combination of master-slave mode and point-to-point mode.

[0069] Master-Slave Mode: The deep space exploration satellite's internal communication management system (unique) is designated as the master, while scientific payloads (not unique) are designated as slaves. Each slave has a unique ID number, which is 1 byte long. Therefore, theoretically, a maximum of 256 slaves are supported, but considering factors such as link latency and response time, this value is generally less than 16. The deep space exploration satellite's internal communication management system polls every 100ms, sending command frames to each payload sequentially and waiting for response frames. This mode is used for issuing routine scientific mission commands and querying status. Typical applications include payload self-testing upon startup, parameter configuration, and routine status monitoring.

[0070] Point-to-point mode: When high-priority tasks (such as target acquisition, emergency response) or large amounts of scientific data need to be performed, the system switches to point-to-point mode based on the parsed bus commands. In this mode, the deep space exploration satellite's internal communication management system establishes a direct communication link with the designated payload, using a SerDes link, with interrupt priority raised to the highest level to ensure the real-time performance of critical tasks. Furthermore, in point-to-point mode, the system does not respond to any operations other than reset during data transmission to ensure data packet integrity.

[0071] As a preferred implementation, when the communication management unit controls the SerDes bus to enter point-to-point mode, it sets a mode status flag. After the link layer detects the flag, it automatically buffers or discards subsequent non-reset commands until the current data transmission is completed and the flag is cleared, and then resumes normal response. At the same time, the interrupt priority of the SerDes bus is raised to the highest level in the system to ensure the immediate response of the high-speed link through hardware means.

[0072] The link layer design includes a command retransmission mechanism: If the master does not receive a response from the slave within 15ms of sending a command, or if the slave reports a command reception error (by sending a response message to the master), the master will automatically resend the command once. If a communication error still occurs at this point, the current communication will be stopped. The master considers the current communication with the slave to have failed and organizes the error status (each serial port's error status has two parameters: a communication error count and an error type, which is the type of the last error) into the engineering parameters. The master will not block slaves experiencing communication failures; when communication is needed again, the master will continue to send commands to that slave.

[0073] 4. Frame Structure Design like Figure 4 As shown, this system defines three types of communication frames: command frames, response frames, and data frames. All frames use a unified header and trailer format; only the data field content differs depending on the frame type. a) Frame header: 2 bytes, fixed value 0xEB90, used for frame synchronization; b) Frame type identifier: 1 byte, 0x01 command frame, 0x02 response frame, 0x03 data frame; c) Address field: 1 byte, destination address or source address, 0x00 is the broadcast address; d) Data field length: 2 bytes, number of bytes in the data field, range 0~65535; e) Data field: variable, containing specific data content; f) Checksum field: 2 bytes, using an accumulation checksum method, covering the address field to the data field.

[0074] Command frame: The data field contains the instruction code (1 byte), the number of parameters (1 byte), and the parameter field.

[0075] Response frame: The data field contains a status code (1 byte), the number of return parameters (1 byte), and the return parameter field. Status code 0x00 indicates normal operation, 0x01 indicates the instruction was not recognized, and 0x02 indicates execution failure, etc.

[0076] Data frame: The data field contains information such as data type identifier (2 bytes), data body, and check bits.

[0077] 5. Instruction Layer The command layer is the core component, responsible for coordinating cross-bus commands and managing global status through frame generation and parsing. In this embodiment, the command layer runs within the real-time operating system of the deep space exploration satellite's internal communication management system as an independent, medium-priority task.

[0078] The instruction layer has three core functions: (1) Command frame generation and delivery: Receive task instructions from the application layer, organize CPU commands into standard command frames, and send them to the payload via the link layer. The instruction layer maintains a command queue, supporting up to 32 commands to be delivered, and supports priority scheduling to avoid multiple instructions blocking different buses in an instant.

[0079] (2) Response frame parsing: Parse the response frames from the payload and perform sorting, matching, tracing and other processing to confirm whether the receiver has correctly received the instruction; (3) Platform Information Interaction and Status Monitoring: Extract key information and update the payload status table. The payload status table contains key parameters such as the current operating mode, health status, temperature, and voltage of each payload, which can be queried by the application layer. At the same time, information such as GNC and yaw angle are exchanged with the satellite integrated electronic subsystem through data frames. The command layer sends the payload status summary information to the integrated electronic subsystem and receives GNC information for mission planning.

[0080] 6. Application Layer The application layer is located at the top of the protocol stack. It organizes and sends command frames to the lower layer, and receives and parses response frames to complete top-level task planning, queue management, and system-wide fault monitoring and handling.

[0081] In this embodiment, the application layer includes the following modules: Mission planning module: Generates mission sequences based on the ground-injected exploration plan. For example, a typical exploration mission includes: platform attitude adjustment, drift angle compensation, camera exposure, synchronous acquisition by the spectrometer, and data downlink.

[0082] Task queue management module: Employs a priority queue, supporting interrupt-level tasks (highest priority), scientific tasks (medium priority), and background maintenance tasks (low priority). The task queue management module caches command frames to be issued and dynamically adjusts the scheduling strategy based on priority.

[0083] As a preferred implementation of this solution, the above priority-based dynamic adjustment scheduling strategy can adopt a priority-based preemptive scheduling combined with a time-slice round-robin mechanism, as follows: 1. Scheduling Framework The system maintains a task queue for each priority level, with configurable queue depth. The default depth of each priority queue is 32, and can be adjusted in orbit via ground commands. When a new task arrives, if the queue is full, a discard or replacement strategy is determined based on priority (e.g., a high-priority task can replace the earliest entry in a low-priority task queue).

[0084] 2. Seizing the Time Slice The scheduler always selects the highest-priority task from the non-empty queue for execution. Higher-priority tasks can preempt lower-priority tasks; tasks of the same priority are scheduled using a round-robin format with time slices. The length of the time slice is configured based on the task level and system real-time requirements, for example: The time slice for interrupt-level tasks can be set to a value comparable to the system polling cycle, such as 10-20ms. The time slice for scientific tasks can be set to 50–100 ms; The time slice for background maintenance tasks can be set to 200–500 ms.

[0085] These time slice values ​​can be modified via ground injection to adapt to different exploration mission profiles.

[0086] 3. Timeout control and retry Each task has a preset maximum execution time (configurable based on task type, e.g., 100ms for interrupt tasks, 500ms for scientific tasks, and 2000ms for background tasks, also configurable). If a task is not completed within this time, it is forcibly terminated and marked as timed out. The system can retry according to a preset strategy, with a maximum of 3 retries. Retrieved tasks can be re-queued in the same priority queue or downgraded for queuing; the specific strategy is configured by the ground team.

[0087] Status monitoring module: Receives load status information parsed from the command layer in real time and performs threshold judgments. When an abnormal load is detected (such as excessive temperature or communication timeout), it automatically triggers a fault handling process, including command retry, load reset, or switching to a backup load.

[0088] III. Communication Management Methods and Procedures like Figure 5 As shown, the deep space exploration satellite internal communication management method of this embodiment includes the following steps: Step S1: Task Generation and Distribution The application layer task planning module generates task instructions based on the exploration plan and writes these instructions into the task queue. The task queue management module retrieves instructions from the queue according to priority and issues them by calling the instruction layer interface.

[0089] Step S2: Command frame encapsulation and transmission The command layer receives commands from the application layer, encapsulates them into standard command frames, and adds a frame header, frame type identifier, address field, checksum, and frame trailer. The command layer sends the command frame to the link layer's transmission queue, where it performs parallel-to-serial conversion and then transmits it to the target payload through the physical layer.

[0090] Step S3: Payload Execution and Response Return The payload receives command frames, parses them, and executes the corresponding operations. After execution, the payload generates a response frame, which is then transmitted back to the deep space exploration satellite's internal communication management system via its link layer and physical layer.

[0091] Step S4: Response parsing and status update The command layer receives the response frame, performs checksum and frame parsing, extracts status information, and updates the payload status table. If command execution failure is detected, the command layer decides whether to retransmit according to a preset strategy (maximum 3 retries).

[0092] Step S5: Platform Information Interaction The command layer interacts with the satellite integrated electronic subsystem via data frames to exchange GNC information and yaw angle information.

[0093] Step S6: Task scheduling adjustment The application layer dynamically adjusts the task scheduling strategy based on the parsed load status information and the platform information exchanged. For example, when the eccentricity angle exceeds the preset range, the task planning module automatically inserts an eccentricity angle compensation command; when the load temperature rises, the task frequency is reduced to protect the load.

[0094] The implementation of the aforementioned three-bus architecture, four-layer protocol stack, dynamic scheduling, intelligent switching, and other functions can be achieved based on optimized details such as weighted health assessment model, preemptive priority queue scheduling, standardized 8b / 10b encoding configuration, and configurable FIFO buffer.

[0095] It should be noted that, unless otherwise defined, the technical or scientific terms used in this invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0096] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

[0097] This invention is not limited to the preferred embodiment described above. Anyone inspired by this invention can derive other forms of deep space exploration satellite internal communication management systems. All equivalent variations and modifications made within the scope of the claims of this invention shall fall within the scope of this invention.

Claims

1. An internal communication management system for a deep space exploration satellite, comprising a communication management unit, a satellite integrated electronic subsystem, and multiple payloads, characterized in that: The communication management unit is connected to the satellite integrated electronic subsystem via a 1553B bus, and to each payload via an RS422 bus and a SerDes bus, respectively. The communication management unit operates a communication protocol stack from bottom to top, comprising the physical layer, link layer, command layer, and application layer. The link layer responds to the data block transmission command received via the 1553B bus and dynamically switches between master-slave mode and point-to-point mode. In master-slave mode, multiple payloads are polled via RS422 bus. In point-to-point mode, a direct link is established with a specified payload via SerDes bus to transmit high-speed scientific data. The instruction layer is used to organize mission instructions into command frames and send them to the payload, parse the response frames returned by the payload, and interact with the satellite integrated electronic subsystem through data frames; During point-to-point data transmission on the SerDes bus, the communication management unit suspends responding to all commands except the reset command until the current data transmission is complete.

2. The internal communication management system for deep space exploration satellite according to claim 1, wherein: The communication management unit suspends response to other instructions by setting a mode status flag when controlling the SerDes bus to enter point-to-point mode. After the link layer detects the flag, it automatically buffers or discards subsequent non-reset instructions until the data transmission ends and the flag is cleared. At the same time, the interrupt priority of the SerDes bus in point-to-point mode is raised to the highest level in the system.

3. The internal communication management system for deep space exploration satellite according to claim 1, wherein: In the master-slave mode, the communication management unit acts as the sole host and polls each payload sequentially at a preset period; each payload is assigned a unique 1-byte ID number.

4. The deep space exploration satellite internal communication management system according to claim 1, characterized in that: The link layer is configured with a command retransmission mechanism: when the communication management unit issues a command, if it does not receive a correct response from the payload within a preset timeout period, or if the received response frame has a verification error, it will automatically retransmit the command once; if it still does not receive a correct response after retransmission, it will record the communication error count and error type and report it, and maintain the subsequent communication capability with the corresponding payload.

5. The deep space exploration satellite internal communication management system according to claim 1, characterized in that: The communication management unit adopts a dual-machine cold backup design and uses a weighted health assessment model to comprehensively determine the communication error rate and bus occupancy rate of the three buses, as well as the processor load rate and instruction parsing error rate of the controller. When the overall health level is lower than the preset health level threshold and the duration exceeds the preset duration threshold, an autonomous switchover is triggered. During the autonomous switchover, the main controller writes the list of incomplete transactions into the non-volatile memory, and the backup controller takes over the bus control and continues execution from the interrupt point.

6. The deep space exploration satellite internal communication management system according to claim 1, characterized in that: The command frame, response frame, and data frame adopt a unified frame structure, which includes a 2-byte fixed frame header 0xEB90, a 1-byte frame type identifier, a 1-byte address field, a 2-byte data field length, a variable-length data field, and a 2-byte checksum field. Among them, the frame type identifier 0x01 represents a command frame, 0x02 represents a response frame, and 0x03 represents a data frame.

7. The deep space exploration satellite internal communication management system according to claim 1, characterized in that: The application layer has a built-in task queue management module, which adopts a priority-based preemptive scheduling algorithm combined with time-slice round-robin scheduling. Priorities are divided into interrupt level, scientific task level and background maintenance level from high to low. High-priority tasks can preempt the execution rights of low-priority tasks, and time-slice round-robin scheduling is used between tasks of the same priority. When a task execution times out, it is forcibly terminated and retried according to a preset strategy. The preset strategy includes retrying in the same priority queue or retrying in a downgraded queue.

8. The deep space exploration satellite internal communication management system according to claim 1, characterized in that: The SerDes bus uses 8b / 10b encoding, uses the K28.5 character for link synchronization, uses the K28.2 / K27.7 characters to identify the start of a data frame, and uses the K29.7 / K30.7 characters to identify the end of a data frame.

9. The deep space exploration satellite internal communication management system according to claim 1, characterized in that: The 1553B bus adopts a dual-redundancy architecture; the baud rate of the RS422 bus can be dynamically configured on-orbit via commands.

10. A method for managing internal communication of a deep space exploration satellite, based on the system as described in claim 1, characterized in that, Includes the following steps: The communication management unit interacts with the satellite integrated electronic subsystem for platform-level information via the 1553B bus, interacts with the payload for control and status information via the RS422 bus, and transmits high-speed scientific data to the payload via the SerDes bus. The communication protocol stack is run, wherein the link layer responds to the data block transmission command received through the 1553B bus and dynamically switches between master-slave mode and point-to-point mode; in master-slave mode, multiple payloads are polled through RS422 bus, and in point-to-point mode, a direct link is established with a specified payload through SerDes bus. The command layer organizes mission instructions into command frames and sends them to the payload, parses the response frames returned by the payload, and interacts with the satellite integrated electronic subsystem through data frames; During point-to-point data transmission on the SerDes bus, the communication management unit suspends responding to all commands except the reset command until the current data transmission is complete.

Images