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

Abstract

The invention provides a satellite operating system and a satellite end for realizing satellite interconnection based on a unified communication protocol, an inner kernel layer of the satellite operating system is integrated with a communication protocol stack interpretation component, and a service framework consisting of a satellite-ground communication engine, an in-satellite communication engine and an inter-satellite communication engine is constructed; the satellite-ground remote control communication engine calls a communication protocol stack interpretation component, and remote control structured data corresponding to the remote control data is constructed according to a communication protocol; the satellite-ground telemetering communication engine calls a communication protocol stack interpretation component, and constructs a telemetering data byte stream corresponding to the telemetering packet data according to a communication protocol; an in-satellite communication engine calls a communication protocol stack interpretation component, and performs conversion between in-satellite structured data and in-satellite data byte streams according to a communication protocol; and the inter-satellite communication engine calls the communication protocol stack interpretation component, and performs conversion between the inter-satellite structured data and the inter-satellite data byte stream according to the communication protocol. According to the invention, satellite-ground, in-satellite and inter-satellite communication interconnection architecture and service framework of satellites are unified.

Description

Technical Field

[0001] The present invention relates to the field of satellite communication technology, and particularly to a satellite operating system and a satellite terminal for realizing satellite interconnection based on a unified communication protocol. Background Art

[0002] In the field of aerospace satellites, on-board computers and satellite operating systems, as important components of satellite hardware and software, provide a reliable and efficient operating environment for satellite mission application systems. With the rapid development of space technology and satellite technology, the computing power of on-board computers has been continuously improved, and the functional requirements of satellite operating systems have become increasingly complex. Current mainstream on-board operating systems such as VxWorks and Linux, although specifically optimized for real-time performance and reliability, are essentially general computing kernel architectures that mainly provide core functions such as basic task scheduling, memory management, and device drivers. These systems were not designed with the special requirements of satellite cluster collaborative work in mind, especially lacking native support for unified communication between space and ground, within the satellite, and between satellites.

[0003] In the current field of aerospace satellites, the on-board operating systems deployed on on-board computers are all computing kernels that provide kernel capabilities such as task scheduling, memory management, file system, interrupt, and device drivers; some on-board operating systems also provide basic tool service capabilities for satellite service applications by integrating some open-source component libraries; satellite service applications then develop service functions such as satellite data communication, flight control, and on-board data processing based on these kernel capabilities and basic tool service capabilities. In particular, data communication functions between space and ground, within the satellite, and between satellites are all developed by upper-layer satellite service applications.

[0004] In terms of satellite data communication, due to the differences in hardware devices, the data communication interface protocols between satellites and the ground (space-ground), within satellite devices (intra-satellite), and between satellites (inter-satellite) are inconsistent. Satellite service applications need to adapt, develop, and debug all data communication interface protocols for space-ground, intra-satellite, and inter-satellite, and the research and development costs of satellite service applications are very high. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a satellite operating system and a satellite terminal for realizing satellite interconnection based on a unified communication protocol, unifying the communication interconnection architecture and service framework between space and ground, within the satellite, and between satellites, and providing a basic platform support for reducing the satellite development cycle and constructing an efficient and reliable large-scale satellite network.

[0006] In a first aspect, the present invention provides a satellite operating system for realizing satellite interconnection based on a unified communication protocol. The satellite operating system is carried on the satellite side. The kernel layer of the satellite operating system is integrated with a communication protocol stack interpretation component library, and a satellite interconnection service framework composed of a space-ground communication engine, an intra-satellite communication engine, and an inter-satellite communication engine is constructed; The space-ground communication engine includes a space-ground telecommand communication engine and a space-ground telemetry communication engine; among them, the space-ground telecommand communication engine is used for: calling the telecommand communication protocol stack interpretation component integrated in the kernel layer, and constructing the telecommand structured data corresponding to the telecommand data according to the unified telecommand communication protocol; the space-ground telemetry communication engine is used for: calling the telemetry communication protocol stack interpretation component integrated in the kernel layer, and constructing the telemetry data byte stream corresponding to the telemetry packet data according to the unified telemetry communication protocol; The intra-satellite communication engine is used for: calling the intra-satellite communication protocol stack interpretation component integrated in the kernel layer, and performing conversion between the intra-satellite structured data and the intra-satellite data byte stream according to the unified intra-satellite communication protocol; The inter-satellite communication engine is used for: calling the inter-satellite communication protocol stack interpretation component integrated in the kernel layer, and performing conversion between the inter-satellite structured data and the inter-satellite data byte stream according to the unified inter-satellite communication protocol.

[0007] In an implementation manner, the telecommand communication protocol includes: a physical channel layer, a space-ground transmission layer, and a packaging layer; The physical channel layer includes a capture sequence and a telecommand information transmission unit; The space-ground transmission layer includes a telecommand start flag, a telecommand transmission frame, and a telecommand end flag; among them, the telecommand start flag indicates the start of the telecommand data transmission; the telecommand transmission frame includes a first leading header, a telecommand frame data field, and a telecommand data check field, and the telecommand frame data field includes a telecommand password area and an encrypted bet number instruction telecommand packet; the telecommand end flag indicates the end of the telecommand data transmission; The packaging layer includes a second leading header of the bet number instruction telecommand packet and telecommand application data.

[0008] In an implementation manner, the tracking and control machine on the satellite side is used for: receiving the telecommand data sent by the ground system, parsing the capture sequence in the telecommand data, and when the field value of the capture sequence is correct, sending the telecommand information transmission unit to the space-ground telecommand communication engine; The space-ground telecommand communication engine calls the telecommand communication protocol stack interpretation component, and the telecommand communication protocol stack interpretation component is specifically used for: Parsing the telecommand start flag in the telecommand information transmission unit to determine whether the telecommand information transmission unit includes a telecommand transmission frame; When the judgment result is yes, reading the telecommand frame data field, the telecommand data check field, and the telecommand end flag to the kernel layer based on the first leading header, so as to perform a legality check on the telecommand frame data field based on the telecommand data check field and the telecommand end flag; In the case of passing the legality check, the decryption information is obtained by reading the remote control password area from the remote control frame data field, and the encrypted bet number instruction remote control packet is decrypted by using the decryption information to obtain the plaintext bet number instruction remote control packet; Using the second leading header of the plaintext bet number instruction remote control packet, the remote control application data of the plaintext bet number instruction remote control packet is parsed to obtain a remote control parsing result, which includes a remote control instruction code, a remote control time code, remote control instruction data, and a remote control instruction data length; The remote control parsing result is filled into a pre-defined remote control structure to obtain remote control structured data.

[0009] In one implementation, 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 telemetry packet data, and the telemetry packet data includes a third leading header, a data field, and a telemetry data check 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, and 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 a source packet leading header, source packet data, and a packet check.

[0010] In one implementation, 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 pre-defined telemetry packet structure, and multiple telemetry packet data are sequentially filled into multiple M-PDU data fields in the telemetry packet structure during the filling process; among them, the telemetry packet data at the head and tail ends in the M-PDU data field are complete or incomplete telemetry packet data; 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, the number of telemetry data packets, and an array of telemetry data packets.

[0011] In one implementation, the in-satellite communication protocol includes: a CAN interface communication protocol and a service data communication protocol; The CAN interface communication protocol is used to define the CAN interface configuration and the 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 service data communication protocol is used to define the service data communication protocol format, which includes data type, length, data field, and checksum. The data type is: remote control instruction, instruction response, telemetry request / response; the length is: the length of the data field; the data field is: valid data; the checksum is: sum checksum.

