Satellite operating system and satellite terminal for satellite interconnection based on unified communication protocol

Abstract

This invention provides a satellite operating system and satellite terminal for satellite interconnection based on a unified communication protocol. The kernel layer of the satellite operating system is integrated with the communication protocol stack interpretation component, constructing a service framework consisting of a satellite-to-ground communication engine, an intra-satellite communication engine, and an inter-satellite communication engine. The satellite-to-ground remote control communication engine calls the communication protocol stack interpretation component to construct remote control structured data corresponding to remote control data according to the communication protocol. The satellite-to-ground telemetry communication engine calls the communication protocol stack interpretation component to construct telemetry data byte streams corresponding to telemetry packet data according to the communication protocol. The intra-satellite communication engine calls the communication protocol stack interpretation component to convert between intra-satellite structured data and intra-satellite data byte streams according to the communication protocol. The inter-satellite communication engine calls the communication protocol stack interpretation component to convert between inter-satellite structured data and inter-satellite data byte streams according to the communication protocol. This invention unifies the satellite-to-ground, intra-satellite, and inter-satellite communication interconnection architecture and service framework.

Description

Technical Field

[0001] This invention relates to the field of satellite communication technology, and in particular to a satellite operating system and satellite terminal for realizing satellite interconnection based on a unified communication protocol. Background Technology

[0002] In the aerospace satellite field, onboard computers and satellite operating systems, as crucial components of satellite hardware and software, provide a reliable and efficient operating environment for satellite mission application systems. With the rapid development of aerospace technology and satellite technology, the computing power of onboard computers continues to improve, and the functional requirements of satellite operating systems are becoming increasingly complex. Current mainstream onboard operating systems, such as VxWorks and Linux, while specifically optimized for real-time performance and reliability, are essentially still general-purpose computing kernel architectures, primarily providing basic core functions such as task scheduling, memory management, and device drivers. These systems were not designed with the specific needs of satellite constellation collaboration in mind, particularly lacking native support for unified communication between satellites and ground stations, within satellites, and between satellites.

[0003] In the current aerospace satellite field, the onboard operating systems deployed on the onboard computers are all computing kernels, providing kernel capabilities such as task scheduling, memory management, file systems, interrupts, and device drivers. Some onboard operating systems also provide basic tool service capabilities for satellite operations by integrating some open-source component libraries. Based on these kernel capabilities and basic tool service capabilities, satellite operations develop business functions such as satellite data communication, flight control, and onboard data processing. In particular, the data communication functions between satellite and ground, within satellite, and between satellites are all developed by the upper-level satellite operations applications.

[0004] In terms of satellite data communication, due to the differences in hardware equipment, the data communication interface protocols between satellite and the ground (satellite-to-ground), satellite internal equipment (satellite-internal), and between satellites (inter-satellite) are inconsistent. Satellite applications need to be adapted, developed, and debugged for all satellite-to-ground, intra-satellite, and inter-satellite data communication interface protocols, which makes the development cost of satellite applications very high. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a satellite operating system and satellite terminal based on a unified communication protocol to achieve satellite interconnection, unify the satellite-to-ground, intra-satellite, and inter-satellite communication interconnection architecture and service framework, and provide basic platform support for reducing satellite development cycle and building an efficient and reliable large-scale satellite network.

[0006] In the first aspect, the present invention provides a satellite operating system for satellite interconnection based on a unified communication protocol. The satellite operating system is mounted on the satellite end. The kernel layer of the satellite operating system is integrated with the communication protocol stack interpretation component library, and a satellite interconnection service framework consisting of a satellite-to-ground communication engine, an intra-satellite communication engine and an inter-satellite communication engine is constructed.

[0007] The satellite-to-ground communication engine includes a satellite-to-ground remote control communication engine and a satellite-to-ground telemetry communication engine. The satellite-to-ground remote control communication engine is used to: call the remote control communication protocol stack interpretation component integrated in the kernel layer to construct the remote control structured data corresponding to the remote control data according to a unified remote control communication protocol. The satellite-to-ground telemetry communication engine is used to: call the telemetry communication protocol stack interpretation component integrated in the kernel layer to construct the telemetry data byte stream corresponding to the telemetry packet data according to a unified telemetry communication protocol.

[0008] The intra-satellite communication engine is used to: call the intra-satellite communication protocol stack interpretation component integrated in the kernel layer, and convert between intra-satellite structured data and intra-satellite data byte streams according to a unified intra-satellite communication protocol;

[0009] The inter-satellite communication engine is used to: call the kernel-integrated inter-satellite communication protocol stack interpretation component to convert between inter-satellite structured data and inter-satellite data byte streams according to a unified inter-satellite communication protocol.

[0010] In one implementation, the remote control communication protocol includes: a physical channel layer, a satellite-to-ground transmission layer, and a packaging layer;

[0011] The physical channel layer includes the acquisition sequence and remote control information transmission unit;

[0012] The satellite-to-ground transmission layer includes a remote control start flag, a remote control transmission frame, and a remote control end flag. The remote control start flag indicates the start of remote control data transmission. The remote control transmission frame includes a first master header, a remote control frame data field, and a remote control data verification field. The remote control frame data field includes a remote control password area and an encrypted input instruction remote control packet. The remote control end flag indicates the end of remote control data transmission.

[0013] The packaging layer includes the second master head of the remote control package for issuing instruction numbers and remote control application data.

[0014] In one implementation, the satellite-end telemetry and control unit is used to: receive remote control data sent by the ground system, parse the capture sequence in the remote control data, and send the remote control information transmission unit to the satellite-to-ground remote control communication engine if the field values ​​of the capture sequence are correct.

[0015] The satellite-to-ground remote control communication engine calls the remote control communication protocol stack interpretation component. Specifically, the remote control communication protocol stack interpretation component is used for:

[0016] The remote control start flag in the remote control information transmission unit is parsed to determine whether the remote control information transmission unit includes a remote control transmission frame;

[0017] If the judgment result is yes, the remote control frame data field, remote control data verification field and remote control end flag are read into the kernel layer based on the first master header, so as to perform legality verification on the remote control frame data field based on the remote control data verification field and the remote control end flag.

[0018] If the validity is verified, the remote control password area is read from the remote control frame data field to obtain the decryption information. The decryption information is then used to decrypt the encrypted betting instruction remote control packet to obtain the plaintext betting instruction remote control packet.

[0019] Using the second master header of the plaintext instruction remote control packet, the remote control application data of the plaintext instruction remote control packet is parsed to obtain the remote control parsing result, which includes the remote control instruction code, the remote control time code, the remote control instruction data, and the remote control instruction data length.

[0020] The remote control parsing results are filled into a predefined remote control structure to obtain structured remote control data.

[0021] In one implementation, the telemetry communication protocol includes: a channel access data unit, a multiplexing protocol data unit, and a packaging protocol data unit;

[0022] The channel access data unit includes a synchronization byte and a virtual channel data unit;

[0023] The virtual channel data unit carries telemetry packet data, which includes a third-party header, a data field, and a telemetry data verification field.

[0024] The multiplexing protocol data unit is used to describe the third-lead header and data field in the telemetry packet data. The data field includes a header pointer and an M-PDU data field. The header pointer is the position of the first byte in the header of the first complete telemetry packet data in the M-PDU data field. The M-PDU data field carries the telemetry packet data.

[0025] The Packaging Protocol Data Unit is used to describe the telemetry packet data carried in the M-PDU data field. The telemetry packet data includes the source packet header, source packet data, and packet checksum.

[0026] In one implementation, the telemetry communication protocol stack interpretation component is specifically used for:

[0027] According to the telemetry communication protocol, the telemetry packet data sent by the upper-level satellite service system inside the satellite is filled into a predefined telemetry packet structure. During the filling process, multiple telemetry packet data are sequentially filled into multiple M-PDU data fields within the telemetry packet structure. Among them, the telemetry packet data at the beginning and end of the M-PDU data field are complete telemetry packet data or incomplete telemetry packet data.

