A spaceflight measurement and control network resource scheduling system, method, device and medium

Abstract

The application discloses a spaceflight measurement and control network resource scheduling system, method, equipment and medium, adopts a layered architecture, includes a basic support layer, a data layer, a service layer, an application layer and an information interaction layer, and communicates between layers through standardized interfaces. The service layer adopts a micro-service architecture, deploys information interaction and interface analysis, task classification and distribution, resource scheduling and conflict resolution, plan generation and release, running monitoring and dynamic adjustment modules; the scheduling core service runs independently as a micro-service, uses a cache to maintain the global resource arc segment state, and provides a standard API interface. Based on a container orchestration platform, health checks, fault self-healing and large-scale node batch deployment are realized, and through a production confirmation+consumption confirmation double mechanism, reliable data transmission is ensured. Business service, data platform, resource pooling and operation and maintenance automation are realized, thousand-level task concurrency and micro-service plug-and-play extension are supported, and second-level fault recovery and cross-environment rapid deployment capabilities are possessed.

Description

Technical Field

[0001] This invention relates to the field of aerospace telemetry and control technology, and in particular to an aerospace telemetry and control network resource scheduling system, method, equipment and medium. Background Technology

[0002] The ground-based telemetry and control network, serving as a hub connecting spacecraft and ground systems, undertakes core functions such as orbit determination, command uploading, data reception, and mission scheduling.

[0003] Currently, mainstream aerospace telemetry, tracking, and command (TT&C) network resource scheduling systems generally adopt an "pre-allocation + centralized management and control" operation mode, which means that resource usage plans are manually or semi-automatically formulated before the mission cycle, lacking the ability to respond quickly to sudden missions and dynamic resource changes.

[0004] Existing resource scheduling systems generally suffer from the following shortcomings: 1. High system coupling: Traditional software is mostly monolithic architecture, with tightly coupled functional modules. Adding or modifying a certain type of business requires overall compilation and deployment, which makes maintenance difficult and has poor scalability.

[0005] 2. Weak concurrent processing capability: It cannot effectively support the parallel scheduling and dynamic resource preemption of multiple types of tasks (such as regular tasks, emergency tasks, and test tasks).

[0006] 3. Low resource utilization: Static resource allocation results in both idle and overloaded computing and storage resources, making it difficult to achieve dynamic allocation on demand.

[0007] 4. Slow fault recovery: Single point of failure can easily cause system interruption, and there is a lack of automatic disaster recovery and rapid recovery mechanisms.

[0008] 5. Difficulty in algorithm expansion: Core logic such as resource scheduling strategies and conflict resolution algorithms are embedded in the main program, making it difficult to evolve and iterate independently. Summary of the Invention

[0009] To address the aforementioned issues, this invention provides an aerospace telemetry and control network resource scheduling system, method, equipment, and medium that can adapt to the parallel scheduling of multiple types of services under different scenarios.

[0010] This invention provides a space telemetry, tracking, and command (TT&C) network resource scheduling system, the specific technical solution of which is as follows: The system adopts a layered architecture, with each layer communicating through standardized interfaces. The layered architecture includes: The basic support layer is built on a private cloud platform and integrates computing servers, distributed storage, network devices, and security components. The data layer consists of a high-speed cache, a relational database, and a big data platform, which are used for real-time data caching, structured business data storage, and log and / or state data mining and analysis, respectively. The service layer includes service units that execute system functional logic. These service units include business processing services, general common services, and scheduling core services. The scheduling core services include a scheduler service, which provides standard API interfaces for resource status query, pre-locking, formal locking, and release. The service layer is equipped with an information interaction and interface parsing module, a task classification and allocation module, a resource scheduling and conflict resolution module, a plan generation and release module, and an operation monitoring and dynamic adjustment module. These modules work together to complete the resource scheduling task of the aerospace telemetry and control network. The application layer, targeting user terminals and management terminals, provides web portals and desktop integrated applications. The information interaction layer is used for internal communication between services via WebService and message middleware, as well as for data interaction with external systems via HTTP / HTTPS and FTP protocols.