[0012] In one implementation, 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 transmission of the inter-satellite data byte stream; the inter-satellite transport frame includes a fourth main header, an inter-satellite frame data field, and an inter-satellite data checksum field. The inter-satellite frame data field includes an inter-satellite cipher area and an encrypted inter-satellite application data packet; the inter-satellite end flag indicates the end of the transmission of the inter-satellite data byte stream; The application data layer includes a fifth main header of the inter-satellite application data packet and inter-satellite application data.

[0013] In one implementation, the inter-satellite communication protocol stack interpretation component is specifically used for: Parsing the inter-satellite start flag in the inter-satellite data byte stream sent by other satellite terminals to determine whether the inter-satellite transport layer includes an inter-satellite transport frame; In the case where the judgment result is yes, based on the fourth main header, read the inter-satellite frame data field, the inter-satellite data checksum field, and the inter-satellite end flag to the kernel layer to perform a legality check on the inter-satellite frame data field based on the inter-satellite data checksum field and the inter-satellite end flag; In the case of passing the legality check, read the inter-satellite cipher 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 a plaintext inter-satellite application data packet; Using the fifth main header of the plaintext inter-satellite application data packet, parse the inter-satellite application data of the plaintext inter-satellite application data packet to obtain an inter-satellite parsing result; Fill the inter-satellite parsing result into a pre-defined inter-satellite structure to obtain inter-satellite structured data.

[0014] In one implementation, the satellite operating system is configured with space-ground global control parameters, intra-satellite global control parameters, and inter-satellite global control parameters, which are used to control the opening and closing of the space-ground communication engine, the intra-satellite communication engine, and the inter-satellite communication engine.

[0015] In a second aspect, the present invention also provides a satellite terminal, including the satellite operating system for realizing satellite interconnection based on any one of the first aspect.

[0016] A satellite operating system and a satellite terminal for realizing satellite interconnection based on a unified communication protocol provided by the present invention. The kernel layer of the satellite operating system is integrated with a communication protocol stack interpretation component library, and a satellite interconnection service framework composed of a space-ground communication engine, an intra-satellite communication engine, and an inter-satellite communication engine is constructed. The space-ground communication engine includes a space-ground telecommand communication engine and a space-ground telemetry communication engine. Among them, the space-ground telecommand communication engine is used to: call the telecommand communication protocol stack interpretation component integrated in the kernel layer, and construct the telecommand structured data corresponding to the telecommand data according to the unified telecommand communication protocol. The space-ground telemetry communication engine is used to: call the telemetry communication protocol stack interpretation component integrated in the kernel layer, and construct the telemetry data byte stream corresponding to the telemetry packet data according to the 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 conversion between the intra-satellite structured data and the 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 perform conversion between the inter-satellite structured data and the inter-satellite data byte stream according to the unified inter-satellite communication protocol. The above system unifies the satellite space-ground, intra-satellite, and inter-satellite communication interconnection architectures and service frameworks, forms a complete solution from the underlying protocol of the satellite operating system to the upper-layer satellite service applications, and provides a basic platform support for reducing the satellite development cycle and constructing an efficient and reliable large-scale satellite network.

[0017] Other features and advantages of the present invention will be described in the following specification, and in part will be obvious from the specification, or will be understood by implementing the present invention. The objectives and other advantages of the present invention are achieved and obtained by the structures specifically pointed out in the specification, the claims, and the drawings.

[0018] To make the above objectives, features, and advantages of the present invention more obvious and understandable, the following specifically provides preferred embodiments and, in conjunction with the accompanying drawings, the detailed description is as follows. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0020] Figure 1 It is a schematic diagram of the structural format of each layer in a telecommand communication protocol provided by an embodiment of the present invention; Figure 2 It is a schematic diagram of the structural format of each layer in a telemetry communication protocol provided by an embodiment of the present invention; Figure 3Schematic diagram of the structural format of each layer in an inter-satellite communication protocol provided by an embodiment of the present invention; Figure 4 Data flow diagram of a satellite-ground remote control communication engine provided by an embodiment of the present invention; Figure 5 Data flow diagram of a satellite-ground telemetry communication engine provided by an embodiment of the present invention; Figure 6 Flowchart of the service data sending module of an intra-satellite communication engine provided by an embodiment of the present invention; Figure 7 Flowchart of the service data receiving module of an intra-satellite communication engine provided by an embodiment of the present invention; Figure 8 Data flow diagram of an inter-satellite communication engine provided by an embodiment of the present invention. Detailed implementation manners

[0021] 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. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the scope of protection of the present invention.

[0022] In the field of aerospace satellites, when realizing satellite communication interconnection, the traditional process usually includes the following steps: deploying an on-board operating system that provides computing kernels and basic tool service capabilities on an on-board computer, and developing satellite communication interconnection functions by the on-board application according to the customized data communication interface protocols for satellite-ground, intra-satellite, and inter-satellite devices. However, this process faces the following key challenges in practical applications and needs to be optimized to improve efficiency.

[0023] 1. High development cost of on-board applications: For each satellite, it is necessary to customize and develop dedicated on-board application software for the communication protocols specific to the devices, and the development and debugging cycle is as long as 6 - 12 months. According to statistics, the development and debugging costs of satellite device communication functions account for more than 35% of the entire on-board software development cost. The communication software cannot be reused between different models of satellites, resulting in serious problems of repeated development. In addition, the protocol adaptation layer needs to be specifically optimized for different hardware platforms, further increasing the development and verification costs.

[0024] 2. Fragmentation of communication protocols and low interconnection efficiency: Currently, there are multiple protocol standards in satellite communication, such as CCSDS (Consultative Committee for Space Data Systems), CAN (Controller Area Network), and serial ports. Different manufacturers have also made private extensions. On average, a satellite needs to support 3 - 5 different communication protocols, and the additional latency caused by protocol conversion reaches 200 - 500 ms. In actual operation, data needs to go through multiple protocol conversions to complete end - to - end transmission, resulting in low effective bandwidth utilization. This fragmented situation also leads to a long time for satellite cluster networking, seriously affecting the emergency response ability.

[0025] 3. Poor portability and reusability: The communication module of on - board application software is deeply coupled with the underlying hardware and operating system. More than 60% of the code needs to be rewritten when transplanted to a new platform. The reuse rate of communication modules between different mission satellites is less than 20%, and each mission requires re - development and verification. Even for satellites of the same model, due to differences in hardware batches, the communication software needs to be adjusted specifically. This low reusability poses a huge challenge to the rapid deployment of satellite constellations.

[0026] 4. Scalability limitations: Under the existing architecture, the number of communication connections of a single satellite is limited by the design of the operating system kernel. When the scale of the satellite cluster exceeds 50, the system performance will decline sharply. Adding a new communication protocol requires recompiling the entire system and cannot be dynamically loaded. In addition, the ground measurement and 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.

[0027] In view of the above - mentioned technical problems, the embodiments of the present invention propose a satellite operating system and a satellite terminal for realizing satellite interconnection based on a unified communication protocol, which can not only effectively solve the above problems, but also realize the plug - and - play, autonomous collaboration, and high - efficiency interconnection of satellite clusters, greatly improving the communication efficiency and system reliability of space - to - ground, intra - satellite, and inter - satellite communications.