[0028] The telemetry packet structure and the telemetry frame data structure are assembled into a telemetry data byte stream; the telemetry frame data structure includes a spacecraft identifier, a virtual channel identifier, a number of telemetry data packets, and an array of telemetry data packets.

[0029] In one implementation, the intra-satellite communication protocol includes: a CAN interface communication protocol and a service data communication protocol;

[0030] The CAN interface communication protocol is used to define the CAN interface configuration and communication information frame format. The communication information frame format includes an arbitration field, a control field, a data field, a CRC, and a frame end.

[0031] The business data communication protocol is used to define the business data communication protocol format. The business data communication protocol format includes data type, length, data field and checksum. The data type is: remote control command, command response, telemetry request / response. The length is: the length of the data field. The data field is: valid data. The checksum is: checksum.

[0032] In one implementation, the inter-satellite communication protocol includes: an inter-satellite transport layer and an application data layer;

[0033] The inter-satellite transport layer includes an inter-satellite start flag, an inter-satellite transport frame, and an inter-satellite end flag. The inter-satellite start flag indicates the start of inter-satellite data byte stream transmission; the inter-satellite transport frame includes a fourth master header, an inter-satellite frame data field, and an inter-satellite data check field. The inter-satellite frame data field includes an inter-satellite cryptographic area and encrypted inter-satellite application data packets; the inter-satellite end flag indicates the end of inter-satellite data byte stream transmission.

[0034] The application data layer includes the fifth master header of the inter-satellite application data packet and the inter-satellite application data.

[0035] In one implementation, the inter-satellite communication protocol stack interpretation component is specifically used for:

[0036] The inter-satellite start flag in the inter-satellite data byte stream sent by other satellites is parsed to determine whether the inter-satellite transport layer includes an inter-satellite transport frame;

[0037] If the judgment result is yes, the inter-satellite frame data field, inter-satellite data verification field, and inter-satellite end flag are read into the kernel layer based on the fourth leading header, so as to perform legality verification on the inter-satellite frame data field based on the inter-satellite data verification field and the inter-satellite end flag.

[0038] If the legitimacy is verified, the inter-satellite cryptographic area is read from the inter-satellite frame data field to obtain the decryption information. The decryption information is then used to decrypt the encrypted inter-satellite application data packet to obtain the plaintext inter-satellite application data packet.

[0039] The inter-satellite application data in the plaintext inter-satellite application data packet is parsed using the fifth leading header to obtain the inter-satellite parsing result;

[0040] The inter-satellite resolution results are filled into a predefined inter-satellite structure to obtain inter-satellite structured data.

[0041] In one implementation, the satellite operating system is configured with global control parameters between the satellite and the ground, global control parameters within the satellite, and global control parameters between the satellite and the ground communication engine, the intra-satellite communication engine, and the inter-satellite communication engine, for controlling their activation and deactivation.

[0042] Secondly, the present invention also provides a satellite terminal, including any of the satellite operating systems provided in the first aspect that enable satellite interconnection based on a unified communication protocol.

[0043] This invention provides a satellite operating system and satellite terminal for satellite interconnection based on a unified communication protocol. The kernel layer of the satellite operating system is integrated with a communication protocol stack interpretation component library, and a satellite interconnection service framework consisting of a satellite-to-ground communication engine, an intra-satellite communication engine, and an inter-satellite communication engine is constructed. The satellite-to-ground communication engine includes a satellite-to-ground remote control communication engine and a satellite-to-ground telemetry communication engine. Specifically, the satellite-to-ground remote control communication engine is used to: call the remote control communication protocol stack interpretation component integrated in the kernel layer to construct remote control structured data corresponding to remote control data according to a unified remote control communication protocol; the satellite-to-ground telemetry communication engine is used to: call the telemetry communication protocol stack interpretation component integrated in the kernel layer to construct telemetry data byte streams corresponding to telemetry packet data according to a unified telemetry communication protocol; the intra-satellite communication engine is used to: call the intra-satellite communication protocol stack interpretation component integrated in the kernel layer to convert between intra-satellite structured data and intra-satellite data byte streams according to a unified intra-satellite communication protocol; and the inter-satellite communication engine is used to: call the inter-satellite communication protocol stack interpretation component integrated in the kernel layer to convert between inter-satellite structured data and inter-satellite data byte streams according to a unified inter-satellite communication protocol. The aforementioned system unifies the satellite-to-ground, intra-satellite, and inter-satellite communication interconnection architecture and service framework, forming a complete solution from the underlying protocols of the satellite operating system to the upper-level satellite service applications, providing basic platform support for reducing satellite development cycles and building efficient and reliable large-scale satellite networks.

[0044] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0045] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0046] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0047] Figure 1 This is a schematic diagram of the structural format of each layer in a remote control communication protocol provided by an embodiment of the present invention;

[0048] Figure 2 This is a schematic diagram of the structural format of each layer in a telemetry communication protocol provided by an embodiment of the present invention;

[0049] Figure 3 This is a schematic diagram of the structural format of each layer in an inter-satellite communication protocol provided by an embodiment of the present invention;

[0050] Figure 4 A data flow diagram of a satellite-to-ground remote control communication engine provided in an embodiment of the present invention;

[0051] Figure 5 A data flow diagram of a satellite-to-ground telemetry communication engine provided in an embodiment of the present invention;

[0052] Figure 6 A flowchart of an intra-satellite communication engine service data transmission module provided in an embodiment of the present invention;

[0053] Figure 7 A flowchart of an intra-satellite communication engine service data receiving module provided in an embodiment of the present invention;

[0054] Figure 8 This is a data flow diagram of an inter-satellite communication engine provided in an embodiment of the present invention. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] In the aerospace satellite field, the traditional process for achieving satellite communication interconnection typically includes the following steps: deploying an onboard operating system on the onboard computer that provides the computing kernel and basic tool services; and developing satellite communication interconnection functions based on customized data communication interface protocols for satellite-to-ground, intra-satellite, and inter-satellite equipment. However, this process faces several key challenges in practical applications, requiring optimization to improve efficiency.

[0057] 1. High Development Costs of Satellite Applications: Each satellite requires customized development of dedicated satellite application software for its specific communication protocols, with development and debugging cycles lasting 6-12 months. Statistics show that the development and debugging costs of satellite equipment communication functions account for over 35% of the total satellite software development cost. The inability to reuse communication software between different satellite models leads to serious issues of redundant development. Furthermore, the protocol adaptation layer requires specialized optimization for different hardware platforms, further increasing development and verification costs.

[0058] 2. Fragmented Communication Protocols and Low Interconnection Efficiency: Current satellite communication relies on multiple protocol standards, including CCSDS (Consultative Committee for Space Data Systems), CAN (Controller Area Network), and serial ports, with different manufacturers implementing proprietary extensions. On average, a single satellite needs to support 3-5 different communication protocols, with protocol conversions adding 200-500ms of latency. In actual operation, data requires multiple protocol conversions to complete end-to-end transmission, resulting in low effective bandwidth utilization. This fragmentation also leads to long satellite constellation setup times, severely impacting emergency response capabilities.

[0059] 3. Poor Portability and Reusability: The communication modules of the satellite application software are deeply coupled with the underlying hardware and operating system, requiring over 60% of the code to be rewritten when porting to a new platform. The reuse rate of communication modules between satellites on different missions is less than 20%, necessitating redevelopment and verification for each mission. Even for satellites of the same model, communication software requires targeted adjustments due to differences in hardware batches. This low reusability poses a significant challenge to the rapid deployment of satellite constellations.

[0060] 4. Scalability Limitations: Under the current architecture, the number of communication connections a single satellite can make is limited by the operating system kernel design. When the satellite constellation size exceeds 50 satellites, system performance drops sharply. Adding new communication protocols requires recompiling the entire system, making dynamic loading impossible. Furthermore, the ground control system needs to maintain independent communication configurations for each satellite, and the management complexity increases exponentially with the number of satellites, severely restricting the development of large-scale satellite networks.