[0011] Furthermore, the information interaction and interface parsing module receives resource usage requests from external systems, transmits them via a general protocol and performs protocol verification, then the interface parser performs format verification and metadata extraction, writes the task information into the database, and notifies the task allocation module through a message queue. The task classification and allocation module distributes tasks to the corresponding planner service through a message queue according to the task type; The resource scheduling and conflict resolution module enables each planner to query and lock resource status based on track forecast data, resource usage rules and scheduling strategies, call the API interface provided by the scheduler to complete resource allocation and conflict judgment, and generate a preliminary scheduling plan. The plan generation and release module transforms the final scheduling results into standardized interface products, which are then sent to the aerospace telemetry and control network equipment control system via message queues or HTTP interfaces to drive the execution of actual telemetry and control or data transmission tasks. The operation monitoring and dynamic adjustment module collects the status of aerospace telemetry and control network equipment, mission execution progress and resource usage in real time, and completes data closed-loop feedback through a highly reliable data channel.

[0012] Furthermore, each service in the service layer is encapsulated in the form of a container engine image and deployed in a container group of the container orchestration platform, with the service proxy and the entry gateway uniformly exposing the interface. The system also includes a container orchestration module for anomaly detection and fault self-healing; The anomaly detection includes: Process-level checks: Periodically check whether the container engine is running; Business-level checks: Inject a custom liveness probe script into the container to simulate heartbeat requests and determine whether the service is responding normally; The self-healing mechanism for the fault is as follows: When an anomaly is detected, the container orchestration platform automatically restarts the container group on the healthy node and automatically redirects traffic through the service broker.

[0013] Furthermore, the container orchestration module also includes: Each ground station is assigned a unique number; Create namespaces in the container orchestration platform and configure domain names for each site; Define a deployment list using templates for one-click batch deployment.

[0014] Furthermore, the system also includes a highly reliable data channel module, which is equipped with a production confirmation mechanism and a consumption confirmation mechanism. The production confirmation mechanism is as follows: The task generator first writes the data to be sent into a cache, then pushes it to the message queue, and waits for the message broker to return an acknowledgment; if no acknowledgment is received within a timeout, it retryes sending until successful. The consumption confirmation mechanism is as follows: After a consumer pulls a message from the message queue, it performs business processing. If successful, it manually sends an acknowledgment message; if it fails, it either pulls the message again or retrieves it from the cache for consumption.

[0015] This invention also provides a method for scheduling resources in an aerospace telemetry and control network. Based on the aforementioned aerospace telemetry and control network resource scheduling system, the method includes: The system receives resource usage requests from external systems, transmits them via a common protocol and performs protocol verification, then the interface parser performs format verification and metadata extraction, writes the task information into the database, and notifies the task allocation module via a message queue. The task allocation module distributes tasks to the corresponding planner service through a message queue according to the task type. Each planner, based on track forecast data, resource usage rules and scheduling strategies, calls the API interface provided by the scheduler to query and lock resource status, complete resource allocation and conflict judgment, and generate a preliminary scheduling plan. The final scheduling results are transformed into standardized interface products and sent to the aerospace telemetry and control network equipment control system through message queues or HTTP interfaces to drive the execution of actual telemetry and control or data transmission tasks. It collects real-time data on the status of aerospace telemetry and control network equipment, mission execution progress, and resource usage, and achieves closed-loop data feedback through a highly reliable data channel.

[0016] Furthermore, the general protocol is the FTP protocol; The message queue is Kafka and / or RabbitMQ.

[0017] Furthermore, the standardized interface product is a planning document in XML and / or JSON format.

[0018] The present invention also provides a space telemetry and control network resource scheduling device, the space telemetry and control network resource scheduling device comprising: a memory, a processor, and a space telemetry and control network resource scheduling program stored in the memory and executable on the processor, wherein when the space telemetry and control network resource scheduling program is executed by the processor, the steps of the space telemetry and control network resource scheduling method described above are implemented.

[0019] The present invention also provides a computer storage medium storing a space telemetry and control network resource scheduling program, which, when executed by a processor, implements the steps of the space telemetry and control network resource scheduling method described above.