[0028] To facilitate the understanding of this embodiment, first, a satellite operating system for realizing satellite interconnection based on a unified communication protocol disclosed in the embodiments of the present invention is introduced in detail. The satellite operating system is carried on the satellite terminal. The kernel layer of the satellite operating system is integrated with the communication protocol stack interpretation component library, and a satellite interconnection service framework composed of a space - 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 a telecommand communication protocol stack interpretation component, a telemetry communication protocol stack interpretation component, an intra - satellite communication protocol stack interpretation component, and an inter - satellite communication protocol stack interpretation component; The space-ground communication engine includes a space-ground telecommand communication engine and a space-ground telemetry communication engine. Among them, the space-ground telecommand communication engine is used to: call the telecommand communication protocol stack decoding component integrated in the kernel layer, and construct the telecommand structured data corresponding to the telecommand data according to the unified telecommand communication protocol; the space-ground telemetry communication engine is used to: call the telemetry communication protocol stack decoding component integrated in the kernel layer, and construct the telemetry data byte stream corresponding to the telemetry packet data according to the unified telemetry communication protocol. The on-board communication engine is used to: call the on-board communication protocol stack decoding component integrated in the kernel layer, and perform the conversion between the on-board structured data and the on-board data byte stream according to the unified on-board communication protocol. The inter-satellite communication engine is used to: call the inter-satellite communication protocol stack decoding component integrated in the kernel layer, and perform the conversion between the inter-satellite structured data and the inter-satellite data byte stream according to the unified inter-satellite communication protocol.

[0029] The above system unifies the space-ground, on-board, and inter-satellite communication interconnection architectures and service frameworks of the satellite, forms a complete solution from the underlying protocol of the satellite operating system to the upper-layer satellite services application, and provides a basic platform support for reducing the satellite development cycle and constructing an efficient and reliable large-scale satellite network.

[0030] For the convenience of understanding, the embodiments of the present invention provide a construction process of a satellite operating system for realizing satellite interconnection based on a unified communication protocol, including: (1) Design the unified communication protocol of the embodiments of the present invention respectively from the aspects of space-ground, on-board, and inter-satellite interconnection based on mainstream satellite communication protocols such as CCSDS, CAN bus, serial port, and laser. Among them, the space-ground communication protocol is designed based on the CCSDS international communication standard protocol; the on-board device communication protocol is designed based on the CAN bus hardware interface; the inter-satellite communication protocol is designed based on the laser communication link.

[0031] Satellite interconnection communication mainly includes space-ground communication (communication between the satellite and the ground), on-board communication (communication between on-board devices), and inter-satellite communication (communication between satellites). The embodiments of the present invention have respectively carried out systematic unified design on the communication protocols in the three aspects of space-ground, on-board, and inter-satellite, and realized the standardization of the full-link communication architecture. In terms of space-ground communication, the data interaction protocol between the satellite and different ground systems is unified; in terms of on-board communication, the internal communication standard between each single device on the satellite platform is standardized; in terms of inter-satellite communication, a standardized interconnection mechanism between satellite clusters is established.

[0032] The data transmission byte stream conventions for space-ground, intra-satellite, and inter-satellite communications are as follows: (1) In a number field of M bytes: The first byte to be transmitted is called byte 0 (B0), followed by byte 1 (B1), … until byte M-1 (BM-1). The first byte (B0) transmitted in the 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 to be transmitted is called bit 7 (b7), followed by bit 6 (b6), … until bit 0 (b0). That is, when this 8-bit number field is regarded as a binary number, the first bit (b7) transmitted is the most significant bit.

[0033] (1.1) Space-ground communication protocol design: The space-ground communication protocol format is based on the CCSDS format and conforms to the CCSDS data protocol specification.

[0034] In terms of services, the space-ground communication service data includes telecommand data sent from the ground to the satellite and telemetry data sent from the satellite to the ground. In the embodiments of the present invention, the satellite telecommand and telemetry communication protocols are uniformly designed, and the transmission standards for uplink control instructions and downlink monitoring data are respectively specified, realizing the protocol standardization of two types of core communication functions.

[0035] In one example, the telecommand communication protocol design: According to the CCSDS standard, the telecommand communication transmission includes multiple layers, which are in turn: the physical channel layer, the space-ground transmission layer, and the packaging layer. Among them, the physical channel layer uses the command link transmission unit (CLTU) for transmission; the transmission layer uses the telecommand transmission frame for transmission; the packaging layer uses the telecommand packet for transmission. See Figure 1 The schematic diagram of the structural format of each layer in a shown telecommand communication protocol: (I) The physical channel layer includes a capture sequence and a command link transmission unit. The physical channel layer mainly uses the command link transmission unit format, which consists of a capture sequence and a command link transmission unit. Among them, the capture sequence is a sequence of alternating "1" and "0", starting with "1", and the length is not less than 128 bits. It is sent before the telecommand information and is used for the satellite to capture and synchronize the ground telecommand information.

[0036] (II) The space-ground transmission layer includes a telecommand start flag, a telecommand transmission frame, and a telecommand end flag; among them, the telecommand start flag indicates the start of the telecommand data transmission; the telecommand transmission frame includes a first major header, a telecommand frame data field, and a telecommand data check field, and the telecommand frame data field includes a telecommand password area and an encrypted note number instruction telecommand packet; the telecommand end flag indicates the end of the telecommand data transmission. Specifically: The command link carries the telecommand transmission frame, which consists of a telecommand start flag, a telecommand transmission frame, and a telecommand end flag.

[0037] The remote control start flag indicates the start of remote control data transmission. It is 4 bytes, with a value of: AC1020H.

[0038] The remote control end flag indicates the end of remote control data transmission. It is 4 bytes, with a value of: BD9080H.

[0039] The remote control transmission frame adopts the CCSDS packetized remote control format and consists of a first primary header, a remote control frame data field, and a remote control data check field. Among them, the "version number" in the first primary header is set to 0; the "pass flag" is set to 1, indicating that only the frame legality check of the received remote control transmission frame is performed, and the sequence correctness check is not required; "spacecraft" represents the spacecraft identifier; the "frame length" is the total number of bytes of the remote control transmission frame minus 1; the "frame sequence" starts from 1 and accumulates in sequence. After accumulating to 0XFFFF, it continues to count from 1.

[0040] The remote control frame data field carries a complete note number instruction remote control packet, including a password area and an encrypted note number instruction remote control packet; among them, the "password area" carries the password field; the "remote control packet" carries a complete indirect and note number instruction remote control packet, including an independent remote control packet, a sequence packet, and a packaged file.

[0041] The remote control data check field performs CRC(n,n - 16) check to detect errors in the transmission frame.

[0042] (III) The packaging layer includes the second primary header of the note number instruction remote control packet and the remote control application data. Among them, the "version number" in the second primary header is set to 0; the "packet type" is set to 1, indicating a remote control packet. "Packet sequence number": If it is an independent remote control packet, it is set to 0000H; if it is a packaged file, it is set to "1XXXH", where "XXX" is the number of independent packets in the packaged file; if it is a sequence packet, it is set to the sequence number of this packet in the relevant packet sequence, ranging from 0 to FFFFH. "Packet length": It is set to the total number of bytes of the remote control application data field minus 1, ranging from 0 to 65535.