[0061] In view of the above-mentioned technical problems, this invention proposes a satellite operating system and satellite terminal based on a unified communication protocol to realize satellite interconnection. This not only effectively solves the above problems, but also enables plug-and-play, autonomous collaboration and efficient interconnection of satellite clusters, greatly improving the efficiency of satellite-to-ground, intra-satellite and inter-satellite communication and system reliability.

[0062] To facilitate understanding of this embodiment, a satellite operating system for satellite interconnection based on a unified communication protocol, as disclosed in this embodiment of the invention, will first be described in detail. The satellite operating system is mounted on the satellite. The kernel layer of the satellite operating system is integrated with the communication protocol stack interpretation component library, and a satellite interconnection service framework consisting of a satellite-to-ground communication engine, an intra-satellite communication engine, and an inter-satellite communication engine is constructed. The communication protocol stack interpretation component library includes remote control communication protocol stack interpretation components, telemetry communication protocol stack interpretation components, intra-satellite communication protocol stack interpretation components, and inter-satellite communication protocol stack interpretation components.

[0063] The satellite-to-ground communication engine includes a satellite-to-ground remote control communication engine and a satellite-to-ground telemetry communication engine. The satellite-to-ground remote control communication engine is used to: call the remote control communication protocol stack interpretation component integrated in the kernel layer to construct the remote control structured data corresponding to the remote control data according to a unified remote control communication protocol. The satellite-to-ground telemetry communication engine is used to: call the telemetry communication protocol stack interpretation component integrated in the kernel layer to construct the telemetry data byte stream corresponding to the telemetry packet data according to a unified telemetry communication protocol.

[0064] The intra-satellite communication engine is used to: call the intra-satellite communication protocol stack interpretation component integrated in the kernel layer, and convert between intra-satellite structured data and intra-satellite data byte streams according to a unified intra-satellite communication protocol;

[0065] The inter-satellite communication engine is used to: call the kernel-integrated inter-satellite communication protocol stack interpretation component to convert between inter-satellite structured data and inter-satellite data byte streams according to a unified inter-satellite communication protocol.

[0066] The aforementioned system unifies the satellite-to-ground, intra-satellite, and inter-satellite communication interconnection architecture and service framework, forming a complete solution from the underlying protocols of the satellite operating system to the upper-level satellite service applications, providing basic platform support for reducing satellite development cycles and building efficient and reliable large-scale satellite networks.

[0067] For ease of understanding, embodiments of the present invention provide a construction process for a satellite operating system based on a unified communication protocol for satellite interconnection, including:

[0068] (i) The unified communication protocol of this invention is designed based on mainstream satellite communication protocols such as CCSDS, CAN bus, serial port, and laser from the aspects of satellite-to-ground, intra-satellite, and inter-satellite interconnection. The satellite-to-ground communication protocol is designed based on the CCSDS international communication standard protocol; the intra-satellite device communication protocol is designed based on the CAN bus hardware interface; and the inter-satellite communication protocol is designed based on the laser communication link.

[0069] Satellite interconnection communication mainly includes satellite-to-ground communication (communication between satellite and the ground), intra-satellite communication (communication between devices within a satellite), and inter-satellite communication (communication between satellites). This invention provides a systematic and unified design for the communication protocols in these three areas, achieving standardization of the entire communication architecture. For satellite-to-ground communication, it unifies the data interaction protocol between the satellite and different ground systems; for intra-satellite communication, it standardizes the internal communication standards between individual devices on the satellite platform; and for inter-satellite communication, it establishes a standardized interconnection mechanism between satellite constellations.

[0070] The data transmission byte stream conventions for satellite-to-ground, intra-satellite, and inter-satellite communications are as follows: (1) In an M-byte number field: the first byte transmitted is called byte 0 (B0), followed by byte 1 (B1), ... up to byte M-1 (BM-1). The first byte (B0) transmitted in an M-byte number field is the most significant byte. Generally, the transmission order of multi-byte data is "high byte first, low byte last", that is, big-endian order. (2) In an 8-bit number field of a byte: the first bit transmitted is called bit 7 (b7), followed by bit 6 (b6), ... up to bit 0 (b0). That is, when this 8-bit number field is regarded as a binary number, the first bit transmitted (b7) is the most significant bit.

[0071] (1.1) Satellite-to-Ground Communication Protocol Design:

[0072] The satellite-to-ground communication protocol format is based on the CCSDS format and conforms to the CCSDS data protocol specification.

[0073] In terms of operations, satellite-to-ground communication data includes remote control data transmitted from the ground to the satellite and telemetry data transmitted from the satellite to the ground. This invention provides a unified design for satellite remote control and telemetry communication protocols, standardizing the transmission standards for uplink control commands and downlink monitoring data, thus achieving protocol standardization for these two core communication functions.

[0074] In one example, the remote control communication protocol design follows the CCSDS standard. Remote control communication transmission comprises multiple layers: the physical channel layer, the satellite-to-ground transmission layer, and the encapsulation layer. The physical channel layer uses a remote channel transmission unit (CLTU); the transmission layer uses remote control transmission frames; and the encapsulation layer uses remote control packets. See also... Figure 1The diagram shows the structural format of each layer in a remote control communication protocol:

[0075] (I) The physical channel layer includes the acquisition sequence and the remote control information transmission unit. The physical channel layer mainly adopts the remote control channel transmission unit format, which consists of the acquisition sequence and the remote control channel transmission unit. The acquisition sequence is a sequence of alternating "1" and "0", starting with "1", and has a length of no less than 128 bits. It is sent before the remote control information and is used for satellite acquisition and synchronization of ground remote control information.

[0076] (II) The satellite-to-ground transmission layer includes a remote control start flag, a remote control transmission frame, and a remote control end flag; wherein, the remote control start flag indicates the start of remote control data transmission; the remote control transmission frame includes a first master header, a remote control frame data field, and a remote control data verification field, and the remote control frame data field includes a remote control password area and an encrypted input command remote control packet; the remote control end flag indicates the end of remote control data transmission. Specifically:

[0077] The remote control channel carries remote control transmission frames, which consist of a remote control start flag, a remote control transmission frame, and a remote control end flag.

[0078] The remote control start flag indicates the start of remote control data transmission. It consists of 4 bytes and has a value of AC1020H.

[0079] The remote control end flag indicates the end of remote control data transmission. It is 4 bytes long and has a value of BD9080H.

[0080] The remote control transmission frame adopts the CCSDS packetized remote control format, which consists of a first leading header, a remote control frame data field, and a remote control data verification field. In the first leading header, the "Version Number" is set to 0; the "Pass Flag" is set to 1, indicating that only frame validity is checked on the received remote control transmission frame, and sequence correctness is not required; "Spacecraft" represents the spacecraft identifier; "Frame Length" is the total number of bytes in the remote control transmission frame minus 1; and the "Frame Sequence" starts from 1 and increments sequentially, continuing to count from 1 after reaching 0xFFFF.

[0081] The remote control frame data field carries a complete betting instruction remote control package, including a password area and an encrypted betting instruction remote control package; wherein, the "password area" carries the password field; the "remote control package" carries a complete indirect betting instruction remote control package, including an independent remote control package, a sequence package and a packaging file.

[0082] The remote control data verification field is checked using CRC(n,n-16) to detect errors in the transmitted frame.

[0083] (III) The packaging layer includes the second master header of the remote control instruction package and the remote control application data. In the second master header, the "Version Number" is set to 0; the "Package Type" is set to 1, indicating a remote control package. "Package Serial Number": If it is an independent remote control package, it is set to 0000H; if it is a package file, it is set to "1XXXH", where "XXX" represents the number of independent packages in the package file; if it is a sequence package, it is set to the sequence number of this package in the relevant package sequence, ranging from 0 to FFFFH. "Package Length": Set to the total number of bytes in the remote control application data field minus 1, ranging from 0 to 65535.