[0020] The beneficial effects of this invention are as follows: 1. This invention addresses the complex aerospace telemetry and control network environment by designing a generalized scheduling platform architecture of "four-dimensional and five-layer". Each layer communicates with each other through standardized interfaces. Through microservice decomposition and communication with standardized interfaces, business services are made available, data is platformized, resources are pooled, and operations and maintenance are automated. The service layer adopts a "containerization + microservice" architecture, which decomposes the system functions into multiple fine-grained, independently deployable, and loosely coupled service units, fundamentally solving the problems of high coupling and difficulty in expansion of traditional scheduling systems.

[0021] 2. The core scheduling service of this invention runs as an independent microservice, uses a high-speed cache to maintain the global resource arc state, and provides standard API interfaces for resource state query, pre-locking, formal locking and release. All operations are transaction-controlled, realizing centralized management and atomic operations of resource state, preventing concurrent conflicts. At the same time, based on microservices and message middleware, asynchronous decoupling is achieved, enabling concurrent processing of thousands of tasks, meeting the parallel scheduling requirements of multi-satellite, multi-location, and multi-type tasks, and effectively improving the resource scheduling efficiency of aerospace telemetry and control network.

[0022] 3. The container orchestration module of this invention is implemented based on a container orchestration platform. It achieves anomaly detection and fault self-healing through a health check mechanism, including process-level and business-level checks. When an anomaly is detected, the container group is automatically restarted on healthy nodes, and traffic is automatically redirected via a service proxy, achieving fault recovery within seconds and overcoming the slow fault recovery of traditional systems. This invention also assigns a unique number to each ground station through the container orchestration module, creates a namespace and configures a domain name in the container orchestration platform, and achieves one-click batch deployment through template-defined deployment lists. The configuration center centrally stores runtime configurations, and the ground station agent dynamically retrieves the configuration via the domain name to complete initialization upon startup, achieving unified orchestration and automated deployment of large-scale ground station agent nodes and improving engineering deployment efficiency. 4. This invention employs a dual mechanism of production confirmation and consumption confirmation through a highly reliable data channel module. The task generator first writes the data to a high-speed cache and then pushes it to the message queue to wait for confirmation. After the consumer successfully processes the data, it manually sends a confirmation message. If the data fails, it recovers the consumption from the high-speed cache, ensuring zero loss of core scheduling instructions and improving the reliability of scheduling data transmission. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the overall process architecture of the scheduling system of the present invention.

[0024] Figure 2 This is a schematic diagram of the core scheduling process of the present invention.

[0025] Figure 3 This is a schematic diagram of the large-scale resource management service orchestration architecture of the present invention.

[0026] Figure 4 This is a schematic diagram of the high-reliability data channel working mechanism of the present invention. Detailed Implementation

[0027] The technical solutions in the embodiments of the present invention are clearly and completely described in the following description. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0028] In the description of the embodiments of the present invention, it should be noted that the indicated orientation or positional relationship is based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the product of the invention is conventionally placed during use, or the orientation or positional relationship in which those skilled in the art conventionally understand it during use. This is only for the convenience of describing the present invention and simplifying the description, and is not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation of the present invention. Furthermore, the terms "first" and "second" are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] In the description of the embodiments of the present invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set" and "connection" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0030] Example 1 Embodiment 1 of the present invention discloses a space telemetry, tracking and command network resource scheduling system, as detailed below: The system adopts a layered architecture, with each layer communicating through standardized interfaces. The layered architecture includes: The basic support layer is built on a private cloud platform, integrating computing servers, distributed storage, network devices and security components. It uses virtualization and containerization technologies to achieve resource pooling management and supports on-demand allocation and elastic scaling. The data layer consists of a high-speed cache (Redis), a relational database (RDBMS), and a big data platform, which are used for real-time data caching, structured business data storage, and log and / or state data mining and analysis, respectively.