[0043] In one example, the design of the telemetry communication protocol: The whole - satellite telemetry transmission frame contains multiple levels. The main elements after decomposition are: Channel Access Data Unit (CADU), Virtual Channel Data Unit (VCDU), Multiplexing Protocol Data Unit (M - PDU), Encapsulation Protocol Data Unit (E - PDU, which is the format adopted by the data source packet). See Figure 2 The structure format schematic diagram of each layer in a shown telemetry communication protocol: (I) The Channel Access Data Unit includes a synchronization byte and a Virtual Channel Data Unit.

[0044] The physical layer data structure of the channel consists of consecutive Channel Access Data Units (CADUs). The length of a CADU is 1024 bytes, which is composed of a 4-byte synchronization word and a 1020-byte Virtual Channel Data Unit (VCDU). Among them, the synchronization word is used for frame synchronization, without coding, and is defined as 1A01101BH.

[0045] (II) The virtual channel data unit carries telemetry packet data, and the telemetry packet data includes a third primary header, a data field, and a telemetry data check field.

[0046] The virtual channel serves as a telemetry channel. The virtual channel data unit carries telemetry transmission frames, and the data of multiple telemetry packets is combined and downloaded in one telemetry transmission frame.

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

[0048] (III) The multiplexing protocol data unit is used to describe the third primary 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 packet header of the first complete telemetry packet data in the M-PDU data field, and the M-PDU data field carries the telemetry packet data.

[0049] The multiplexing protocol data unit contains the third primary header and the data field in the telemetry transmission frame.

[0050] The "version number" in the third primary header is set to 0, "spacecraft" represents the spacecraft identification, "channel identification" is filled according to the type of the carried telemetry transmission frame. 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 the individual sequential count of VCDU transmissions on each VC, and "reservation" is set to 0XAAAAAA.

[0051] Leading header pointer: It is the position of the first byte in the packet header of the first complete telemetry packet data (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, it is filled with all "1"s.

[0052] M_PDU Data Field: It carries telemetry packet data (E_PDU), with a total of 1008 bytes. The first packet and the last packet can be "incomplete packets". The tail frame fills multiple AAHs as padding codes from after the end of the telemetry packet (E_PDU) to the end of the M_PDU data field.

[0053] (IV) The packetization 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 main header, source packet data, and packet checksum.

[0054] The telemetry packet data is the packetized protocol data unit (E_PDU) formed by formatting the data generated by each on-board application process. The telemetry packet data is the basic transmission unit. The telemetry data packet mainly includes the packet main header, source packet data, and packet checksum.

[0055] The "version number" in the telemetry packet main header is set to 0; the APID is the application process identifier, used to identify the data source that generates the source packet on the spacecraft; the "packet sequence number" is a sequential counter that counts each packet generated by the application process marked with a unique application process identifier. This binary count should be continuous, with a modulus of 65535, and idle packets do not require counting. During the continuous operation of an application process, it is not allowed to reset the counter before it reaches the full count; the "packet length" is the number of bytes in the packet data field minus 1.

[0056] The source packet data carries the telemetry data collected by the entire satellite.

[0057] Packet checksum: Perform a byte-by-byte sum check on all fields in the source packet data field. The high 8 bits are the overflow part of the sum.

[0058] (1.2) In-satellite communication protocol design: The unified in-satellite communication protocol design scheme proposed in the embodiments of the present invention has a CAN bus as its underlying hardware interface. For normalization processing, to shield the differences in the underlying hardware interfaces, the communication format of the data field part is uniformly defined. When in-satellite single-device manufacturers customize single devices, they should specify the communication protocol according to this format convention.

[0059] The in-satellite unified communication protocol includes the CAN interface communication protocol and the service data communication protocol.

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

[0061] The CAN interface configuration is as follows: 1) Baud rate: 600 Kbps; 2) Technical specification: CAN2.0B; 3) Communication format: Standard frame (ID 11 bits), only transmit data frames (RTR = 0).

[0062] Communication information frame format: It includes an arbitration field, a control field, a data field, CRC, and frame end.

[0063] Table 1 is the CAN communication information frame format table

[0064] Table 2 is the identifier format table

[0065] Device type: The on-board computer device sends 0, and other single devices send 1.

[0066] Device ID: When the device type (ID10) is 0, this field is filled with the ID of the target slave; when the device type (ID10) is 1, this field is filled with the ID of the source slave. The device ID is customized according to the actual internal devices of the satellite, including single devices such as on-board computers, power supplies, and GNSS.

[0067] Frame type: (00)b: Single frame; (01)b: First frame; (10)b: Middle frame; (11)b: Last frame.

[0068] (II) The service data communication protocol is used to define the service data communication protocol format. The service data communication protocol format includes data type, length, data field, and checksum. The data type is: telecommand, command response, telemetry request / response. The length is: the length of the data field. The data field is: valid data. The checksum is: sum checksum.

[0069] Table 3 is the service data communication protocol format

[0070] Among them, "data type" represents the type of data content, including: telecommand, command response, telemetry request / response, etc., which is customized and designed by specific projects; "length" represents the length of the data field; "data field" represents valid data; "checksum" represents sum checksum, which is unsigned 8-bit accumulated byte by byte from the data type, length, and data field content, and the low 8 bits are retained.

[0071] (1.3) Inter-satellite communication protocol design: The unified inter-satellite communication protocol design scheme proposed in the embodiment of the present invention has a laser communication link as its communication link. For normalization processing and to shield the differences in the underlying hardware interfaces, the communication format of the data field part is uniformly defined. When inter-satellite laser device manufacturers customize single devices, they should specify the communication protocol according to this format convention.

