A spaceflight TT&C equipment data acquisition scheduling method and system based on task chain arrangement

Abstract

The application discloses a kind of based on task chain arrangement's aerospace TT&C equipment data acquisition scheduling method and system, comprising: constructing scheduling configuration center, unified management analysis rule, stage generation rule and scheduling strategy library;Receive and analyze equipment work plan file, generate ordered time node set, and then generate work stage set;Match scheduling strategy for each work stage;Construct task chain state machine model, promote work stage to state node with complete life cycle (not activated, running, complete, interrupt), run state machine and implement the rule trigger control of acquisition instruction.This method externalizes rules through scheduling configuration center, decouples rules from execution logic, and only needs to modify XML configuration when adding new device types, without code changes. The adaptation cycle is shortened from development and testing deployment to configuration verification, and the configuration is auditable and version-manageable.

Description

Technical Field

[0001] This invention relates to the field of aerospace telemetry, tracking, and command (TT&C) technology, and in particular to a data acquisition and scheduling method and system for aerospace TT&C equipment based on mission chain orchestration. Background Technology

[0002] Currently, in aerospace telemetry, tracking, and command (TT&C) systems, ground-based TT&C stations deploy more than ten types of sub-units. During the execution of aerospace TT&C missions, real-time data acquisition is required for the operational status, link status, and mission execution of each sub-unit. A typical TT&C mission includes multiple execution phases such as mission preparation, startup, tracking, remote control, uplink control, data transmission, and termination. Different phases involve different combinations of sub-units, and the same sub-unit may need to collect different types of data at different phases. For example, during the mission preparation phase, the monitoring server focuses on collecting the power-on self-test status of each sub-unit, while during the mission phase, server performance data acquisition is added. During the startup phase, the antenna collects position and servo status data, while during the tracking phase, it needs to switch to collecting angular error and pointing angle data. In addition, some sub-units (such as monitoring servers, time-frequency sub-units, intelligent PDUs, and matrix switches) need to operate continuously throughout the entire mission cycle, while others (such as tracking baseband, data transmission baseband, and power amplifier sub-units) only operate during specific phases.

[0003] The existing data acquisition and scheduling methods have the following main shortcomings: (1) Fixed periodic data collection method. By setting a fixed time interval, each extension unit is polled and data is collected. It is impossible to dynamically adjust the collection strategy according to the task stage. The data density is insufficient in the critical stage and resources are wasted in the idle stage. All extension units adopt a uniform collection cycle, which cannot meet the differentiated needs.

[0004] (2) Manual configuration of data collection method. The data collection tasks and start and end times of each extension are manually configured by the operation and maintenance personnel. In complex scenarios with multiple stations and multiple task types, the workload is large and error is easy to make. It is difficult to guarantee the consistency and replicability of the configuration. When the task plan changes, manual intervention is required again. It is impossible to dynamically adjust the data collection strategy according to the real-time status of the extension.

[0005] (3) Simple time-triggered acquisition method. The acquisition task is triggered according to the preset time node, which realizes basic automation, but still has the following defects: First, there is a lack of unified abstraction and modeling of the complete task stage, and the relationship, nesting relationship and parallel relationship between nodes are difficult to express and utilize; Second, the acquisition tasks of each sub-machine are configured and executed independently, and it is impossible to coordinate and arrange multiple sub-machines under a unified scheduling framework; Third, the acquisition content is fixed in the triggering rules, and it is impossible to dynamically control the start and stop of the acquisition command according to the key operating status reported by the sub-machine in real time, which leads to invalid data being acquired when the preset preconditions are not met, occupying storage and transmission resources; Fourth, the scheduling logic is tightly coupled with the device type, and the scheduling execution code needs to be modified when adding a new device type or a new format work plan, resulting in poor scalability.

[0006] Therefore, there is an urgent need for a data acquisition scheduling method that can support multi-stage task chain orchestration, multi-device collaborative scheduling, dynamic adjustment of acquisition instructions, and has good applicability to various equipment types. Based on existing technologies, the following problems need to be solved: (1) There is a lack of a unified task stage model, which cannot express the nesting, parallelism, and subordinate relationships between stages; (2) There is a lack of a multi-device collaborative scheduling mechanism, and the acquisition tasks of each device are isolated from each other; (3) The acquisition instructions are statically fixed, and it is impossible to dynamically control the start and stop of acquisition based on the key states such as lock / unlock reported by the device in real time, resulting in invalid data acquisition; (4) The scheduling logic is tightly coupled with the device type, and the code needs to be modified when adding a new device type, resulting in poor scalability. Summary of the Invention

[0007] The purpose of this invention is to provide a data acquisition and scheduling method and system for aerospace telemetry and control equipment based on task chain orchestration, which can solve the problems of lack of unified task phase model, inability to achieve multi-unit collaborative scheduling, static solidification of acquisition commands, and poor system scalability.

[0008] The technical solution adopted in this invention is as follows: A data acquisition and scheduling method for aerospace telemetry and control equipment based on task chain orchestration includes the following steps: Step S1: Construct a scheduling configuration center, which is used to uniformly define and manage parsing rules, stage generation rules, and scheduling strategy library for different types of devices; Step S2: Receive work plan files for different types of equipment; Step S3: Parse the device work plan file based on the parsing rules to generate an ordered set of time nodes; Step S4: Generate a set of working stages according to the stage generation rules; Step S5: Match a corresponding scheduling strategy for each work stage based on the scheduling strategy library; Step S6: Construct a task chain state machine model, elevating each work stage to a dynamic state node with a complete lifecycle and migration capabilities; Step S7: Run the task chain state machine and implement rule-triggered control for the acquisition command; The rule-triggered control is specifically as follows: During task execution, each sub-machine pushes key operating status data to the rule evaluation engine in real time. The rule evaluation engine performs condition judgment based on preset trigger rules. When the condition expression is met, the execution of the relevant acquisition instruction is triggered. When the condition is no longer met, the execution of the corresponding acquisition instruction is stopped. The rule-triggered control does not change the state transition path of the task chain state machine, but only controls whether a specific acquisition instruction is executed within the current working phase. The parsing rules include field mapping rules, time format conversion rules, and node verification rules. The field mapping rules are used to map heterogeneous fields in work plans of different devices to unified standard time node names. The time format conversion rules are used to convert time expressions in different formats into a unified time format. The node verification rules are used to verify the integrity of time nodes and the validity of time logic. The stage generation rules are used to define the combination relationship between time nodes to generate work stages. They adopt interval-based generation rules, which generate work stages by defining the correspondence between start time nodes and end time nodes. They support the coexistence of multiple rules, rule priority configuration, and stage nesting relationship definition. The scheduling strategy library is used to define the scheduling behavior of the acquisition modules deployed on each extension under different working stages. It includes the binding relationship between stage name and execution mode, and scheduling action list. The scheduling list contains multiple scheduling actions. The task chain state machine model defines lifecycle attributes for each state node, including at least inactive, running, completed, and interrupted states, and establishes state transition relationships between state nodes, which are driven by time-triggered conditions and / or state-triggered conditions.