[0031] The service layer adopts a "containerization + microservices" architecture, which breaks down the system functions into multiple fine-grained, independently deployable, loosely coupled service units. These service units include business processing services, general common services, and scheduling core services. Specifically, the business processing services include: demand planning services, resource scheduling services, resource management services, health management services, performance evaluation services, testing and simulation services, and user-end services; The common services include: file access service, message queue service, job scheduling service, data service, and configuration center service. The core scheduling service includes a scheduler service, which provides standard API interfaces for resource status query, pre-locking, formal locking and releasing. The scheduler service runs as an independent microservice, uses a cache to maintain the global resource arc state, and provides standard API interfaces for resource status query, pre-locking, formal locking and release. All operations are transaction-controlled. The service layer is equipped with an information interaction and interface parsing module, a task classification and allocation module, a resource scheduling and conflict resolution module, a plan generation and release module, and an operation monitoring and dynamic adjustment module. These modules work together to complete the resource scheduling task of the aerospace telemetry and control network.

[0032] In a preferred embodiment, each microservice in the service layer is encapsulated in the form of a Docker image and deployed in a container group (Pod) of a container orchestration platform, with the service proxy (Service) and ingress gateway (Ingress) exposing interfaces uniformly. The system also includes a container orchestration module. In this embodiment, the container orchestration module is implemented based on Kubernetes and uses a health check mechanism to achieve anomaly detection and fault self-healing. The anomaly detection includes: Process-level checks: Periodically check whether the container engine is running; Business-level checks: Inject a custom liveness probe script into the container to simulate heartbeat requests and determine whether the service is responding normally; The self-healing mechanism for the fault is as follows: When an anomaly is detected, the container orchestration platform automatically restarts the container group on the healthy node and automatically redirects traffic through the service broker.

[0033] As a preferred embodiment, such as Figure 3 As shown, the container orchestration module also includes one-click batch deployment for dynamic deployment requirements of ground station agent nodes: Each ground station is assigned a unique number; Create namespaces in a container orchestration platform (such as Kubernetes) and configure domain names for each site; Define a deployment list using Helm templates for one-click batch deployment.

[0034] In a preferred embodiment, the container orchestration module further includes configuration management for the dynamic deployment requirements of ground station agent nodes; specifically as follows: The container orchestration module creates namespaces, configures domain names, and deploys Pods (ground station agent containers). The configuration center in the service layer stores runtime configurations such as IP address, port, and authentication key for each station. Ground station agent (container application within a Pod) is a client program deployed on a ground station. It acts as an interaction proxy between the system and external devices. Upon startup, it discovers the configuration center via the domain name, sends a request to the configuration center, dynamically pulls the configuration of the local station, and completes the initialization.

[0035] The application layer, targeting user terminals and management terminals, provides a web portal with a B / S architecture and a desktop integrated application with a C / S architecture, supporting role-customized interfaces, multi-terminal isomorphism, dynamic plugin loading, and human-computer interaction control. Specifically, the web application can be developed using the Vue or React framework, supports multi-role access control, and dynamically loads plugins into the interface. The desktop application can be built on Electron or WPF, adopts a plug-in architecture, and different user roles load different functional modules. It supports visual monitoring of task flow, real-time tracking of execution status, and abnormal alarm pop-up prompts.

[0036] The information interaction layer is used for internal system communication between services via WebService and message middleware (such as Kafka / RabbitMQ), and for external systems to exchange data via HTTP / HTTPS and FTP protocols. Key external interfaces are deployed on bare metal servers to circumvent cloud platform multicast restrictions.

[0037] like Figure 1 and Figure 2 As shown in this embodiment, the information interaction and interface parsing module receives resource usage requests from external systems, transmits them via a general protocol and performs protocol verification, then the interface parser performs format verification and metadata extraction, writes the task information into the database, and notifies the task allocation module through a message queue. The task classification and allocation module distributes tasks to the corresponding planner service through a message queue according to the task type; The resource scheduling and conflict resolution module enables each planner to query and lock resource status based on track forecast data, resource usage rules and scheduling strategies, call the API interface provided by the scheduler to complete resource allocation and conflict judgment, and generate a preliminary scheduling plan. The plan generation and release module transforms the final scheduling results into standardized interface products, which are then sent to the aerospace telemetry and control network equipment control system via message queues or HTTP interfaces to drive the execution of actual telemetry and control or data transmission tasks. The operation monitoring and dynamic adjustment module collects the status of aerospace telemetry and control network equipment, mission execution progress and resource usage in real time, and completes data closed-loop feedback through a highly reliable data channel, supporting the insertion of temporary tasks, resource preemption and plan changes.