[0084] In one example, the telemetry communication protocol design: the entire satellite telemetry transmission frame contains multiple layers, and the main elements after decomposition are: Channel Access Data Unit (CADU), Virtual Channel Data Unit (VCDU), Multiplexing Protocol Data Unit (M-PDU), and Packaging Protocol Data Unit (E-PDU, i.e., the format adopted by the data source packet). See also Figure 2 The diagram shows the structural format of each layer in a telemetry communication protocol:

[0085] (I) The channel access data unit includes a synchronization byte and a virtual channel data unit.

[0086] The channel physical layer data structure consists of consecutive Channel Access Data Units (CADUs). Each CADU is 1024 bytes long, consisting of a 4-byte synchronization word and a 1020-byte Virtual Channel Data Unit (VCDU). The synchronization word, used for frame synchronization, is uncoded and defined as 1A01101BH.

[0087] (II) The virtual channel data unit carries telemetry packet data, which includes a third master header, a data field, and a telemetry data verification field.

[0088] The virtual channel serves as a telemetry channel, with virtual channel data units carrying telemetry transmission frames. Data from multiple telemetry packets are combined and transmitted within a single telemetry transmission frame.

[0089] The telemetry transmission frame adopts the CCSDS AOS frame format, with a total length of 1020 bytes (from the first bit of the transmission frame master header to the last bit of the frame error control field), including the third master header, the data field, and the telemetry data check field; among them, the telemetry data check field is checked by CRC(n,n-16) to detect errors in the telemetry transmission frame.

[0090] (III) The multiplexing protocol data unit is used to describe the third lead header and data field in the telemetry packet data. The data field includes the lead header pointer and the M-PDU data field. The lead header pointer is the position of the first byte in the header of the first complete telemetry packet data in the M-PDU data field. The M-PDU data field carries the telemetry packet data.

[0091] The multiplexing protocol data unit includes a third master header and a data field in the telemetry transmission frame.

[0092] In the third master header, the "Version Number" is set to 0, "Spacecraft" represents the spacecraft identifier, "Channel Identification" is filled in according to the type of telemetry transmission frame carried, if it is a valid telemetry transmission frame, it is set to 0X11, if it is an idle telemetry transmission frame, it is set to 0X22, "Frame Count" provides a separate count for each virtual channel, representing a separate sequential count of VCDU transmissions on each VC, and "Spare" is set to 0XAAAAAA.

[0093] Header pointer: This indicates the position of the first byte of the header of the first complete telemetry packet (E_PDU) in the M_PDU data field, starting from 0 and incrementing sequentially; if there is no telemetry packet header in the current M_PDU data field, fill in all "1"s.

[0094] The M_PDU data field carries telemetry packet data (E_PDU), totaling 1008 bytes. The first and last packets can be "incomplete packets". The tail frame pads the space between the end of the telemetry packet (E_PDU) and the end of the M_PDU data field with multiple AAHs as padding codes.

[0095] (IV) Packaging Protocol Data Unit is used to describe the telemetry packet data carried in the M-PDU data field. The telemetry packet data includes the source packet header, source packet data, and packet checksum.

[0096] Telemetry packet data is a packaged protocol data unit (E_PDU) formed by data generated from various onboard applications in a specific format. Telemetry packet data is the basic unit of transmission. Telemetry data packets mainly include a packet header, source packet data, and packet checksum.

[0097] The "Version Number" in the telemetry packet header is set to 0; APID is the Application Process Identifier, used to identify the data source on the spacecraft that generates the source packet; "Package Sequence Number" is a sequential counter that counts each packet generated by an application process marked with a unique Application Process Identifier. This binary count should be continuous, modulo 65535, and idle packets are not required to be counted. During the continuous execution of an application process, its counter must not be reset to zero before it reaches full; "Package Length" is the number of bytes in the packet data field minus 1.

[0098] The source packet data carries the telemetry data acquired by the entire satellite.

[0099] Packet verification: Perform a byte-by-byte check on all fields of the source packet data field, with the high 8 bits representing the overflow portion of the sum.

[0100] (1.2) Design of intra-satellite communication protocol:

[0101] The unified intra-satellite communication protocol design scheme proposed in this embodiment of the invention uses the CAN bus as its underlying hardware interface. In order to normalize the process and shield the differences in the underlying hardware interface, the communication format of the data field is uniformly defined. When customizing individual units, manufacturers of intra-satellite equipment should specify the communication protocol in accordance with this format.

[0102] The unified communication protocol within the satellite includes the CAN interface communication protocol and the service data communication protocol.

[0103] (I) The CAN interface communication protocol is used to define the CAN interface configuration and communication information frame format.

[0104] The CAN interface is configured as follows: 1) Baud rate: 600Kbps; 2) Technical specification: CAN2.0B; 3) Communication format: standard frame (ID11 bits), only data frames are transmitted (RTR=0).

[0105] Communication information frame format: includes arbitration field, control field, data field, CRC, and frame end.

[0106] Table 1 shows the CAN communication information frame format.

[0107]

[0108] Table 2 is the identifier format table.

[0109]

[0110] Device type: Onboard computer equipment sending: 0, other stand-alone equipment sending: 1.

[0111] Device ID: When the device type (ID10) is 0, this field is filled with the ID of the target slave device; when the device type (ID10) is 1, this field is filled with the ID of the source slave device. The device ID is customized based on the actual internal equipment of the satellite, including standalone devices such as onboard computers, power supplies, and GNSS.

[0112] Frame types: (00)b: single frame; (01)b: first frame; (10)b: middle frame; (11)b: last frame.

[0113] (II) The business data communication protocol is used to define the business data communication protocol format. The business data communication protocol format includes data type, length, data field and checksum. The data type is: remote control command, command response, telemetry request / response. The length is: the length of the data field. The data field is: valid data. The checksum is: checksum.

[0114] Table 3 shows the business data communication protocol format.

[0115]

[0116] Among them, "data type" indicates the type of data content, including: remote control command, command response, telemetry request / response, etc., which are customized by the specific project; "length" indicates the length of the data field; "data field" indicates the valid data; "checksum" indicates the checksum, which is to perform unsigned 8-bit accumulation on the data type, length, and data field content byte by byte, and retain the lower 8 bits.

[0117] (1.3) Design of inter-satellite communication protocol:

[0118] The unified inter-satellite communication protocol design scheme proposed in this embodiment of the invention uses a laser communication link. In order to normalize the process and shield the differences in the underlying hardware interfaces, the communication format of the data domain is uniformly defined. When customizing individual inter-satellite laser equipment, manufacturers should specify the communication protocol according to this format.

[0119] According to the CCSDS standard, inter-satellite communication transmission comprises two layers: the inter-satellite transport layer and the application data layer. See also... Figure 3 The diagram shows the structural format of each layer in an inter-satellite communication protocol:

[0120] (I) The inter-satellite transport layer includes an inter-satellite start flag, an inter-satellite transport frame, and an inter-satellite end flag. The inter-satellite start flag indicates the start of the inter-satellite data byte stream transmission. The inter-satellite transport frame includes a fourth master header, an inter-satellite frame data field, and an inter-satellite data verification field. The inter-satellite frame data field includes an inter-satellite cryptographic area and an encrypted inter-satellite application data packet. The inter-satellite end flag indicates the end of the inter-satellite data byte stream transmission.

[0121] Inter-satellite transport layer data consists of an inter-satellite start flag, an inter-satellite transport frame, and an inter-satellite end flag.

[0122] The inter-satellite start flag indicates the start of information transmission. It is 4 bytes long and has a value of FD8161H.

[0123] The inter-satellite end flag indicates the end of information transmission. It is 4 bytes long and has a value of EF0182H.