[0009] The scheduling action includes the following characteristics: Each scheduling action specifies the target extension and the acquisition module deployed on it, and includes at least one acquisition instruction, which is used to instruct the acquisition module to perform the corresponding type of data acquisition; Each scheduling action includes a lifecycle attribute, which includes task-level and stage-level attributes. Once a task-level action is first activated, it continues to run until the task ends, and is not rescheduled when switching stages. A stage-level action is activated when entering a stage and released when leaving a stage. For the task-level action, it further includes an instruction mode attribute, which includes an append mode and a replacement mode, used to update the acquisition instructions when switching stages; the append mode adds instructions based on the current instruction set, and the replacement mode replaces the current instruction set with a new instruction set.

[0010] The execution modes include parallel execution mode, serial execution mode, and conditional execution mode; the parallel execution mode issues all scheduling actions simultaneously; the serial execution mode issues actions sequentially in a predefined order, waiting for the previous action to complete before issuing the next action; the conditional execution mode first evaluates a preset precondition expression, and issues the scheduling action only when the condition is met; the rule expression based on the conditional execution mode is constructed based on at least one of the following: device operating status, signal quality parameters, or task execution status.

[0011] Among the lifecycle attributes of the state node: the inactive state indicates that the state node has been created but has not yet met the activation conditions, and the corresponding scheduling action has not been executed; the running state indicates that the activation conditions of the state node have been met, and the scheduling action is being executed according to the binding strategy; the completed state indicates that all the scheduling actions corresponding to the state node have been executed, and it can trigger the migration to the next state node; the interrupted state indicates that the state node was terminated in advance during the execution process because the preset interruption conditions were met.

[0012] In the state transition relationship of the state nodes: the time triggering condition includes driving state transition when the system time reaches the end time of the phase corresponding to the current state node, and / or driving state transition when the system time reaches the start time of the phase of the next state node; the state triggering condition includes generating a completion event to drive state transition when the current state node or sub-state node enters the completion state.

[0013] The task chain state machine model supports at least one of the following execution control capabilities: multi-state parallel execution, allowing multiple state nodes to be in the running state simultaneously; nested state structure, allowing a parent state node to contain multiple child state nodes, with the lifecycle of the parent state node covering all child state nodes; state reentrancy, allowing a state node that has entered the completed state to be reactivated when certain conditions are met; and state transition control, allowing the transition between state nodes to be not limited to a preset linear order, and to jump to any legal state node in the task chain according to trigger conditions.

[0014] In the rule-triggered control: the default execution of the collection command is unaffected; if no trigger rule is configured for a certain collection command, the collection command will be executed according to the stage strategy as usual; all collected data is directly sent to the downstream data center, and only key trigger status signals are reported to the rule evaluation engine to form a control closed loop; when all scheduling actions of a status node are completed or the preset completion conditions are met, the status node enters the completion state, releases the stage-level actions corresponding to the status node, the task-level actions continue to run, and are driven to migrate to the next status node according to the state transition relationship, until the last status node of the task chain is completed.

[0015] The scheduling configuration center decouples rule configuration from scheduling execution logic at the design level. When adding a new equipment type, only the rule configuration needs to be modified, without changing the core code of the task scheduling executor. The equipment work plan file is automatically generated by the aerospace telemetry and control system according to the mission plan. The files generated by different equipment types and station types differ in data format, field naming, and time expression. The equipment work plan file contains mission identifier, mission type, mission priority, names and corresponding times of multiple key time nodes, as well as equipment mutual exclusion relationships and inter-stage cooling gap constraint information.

[0016] A space telemetry, tracking, and command (TT&C) data acquisition and scheduling system based on a task chain state machine includes: The scheduling configuration center is used to uniformly define and manage parsing rules, stage generation rules, and scheduling strategy libraries for different device types. The parsing module is used to receive the equipment work plan file, parse the equipment work plan file based on the parsing rules, and generate an ordered set of time nodes; A stage generation module is used to generate a set of working stages according to the stage generation rules. The strategy matching module is used to match a corresponding scheduling strategy for each work stage based on the scheduling strategy library; The state machine building module is used to build task chain state machine models, elevating each work stage into a dynamic state node with a complete lifecycle and migration capabilities; A task scheduler executor is used to run the task chain state machine and implement rule-triggered control for collecting instructions; The rule evaluation engine is used to receive key operational status data pushed in real time by each extension unit, and to make condition judgments based on preset trigger rules. When the condition expression is met, the relevant collection command is triggered to start execution; when the condition is no longer met, the corresponding collection command is triggered to stop execution. The parsing rules include field mapping rules, time format conversion rules, and node verification rules. The stage generation rules are used to define the combination relationship between time nodes to generate work stages. They adopt interval-based generation rules and support multiple rules coexisting, rule priority configuration, and stage nesting relationship definition. The scheduling strategy library is used to define the scheduling behavior of the acquisition modules deployed on each sub-machine under different work stages, including the binding relationship between stage name and execution mode, and scheduling action list. The task chain state machine model defines life cycle attributes for each state node, including at least inactive state, running state, completed state, and interrupted state, and establishes state transition relationships between state nodes.

[0017] The task scheduler executor is also used for: When the triggering condition is met, the target state node that needs to be activated is determined, and the state node is switched from the inactive state to the running state. After a state node is activated, the scheduling policy bound to that state node is read, and the scheduling actions within it are traversed one by one. For each scheduled action, check the lifecycle attribute: if it is a task-level action and the corresponding acquisition module is already running, skip the activation operation; if it is a task-level action but the action has not yet been activated, perform the first activation; if it is a stage-level action, perform the activation operation. If the execution mode of the scheduling action is conditional execution, the preset precondition expression is evaluated first, and the collection command is issued only when the condition is met. Once all scheduled actions of a state node have been executed or the preset completion conditions have been met, the state node is switched to the completed state, the stage-level actions corresponding to the state node are released, the task-level actions continue to run, and the state transition relationship drives the transition to the next state node.