[0038] In this embodiment, the system also includes a high-reliability data channel module, which is equipped with a production confirmation mechanism and a consumption confirmation mechanism. like Figure 4 As shown, the production confirmation mechanism is as follows: The task generator first writes the data to be sent to a Redis cache, then pushes it to a Kafka message queue, and waits for the message broker to return an acknowledgment. If no acknowledgment is received within a timeout period, the sending is retried until successful. The consumption confirmation mechanism is as follows: After a consumer pulls a message from the Kafka message queue, it performs business processing. If successful, it manually sends an acknowledgment message; if it fails, it either pulls the message again or retrieves it from the Redis cache.

[0039] Example 2 Embodiment 2 of the present invention discloses a method for scheduling resources in an aerospace telemetry and control network based on Embodiment 1 above, such as... Figure 1 and Figure 2 As shown, the specific steps are as follows: The system receives resource usage requests from external systems, transmits them via the FTP protocol and performs protocol verification. The interface parser then performs format verification and metadata extraction, writes the task information into a relational database, and notifies the task allocation module via a message queue. The task allocation module distributes tasks to the corresponding planner service through a message queue based on the task type; the task types include regular tasks, emergency tasks, and test tasks; the message queue is Kafka and / or RabbitMQ. Each planner, based on track forecast data, resource usage rules, and scheduling strategies, calls the RESTful API interface provided by the scheduler; the scheduler service queries the global resource arc status in the cache to perform resource conflict detection; based on the resource locking results returned by the scheduler, the planner completes resource allocation and conflict judgment, and generates a preliminary scheduling plan. The final scheduling results are converted into standardized plan files in XML or JSON format and sent to the aerospace telemetry and control network equipment control system through message queues or HTTP interfaces to drive the execution of actual telemetry, control or data transmission tasks. The system collects real-time data on the status of aerospace telemetry and control network equipment, mission execution progress, and resource usage, and feeds this data back to the system through a highly reliable data channel, supporting the insertion of temporary missions, resource preemption, and plan changes.

[0040] like Figure 4 As shown, the working mechanism of the highly reliable data channel includes: Production confirmation mechanism: The task generator first writes the data to be sent to the Redis cache, then pushes it to the Kafka message queue, and waits for the Kafka Broker to return confirmation; if no confirmation is received after a timeout, it retryes sending until successful; Consumption confirmation mechanism: After the consumer pulls a message from the Kafka message queue, it performs business processing. If successful, it manually sends an ACK confirmation message. If the processing fails, it pulls the message again or reads data from the Redis cache for recovery consumption. Through the two-way confirmation of the production confirmation mechanism and the consumption confirmation mechanism, zero loss of core scheduling instructions is ensured.

[0041] Example 3 Embodiment 3 of the present invention discloses a space tracking and control network resource scheduling device. The device can be a user equipment (UE) such as a mobile phone, smartphone, laptop computer, digital broadcast receiver, personal digital assistant (PDA), tablet computer (PAD), handheld device, vehicle-mounted device, wearable device, computing device, or other processing device connected to a wireless modem, or mobile station (MS), used to execute space tracking and control network resource scheduling methods. The device may be referred to as a user terminal, portable terminal, desktop terminal, etc.

[0042] Typically, the device includes: at least one processor, a memory, and a space tracking and control network resource scheduling program stored in the memory and executable on the processor, the space tracking and control network resource scheduling program being configured to implement the steps of the space tracking and control network resource scheduling method as described in Example 1.

[0043] The processor may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor can be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). The processor may also include a main processor and coprocessors. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. The processor may also include an AI (Artificial Intelligence) processor, which handles computational operations related to the aerospace telemetry and control network resource scheduling program, enabling the aerospace telemetry and control network resource scheduling method to learn autonomously and improve efficiency and accuracy.

[0044] The memory may include one or more computer-readable storage media, which may be non-transitory. The memory may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory are used to store at least one instruction, which is executed by a processor to implement the space telemetry and control network resource scheduling method described in Embodiment 1.