[0124] The inter-satellite transmission frame adopts the CCSDS packet format, which consists of a fourth leading header, an inter-satellite frame data field, and an inter-satellite data verification field. In the fourth leading header, the "Version Number" is set to 0; "Launch Satellite" and "Receive Satellite" represent satellite IDs; the "Encryption Identifier" is set to 1 to indicate that the data packet is ciphertext, and 0 to indicate that the data packet is plaintext; the "Frame Length" is the total number of bytes in the remote control transmission frame minus 1; and the "Frame Sequence" starts from 1 and increments sequentially until it reaches 0xFFFF, after which it resumes counting from 1.

[0125] The inter-satellite frame data field carries a complete inter-satellite application data packet, including the inter-satellite cryptographic area (optional) and the inter-satellite application data packet; among which, the "cryptographic area" carries the cryptographic fields.

[0126] The inter-satellite data check field is checked using CRC(n,n-16) to detect errors in the transmitted frame.

[0127] (II) The application data layer includes the fifth master header of the inter-satellite application data packet and the inter-satellite application data. In the fifth master header, the "Version Number" is set to 0; the "Packet Type" is set to 1, indicating a payload data packet. "Packet Length": set to the total number of bytes in the application data field minus 1.

[0128] (ii) Deeply integrate the above-mentioned communication protocol stack interpretation component library at the kernel level of the satellite operating system (including real-time operating system and general operating system) to achieve the underlying unification of satellite-to-ground, intra-satellite and inter-satellite communication protocols and eliminate the performance loss caused by protocol conversion.

[0129] After completing the design of the unified satellite interconnection communication protocol in the first step (1), these unified satellite interconnection communication protocol stack interpretation components are built in the kernel layer of the satellite operating system (including real-time operating system and general operating system) to realize the parsing and security verification of the satellite-ground, intra-satellite and inter-satellite communication protocols, reduce the development cost of upper-layer satellite applications due to the differences in underlying hardware and communication protocols, and eliminate the performance loss caused by protocol conversion.

[0130] Developed in C, this system deeply integrates the data encapsulation, decoding, and security verification capabilities of the satellite interconnection communication protocol stack into the kernel layer of the satellite operating system as a library of components. During integration, kernel functions are invoked through APIs provided by the satellite operating system.

[0131] (2.1) The operating system kernel constructs a satellite-to-ground communication protocol stack interpretation component:

[0132] The operating system kernel has built remote control communication protocol stack interpretation components and telemetry communication protocol stack interpretation components respectively.

[0133] In one example, the remote control communication protocol stack interpretation component:

[0134] The remote control data is assembled by the ground system and sent to the satellite. The remote control communication protocol stack decoding component in the satellite operating system kernel layer is responsible for parsing and verifying the protocol data and forwarding it to the upper-layer satellite service applications.

[0135] The ground system sends remote control data packets to the telemetry and control unit (TT&C) inside the satellite via a satellite-to-ground wireless link. Upon receiving the data, the TT&C unit performs the following: receives the remote control data sent by the ground system, parses the capture sequence within the remote control data, and, if the field values ​​of the capture sequence are correct, sends the remote control information transmission unit to the satellite-to-ground remote control communication engine. Specifically, it first parses the "capture sequence" field value; if the "capture sequence" field value is correct, the data security verification passes, and the data in the "remote control information transmission unit" is sent to the onboard computer via serial port.

[0136] The remote control communication protocol stack decoding component is used to: parse the remote control start flag in the remote control information transmission unit to determine whether the remote control information transmission unit includes a remote control transmission frame; if the determination result is yes, read the remote control frame data field, remote control data verification field, and remote control end flag into the kernel layer based on the first master header, and perform a validity check on the remote control frame data field based on the remote control data verification field and the remote control end flag; if the validity check is passed, read the remote control password area from the remote control frame data field to obtain decryption information, and use the decryption information to decrypt the encrypted input instruction remote control packet to obtain the plaintext input instruction remote control packet; use the second master header of the plaintext input instruction remote control packet to parse the remote control application data of the plaintext input instruction remote control packet to obtain the remote control parsing result, which includes the remote control command code, remote control time code, remote control command data, and remote control command data length; fill the remote control parsing result into a predefined remote control structure to obtain remote control structured data.

[0137] Specifically:

[0138] After receiving data from the "Remote Control Information Transmission Unit," the remote control communication protocol stack decoding component in the satellite operating system kernel layer of the onboard computer parses the "Remote Control Start Flag." If it determines that the data is not a "Remote Control Transmission Frame," it discards the data packet. If it determines that the data is a "Remote Control Transmission Frame," it continues to read the first master header data in the "Remote Control Transmission Frame," performing a validity check by judging the "Version Number" and "Pass Flag" in the first master header. Then, it reads the "Frame Length" field value in the first master header to obtain the length of the entire "Remote Control Transmission Frame" data. Based on the frame length, it reads all the unread data in the entire frame data of the "Remote Control Transmission Frame" into the operating system kernel layer, obtaining three fields: "Remote Control End Flag," "Remote Control Frame Data Field," and "Remote Control Data Verification Field." The "Remote Control End Flag" is used to determine whether the frame data is valid. If it is invalid, the frame data is discarded. Then, the CRC value of the entire frame data is calculated and compared with the value of the "Remote Control Data Verification Field." If they are not equal, the data is invalid, and the frame data is discarded.

[0139] Read the "Remote Control Password Area" data from the "Remote Control Frame Data Field" to obtain decryption information. Then, decrypt the "Encrypted Betting Command Remote Control Packet" field value to obtain the plaintext betting command remote control packet, and parse it to obtain the "Second Leading Header" and "Remote Control Application Data". From the "Package Type" in the "Second Leading Header", obtain the type of the betting command remote control packet (independent remote control packet, sequence packet, package file). After obtaining the "Package Length" field value, obtain the final "Remote Control Application Data" based on the packet length, and obtain the remote control command code, remote control time code, remote control command data, and remote control command data length according to the protocol format.

[0140] Finally, a remote control structure is defined, which includes fields such as spacecraft identifier, remote control command code, remote control time code, remote control command data, and remote control command data length. The remote control structure is filled according to the above protocol parsing results and then forwarded to the upper-layer space service application in the form of a callback.

[0141] The upper-level satellite application receives structured remote control data. Regardless of the differences in underlying hardware and communication protocols, the remote control data received by the satellite application is in a fixed and uniform format, which significantly reduces the development cost of the satellite application.

[0142] In one example, the telemetry communication protocol stack interpretation component:

[0143] Telemetry data is assembled by the satellite operating system and sent to the ground system. The telemetry communication protocol stack interpretation component in the satellite operating system kernel layer is responsible for assembling telemetry packet data according to the protocol and transmitting it to the ground system via the satellite-to-ground link.

[0144] The telemetry communication protocol stack interpretation component is used to: fill the telemetry packet data sent by the upper-level satellite service system inside the satellite into a predefined telemetry packet structure according to the telemetry communication protocol, and during the filling process, sequentially fill multiple telemetry packet data into multiple M-PDU data fields within the telemetry packet structure; wherein, the telemetry packet data at the beginning and end of the M-PDU data field are complete telemetry packet data or incomplete telemetry packet data; assemble the telemetry packet structure and the telemetry frame data structure into a telemetry data byte stream; wherein, the telemetry frame data structure includes a spacecraft identifier, a virtual channel identifier, a number of telemetry data packets, and an array of telemetry data packets.

[0145] Specifically:

[0146] In the telemetry communication protocol stack interpretation component, a telemetry packet structure gseng_tlm_pack_t is designed, which includes telemetry packet type, packet number, packet count, packet data length, and packet data. Then, a telemetry frame data structure gseng_tlm_data_t is designed to be transmitted to the ground, which includes spacecraft identifier, virtual channel identifier, number of telemetry data packets, and array of telemetry data packets.

[0147] The telemetry communication protocol stack decoding component first fills in these two structure data according to the service, and then assembles these two structure data into telemetry byte stream data according to the telemetry communication protocol format in step (1), and transmits it to the ground system through the satellite-to-ground telemetry link.