[0072] According to the CCSDS standard, inter-satellite communication transmission includes 2 layers: the inter-satellite transmission layer and the application data layer. See Figure 3Schematic diagram of the structural formats of each layer in an inter-satellite communication protocol shown: (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 transmission of the inter-satellite data byte stream; the inter-satellite transport frame includes a fourth primary header, an inter-satellite frame data field, and an inter-satellite data check field. The inter-satellite frame data field includes an inter-satellite cipher area and an encrypted inter-satellite application data packet; the inter-satellite end flag indicates the end of the transmission of the inter-satellite data byte stream.

[0073] The data of the inter-satellite transport layer consists of an inter-satellite start flag, an inter-satellite transport frame, and an inter-satellite end flag.

[0074] The inter-satellite start flag indicates the start of information transmission, 4 bytes, with a value of: FD8161H.

[0075] The inter-satellite end flag indicates the end of information transmission, 4 bytes, with a value of: EF0182H.

[0076] The inter-satellite transport frame adopts the CCSDS packetization format and consists of a fourth primary header, an inter-satellite frame data field, and an inter-satellite data check field. Among them, the "version number" in the fourth primary header is set to 0; "transmitting satellite" and "receiving satellite" represent satellite IDs; the "encryption flag" is set to 1, indicating that the data packet is ciphertext data, and if it is set to 0, it indicates that the data packet is plaintext data. The "frame length" is the total number of bytes of the telecommand transport frame minus 1; the "frame sequence" starts from 1 and accumulates sequentially. After accumulating to 0XFFFF, it continues to count from 1.

[0077] The inter-satellite frame data field carries a complete inter-satellite application data packet, including an inter-satellite cipher area (optional) and an inter-satellite application data packet; among them, the "cipher area" carries the cipher field.

[0078] The inter-satellite data check field performs CRC(n,n - 16) check to detect errors in the transport frame.

[0079] (II) The application data layer includes a fifth primary header of the inter-satellite application data packet and inter-satellite application data. Among them, the "version number" in the fifth primary header is set to 0; the "packet type" is set to 1, indicating a payload data packet. The "packet length" is set to the total number of bytes of the application data field minus 1.

[0080] (2) Deeply integrate the above 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 the satellite-ground, intra-satellite, and inter-satellite communication protocols and eliminate the performance loss caused by protocol conversion.

[0081] After completing the design of the unified communication protocol for satellite - to - ground, intra - satellite, and inter - satellite connections in the first step, build these unified satellite - interconnection communication protocol stack parsing components at the kernel layer of the satellite operating system (including real - time operating system and general operating system) to implement functions such as parsing and security verification of satellite - to - ground, intra - satellite, and inter - satellite communication protocols, reduce the development costs of upper - layer satellite services applications caused by the differences in underlying hardware and communication protocols, and eliminate the performance loss caused by protocol conversion.

[0082] Developed in C language, the capabilities of data encapsulation, parsing, and security verification of the satellite - interconnection communication protocol stack are deeply integrated into the kernel layer of the satellite operating system in the form of a lib component library. When integrating, call its kernel functions through the APIs provided by the satellite operating system.

[0083] (2.1) The operating system kernel builds the satellite - to - ground communication protocol stack parsing component: The operating system kernel builds a telecommand communication protocol stack parsing component and a telemetry communication protocol stack parsing component respectively.

[0084] In one example, the telecommand communication protocol stack parsing component: Telecommand data is assembled by the ground system and sent to the satellite. The telecommand communication protocol stack parsing component at the kernel layer of the satellite operating system is responsible for parsing and verifying the protocol data and forwarding it to the upper - layer satellite services application.

[0085] The ground system sends the telecommand data packet to the on - satellite measurement and control machine through the satellite - to - ground wireless link. After receiving the data, the on - satellite measurement and control machine is used to: receive the telecommand data sent by the ground system, parse the capture sequence in the telecommand data, and when the field value of the capture sequence is correct, send the telecommand information transmission unit to the satellite - to - ground telecommand communication engine. Specifically, first parse the field value of the "capture sequence". If the field value of the "capture sequence" is correct, after passing the data security verification, send the data in the "telecommand information transmission unit" to the on - board computer through the serial port.

[0086] The remote control communication protocol stack decoding component is used for: parsing 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; in the case that the judgment result is yes, reading the remote control frame data field, the remote control data verification field, and the remote control end flag to the kernel layer based on the first main header, so as to perform a legality verification on the remote control frame data field based on the remote control data verification field and the remote control end flag; in the case of passing the legality verification, reading the remote control password area from the remote control frame data field to obtain decryption information, and using the decryption information to decrypt the encrypted bet number instruction remote control packet to obtain the plaintext bet number instruction remote control packet; using the second main header of the plaintext bet number instruction remote control packet to parse the remote control application data of the plaintext bet number instruction remote control packet to obtain a remote control parsing result, where the remote control parsing result includes a remote control instruction code, a remote control time code, remote control instruction data, and a remote control instruction data length; and filling the remote control parsing result into a predefined remote control structure to obtain remote control structured data.

[0087] Specifically: After receiving the "remote control information transmission unit" data, the remote control communication protocol stack decoding component in the satellite operating system kernel layer of the on-board computer parses the "remote control start flag". If it is judged that the data is not a "remote control transmission frame", the data packet is discarded; if it is judged that the data is a "remote control transmission frame", the first main header data in the "remote control transmission frame" is continuously read, and a legality verification is performed by judging the "version number" and the "pass flag" in the first main header; then the "frame length" field value in the first main header is read to obtain the entire data length of the "remote control transmission frame", and then according to the frame length, all the unread data in the entire frame data of the "remote control transmission frame" is read to the operating system kernel layer, and the 3 field data of the "remote control end flag", the "remote control frame data field", and the "remote control data verification field" are obtained; the legality of the frame data is judged through the "remote control end flag". If it is not legal, the frame data is discarded. Then, by calculating the CRC value of the entire frame data and comparing it with the "remote control data verification field" field value, if they are not equal, the data is not legal and the frame data is discarded.

[0088] Read the "remote control password area" data from the "remote control frame data field" to obtain decryption-related information, then decrypt the "encrypted bet number instruction remote control packet" field value to obtain the plaintext bet number instruction remote control packet, and after parsing, obtain the "second main header" and the "remote control application data"; obtain the type of the bet number instruction remote control packet (independent remote control packet, sequence packet, packaged file) from the "packet type" in the "second main header"; after obtaining the "packet length" field value, and according to the packet length, obtain the final "remote control application data", and obtain the remote control instruction code, the remote control time code, the remote control instruction data, and the remote control instruction data length, etc. of the remote control application data according to the protocol format.

[0089] Finally, define a remote control structure, which includes fields such as spacecraft identifier, remote control instruction code, remote control time code, remote control instruction data, and remote control instruction data length. Fill this remote control structure according to the above protocol parsing result, and then forward it to the upper-level satellite service application in a callback manner.

[0090] The upper-level satellite service application receives structured remote control data. Regardless of the differences in the underlying hardware and communication protocol, the format of the remote control data received by the satellite service application is fixed and unified, thus significantly reducing the development cost of the satellite service application.

[0091] In one example, the telemetry communication protocol stack decoding component: The telemetry data is assembled by the satellite operating system and sent to the ground system. The telemetry communication protocol stack decoding component in the kernel layer of the satellite operating system is responsible for assembling the telemetry packet data according to the protocol and transmitting it to the ground system through the space-ground link.

[0092] The telemetry communication protocol stack decoding component is used to: according to the telemetry communication protocol, fill the telemetry packet data sent by the upper-level satellite service system inside the satellite into a pre-defined telemetry packet structure, and sequentially fill multiple telemetry packet data into multiple M-PDU data fields in the telemetry packet structure during the filling process; among them, the telemetry packet data at the head and tail ends in the M-PDU data field is complete or incomplete telemetry packet data; assemble the telemetry packet structure and the telemetry frame data structure into a telemetry data byte stream; among them, the telemetry frame data structure includes spacecraft identifier, virtual channel identifier, number of telemetry data packets, and telemetry data packet array.

[0093] Specifically: Design a telemetry packet structure gseng_tlm_pack_t in the telemetry communication protocol stack decoding component, which includes telemetry packet type, packet number, packet count, packet data length, and packet data; then design a telemetry frame data structure gseng_tlm_data_t transmitted to the ground, which includes spacecraft identifier, virtual channel identifier, number of telemetry data packets, and telemetry data packet array.

[0094] The telemetry communication protocol stack decoding component first fills the data of these 2 structures according to the service, and then assembles the data of these 2 structures into telemetry byte stream data according to the telemetry communication protocol format in the first step, and transmits it to the ground system through the space-ground telemetry link.

[0095] Each frame of telemetry packet data is 1024 bytes. The M-PDU carrying telemetry data is 1008 bytes. If multiple telemetry packet data are sent together (i.e., in one frame), and if it 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) leading header and the E-PDU (telemetry) actual data. When the system sends one frame each time, it first checks whether there is any remaining telemetry packet data from the previous frame. If there is, the remaining data from the previous frame will be filled in the front part of the M-PDU, and then the telemetry packet data to be sent in this frame will be filled.