[0045] In some embodiments, the terminal may also optionally include a communication interface and at least one peripheral device. The processor, memory, and communication interface can be connected via a bus or signal lines. Each peripheral device can be connected to the communication interface via a bus, signal lines, or a circuit board. Specifically, the peripheral device includes at least one of a radio frequency circuit, a display screen, and a power supply.

[0046] The communication interface can be used to connect at least one I / O (Input / Output) related peripheral device to the processor and memory. The communication interface is used via the peripheral device to receive movement trajectories and other data uploaded by the user from multiple mobile terminals. In some embodiments, the processor, memory, and communication interface are integrated on the same chip or circuit board; in other embodiments, any one or two of the processor, memory, and communication interface can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0047] Radio frequency (RF) circuits are used to receive and transmit RF signals, also known as electromagnetic signals. RF circuits communicate with communication networks and other communication devices via electromagnetic signals, thereby acquiring the movement trajectories and other data of multiple mobile terminals. RF circuits convert electrical signals into electromagnetic signals for transmission, or convert received electromagnetic signals back into electrical signals. Optionally, RF circuits include: antenna systems, RF transceivers, one or more amplifiers, tuners, oscillators, digital signal processors, codec chipsets, user identity module cards, etc. RF circuits can communicate with other terminals through at least one wireless communication protocol. These wireless communication protocols include, but are not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit may also include circuitry related to NFC (Near Field Communication), which is not limited in this embodiment.

[0048] The display screen is used to display the UI (User Interface). This UI can include graphics, text, icons, videos, and any combination thereof. When the display screen is a touch screen, it also has the ability to collect touch signals on or above the surface of the display. These touch signals can be input as control signals to a processor for processing. In this case, the display screen can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, the display screen can be a single screen, the front panel of the electronic device; in other embodiments, there can be at least two screens, respectively disposed on different surfaces of the electronic device or in a folded design; in still other embodiments, the display screen can be a flexible screen, disposed on a curved or folded surface of the electronic device. Furthermore, the display screen can be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. The display screen can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0049] A power supply is used to power the various components in an electronic device. The power supply can be alternating current (AC), direct current (DC), a disposable battery, or a rechargeable battery. When the power supply includes a rechargeable battery, the rechargeable battery can support wired or wireless charging. The rechargeable battery can also be used to support fast charging technology.

[0050] Example 4 Embodiment 4 of the present invention discloses a computer storage medium, which is a readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the aerospace telemetry and control network resource scheduling method of Embodiment 1.

[0051] The readable storage medium can specifically be a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, or any other readable storage medium capable of storing program code.

[0052] This invention is not limited to the specific embodiments described above. The invention extends to any new feature or combination disclosed in this specification, as well as any new method or process step or combination disclosed herein.

Claims

1. A space telemetry, tracking, and command (TT&C) network resource scheduling system, characterized in that, A layered architecture is adopted, with each layer communicating through standardized interfaces. The layered architecture includes: The basic support layer is built on a private cloud platform and integrates computing servers, distributed storage, network devices, and security components. The data layer consists of a high-speed cache, a relational database, and a big data platform, which are used for real-time data caching, structured business data storage, and log and / or state data mining and analysis, respectively. The service layer includes service units that execute system functional logic. These service units include business processing services, general common services, and scheduling core services. The scheduling core services include a scheduler service, which provides standard API interfaces for resource status query, pre-locking, formal locking, and release. The service layer is equipped with an information interaction and interface parsing module, a task classification and allocation module, a resource scheduling and conflict resolution module, a plan generation and release module, and an operation monitoring and dynamic adjustment module. These modules work together to complete the resource scheduling task of the aerospace telemetry and control network. The application layer, targeting user terminals and management terminals, provides web portals and desktop integrated applications; The information interaction layer is used for internal communication between services via WebService and message middleware, as well as for data interaction with external systems via HTTP / HTTPS and FTP protocols.