[0018] This invention achieves automated scheduling and multi-machine collaborative execution of data acquisition tasks by constructing a rule-driven scheduling configuration center, a task chain state machine model, and a configurable real-time rule triggering mechanism. Furthermore, by externalizing parsing rules, stage-generated rules, and scheduling strategies through the scheduling configuration center, rules and execution logic are decoupled. Adding a new device type only requires adding or modifying the XML configuration; the scheduler executor requires no code changes, shortening the adaptation cycle from the software engineering cycle of development, testing, and deployment to the operation and maintenance cycle of configuration verification. Moreover, because rule configurations are stored and managed in structured data form, the auditability, version management, and replicable deployment capabilities of the configuration are significantly superior to code-level adaptation methods.

[0019] Furthermore, a unified model of the task chain state machine is adopted, elevating each work phase to a state node with a complete lifecycle (inactive, running, completed, interrupted) and constructing a state machine model. This supports complex execution semantics such as nesting, parallelism, reentrancy, and jumps, solving the problems of lacking a unified task phase model and fragmented scheduling logic in existing technologies. The scheduling method based on the state machine model also facilitates the tracing, replay, and anomaly analysis of the task execution process.

[0020] Furthermore, multi-sub-unit collaborative scheduling and dynamic adjustment of acquisition instructions are implemented. Under the same scheduling framework, acquisition instructions are uniformly issued to the acquisition modules of 11 types of sub-units. Task-level and stage-level actions are distinguished by lifecycle attributes to avoid invalid rescheduling of task-level modules during stage switching. Flexible adjustment of acquisition content during stage switching is achieved through instruction append / replacement mechanism.

[0021] This invention uses real-time rule-triggered control to start and stop data acquisition, avoiding invalid data. Through configurable trigger rules, it dynamically controls the start and stop of specific acquisition commands based on key status signals reported by the extension unit in real time (such as antenna lock / unlock, carrier lock / unlock, etc.), ensuring that valid data is acquired only when preset preconditions are met. For example, elevation angle, azimuth angle, and AGC voltage acquired when the antenna is not locked have no engineering significance. The rule-triggered mechanism ensures that these data are only acquired after the antenna locks and stop when it is unlocked, avoiding the storage and transmission overhead of invalid data. If no rules are configured, the default scheduling is not interfered with, combining flexibility and ease of use. Attached Figure Description

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

[0023] Figure 1 This is a system framework diagram of the present invention; Figure 2 This is a schematic diagram of the task chain state machine described in this invention; Figure 3 This is a flowchart of the data acquisition and scheduling process described in this invention; Figure 4 This is the real-time trigger control diagram described in this invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] like Figure 1 , 2 As shown in Figures 3 and 4, the present invention includes the following steps: Step S1: Construct a scheduling configuration center. This center is used to uniformly define and manage parsing rules, stage generation rules, and scheduling strategy libraries for different types of equipment. The scheduling configuration center decouples rule configuration from scheduling execution logic at the design level. When adding a new equipment type, only the rule configuration needs to be modified, without changing the core code of the task scheduling executor. The equipment work plan file is automatically generated by the aerospace telemetry and control system according to the mission plan. The files generated by different equipment types and station types differ in data format, field naming, and time expression. The equipment work plan file contains mission identifier, mission type, mission priority, names and corresponding times of multiple key time nodes, as well as equipment mutual exclusion relationships and inter-stage cooling gap constraint information (e.g., after the remote control stage ends, at least 10 seconds must be waited before data transmission can begin).

[0026] Step S2: Receive work plan files for different types of equipment; the equipment work plan files are automatically generated by the aerospace telemetry and control system according to the mission plan. Files generated by different equipment types and station types differ in data format, field naming, and time expression. The files contain information such as mission identifier, mission type (e.g., telemetry and tracking, data transmission reception, telemetry monitoring), mission priority (e.g., ordinary, important, urgent), names and corresponding times of multiple key time nodes, as well as constraints such as equipment mutual exclusion relationships and inter-stage cooling gaps.

[0027] Step S3: Parse the equipment work plan file based on the parsing rules to generate an ordered set of time nodes; wherein, the parsing rules include field mapping rules, time format conversion rules, and node verification rules; the field mapping rules are used to map heterogeneous fields in different equipment work plans to a unified standard time node name; the time format conversion rules are used to convert time expressions in different formats into a unified time format; the node verification rules are used to verify the integrity of time nodes and the validity of time logic; the field mapping rules map heterogeneous fields appearing in different types of equipment work plan files to a unified standard time node name; the time format conversion rules support the conversion of multiple time formats, including "yyyyMMddHHmmss" and "yyyy-MM-dd HH:mm:ss", to a unified time format; the node verification rules include verification of the integrity of time nodes and verification of the validity of the sequential logical relationship between time nodes.

[0028] In practical applications, firstly, heterogeneous fields are mapped to unified standard time node names according to field mapping rules. Secondly, time expressions in different formats are converted to a unified time format according to time format conversion rules. Thirdly, time nodes are checked for integrity and logical validity according to node validation rules. Finally, the validated time nodes are sorted in ascending order of time to generate an ordered set of time nodes.

[0029] Step S4: Generate a set of working stages according to the stage generation rules; the stage generation rules are used to define the combination relationship between time nodes to generate working stages, adopting interval-based generation rules, and generating working stages by defining the correspondence between start time nodes and end time nodes, supporting multiple rules coexisting, rule priority configuration, and stage nesting relationship definition; in the stage generation rules, when there is time overlap or inclusion relationship between multiple working stages, the parallel relationship or subordinate relationship between working stages is determined according to rule priority and hierarchical relationship; the stage generation rules also support stage constraint definition, the stage constraints include minimum stage duration constraint, maximum stage duration constraint, and inter-stage cooling gap constraint. The scheduling strategy library is used to define the scheduling behavior of the acquisition modules deployed on each sub-machine under different working stages, including the binding relationship between stage name and execution mode, and scheduling action list.

[0030] In practical use, the ordered set of time nodes is matched one by one with each interval generation rule. Each rule specifies a pair of start and end time nodes and a corresponding work stage name. After a successful match, the time values ​​of the pair of nodes are used as boundaries to generate a work stage. Each work stage includes at least a stage name, a start time, and an end time. When multiple work stages generated by multiple rules have overlapping or inclusive relationships, the parallel or subordinate relationship between the stages is determined according to the rule priority and hierarchical relationship. For example, if the time interval of the "tracking stage" completely includes the time interval of the "remote control stage," and the rule defines the "tracking stage" as the parent stage of the "remote control stage," then the two are determined to have a nested (subordinate) relationship; if the time intervals of the "remote control stage" and the "uplink control stage" overlap, and the rule does not define the hierarchical relationship between the two, then the two are determined to have a parallel relationship.