[0096] (2.2) The operating system kernel constructs an in-satellite communication protocol stack decoding component: In the embodiment of the present invention, the internal devices of the satellite are interconnected through the CAN bus. The in-satellite communication data is assembled by each single-board device inside the satellite (including the satellite operating system of the on-board computer, etc.) and sent to the designated target single-board device inside the satellite through the CAN bus. After receiving the data, the target single-board device parses and processes it by itself.

[0097] Specifically: For the on-board computer operating system, in the in-satellite communication protocol stack decoding component, 2 structure bodies are designed: iseng_can_send_pack_t and iseng_can_recv_pack_t. Among them, iseng_can_send_pack_t represents the structure body of the data packet sent through the CAN bus, including fields such as data type, data length, and data domain; iseng_can_recv_pack_t represents the structure body of the data packet received through the CAN bus, including fields such as data type, data length, and data domain.

[0098] When sending data, the in-satellite communication protocol stack decoding component first fills the data of the iseng_can_send_pack_t structure body, and then assembles this structure body data into byte stream data according to the in-satellite communication protocol format in the first step, and transmits it to the in-satellite target device through the CAN bus.

[0099] When the in-satellite communication protocol stack decoding component receives the communication data from the CAN bus, it fills the iseng_can_recv_pack_t structure according to the in-satellite communication protocol format in the first step, and then forwards it to the upper-layer satellite service application in a callback manner.

[0100] (2.3) The operating system kernel constructs an inter-satellite communication protocol stack decoding component: In the embodiments of the present invention, satellites are interconnected and communicate with each other through laser links. An inter-satellite communication protocol stack interpretation component is built at the kernel layer of the satellite operating system. This component is responsible for parsing / encapsulating, performing security verification on data, and forwarding it to the upper-level satellite service applications.

[0101] The inter-satellite communication protocol stack interpretation component is used to: parse the inter-satellite start flag in the inter-satellite data byte stream sent by other satellite terminals to determine whether the inter-satellite transport layer includes an inter-satellite transport frame; in the case where the judgment result is yes, read the inter-satellite frame data field, the inter-satellite data verification field, and the inter-satellite end flag to the kernel layer based on the fourth main header, so as to perform a legality verification on the inter-satellite frame data field based on the inter-satellite data verification field and the inter-satellite end flag; in the case where the legality verification is passed, read the inter-satellite password 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 main 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 an inter-satellite parsing result; fill the inter-satellite parsing result into a pre-defined inter-satellite structure to obtain inter-satellite structured data.

[0102] Specifically: After receiving the data, the inter-satellite communication protocol stack interpretation component parses the "inter-satellite start flag". If it is judged that the data is not an "inter-satellite transport frame", the data packet is discarded; if it is judged that the data is an "inter-satellite transport frame", the fourth main header in the "inter-satellite transport frame" is continuously read, and a legality verification is performed by judging the "version number" in the fourth main header; then the value of the "frame length" field in the fourth main header is read to obtain the length of the entire "transport frame" data, and according to the frame length, all the unread data in the entire frame data of the "inter-satellite transport frame" is read into the operating system kernel layer, and the 3 field data of the "inter-satellite end flag", the "inter-satellite frame data field", and the "inter-satellite data verification field" are obtained; the legality of the frame data is judged through the "inter-satellite end flag". If it is not legal, the frame data is discarded. Then, by calculating the CRC value of the entire frame data and comparing it with the value of the "inter-satellite data verification field" field, if they are not equal, the data is not legal and the frame data is discarded.

[0103] Judge whether the data is encrypted according to the "encryption flag" in the "fourth main header". If it is encrypted, read the "inter-satellite password area" data from the "inter-satellite frame data field" to obtain decryption-related information, and then decrypt the "inter-satellite application data packet" field value to obtain plaintext data; if it is not encrypted, directly read the plaintext data of the "inter-satellite application data packet" field, and after parsing, obtain the "fifth main header" and the "application data"; after reading the value of the "packet length" field, and according to the packet length, obtain the final "inter-satellite application data", and obtain the time code, specific service data, etc. of the inter-satellite application data according to the protocol format.

[0104] Finally, define a structure that includes fields such as the transmitting satellite ID, receiving satellite ID, data length, and data. Fill this structure according to the above protocol parsing results, and then forward it to the upper-level satellite service application in a callback manner.

[0105] The upper-level satellite service application receives 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 service application is fixed and unified, thus significantly reducing the research and development costs of the satellite service application.

[0106] (3) Build a satellite interconnection service framework that includes core functions such as the space-ground communication engine, intra-satellite communication engine, and inter-satellite communication engine, and provide a standardized communication interface for the upper-level satellite service application, so that the satellite service application development does not need to pay attention to the differences in underlying protocols, and reduces the communication function development cost of the satellite service application by more than 80%.

[0107] After the satellite operating system kernel integrates the satellite interconnection communication protocol stack, then build a satellite interconnection service framework with core functions such as the space-ground communication engine, intra-satellite communication engine, and inter-satellite communication engine in the satellite operating system service layer, and provide a standardized communication interface for the upper-level satellite service application, so that the satellite service application development can realize the data communication functions of satellite space-ground, intra-satellite, and inter-satellite without paying attention to the differences in underlying protocols.

[0108] (3.1) Space-ground communication engine: In the embodiment of the present invention, the space-ground communication engine in the satellite operating system mainly provides services such as receiving, interpreting, security verifying, assembling structured data of the telecommand data sent from the ground system to the satellite end and forwarding it to the upper-level satellite service application, and assembling and forwarding the telemetry data to the ground system for space-ground communication.

[0109] Among them, the space-ground communication engine includes a space-ground telecommand communication engine and a space-ground telemetry communication engine.

[0110] In one example, the space-ground telecommand communication engine: Refer to Figure 4 The data flow diagram of a space-ground telecommand communication engine as shown, including the ground system sending telecommand data; the internal satellite measurement and control machine receiving the telecommand data; the space-ground telecommand communication engine of the satellite operating system performing the following operations: receiving the telecommand data, calling the kernel telecommand communication protocol stack interpretation component to interpret the data, constructing the telecommand structured data; sending it to the satellite service application.

[0111] Specifically: The remote control data is initiated by the ground system and sent to the measurement and control machine inside the satellite through the wireless network between the satellite and the ground. After the measurement and control machine receives the remote control data and passes the data security verification, it forwards the remote control data packet to the on-board computer through the serial port. The space-ground remote control data communication engine of the on-board computer operating system is responsible for receiving and processing the remote control data. To improve reliability, the measurement and control machine sends the remote control data to the on-board computer through 2 serial ports at the same time, and the space-ground remote control communication engine removes duplicates through the frame sequence field.

[0112] The space-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, it calls the remote control communication protocol stack interpretation component in the kernel layer of the satellite operating system to interpret and perform security verification on the data. After the verification passes, it constructs structured remote control data in the form of a structure and forwards it to the upper-layer satellite service application through a callback.

[0113] To improve the stability of the serial port connection and the reliability of data reception, in the serial port communication task (thread), if a serial port communication anomaly (connection interruption) is detected, the serial port reconnection logic is started; if the connection is unsuccessful, it keeps connecting until the connection is successful.