2. The aerospace telemetry and control network resource scheduling system according to claim 1, characterized in that, The information interaction and interface parsing module receives resource usage requests from external systems. After transmission via a general protocol and protocol verification, the interface parser performs format verification and metadata extraction, writes task information into the database, and notifies the task allocation module via a message queue. The task classification and allocation module distributes tasks to the corresponding planner service through a message queue according to the task type; The resource scheduling and conflict resolution module enables each planner to query and lock resource status based on track forecast data, resource usage rules and scheduling strategies, call the API interface provided by the scheduler to complete resource allocation and conflict judgment, and generate a preliminary scheduling plan. The plan generation and release module transforms the final scheduling results into standardized interface products, which are then sent to the aerospace telemetry and control network equipment control system via message queues or HTTP interfaces to drive the execution of actual telemetry and control or data transmission tasks. The operation monitoring and dynamic adjustment module collects the status of aerospace telemetry and control network equipment, mission execution progress and resource usage in real time, and completes data closed-loop feedback through a highly reliable data channel.

3. The aerospace telemetry and control network resource scheduling system according to claim 1, characterized in that, Each service in the service layer is encapsulated in the form of a container engine image and deployed in a container group of the container orchestration platform. The service proxy and the entry gateway expose the interface in a unified manner. The system also includes a container orchestration module for anomaly detection and fault self-healing; The anomaly detection includes: Process-level checks: Periodically check whether the container engine is running; Business-level checks: Inject a custom liveness probe script into the container to simulate heartbeat requests and determine whether the service is responding normally; The self-healing mechanism for the fault is as follows: When an anomaly is detected, the container orchestration platform automatically restarts the container group on the healthy node and automatically redirects traffic through the service broker.

4. The aerospace telemetry and control network resource scheduling system according to claim 3, characterized in that, The container orchestration module also includes: Each ground station is assigned a unique number; Create namespaces in the container orchestration platform and configure domain names for each site; Define a deployment list using templates for one-click batch deployment.

5. The aerospace telemetry and control network resource scheduling system according to claim 1, characterized in that, The system also includes a highly reliable data channel module, which is equipped with a production confirmation mechanism and a consumption confirmation mechanism. The production confirmation mechanism is as follows: The task generator first writes the data to be sent into a cache, then pushes it to the message queue, and waits for the message broker to return an acknowledgment; if no acknowledgment is received within a timeout, it retryes sending until successful. The consumption confirmation mechanism is as follows: After a consumer pulls a message from the message queue, it performs business processing. If successful, it manually sends an acknowledgment message; if it fails, it either pulls the message again or retrieves it from the cache for consumption.

6. A method for scheduling resources in an aerospace telemetry and control network, characterized in that, Based on the aerospace telemetry and control network resource scheduling system according to any one of claims 1-5, the method includes: The system receives resource usage requests from external systems, transmits them via a common protocol and performs protocol verification, then the interface parser performs format verification and metadata extraction, writes the task information into the database, and notifies the task allocation module via a message queue. The task allocation module distributes tasks to the corresponding planner service through a message queue according to the task type. Each planner, based on track forecast data, resource usage rules and scheduling strategies, calls the API interface provided by the scheduler to query and lock resource status, complete resource allocation and conflict judgment, and generate a preliminary scheduling plan. The final scheduling results are transformed into standardized interface products and sent to the aerospace telemetry and control network equipment control system through message queues or HTTP interfaces to drive the execution of actual telemetry and control or data transmission tasks. It collects real-time data on the status of aerospace telemetry and control network equipment, mission execution progress, and resource usage, and achieves closed-loop data feedback through a highly reliable data channel.

7. The aerospace telemetry and control network resource scheduling method according to claim 6, characterized in that, The common protocol is the FTP protocol; The message queue is Kafka and / or RabbitMQ.

8. The aerospace telemetry and control network resource scheduling method according to claim 6, characterized in that, The standardized interface product is a planning document in XML and / or JSON format.

9. A space telemetry, tracking, and command (TT&C) network resource scheduling device, characterized in that, The aerospace telemetry and control network resource scheduling equipment includes: a memory, a processor, and an aerospace telemetry and control network resource scheduling program stored in the memory and executable on the processor. When the aerospace telemetry and control network resource scheduling program is executed by the processor, it implements the steps of the aerospace telemetry and control network resource scheduling method according to any one of claims 1-8.

10. A computer storage medium, characterized in that, The storage medium stores a space telemetry and control network resource scheduling program, which, when executed by a processor, implements the steps of the space telemetry and control network resource scheduling method according to any one of claims 1-8.

Images