[0031] Step S5: Match a corresponding scheduling strategy for each work stage based on the scheduling strategy library. The scheduling strategy library is used to define the scheduling behavior of the acquisition modules deployed on each sub-unit under different work stages, including the binding relationship between stage name and execution mode, and scheduling action list. The scheduling list contains multiple scheduling actions. The execution modes include parallel execution (issuing all scheduling actions simultaneously, suitable for scenarios where there is no sequential dependency between actions), serial execution (issuing actions in a predefined order, waiting for the previous action to be completed before issuing the subsequent action), and conditional execution (first evaluating a preset precondition expression, and issuing the scheduling action only when the condition is met). Among them, the rule expression based on the conditional execution mode is constructed based on at least one of the device operating status, signal quality parameters, or task execution status.

[0032] Each scheduling action targets the target extension and the data acquisition module deployed on it, and contains at least one acquisition instruction indicating what type of data acquisition the acquisition module should perform. The same acquisition module can be issued different acquisition instructions at different stages and under different conditions, enabling the scheduler to dynamically determine "what data" each extension (such as monitoring server, antenna, time and frequency extension, intelligent PDU, matrix switch, etc.) should acquire, rather than simply "activating" or "deactivating" an acquisition module.

[0033] The scheduling action includes the following characteristics: Each scheduling action specifies the target extension and the acquisition module deployed on it (one acquisition module is deployed on each extension in a 1:1 ratio as a software agent), and includes at least one acquisition instruction, which is used to instruct the acquisition module to perform the corresponding type of data acquisition; Each scheduling action includes a lifecycle attribute, which includes task-level and stage-level attributes. Once a task-level action is first activated, it continues to run until the task ends, and is not rescheduled when switching stages. A stage-level action is activated when entering a stage and released when leaving a stage. For the aforementioned task-level actions, a further instruction mode attribute is included. This attribute comprises an append mode and a replacement mode, used to update the acquisition instructions during phase switching without reactivating the module. The append mode adds new instructions based on the current instruction set, while the replacement mode replaces the current instruction set with a new one. For example, the antenna acquisition module receives a "log acquisition" instruction during the startup phase and updates it to "real-time status acquisition" through the replacement mode when entering the tracking phase, allowing the module to continue running without readjustment.

[0034] Scheduling strategies are matched based on a scheduling strategy library. A corresponding execution mode and at least one scheduling action are matched for each work stage.

[0035] Step S6: Construct a task chain state machine model, elevating each work stage to a dynamic state node with a complete lifecycle and migration capabilities; the task chain state machine model defines lifecycle attributes for each state node, including at least inactive state, running state, completed state, and interrupted state, and establishes state migration relationships between state nodes, which are driven by time-triggered conditions and / or state-triggered conditions.

[0036] Among the lifecycle attributes of the state node: the inactive state indicates that the state node has been created but has not yet met the activation conditions, and the corresponding scheduling action has not been executed; the running state indicates that the activation conditions of the state node have been met, and the scheduling action is being executed according to the binding strategy; the completed state indicates that all the scheduling actions corresponding to the state node have been executed, and it can trigger the migration to the next state node; the interrupted state indicates that the state node was terminated in advance during the execution process because the preset interruption conditions were met.

[0037] In the state transition relationship of the state nodes: the time triggering condition includes driving state transition when the system time reaches the end time of the phase corresponding to the current state node, and / or driving state transition when the system time reaches the start time of the phase of the next state node; the state triggering condition includes generating a completion event to drive state transition when the current state node or sub-state node enters the completion state.

[0038] The task chain state machine model supports at least one of the following execution control capabilities: multi-state parallel execution, allowing multiple state nodes to be in the running state simultaneously; nested state structure, allowing a parent state node to contain multiple child state nodes, with the lifecycle of the parent state node covering all child state nodes; state reentrancy, allowing a state node that has entered the completed state to be reactivated when certain conditions are met; and state transition control, allowing the transition between state nodes to be not limited to a preset linear order, and to jump to any legal state node in the task chain according to trigger conditions.

[0039] In practical use, semantic enhancement processing is applied to the work stages, elevating each work stage from a "static description with time intervals and scheduling strategies" to a "dynamic state node with a complete lifecycle and migration capabilities." Specifically, lifecycle attributes are defined for each state node, including at least four states: Idle – The state node has been created but the activation conditions have not yet been met, and the corresponding scheduling action has not been executed; Active – The activation conditions of the state node have been met, and the scheduling action is being executed according to the binding strategy; Done – All scheduling actions corresponding to the state node have been executed, and migration to the next state node can be triggered; Aborted – The state node is prematurely terminated during execution due to the fulfillment of preset interruption conditions.