[0148] Each frame of telemetry packet data is 1024 bytes, and the M-PDU carrying the telemetry data is 1008 bytes. If multiple telemetry packet data are sent together (i.e., in one frame), and the total length exceeds 1008 bytes, the excess bytes will be sent in the next frame. The data sent in the next frame includes the E-PDU (telemetry) header and the actual E-PDU (telemetry) data. When the system sends a frame each time, it first checks whether there is any unsent telemetry packet data left over from the previous frame. If so, the unsent data from the previous frame is filled into the beginning of the M-PDU, and then the telemetry packet data to be sent in the current frame is filled in.

[0149] (2.2) The operating system kernel constructs the intra-satellite communication protocol stack interpretation component:

[0150] In this embodiment of the invention, the satellite's internal devices are interconnected via a CAN bus. Intra-satellite communication data is assembled by each individual device within the satellite (including the satellite operating system of the onboard computer, etc.) and sent via the CAN bus to a designated target intra-satellite device. The target device receives the data, parses and processes it independently.

[0151] Specifically:

[0152] For the onboard computer operating system, two structures are designed in the onboard communication protocol stack interpretation component: iseng_can_send_pack_t and iseng_can_recv_pack_t. iseng_can_send_pack_t represents the data packet structure sent via the CAN bus, including fields such as data type, data length, and data fields; iseng_can_recv_pack_t represents the data packet structure received via the CAN bus, including fields such as data type, data length, and data fields.

[0153] When sending data, the intra-satellite communication protocol stack interpreter first fills the iseng_can_send_pack_t structure data, and then assembles this structure data into byte stream data according to the intra-satellite communication protocol format in step (1), and transmits it to the intra-satellite target device through the CAN bus.

[0154] When the intra-satellite communication protocol stack decoding component receives communication data from the CAN bus, it fills the iseng_can_recv_pack_t structure according to the intra-satellite communication protocol format in step (1), and then forwards it to the upper-layer satellite application in the form of a callback.

[0155] (2.3) Operating system kernel builds inter-satellite communication protocol stack interpretation component:

[0156] In this embodiment of the invention, satellites communicate with each other via laser links. An inter-satellite communication protocol stack decoding component is built at the satellite operating system kernel layer. This component is responsible for parsing / encapsulating and securely verifying data, and forwarding it to upper-layer satellite applications.

[0157] The inter-satellite communication protocol stack decoding component is used to: parse the inter-satellite start flag in the inter-satellite data byte stream sent by other satellites to determine whether the inter-satellite transport layer includes an inter-satellite transport frame; if the determination result is yes, read the inter-satellite frame data field, inter-satellite data verification field, and inter-satellite end flag into the kernel layer based on the fourth leading header, and perform a validity check on the inter-satellite frame data field based on the inter-satellite data verification field and the inter-satellite end flag; if the validity check is passed, read the inter-satellite cryptographic area from the inter-satellite frame data field to obtain decryption information, and use the decryption information to decrypt the encrypted inter-satellite application data packet to obtain the plaintext inter-satellite application data packet; use the fifth leading header of the plaintext inter-satellite application data packet to parse the inter-satellite application data of the plaintext inter-satellite application data packet to obtain the inter-satellite parsing result; and fill the inter-satellite parsing result into a predefined inter-satellite structure to obtain inter-satellite structured data.

[0158] Specifically:

[0159] After receiving data, the inter-satellite communication protocol stack interpretation component parses the "inter-satellite start flag." If it determines that the data is not an "inter-satellite transmission frame," it discards the data packet. If it determines that the data is an "inter-satellite transmission frame," it continues to read the fourth master header in the "inter-satellite transmission frame," performing a validity check by checking the "version number" in the fourth master header. Then, it reads the "frame length" field value in the fourth master header to obtain the length of the entire "transmission frame" data. Based on the frame length, it reads all the unread data from the entire "inter-satellite transmission frame" data into the operating system kernel layer, obtaining the three fields: "inter-satellite end flag," "inter-satellite frame data field," and "inter-satellite data checksum field." The "inter-satellite end flag" is used to determine if the frame data is valid; if invalid, the frame data is discarded. Finally, the CRC value of the entire frame data is calculated and compared with the value in the "inter-satellite data checksum field." If they are not equal, the data is invalid, and the frame data is discarded.

[0160] The encryption identifier in the fourth leading header determines whether the data is encrypted. If encrypted, the data in the inter-satellite cryptographic area is read from the inter-satellite frame data field to obtain decryption information. Then, the plaintext data is obtained by decrypting the value of the inter-satellite application data packet field. If not encrypted, the plaintext data in the inter-satellite application data packet field is read directly and parsed to obtain the fifth leading header and application data. After reading the value of the packet length field, the final inter-satellite application data is obtained based on the packet length. The timecode and specific business data of the inter-satellite application data are obtained according to the protocol format.

[0161] Finally, a structure is defined, which includes fields such as the launching satellite ID, receiving satellite ID, data length, and data. This structure is then filled with the results of the protocol parsing described above and forwarded to the upper-layer satellite service application via a callback.

[0162] The upper-level satellite applications receive structured inter-satellite communication data. Regardless of the differences in underlying hardware and communication protocols, the format of the inter-satellite communication data received by the satellite applications is fixed and uniform, which significantly reduces the development cost of satellite applications.

[0163] (III) Construct a satellite interconnection service framework that includes core functions such as satellite-to-ground communication engine, intra-satellite communication engine, and inter-satellite communication engine, providing standardized communication interfaces for upper-level satellite service applications, so that satellite service application development does not need to pay attention to the differences in underlying protocols, and reducing the development cost of satellite service application communication functions by more than 80%.

[0164] After integrating the satellite interconnection communication protocol stack into the satellite operating system kernel, a satellite interconnection service framework with core functions such as satellite-to-ground communication engine, intra-satellite communication engine, and inter-satellite communication engine is built in the satellite operating system service layer. Standardized communication interfaces are provided for upper-layer satellite service applications, enabling satellite service application development to achieve satellite-to-ground, intra-satellite, and inter-satellite data communication functions without having to worry about the differences in underlying protocols.

[0165] (3.1) Satellite-to-ground communication engine: In this embodiment of the invention, the satellite-to-ground communication engine in the satellite operating system mainly provides satellite-to-ground communication services such as receiving, interpreting, security verification, assembling structured data and forwarding it to upper-level satellite applications, as well as assembling telemetry data and forwarding it to the ground system.

[0166] The satellite-to-ground communication engine includes a satellite-to-ground remote control communication engine and a satellite-to-ground telemetry communication engine.

[0167] In one example, the satellite-to-ground remote control communication engine: see [link / reference] Figure 4 The diagram shows a data flow chart of a satellite-to-ground remote control communication engine, which includes the ground system sending remote control data; the satellite's internal telemetry and control unit receiving remote control data; and the satellite operating system's satellite-to-ground remote control communication engine performing the following operations: receiving remote control data, calling the kernel remote control communication protocol stack decoding component to decode the data, constructing remote control structured data, and sending it to the satellite service application.

[0168] Specifically:

[0169] Remote control data is initiated by the ground system and transmitted to the telemetry, tracking, and command (TT&C) unit inside the satellite via a wireless network between the satellite and the ground. After receiving the remote control data and verifying its security, the TT&C unit forwards the remote control data packets to the onboard computer via serial port. The satellite-to-ground remote control data communication engine of the onboard computer's operating system is responsible for receiving and processing the remote control data. To improve reliability, the TT&C unit simultaneously sends remote control data to the onboard computer through two serial ports, and the satellite-to-ground remote control communication engine uses frame sequence fields to deduplicate the data.

[0170] The satellite-to-ground remote control communication engine starts a task (thread) responsible for polling and receiving remote control data from the serial port. When a complete remote control data is received, the remote control communication protocol stack decoding component in the satellite operating system kernel layer is invoked to decode and perform security verification on the data. After successful verification, the remote control data is constructed as a structure and forwarded to the upper-layer satellite service application via a callback.