[0114] In one example, the space-ground telemetry communication engine: Refer to Figure 5 The data flow diagram of a space-ground telemetry communication engine shown in the figure. It includes: The satellite service application sends the structured telemetry packet data to the space-ground telemetry data communication engine by calling the API. Then the space-ground telemetry communication engine calls the telemetry communication protocol stack interpretation component in the kernel layer of the operating system to translate the data and construct a telemetry data byte stream. Then it sends the telemetry data byte stream to the measurement and control machine through the serial port. Finally, the measurement and control machine forwards it to the ground system through the space-ground wireless network.

[0115] Specifically: The space-ground telemetry data communication engine starts a task (thread) responsible for sending telemetry data to the measurement and control machine through the serial port. To improve the stability of the serial port connection and the reliability of data reception, in the serial port communication task (thread), if a serial port communication anomaly (connection interruption) is detected, the serial port reconnection logic is started; if the connection is unsuccessful, it keeps connecting until the connection is successful.

[0116] (3.2) Intra-satellite communication engine In the embodiment of the present invention, the intra-satellite communication engine in the satellite operating system mainly provides intra-satellite communication services such as data sending / receiving, interpretation, security verification, structured data assembly, and forwarding to the upper-layer satellite service application between satellite internal devices based on the CAN bus.

[0117] (I) Data sending module, refer to Figure 6Flowchart of the service data sending module of the in-satellite communication engine: The service data sending module of the in-satellite communication engine provides an API interface. The satellite operation application calls the API to transfer structured data to the in-satellite communication engine of the operating system. After receiving the structured data, the engine calls the in-satellite communication protocol stack translation component in the kernel layer of the operating system to translate the structured data into byte stream data, and then sends it to the target device via the CAN bus based on the CAN communication protocol. After receiving the data, the target device immediately returns the response acknowledgment data.

[0118] (II) Data receiving module, see Figure 7 Flowchart of the service data receiving module of the in-satellite communication engine: When a single device inside the satellite sends data via the CAN bus, the satellite operating system will trigger an interrupt. Then, the data receiving module of the in-satellite communication engine of the satellite operating system will respond to the interrupt, read the CAN data from the interrupt FIFO, and then call the in-satellite communication protocol stack translation component in the kernel layer of the operating system to interpret the data and construct it into structured data. Then, the structured data is forwarded to the satellite operation application in a callback manner. After the satellite operation application finishes processing, it immediately returns the response acknowledgment data.

[0119] (3.3) Inter-satellite communication engine: In the embodiment of the present invention, the inter-satellite communication engine in the satellite operating system mainly provides inter-satellite communication services such as data sending / receiving, translation, security verification, structured data assembly, and forwarding to the upper-layer satellite operation application based on the laser link. See Figure 8 Data flowchart of an inter-satellite communication engine, including: When sending inter-satellite data, the inter-satellite communication engine service provides an API interface. The satellite operation application calls the API to transfer structured data to the inter-satellite communication engine of the operating system. After receiving the structured data, the engine calls the inter-satellite communication protocol stack translation component in the kernel layer of the operating system to translate the structured data into byte stream data, and then sends it to the inter-satellite laser device via the CAN bus based on the CAN communication protocol. Then, the laser device forwards it to the target satellite via the laser link.

[0120] When the inter-satellite laser device receives data from other satellites, after the laser device completes data verification, it sends the data to the on-board computer via the CAN bus. After the satellite operating system receives the inter-satellite data, it calls the inter-satellite communication protocol stack translation component in the kernel layer of the operating system to interpret the byte stream data into structured data, and then forwards the structured data to the satellite operation application for processing in a callback manner.

[0121] (IV) Adopting a modular design to achieve dynamic loading of communication protocols and services, supporting OTA (Over-The-Air) in-orbit updates and dynamic expansion, and meeting the communication and networking requirements of large-scale satellite constellations.

[0122] In the third step, the space-ground communication engine, the intra-satellite communication engine, and the inter-satellite communication engine in the satellite interconnection service framework are implemented using modular design and service dynamic loading technology.

[0123] The satellite operating system service layer defines three global control parameters, namely the space-ground global control parameter, the intra-satellite global control parameter, and the inter-satellite global control parameter, which are used to control the startup and shutdown of the space-ground communication engine, the intra-satellite communication engine, and the inter-satellite communication engine, and to achieve modular and service dynamic loading functions.

[0124] During the on-orbit operation of the satellite, if the three satellite interconnection services, namely the space-ground communication engine, the intra-satellite communication engine, and the inter-satellite communication engine, need to be updated and upgraded, the three services are updated, upgraded, and dynamically expanded through the OTA on-orbit update function between the space and the ground, so as to meet the communication and networking requirements of large-scale satellite constellations.

[0125] The satellite operating system for realizing satellite interconnection based on a unified communication protocol proposed in the embodiment of the present invention brings the following remarkable advantages in the satellite field through protocol standardization, operating system kernel-level integration, and service framework dynamic design: 1. Greatly reduce the development cost of satellite service applications: In the traditional solution, satellite service applications need to customize and develop communication modules for different hardware and protocols, with a long development cycle (about 6 - 12 months) and a cost ratio exceeding 35%. In the embodiment of the present invention, the space-ground, intra-satellite, and inter-satellite communication protocol stacks are uniformly integrated into the operating system kernel, and a standardized interface is provided for the upper layer, so that satellite service applications do not need to pay attention to the differences in underlying protocols, the development cost of communication functions is reduced by more than 80%, and cross-satellite model reuse is supported, completely solving the problem of repeated development.

[0126] 2. Improve communication efficiency and reliability: Due to protocol fragmentation (needing to support 3 - 5 protocols) and multiple conversions in traditional satellite communication, the effective bandwidth utilization rate is low, and the time delay is as high as 200 - 500 ms. In the embodiment of the present invention, through unified protocol design and kernel-level integration, the protocol conversion overhead is eliminated, and the end-to-end time delay is reduced to within 50 ms, significantly improving the emergency response ability of satellite clusters.

[0127] 3. Enhance system scalability and dynamicity: The performance of the traditional architecture is severely degraded when the scale of the satellite cluster exceeds 50 due to the limitation of the kernel design. The embodiment of the present invention adopts a modular service framework, supports the dynamic loading of communication engines and OTA on-orbit updates, and can expand new protocols or adjust configurations without recompiling the system, meeting the efficient networking requirements of large-scale constellations.

[0128] 4. Simplify operation and maintenance and enhance security: Through unified communication protocols and structured data interfaces, the ground measurement and control system does not need to maintain independent configurations for each satellite, and the management complexity is reduced from exponential growth to linear growth. In addition, the kernel-level protocol stack integrates encryption verification mechanisms (such as CRC and decryption of the password area) to ensure the security of data transmission and avoid security risks caused by vulnerabilities in the protocol adaptation layer in traditional solutions.

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

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

[0131] Based on the foregoing embodiments, the embodiments of the present invention provide a satellite terminal, including the satellite operating system that realizes satellite interconnection based on the unified communication protocol described above.

[0132] For the satellite terminal provided by the embodiments of the present invention, the implementation principle and the technical effects produced are the same as those of the foregoing system embodiments. For a brief description, for the parts not mentioned in the satellite terminal embodiments, reference may be made to the corresponding content in the foregoing system embodiments.

[0133] Finally, it should be noted that the above embodiments are only specific implementation manners of the present invention, used to illustrate the technical solutions of the present invention, rather than limiting them. The protection scope of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that any person skilled in the art within the technical scope disclosed by the present invention can still modify the technical solutions recorded in the foregoing embodiments, or can easily think of changes, or perform equivalent replacements for some of the technical features; and these modifications, changes, or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims

1. A satellite operating system for realizing satellite interconnection based on a unified communication protocol, characterized in that, The satellite operating system is carried on the satellite side. The kernel layer of the satellite operating system is integrated with the communication protocol stack interpretation component library, and a satellite interconnection service framework composed of a space-ground communication engine, an intra-satellite communication engine, and an inter-satellite communication engine is constructed; The space-ground communication engine includes a space-ground telecommand communication engine and a space-ground telemetry communication engine; among them, the space-ground telecommand communication engine is used for: calling the telecommand communication protocol stack interpretation component integrated in the kernel layer, and constructing the telecommand structured data corresponding to the telecommand data according to the unified telecommand communication protocol; the space-ground telemetry communication engine is used for: calling the telemetry communication protocol stack interpretation component integrated in the kernel layer, and constructing the telemetry data byte stream corresponding to the telemetry packet data according to the unified telemetry communication protocol; The intra-satellite communication engine is used for: calling the intra-satellite communication protocol stack interpretation component integrated in the kernel layer, and converting the intra-satellite structured data and the intra-satellite data byte stream according to the unified intra-satellite communication protocol; The inter-satellite communication engine is used for: calling the inter-satellite communication protocol stack interpretation component integrated in the kernel layer, and converting the inter-satellite structured data and the inter-satellite data byte stream according to the unified inter-satellite communication protocol.

2. The satellite operating system for realizing satellite interconnection based on a unified communication protocol according to claim 1, characterized in that, The telecommand communication protocol includes: a physical channel layer, a space-ground transport layer, and a packaging layer; The physical channel layer includes a capture sequence and a telecommand information transmission unit; The space-ground transport layer includes a telecommand start flag, a telecommand transport frame, and a telecommand end flag; among them, the telecommand start flag indicates the start of the telecommand data transmission; the telecommand transport frame includes a first main header, a telecommand frame data field, and a telecommand data check field, and the telecommand frame data field includes a telecommand password area and an encrypted bet number instruction telecommand packet; the telecommand end flag indicates the end of the telecommand data transmission; The packaging layer includes a second main header of the bet number instruction telecommand packet and telecommand application data.

3. The satellite operating system for realizing satellite interconnection based on a unified communication protocol according to claim 2, characterized in that, The telemetry and command machine on the satellite side is used for: receiving the telecommand data sent by the ground system, parsing the capture sequence in the telecommand data, and when the field value of the capture sequence is correct, sending the telecommand information transmission unit to the space-ground telecommand communication engine; The space-ground telecommand communication engine calls the telecommand communication protocol stack interpretation component, and the telecommand communication protocol stack interpretation component is specifically used for: Parsing the telecommand start flag in the telecommand information transmission unit to determine whether the telecommand information transmission unit includes the telecommand transport frame; When the judgment result is yes, reading the telecommand frame data field, the telecommand data check field, and the telecommand end flag to the kernel layer based on the first main header, so as to perform a legality check on the telecommand frame data field based on the telecommand data check field and the telecommand end flag; When passing the legality check, reading the telecommand password area from the telecommand frame data field to obtain decryption information, and using the decryption information to decrypt the encrypted bet number instruction telecommand packet to obtain the plaintext bet number instruction telecommand packet; Using the second leading header of the bet count instruction remote control packet of the plaintext to parse the remote control application data of the bet count instruction remote control packet of the plaintext to obtain a remote control parsing result, the remote control parsing result including a remote control instruction code, a remote control time code, remote control instruction data, and a remote control instruction data length; Filling the remote control parsing result into a predefined remote control structure to obtain remote control structured data.

4. The satellite operating system for realizing 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, the telemetry packet data including a third leading header, a data field, and a telemetry data check 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 including a leading header pointer and an M-PDU data field, the leading header pointer being the position of the first byte in the packet header of the first complete telemetry packet data in the M-PDU data field, and the M-PDU data field carrying 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 including a source packet leading header, source packet data, and a packet check; 5. The satellite operating system for realizing 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, filling the telemetry packet data sent by the upper-level satellite service system inside the satellite into a predefined telemetry packet structure, and sequentially filling multiple pieces of the telemetry packet data into multiple M-PDU data fields in the telemetry packet structure during the filling process; wherein, the telemetry packet data at the head and tail ends in the M-PDU data field is complete or incomplete telemetry packet data; Assembling the telemetry packet structure and the telemetry frame data structure into the telemetry data byte stream; wherein, the telemetry frame data structure includes a spacecraft identifier, a virtual channel identifier, the number of telemetry data packets, and an array of telemetry data packets.

6. The satellite operating system for realizing satellite interconnection based on a unified communication protocol according to claim 1, characterized in that, The in-satellite communication protocol includes: a CAN interface communication protocol and a service data communication protocol; The CAN interface communication protocol is used to define the CAN interface configuration and the communication information frame format, the communication information frame format including an arbitration field, a control field, a data field, a CRC, and a frame end; The service data communication protocol is used to define the service data communication protocol format, the service data communication protocol format including a data type, a length, a data field, and a check, the data type being: a remote control instruction, an instruction response, a telemetry request / response, the length being: the length of the data field, the data field being: valid data, and the check being: a sum check; 7. The satellite operating system for realizing 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 transmission layer includes an inter-satellite start flag, an inter-satellite transmission frame, and an inter-satellite end flag. The inter-satellite start flag indicates the start of the transmission of the inter-satellite data byte stream; the inter-satellite transmission frame includes a fourth main header, an inter-satellite frame data field, and an inter-satellite data check field. The inter-satellite frame data field includes an inter-satellite cipher area and an encrypted inter-satellite application data packet; the inter-satellite end flag indicates the end of the transmission of the inter-satellite data byte stream; The application data layer includes a fifth main header of the inter-satellite application data packet and inter-satellite application data.

8. The satellite operating system for realizing satellite interconnection based on the unified communication protocol according to claim 7, characterized in that, The inter-satellite communication protocol stack interpretation component is specifically used for: Parsing the inter-satellite start flag in the inter-satellite data byte stream sent by other satellite terminals to determine whether the inter-satellite transmission layer includes the inter-satellite transmission frame; In the case where the judgment result is yes, reading the inter-satellite frame data field, the inter-satellite data check field, and the inter-satellite end flag to the kernel layer based on the fourth main header to perform a legality check on the inter-satellite frame data field based on the inter-satellite data check field and the inter-satellite end flag; In the case of passing the legality check, reading the inter-satellite cipher area from the inter-satellite frame data field to obtain decryption information, and using the decryption information to decrypt the encrypted inter-satellite application data packet to obtain the plaintext inter-satellite application data packet; Using the fifth main 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 an inter-satellite parsing result; Filling the inter-satellite parsing result into a pre-defined inter-satellite structure to obtain inter-satellite structured data.

9. The satellite operating system for realizing satellite interconnection based on the unified communication protocol according to claim 1, characterized in that, The satellite operating system is configured with space-ground global control parameters, in-satellite global control parameters, and inter-satellite global control parameters for controlling the opening and closing of the space-ground communication engine, the in-satellite communication engine, and the inter-satellite communication engine.

10. A satellite terminal, characterized in that, It includes a satellite operating system for realizing satellite interconnection based on a unified communication protocol according to any one of claims 1-9.

Images