[0040] A task chain state machine model is constructed based on all state nodes, establishing state transition relationships between them. These state transitions are driven by two triggering conditions: (a) time-triggered conditions – state transitions are triggered when the system time reaches the end time of the current state node's phase or the start time of the next state node's phase; (b) state-triggered conditions – state transitions are triggered when the current state node or its sub-state node enters the completed state, generating a completion event. The constructed task chain state machine model supports at least one of the following execution control capabilities: multi-state parallel execution (allowing multiple state nodes to be in the running state simultaneously, such as the remote control phase and the uplink control phase being executed in parallel), nested state structure (allowing a parent state node to contain multiple sub-state nodes, with the parent state node's lifecycle covering all sub-state nodes), state reentry (allowing a state node that has entered the completed state to be reactivated when specific conditions are met, such as re-entering the tracking phase for signal reacquisition after carrier lock-up), and state jump control (allowing transitions between state nodes not limited to a preset linear order, allowing jumps to any legal state node in the task chain based on triggering conditions).

[0041] Step S7: Run the task chain state machine and implement rule-triggered control for the acquisition instructions; the rule-triggered control specifically involves: during task execution, each sub-machine pushes key operating status data to the rule evaluation engine in real time. The rule evaluation engine performs condition judgment based on preset trigger rules. When the condition expression is met, the execution of the relevant acquisition instructions is triggered; when the condition is no longer met, the execution of the corresponding acquisition instructions is stopped. The rule-triggered control does not change the state transition path of the task chain state machine, but only controls whether a specific acquisition instruction is executed within the currently running working phase. In the rule-triggered control: the default execution of the collection command is unaffected; if no trigger rule is configured for a certain collection command, the collection command will be executed according to the stage strategy as usual; all collected data is directly sent to the downstream data center, and only key trigger status signals are reported to the rule evaluation engine to form a control closed loop; when all scheduling actions of a status node are completed or the preset completion conditions are met, the status node enters the completion state, releases the stage-level actions corresponding to the status node, the task-level actions continue to run, and are driven to migrate to the next status node according to the state transition relationship, until the last status node of the task chain is completed.

[0042] A space telemetry, tracking, and command (TT&C) data acquisition and scheduling system based on a task chain state machine includes: The scheduling configuration center is used to uniformly define and manage parsing rules, stage generation rules, and scheduling strategy libraries for different device types. The parsing module is used to receive the equipment work plan file, parse the equipment work plan file based on the parsing rules, and generate an ordered set of time nodes; A stage generation module is used to generate a set of working stages according to the stage generation rules. The strategy matching module is used to match a corresponding scheduling strategy for each work stage based on the scheduling strategy library; The state machine building module is used to build task chain state machine models, elevating each work stage into a dynamic state node with a complete lifecycle and migration capabilities; The task scheduler executor is used to run the task chain state machine and implement rule-triggered control for collecting instructions; the task scheduler executor is also used for: When the triggering condition is met, the target state node that needs to be activated is determined, and the state node is switched from the inactive state to the running state. After a state node is activated, the scheduling policy bound to that state node is read, and the scheduling actions within it are traversed one by one. For each scheduled action, check the lifecycle attribute: if it is a task-level action and the corresponding acquisition module is already running, skip the activation operation; if it is a task-level action but the action has not yet been activated, perform the first activation; if it is a stage-level action, perform the activation operation. If the execution mode of the scheduling action is conditional execution, the preset precondition expression is evaluated first, and the collection command is issued only when the condition is met. Once all scheduled actions of a state node have been executed or the preset completion conditions have been met, the state node is switched to the completed state, the stage-level actions corresponding to the state node are released, the task-level actions continue to run, and the state transition relationship drives the transition to the next state node.

[0043] The rule evaluation engine is used to receive key operational status data pushed in real time by each extension unit, and to make condition judgments based on preset trigger rules. When the condition expression is met, the relevant collection command is triggered to start execution; when the condition is no longer met, the corresponding collection command is triggered to stop execution. The parsing rules include field mapping rules, time format conversion rules, and node verification rules. The stage generation rules are used to define the combination relationship between time nodes to generate work stages. They adopt interval-based generation rules and support multiple rules coexisting, rule priority configuration, and stage nesting relationship definition. The scheduling strategy library is used to define the scheduling behavior of the acquisition modules deployed on each sub-machine under different work stages, including the binding relationship between stage name and execution mode, and scheduling action list. The task chain state machine model defines life cycle attributes for each state node, including at least inactive state, running state, completed state, and interrupted state, and establishes state transition relationships between state nodes.

[0044] The task scheduler executor is the runtime engine of the state machine model, responsible for continuously monitoring time-triggered and state-triggered conditions, driving state transitions, and issuing scheduling actions. When a certain triggering condition is met, the task scheduler executor determines the target state node to be activated and switches the state node from an inactive state to a running state. After the state node is activated, the task scheduler executor reads the scheduling policy bound to the state node and iterates through the scheduling actions in it one by one. For each scheduling action, the lifecycle attribute is checked first: if it is a task-level action and the corresponding acquisition module is already in a running state, the activation operation is skipped; if it is a task-level action but the action has not yet been activated, the first activation is performed; if it is a stage-level action, the activation operation is performed normally. If the execution mode of the scheduling action is conditional execution, the preset precondition expression is evaluated first, and the acquisition command is issued only when the condition is met.

[0045] During task execution, a rule triggering mechanism operates concurrently: each extension unit pushes critical operating status data (such as antenna lock / loss-of-lock status, tracking baseband carrier lock / loss-of-lock status, TT&C baseband dual-capture completion status, and data transmission baseband frame synchronization lock / loss-of-lock status) to the rule evaluation engine in real time through external channels such as UDP multicast. The rule evaluation engine performs condition judgment based on configurable preset triggering rules: when a conditional expression defined in a certain rule is satisfied (for example, the antenna status changes from loss-of-lock to locked), an instruction is issued to the corresponding acquisition module to trigger the start of execution of the relevant acquisition instruction (for example, starting to collect real-time status data such as the antenna's pitch angle, azimuth angle, and AGC voltage); when the condition is no longer satisfied (for example, the antenna changes from locked to loss-of-lock), the stop of execution of the corresponding acquisition instruction is triggered. The above rule triggering mechanism does not change the state transition path of the task chain state machine, and only controls whether specific acquisition instructions are executed within the currently running working phase, so as to avoid collecting invalid data when preset preconditions are not met. The default execution of acquisition instructions is not affected — if no triggering rule is configured for a certain acquisition instruction, the acquisition instruction is executed as usual according to the phase strategy. Full-volume acquisition data is directly sent to the downstream data center, and only lightweight critical triggering status signals are reported to the rule evaluation engine to form a control closed loop. After all scheduling actions of a state node are executed (or preset completion conditions are met), the state node enters a completed state, the task scheduling executor releases the phase-level actions corresponding to the state node (task-level actions remain running), and drives the transition to the next state node according to the state transition relationship, until the last state node of the task chain is completed, and the entire data acquisition scheduling task ends.

[0046] To further explain the present invention, further description is provided below with specific examples: Embodiment 1: Input and parsing of equipment work plan file The equipment work plan file generated by the XX model TT&C station in a TT&C tracking task is in a structured XML format, including task dimension and time node information: <设备工作计划> <任务信息> <任务ID>TARGET001< / 任务ID> <任务类型>TT&C Tracking< / 任务类型> <任务优先级>Important< / 任务优先级> <工作方式>SZ< / 工作方式> <设备代号>XX-XX< / 设备代号> <开始时间>20250904100000< / 开始时间> <结束时间>20250904110000< / 结束时间> < / Task Information> <Constraint Conditions> <Device Mutual Exclusion MutexDevice="YY-YY" / > <Phase Constraint Phase="Remote Control→Data Transmission" MinimumGap="10s" / > < / Constraint Conditions> <Time Node Set> <Node Name="Mission Preparation Start" Time="20250904100000" / > <Node Name="Mission Start" Time="20250904100500" / > <Node Name="Tracking Start" Time="20250904101000" / > <Node Name="Remote Control Start" Time="20250904101500" / > <Node Name="Remote Control End" Time="20250904102500" / > <Node Name="Turn On Uplink Signal" Time="20250904103000" / > <Node Name="Turn Off Uplink Signal" Time="20250904103500" / > <Node Name="Data Transmission Start" Time="20250904103500" / > <Node Name="Data Transmission End" Time="20250904105000" / > <Node Name="Tracking End" Time="20250904105500" / > <Node Name="Mission End" Time="20250904110000" / > < / Time Node Set> < / Device Work Plan> Although the other model YY-YY measurement and control station expresses the same mission content, its field naming adopts "Mission Preparation Start Time", "Mission Start Time", etc., and the time format is "yyyy-MM-dd HH:mm:ss". Through the parsing rules pre-configured for the YY model in the scheduling configuration center (defining the field mapping relationship such as "Mission Preparation Start Time" → "Mission Preparation Start", and configuring the time format pattern "yyyy-MM-dd HH:mm:ss"), heterogeneous inputs can be unified into the standard time node model, and the upper-layer scheduling logic does not need to perceive the underlying differences.

[0047] The parsing process for the XX model file is as follows: Map 11 time nodes to standard names according to the field mapping rule; convert the time format according to the time format pattern "yyyyMMddHHmmss"; verify that all mandatory nodes (tracking start, tracking end, task end) exist, and the end time of each node is greater than or equal to the start time; generate an ordered set of time nodes after sorting: task preparation start (10:00:00) → task start (10:05:00) → tracking start (10:10:00) → remote control start (10:15:00) → remote control end (10:25:00) → uplink signal on (10:30:00) → uplink signal off (10:35:00) / data transmission start (10:35:00) → data transmission end (10:50:00) → tracking end (10:55:00) → task end (11:00:00).

[0048] The pre-configured phase generation rules in the scheduling configuration center are as follows: <Phase generation rule Device type="XX model" Task type="TT&C tracking"> <Rule id="R01" Type="Interval generation" Phase="Task preparation" Start="Task preparation start" End="Task start" Priority="1" / > <Rule id="R02" Type="Interval generation" Phase="Start phase" Start="Task start" End="Tracking start" Priority="1" / > <Rule id="R03" Type="Interval generation" Phase="Tracking phase" Start="Tracking start" End="Tracking end" Priority="1" / > <Rule id="R04" Type="Interval generation" Phase="Remote control phase" Start="Remote control start" End="Remote control end" Priority="2" Condition="Working mode='SZ'" / > <Rule id="R05" Type="Interval generation" Phase="Uplink control phase" Start="Uplink signal on" End="Uplink signal off" Priority="2" / > <Rule id="R06" Type="Interval generation" Phase="Data transmission phase" Start="Data transmission start" End="Data transmission end" Priority="2" / > <Rule id="R07" Type="Interval generation" Phase="Closing phase" Start="Tracking end" End="Task end" Priority="1" / > <Nesting relationship Parent="Tracking phase"><Child>Remote control phase< / Child><Child>Uplink control phase< / Child>< / Nesting relationship> <ParallelRelationship><Group Members="Remote Control Phase, Uplink Control Phase" / >< / ParallelRelationship> <PhaseConstraint Phase="Remote Control Phase" MinimumDuration="60s" MaximumDuration="600s" / > <PhaseConstraint Phase="Data Transmission Phase" MinimumDuration="300s" / > <CoolingConstraint PrecedingPhase="Remote Control Phase" SubsequentPhase="Data Transmission Phase" MinimumGap="10s" / > < / PhaseGenerationRule> Match the ordered time nodes with the above rules, R01 to R07 are matched successfully in sequence, and 7 working phases are generated: |Phase Name|Start Time|End Time|Structural Relationship| |----------|----------|----------|----------| |Mission Preparation|10:00:00|10:05:00|Independent| |Startup Phase|10:05:00|10:10:00|Independent| |Tracking Phase|10:10:00|10:55:00|Parent Phase| |Remote Control Phase|10:15:00|10:25:00|Nested in the Tracking Phase| |Uplink Control Phase|10:30:00|10:35:00|Nested in the Tracking Phase, parallel with the Remote Control Phase| |Data Transmission Phase|10:35:00|10:50:00|Independent, time overlaps with the Tracking Phase| |Closing Phase|10:55:00|11:00:00|Independent| After verification, the duration of each phase meets the constraint conditions, and the gap between the Remote Control Phase and the Data Transmission Phase (10:25→10:35) meets the 10-second cooling requirement.

[0049] Taking the Tracking Phase as an example, its scheduling policy binding configuration is as follows: <PolicyBinding Phase="Tracking Phase"> <ExecutionMode>Parallel< / ExecutionMode> <SchedulingAction> <Action id="T1" LifeCycle="Phase-level" Subunit="Tracking Baseband" CollectionModule="Tracking Collection Module" CollectionInstruction="Real-time Status Collection, Subunit Performance Collection" / > <Action id="T2" LifeCycle="Phase-level" Subunit="TT&C Baseband" CollectionModule="TT&C Collection Module" Acquisition instruction="Real-time status acquisition, extension performance acquisition" / > <Action id="T3" lifecycle="task-level" extension="Antenna" acquisition module="Antenna acquisition module" Acquisition instruction="Real-time status acquisition" mode="Update" / > < / Scheduling action> < / Policy binding> Herein, task-level extensions such as the monitoring server, time-frequency extension, intelligent PDU, and matrix switch are activated in the task preparation or startup phase, and remain operating without readjustment during the tracking phase (only updating instructions as needed); the antenna updates the acquisition instruction from "Log acquisition" to "Real-time status acquisition" through the replacement mode; the tracking baseband and TT&C baseband are phase-level actions that are activated upon entry and released upon exit. The execution mode is parallel, and the three scheduling actions are issued simultaneously.

[0050] The complete correspondence between each extension and its acquisition module is as follows: |Extension|Acquisition module|Lifecycle|Activation phase| |Monitoring server|Monitoring acquisition module|Task-level|Task preparation| |Time-frequency extension|Time-frequency acquisition module|Task-level|Task preparation| |Intelligent PDU|Power supply and distribution acquisition module|Task-level|Task preparation| |Matrix switch|Channel acquisition module|Task-level|Task preparation| |Antenna|Antenna acquisition module|Task-level|Startup phase| |Tracking baseband|Tracking acquisition module|Phase-level|Tracking phase| |TT&C baseband|TT&C acquisition module|Phase-level|Tracking phase| |Data transmission baseband|Data transmission acquisition module|Phase-level|Data transmission phase| |Power amplifier extension|Transmission acquisition module|Phase-level|Uplink control phase| |Store-and-forward extension|Store-and-forward acquisition module|Phase-level|Data transmission phase| |Test transponder|Calibration acquisition module|Phase-level|Task preparation| Task chain state machine construction and real-time rule triggering: Semantic enhancement is performed on the 7 working phases to construct a task chain state machine model. The transition relationships between state nodes are as follows: Task preparation → (time-triggered) → Startup phase → (time-triggered) → Tracking phase → (sub-phase completion + time-triggered) → Winding-up phase → (time-triggered) → End. The remote control phase and the uplink control phase (both in parallel) are nested inside the tracking phase, and there is a time overlap between the data transmission phase and the tracking phase.

[0051] The configurable real-time rule triggering mechanism is illustrated using the antenna lock / unlock scenario. The following triggering rules are preconfigured in the scheduling configuration center: <Trigger Rule id="TR001"> <Condition Expression> <Condition Data Source="Antenna" Parameter="Lock Status" Operation="==" Value="Locked" / > < / Condition Expression> <Trigger Action Type="Start Acquisition"> <Target Sub-unit="Antenna" Acquisition Module="Antenna Acquisition Module" Acquisition Instruction="Real-time Status Data Acquisition (Elevation Angle, Azimuth Angle, AGC Voltage)" / > < / Trigger Action> <Trigger Action Type="Stop Acquisition"> <Target Sub-unit="Antenna" Acquisition Module="Antenna Acquisition Module" Acquisition Instruction="Real-time Status Data Acquisition (Elevation Angle, Azimuth Angle, AGC Voltage)" / > < / Trigger Action> < / Trigger Rule> The antenna acquisition module reports the lock status once per second through the external interface. At the initial stage of the tracking phase, the antenna has not yet completed target locking, the reported status is "unlocked", the condition expression "lock status == locked" is not satisfied, and the antenna acquisition module only executes the conventional instructions in the default scheduling strategy (such as "log acquisition") and does not execute the "real-time status acquisition" instruction.

[0052] At a certain moment, the antenna successfully locks the target, the reported status changes to "locked", the rule evaluation engine detects that the condition changes from unsatisfied to satisfied, and issues a "start acquisition" instruction to the antenna acquisition module to start real-time acquisition of statuses such as elevation angle, azimuth angle, and AGC voltage. If the antenna loses lock later (such as due to target maneuvering or occlusion), the status changes from "locked" to "unlocked", the engine detects that the condition is no longer satisfied, issues a "stop acquisition" instruction, terminates the above real-time status data acquisition, and returns to the state of only executing the default scheduling instruction. If the lock is re-established later, the start of acquisition is triggered again. If the user does not configure this trigger rule, the real-time status data acquisition of the antenna is completely executed according to the default scheduling action in the phase strategy, and is not affected by the rule triggering mechanism.

[0053] In this mechanism, rule triggering only controls the start and stop of specific data acquisition commands, without altering the stage transition path of the task chain state machine. The task chain state machine continues to advance according to time-triggered and state-triggered events. By decoupling rule configuration from default scheduling, the system dynamically controls the start and stop of specific data acquisition based on real-time key states such as lock / unlock on the slave unit, while ensuring basic data acquisition integrity. This avoids acquiring invalid data when preset preconditions are not met. All acquired data is directly sent to the downstream data center for task monitoring and post-analysis, with only lightweight key trigger status signals reported to the rule evaluation engine to form a closed-loop control system.

[0054] In the description of this invention, it should be noted that for directional terms, such as "center," "lateral," and "vertical," the appropriate terms may be used. The directions and positional relationships indicated by symbols such as "direction", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", and "counterclockwise" are based on the directions or positional relationships shown in the accompanying drawings and are only for the convenience of describing the present invention and simplifying the description. They are 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, and should not be construed as limiting the specific protection scope of the present invention.

[0055] It should be noted that the terms "comprising" and "having" and any variations thereof in the specification and claims of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0056] Note that the above description is merely a preferred embodiment and application of the technical principles of the present invention. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the specific embodiments described herein, and may include many other effective embodiments without departing from the concept of the present invention. The scope of the present invention is determined by the scope of the appended claims.

Claims

1. A data acquisition and scheduling method for aerospace telemetry and control equipment based on task chain orchestration, characterized in that: Includes the following steps: Step S1: Construct a scheduling configuration center, which is used to uniformly define and manage parsing rules, stage generation rules, and scheduling strategy library for different types of devices; Step S2: Receive work plan files for different types of equipment; Step S3: Parse the device work plan file based on the parsing rules to generate an ordered set of time nodes; Step S4: Generate a set of working stages according to the stage generation rules; Step S5: Match a corresponding scheduling strategy for each work stage based on the scheduling strategy library; Step S6: Construct a task chain state machine model, elevating each work stage to a dynamic state node with a complete lifecycle and migration capabilities; Step S7: Run the task chain state machine and implement rule-triggered control for the acquisition command; The rule-triggered control is specifically as follows: During task execution, each sub-machine pushes key operating status data to the rule evaluation engine in real time. The rule evaluation engine performs condition judgment based on preset trigger rules. When the condition expression is met, the execution of the relevant acquisition instruction is triggered. When the condition is no longer met, the execution of the corresponding acquisition instruction is stopped. The rule-triggered control does not change the state transition path of the task chain state machine, but only controls whether a specific acquisition instruction is executed within the current working phase. The parsing rules include field mapping rules, time format conversion rules, and node verification rules. The field mapping rules are used to map heterogeneous fields in work plans of different devices to unified standard time node names. The time format conversion rules are used to convert time expressions in different formats into a unified time format. The node verification rules are used to verify the integrity of time nodes and the validity of time logic. The stage generation rules are used to define the combination relationship between time nodes to generate work stages. They adopt interval-based generation rules, which generate work stages by defining the correspondence between start time nodes and end time nodes. They support the coexistence of multiple rules, rule priority configuration, and stage nesting relationship definition. The scheduling strategy library is used to define the scheduling behavior of the acquisition modules deployed on each extension under different working stages. It includes the binding relationship between stage name and execution mode, and scheduling action list. The scheduling list contains multiple scheduling actions. The task chain state machine model defines lifecycle attributes for each state node, including at least inactive, running, completed, and interrupted states, and establishes state transition relationships between state nodes, which are driven by time-triggered conditions and / or state-triggered conditions.

2. The aerospace telemetry, tracking, and command (TT&C) data acquisition and scheduling method based on a task chain state machine according to claim 1, characterized in that, The scheduling action includes the following characteristics: Each scheduling action specifies the target extension and the acquisition module deployed on it, and includes at least one acquisition instruction, which is used to instruct the acquisition module to perform the corresponding type of data acquisition; Each scheduling action includes a lifecycle attribute, which includes task-level and stage-level attributes. Once a task-level action is first activated, it continues to run until the task ends, and is not rescheduled when switching stages. A stage-level action is activated when entering a stage and released when leaving a stage. For the task-level action, it further includes an instruction mode attribute, which includes an append mode and a replacement mode, used to update the acquisition instructions when switching stages; the append mode adds instructions based on the current instruction set, and the replacement mode replaces the current instruction set with a new instruction set.

3. The aerospace telemetry, tracking, and command (TT&C) data acquisition and scheduling method based on a task chain state machine according to claim 1, characterized in that, The execution modes include parallel execution mode, serial execution mode and conditional execution mode; the parallel execution mode issues all scheduled actions simultaneously; the serial execution mode issues actions sequentially in a predefined order, waiting for the previous action to be completed before issuing the subsequent action; the conditional execution mode first evaluates the preset precondition expression, and issues the scheduled action only when the condition is met. The rule expression upon which the conditional execution mode is based is constructed based on at least one of the following: device operating state, signal quality parameters, or task execution state.

4. The aerospace telemetry, tracking, and command (TT&C) data acquisition and scheduling method based on a task chain state machine according to claim 1, characterized in that, Among the lifecycle attributes of the state node: the inactive state indicates that the state node has been created but has not yet met the activation conditions, and the corresponding scheduling action has not been executed; the running state indicates that the activation conditions of the state node have been met, and the scheduling action is being executed according to the binding strategy; the completed state indicates that all the scheduling actions corresponding to the state node have been executed, and it can trigger the migration to the next state node. The interruption status indicates that the status node was prematurely terminated during execution because a preset interruption condition was met.

5. The aerospace telemetry, tracking, and command (TT&C) data acquisition and scheduling method based on a task chain state machine according to claim 1, characterized in that, In the state transition relationship of the state nodes: the time triggering condition includes driving state transition when the system time reaches the end time of the phase corresponding to the current state node, and / or driving state transition when the system time reaches the start time of the phase of the next state node; the state triggering condition includes generating a completion event to drive state transition when the current state node or sub-state node enters the completion state.

6. The aerospace telemetry, tracking, and command (TT&C) data acquisition and scheduling method based on a task chain state machine according to claim 1, characterized in that, The task chain state machine model supports at least one of the following execution control capabilities: multi-state parallel execution, allowing multiple state nodes to be in the running state simultaneously; nested state structure, allowing a parent state node to contain multiple child state nodes, with the lifecycle of the parent state node covering all child state nodes; state reentrancy, allowing a state node that has entered the completed state to be reactivated when certain conditions are met; and state transition control, allowing the transition between state nodes to be not limited to a preset linear order, and to jump to any legal state node in the task chain according to trigger conditions.

7. The aerospace telemetry, tracking, and command (TT&C) data acquisition and scheduling method based on a task chain state machine according to claim 1, characterized in that, In the rule-triggered control: the default execution of the collection command is unaffected; if no trigger rule is configured for a certain collection command, the collection command will be executed according to the stage strategy as usual; all collected data is directly sent to the downstream data center, and only key trigger status signals are reported to the rule evaluation engine to form a control closed loop; when all scheduling actions of a status node are completed or the preset completion conditions are met, the status node enters the completion state, releases the stage-level actions corresponding to the status node, the task-level actions continue to run, and are driven to migrate to the next status node according to the state transition relationship, until the last status node of the task chain is completed.

8. The aerospace telemetry, tracking, and command (TT&C) data acquisition and scheduling method based on a task chain state machine according to claim 1, characterized in that, The scheduling configuration center decouples rule configuration from scheduling execution logic at the design level. When adding a new equipment type, only the rule configuration needs to be modified, without changing the core code of the task scheduling executor. The equipment work plan file is automatically generated by the aerospace telemetry and control system according to the mission plan. The files generated by different equipment types and station types differ in data format, field naming, and time expression. The equipment work plan file contains mission identifier, mission type, mission priority, names and corresponding times of multiple key time nodes, as well as equipment mutual exclusion relationships and inter-stage cooling gap constraint information.

9. A space telemetry, tracking, and command (TT&C) data acquisition and scheduling system based on a task chain state machine, characterized in that, include: The scheduling configuration center is used to uniformly define and manage parsing rules, stage generation rules, and scheduling strategy libraries for different device types. The parsing module is used to receive the equipment work plan file, parse the equipment work plan file based on the parsing rules, and generate an ordered set of time nodes; A stage generation module is used to generate a set of working stages according to the stage generation rules. The strategy matching module is used to match a corresponding scheduling strategy for each work stage based on the scheduling strategy library; The state machine building module is used to build task chain state machine models, elevating each work stage into a dynamic state node with a complete lifecycle and migration capabilities; A task scheduler executor is used to run the task chain state machine and implement rule-triggered control for collecting instructions; The rule evaluation engine is used to receive key operational status data pushed in real time by each extension unit, and to make condition judgments based on preset trigger rules. When the condition expression is met, the relevant collection command is triggered to start execution; when the condition is no longer met, the corresponding collection command is triggered to stop execution. The parsing rules include field mapping rules, time format conversion rules, and node verification rules. The stage generation rules are used to define the combination relationship between time nodes to generate work stages. They adopt interval-based generation rules and support multiple rules coexisting, rule priority configuration, and stage nesting relationship definition. The scheduling strategy library is used to define the scheduling behavior of the acquisition modules deployed on each sub-machine under different work stages, including the binding relationship between stage name and execution mode, and scheduling action list. The task chain state machine model defines life cycle attributes for each state node, including at least inactive state, running state, completed state, and interrupted state, and establishes state transition relationships between state nodes.

10. The aerospace telemetry, tracking, and command (TT&C) data acquisition and scheduling system based on a task chain state machine according to claim 9, characterized in that, The task scheduler executor is also used for: When the triggering condition is met, the target state node that needs to be activated is determined, and the state node is switched from the inactive state to the running state. After a state node is activated, the scheduling policy bound to that state node is read, and the scheduling actions within it are traversed one by one. For each scheduled action, check the lifecycle attribute: if it is a task-level action and the corresponding acquisition module is already running, skip the activation operation; If it is a task-level action but the action has not yet been activated, then perform the first activation. If it is a stage, then perform the activation operation; If the execution mode of the scheduling action is conditional execution, the preset precondition expression is evaluated first, and the collection command is issued only when the condition is met. Once all scheduled actions of a state node have been executed or the preset completion conditions have been met, the state node is switched to the completed state, the stage-level actions corresponding to the state node are released, the task-level actions continue to run, and the state transition relationship drives the transition to the next state node.

Images