[0171] To improve the stability of serial port connections and the reliability of data reception, if a serial port communication abnormality (connection interruption) is detected in the serial communication task (thread), the serial port reconnection logic is initiated; if the connection fails, the connection will continue to be established until it is successful.

[0172] In one example, the satellite-to-ground telemetry communication engine: see [link / reference] Figure 5 The data flow diagram of a satellite-to-ground telemetry communication engine shown includes: the satellite application sends structured telemetry packet data to the satellite-to-ground telemetry data communication engine by calling the API; the satellite-to-ground telemetry communication engine then calls the telemetry communication protocol stack decoding component of the operating system kernel layer to translate the data and construct a telemetry data byte stream; the telemetry data byte stream is then sent to the telemetry and control unit via a serial port; and finally, the telemetry and control unit forwards the data to the ground system via the satellite-to-ground wireless network.

[0173] Specifically:

[0174] The satellite-to-ground telemetry data communication engine starts a task (thread) responsible for sending telemetry data to the telemetry and control unit via serial port. To improve the stability of the serial port connection and the reliability of data reception, if a serial port communication abnormality (connection interruption) is detected in the serial communication task (thread), the serial port reconnection logic is initiated; if the connection fails, it continues to connect until the connection is successful.

[0175] (3.2) Intra-satellite communication engine

[0176] In this embodiment of the invention, the intra-satellite communication engine in the satellite operating system mainly provides intra-satellite communication services such as data transmission / reception, decoding, security verification, structured data assembly, and forwarding to upper-layer satellite applications between internal satellite devices based on the CAN bus.

[0177] (I) Data transmission module, see Figure 6 The flowchart shown is for a data transmission module of the intra-satellite communication engine service: The intra-satellite communication engine service data transmission module provides an API interface. The satellite application calls the API to transmit structured data to the intra-satellite communication engine of the operating system. After receiving the structured data, the engine calls the intra-satellite communication protocol stack interpretation component of the operating system kernel layer to translate the structured data into byte stream data, and then sends it to the target device through the CAN bus based on the CAN communication protocol. The target device immediately returns response data after receiving the data.

[0178] (II) Data receiving module, see Figure 7 The flowchart shown is for a data receiving module of the satellite's intra-satellite communication engine service: When a standalone device inside the satellite sends data via the CAN bus, the satellite operating system triggers an interrupt. The intra-satellite communication engine data receiving module then responds to the interrupt, reads the CAN data from the interrupt FIFO, and calls the intra-satellite communication protocol stack decoding component in the operating system kernel layer to decode the data and construct it into structured data. This structured data is then forwarded to the satellite service application via a callback mechanism. The satellite service application immediately returns a response response after processing.

[0179] (3.3) Inter-satellite communication engine:

[0180] In this embodiment of the invention, the inter-satellite communication engine in the satellite operating system mainly provides inter-satellite communication services such as data transmission / reception, decoding, security verification, structured data assembly, and forwarding to upper-layer satellite applications based on laser links. See also Figure 8 The diagram shown is a data flow chart of an inter-satellite communication engine, including:

[0181] When sending inter-satellite data, the inter-satellite communication engine service provides an API interface. The satellite application calls the API to send structured data to the operating system's inter-satellite communication engine. After receiving the structured data, the engine calls the inter-satellite communication protocol stack interpretation component in the operating system kernel layer to translate the structured data into byte stream data. Then, based on the CAN communication protocol, it sends the data to the inter-satellite laser device via the CAN bus. The laser device then forwards the data to the target satellite via the laser link.

[0182] After the inter-satellite laser device receives data from other satellites, it performs data verification and then sends the data to the onboard computer via the CAN bus. After receiving the inter-satellite data, the satellite operating system calls the inter-satellite communication protocol stack decoding component in the operating system kernel layer to decode the byte stream data into structured data. Then, it forwards the structured data to the satellite application for processing via a callback mechanism.

[0183] (iv) The modular design enables dynamic loading of communication protocols and services, supports OTA (Over-The-Air) on-orbit updates and dynamic expansion, and meets the communication and networking needs of large-scale satellite constellations.

[0184] The satellite interconnection service framework constructed in step (iii) adopts modular design and service dynamic loading technology to implement the satellite-to-ground communication engine, intra-satellite communication engine, and inter-satellite communication engine.

[0185] The satellite operating system service layer defines three global control parameters: satellite-to-ground global control parameters, intra-satellite global control parameters, and inter-satellite global control parameters. These parameters are used to control the activation and deactivation of the satellite-to-ground communication engine, intra-satellite communication engine, and inter-satellite communication engine, enabling modularization and dynamic service loading.

[0186] During satellite operation, if the three satellite interconnection services—the satellite-to-ground communication engine, the intra-satellite communication engine, and the inter-satellite communication engine—need to be updated or upgraded, these three services will be updated, upgraded, and dynamically expanded through the OTA (Over-The-Air) on-orbit update and upgrade function between the satellite and the ground, thereby meeting the communication and networking needs of large-scale satellite constellations.

[0187] The satellite operating system for satellite interconnection based on a unified communication protocol proposed in this invention brings the following significant advantages in the satellite field through protocol standardization, operating system kernel-level integration, and dynamic design of the service framework:

[0188] 1. Significantly Reduced Development Costs of Satellite Applications: In traditional solutions, satellite applications require customized development of communication modules for different hardware and protocols, resulting in long development cycles (approximately 6-12 months) and costs exceeding 35%. This invention integrates the satellite-to-ground, intra-satellite, and inter-satellite communication protocol stacks uniformly through the operating system kernel and provides standardized interfaces for the upper layers. This eliminates the need for satellite applications to concern themselves with underlying protocol differences, reducing communication function development costs by over 80% and supporting reuse across satellite models, thus completely resolving the problem of redundant development.

[0189] 2. Improved Communication Efficiency and Reliability: Traditional satellite communication suffers from low effective bandwidth utilization and latency as high as 200-500ms due to protocol fragmentation (requiring support for 3-5 protocols) and multiple conversions. This invention, through unified protocol design and kernel-level integration, eliminates protocol conversion overhead, reducing end-to-end latency to less than 50ms, significantly improving the emergency response capabilities of satellite constellations.

[0190] 3. Enhanced System Scalability and Dynamism: Traditional architectures, limited by kernel design, experience a sharp performance drop when the satellite constellation size exceeds 50 satellites. This invention employs a modular service framework, supporting dynamic loading of the communication engine and OTA (Over-The-Air) updates. It allows for the expansion of new protocols or configuration adjustments without recompiling the system, meeting the high-efficiency networking requirements of large-scale constellations.

[0191] 4. Simplified Operation and Enhanced Security: Through a unified communication protocol and structured data interface, the ground telemetry and control system no longer needs to maintain independent configurations for each satellite, reducing management complexity from exponential to linear growth. Furthermore, the kernel-level protocol stack integrates encryption and verification mechanisms (such as CRC and cryptographic decryption) to ensure secure data transmission and avoid security risks caused by protocol adaptation layer vulnerabilities in traditional solutions.

[0192] 5. Enables plug-and-play and autonomous collaboration: The satellite operating system's built-in interconnect service framework supports automatic protocol adaptation and resource allocation when new satellites / devices are connected, laying the foundation for rapid constellation deployment and autonomous collaborative tasks (such as inter-satellite data relay and distributed computing).

[0193] In summary, the embodiments of the present invention solve the core problems of high cost, low efficiency, and difficulty in expansion in the field of satellite communication through communication protocol standardization, deep kernel integration, and dynamic service framework, providing key technical support for building efficient and reliable large-scale satellite networks.

[0194] Based on the foregoing embodiments, this invention provides a satellite terminal, including the aforementioned satellite operating system that enables satellite interconnection based on a unified communication protocol.

[0195] The satellite terminal provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned system embodiment. For the sake of brevity, any parts not mentioned in the satellite terminal embodiment can be referred to the corresponding content in the aforementioned system embodiment.

[0196] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A satellite operating system for satellite interconnection based on a unified communication protocol, characterized in that, The satellite operating system is mounted on the satellite. The kernel layer of the satellite operating system is integrated with the communication protocol stack interpretation component library, and a satellite interconnection service framework consisting of a satellite-to-ground communication engine, an intra-satellite communication engine, and an inter-satellite communication engine is constructed. The satellite-to-ground communication engine includes a satellite-to-ground remote control communication engine and a satellite-to-ground telemetry communication engine. The satellite-to-ground remote control communication engine is used to: invoke the remote control communication protocol stack decoding component integrated in the kernel layer to construct remote control structured data corresponding to the remote control data according to a unified remote control communication protocol; the satellite-to-ground telemetry communication engine is used to: invoke the telemetry communication protocol stack decoding component integrated in the kernel layer to construct a telemetry data byte stream corresponding to the telemetry packet data according to a unified telemetry communication protocol. The intra-satellite communication engine is used to: call the intra-satellite communication protocol stack interpretation component integrated in the kernel layer, and perform the conversion between intra-satellite structured data and intra-satellite data byte stream according to the unified intra-satellite communication protocol; The inter-satellite communication engine is used to: call the inter-satellite communication protocol stack interpretation component integrated in the kernel layer, and convert between inter-satellite structured data and inter-satellite data byte streams according to a unified inter-satellite communication protocol; The remote control communication protocol stack decoding component is specifically used for: The remote control start flag in the remote control information transmission unit is parsed to determine whether the remote control information transmission unit includes a remote control transmission frame; If the judgment result is yes, the remote control frame data field, remote control data verification field and remote control end flag are read into the kernel layer based on the first master header, so as to perform legality verification on the remote control frame data field based on the remote control data verification field and the remote control end flag; If the legality verification is passed, the remote control password area is read from the remote control frame data field to obtain the decryption information. The decryption information is then used to decrypt the encrypted betting instruction remote control packet to obtain the plaintext betting instruction remote control packet. Using the second master header of the plaintext number instruction remote control packet, the remote control application data of the plaintext number instruction remote control packet is parsed to obtain the remote control parsing result, which includes the remote control instruction code, the remote control time code, the remote control instruction data, and the remote control instruction data length. The remote control parsing results are filled into a predefined remote control structure to obtain structured remote control data.

2. The satellite operating system for satellite interconnection based on a unified communication protocol according to claim 1, characterized in that, The remote control communication protocol includes: a physical channel layer, a satellite-to-ground transmission layer, and a packaging layer; The physical channel layer includes a capture sequence and a remote control information transmission unit; The satellite-to-ground transmission layer includes a remote control start flag, a remote control transmission frame, and a remote control end flag; wherein, the remote control start flag indicates the start of the remote control data transmission; the remote control transmission frame includes a first master header, a remote control frame data field, and a remote control data verification field, the remote control frame data field including a remote control password area and an encrypted input instruction remote control packet; the remote control end flag indicates the end of the remote control data transmission. The packaging layer includes a second master head of the remote control package for the numbering instructions and remote control application data.

3. The satellite operating system for satellite interconnection based on a unified communication protocol according to claim 2, characterized in that, The satellite-end telemetry and control unit is used to: receive remote control data sent by the ground system, parse the capture sequence in the remote control data, and, if the field values ​​of the capture sequence are correct, send the remote control information transmission unit to the satellite-to-ground remote control communication engine. The satellite-to-ground remote control communication engine invokes the remote control communication protocol stack decoding component.

4. The satellite operating system for satellite interconnection based on a unified communication protocol according to claim 1, characterized in that, The telemetry communication protocol includes: a channel access data unit, a multiplexing protocol data unit, and a packaging protocol data unit; The channel access data unit includes a synchronization byte and a virtual channel data unit; The virtual channel data unit carries the telemetry packet data, which includes a third master header, a data field, and a telemetry data verification field. The multiplexing protocol data unit is used to describe the third leading header and the data field in the telemetry packet data. The data field includes a leading header pointer and an M-PDU data field. The leading header pointer is the position of the first byte in the header of the first complete telemetry packet data in the M-PDU data field. The M-PDU data field carries the telemetry packet data. The Packaging Protocol Data Unit is used to describe the telemetry packet data carried by the M-PDU data field. The telemetry packet data includes the source packet header, source packet data, and packet checksum.

5. The satellite operating system for satellite interconnection based on a unified communication protocol according to claim 4, characterized in that, The telemetry communication protocol stack interpretation component is specifically used for: According to the telemetry communication protocol, the telemetry packet data sent by the upper-level satellite service system inside the satellite is filled into a predefined telemetry packet structure, and during the filling process, multiple telemetry packet data are sequentially filled into multiple M-PDU data fields within the telemetry packet structure; wherein, the telemetry packet data at the beginning and end of the M-PDU data field are complete telemetry packet data or incomplete telemetry packet data; The telemetry packet structure and the telemetry frame data structure are assembled into the telemetry data byte stream; wherein, the telemetry frame data structure includes a spacecraft identifier, a virtual channel identifier, a number of telemetry data packets, and an array of telemetry data packets.

6. The satellite operating system for satellite interconnection based on a unified communication protocol according to claim 1, characterized in that, The intra-satellite communication protocol includes: CAN interface communication protocol and service data communication protocol; The CAN interface communication protocol is used to define the CAN interface configuration and communication information frame format. The communication information frame format includes an arbitration field, a control field, a data field, a CRC, and a frame end. The business data communication protocol is used to define the business data communication protocol format. The business data communication protocol format includes data type, length, data field and checksum. The data type is: remote control command, command response, telemetry request / response. The length is: the length of the data field. The data field is: valid data. The checksum is: checksum.

7. The satellite operating system for satellite interconnection based on a unified communication protocol according to claim 1, characterized in that, The inter-satellite communication protocol includes: an inter-satellite transport layer and an application data layer; The inter-satellite transport layer includes an inter-satellite start flag, an inter-satellite transport frame, and an inter-satellite end flag. The inter-satellite start flag indicates the start of the inter-satellite data byte stream transmission. The inter-satellite transport frame includes a fourth master header, an inter-satellite frame data field, and an inter-satellite data verification field. The inter-satellite frame data field includes an inter-satellite cryptographic area and an encrypted inter-satellite application data packet. The inter-satellite end flag indicates the end of the inter-satellite data byte stream transmission. The application data layer includes the fifth master header of the inter-satellite application data packet and the inter-satellite application data.

8. The satellite operating system for satellite interconnection based on a unified communication protocol according to claim 7, characterized in that, The inter-satellite communication protocol stack decoding component is specifically used for: The inter-satellite start flag in the inter-satellite data byte stream sent by other satellites is parsed to determine whether the inter-satellite transport layer includes the inter-satellite transport frame; If the judgment result is yes, the inter-satellite frame data field, the inter-satellite data verification field, and the inter-satellite end flag are read into the kernel layer based on the fourth leading header, so as to perform legality verification on the inter-satellite frame data field based on the inter-satellite data verification field and the inter-satellite end flag; If the legitimacy verification is passed, the inter-satellite cryptographic area is read from the inter-satellite frame data field to obtain decryption information. The decryption information is then used to decrypt the encrypted inter-satellite application data packet to obtain the plaintext inter-satellite application data packet. Using the fifth leading header of the plaintext inter-satellite application data packet, the inter-satellite application data of the plaintext inter-satellite application data packet is parsed to obtain the inter-satellite parsing result; The inter-satellite resolution results are filled into a predefined inter-satellite structure to obtain inter-satellite structured data.

9. The satellite operating system for satellite interconnection based on a unified communication protocol according to claim 1, characterized in that, The satellite operating system is configured with global control parameters between the satellite and the ground, global control parameters within the satellite, and global control parameters between the satellite and the ground, as well as the intra-satellite and inter-satellite communication engines, for controlling their activation and deactivation.

10. A satellite terminal, characterized in that, Including the satellite operating system based on a unified communication protocol for satellite interconnection as described in any one of claims 1-9.

Images