Satellite telemetry monitoring and alarming method and system based on event-driven state machine

Abstract

This invention belongs to the field of spacecraft ground telemetry, tracking, and command (TT&C) technology, and particularly relates to a satellite telemetry monitoring and alarm method and system based on an event-driven state machine. It includes modeling the lifecycle of a satellite's planned arc as an event-driven finite state machine; acquiring the planned time of the satellite to be monitored and the corresponding latest telemetry data, generating a current event; routing the generated current event to a state processor corresponding to the current state of the satellite to be monitored. The state processor, based on preset business logic for responding to different events, and combined with the current satellite state, executes the corresponding alarm operation and completes the state transition to the next satellite state. This invention constructs an event-driven finite state machine model, abstracting the lifecycle of a satellite's planned arc into four states and three types of events, and executes business logic through a state processor pattern, reconstructing the entire monitoring and alarm logic through states, events, and actions.

Description

Technical Field

[0001] This invention belongs to the field of spacecraft ground telemetry and control technology, and particularly relates to a satellite telemetry monitoring and alarm method and system based on event-driven state machine. Background Technology

[0002] In satellite telemetry, tracking, and command (TT&C) operations, satellites must strictly adhere to the pre-set planned arc segments (i.e., "entry" and "exit" times) for communication and data transmission. After a satellite enters the orbit, the ground station should continuously receive the telemetry data it transmits. However, in actual operation, abnormal situations frequently occur, such as satellites entering the orbit late, leaving the orbit early, or experiencing communication interruptions within the arc segment.

[0003] Currently, most mainstream monitoring solutions in the industry adopt a procedural programming paradigm, using complex conditional statements (if-else statements) to detect anomalies. The if-else statement is a control structure in programming languages ​​used to determine which code to execute based on the truth value of a condition. A typical implementation involves deploying a timed task that executes every few seconds, iteratively checking all active satellite schedules and performing the following checks in sequence:

[0004] Check whether the satellite has missed its planned entry time but has not yet received telemetry data to determine "late entry";

[0005] When the satellite is within the orbit, check whether the time difference between the current time and the last time telemetry data was received exceeds a threshold to determine if "communication interruption" has occurred;

[0006] Check whether the satellite has exceeded its planned exit time and whether the last time it received data was much earlier than the planned exit time to determine if it has "exited the orbit prematurely".

[0007] This traditional approach has the following inherent drawbacks:

[0008] (1) Highly coupled logic: All judgment logic is piled up in a few services or scripts, and the handling code for various exceptions is intertwined, resulting in poor code readability and difficulty in maintenance.

[0009] (2) Extremely poor scalability: When a new monitoring state is needed, a new branch must be inserted into the original complex judgment logic, which not only easily introduces errors, but also violates the "open and closed principle" of software design.

[0010] (3) Disorganized status management: The current status of the system (e.g., whether an alarm has been triggered, when the interruption started) is scattered across multiple variables, database fields, or caches, lacking a unified and clear status view. This leads to inaccurate and incomplete alarm condition judgments, making it very easy for false alarms or missed alarms to occur. Summary of the Invention

[0011] To overcome the shortcomings of the existing technologies, this invention provides a satellite telemetry monitoring and alarm method and system based on event-driven state machine. It constructs an event-driven finite state machine (FSM) model, abstracts the life cycle of the satellite's planned arc into four states and three types of events, and executes business logic through a state processor pattern. The entire monitoring and alarm logic is reconstructed through states, events, and actions, thereby fundamentally solving the structural defects of traditional solutions.

[0012] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions:

[0013] The first aspect of this invention provides a satellite telemetry monitoring and alarm method based on an event-driven state machine.

[0014] The satellite telemetry monitoring and alarm method based on event-driven state machines includes the following steps:

[0015] The lifecycle of a satellite program segment is modeled as an event-driven finite state machine containing four states and three types of events;

[0016] Obtain the planned times and corresponding latest telemetry data for the satellites and plans that need to be monitored;

[0017] Based on the planned time of the satellites to be monitored and the preset logical relationship between the latest telemetry data and the current time, the current event is generated;

[0018] The generated current event is routed to a state processor that corresponds to the current state of the satellite to be monitored. The state processor, based on the preset business logic for responding to different events and combined with the current state of the satellite, executes the corresponding alarm operation and completes the state transition of the satellite to the next state.

[0019] The second aspect of this invention provides a satellite telemetry monitoring and alarm system based on an event-driven state machine.

[0020] A satellite telemetry monitoring and alarm system based on event-driven state machines includes:

[0021] The satellite planning arc modeling module is configured to model the lifecycle of a satellite planning arc as an event-driven finite state machine containing four states and three types of events.

[0022] The data acquisition module is configured to acquire the satellites to be monitored, the planned times, and the corresponding latest telemetry data.

[0023] The event generation module is configured to generate the current event based on the preset logical relationship between the satellites being monitored, the planned time of the plan, the latest telemetry data, and the current time.

[0024] The state processor execution module is configured to route the generated current event to a state processor corresponding to the current state of the satellite to be monitored. The state processor, based on the preset business logic for responding to different events and combined with the current state of the satellite, executes the corresponding alarm operation and completes the state transition of the satellite to the next state.

[0025] The above one or more technical solutions have the following beneficial effects:

[0026] This invention provides a satellite telemetry monitoring and alarm method and system based on an event-driven state machine. In terms of overall architecture, it achieves high cohesion and low coupling in the monitoring and alarm logic, with the logic of each state encapsulated in an independent processor. Functionally, it possesses strong scalability; adding a new state or event only requires adding a new enumeration value and processor class, without modifying existing code, thus adhering to the open / closed principle. In terms of performance, alarm triggering is based on explicit state transition rules, significantly improving alarm accuracy. In terms of operation and maintenance, the system is easy to maintain; the generation path of each alarm is clearly visible in the code, facilitating log recording, problem backtracking, and system debugging.

[0027] This invention abstracts the monitoring process of satellite planning arcs into an event-driven finite state machine defined by state enumeration and event enumeration. It adopts the state processor pattern to define an independent processor for each state, thereby decoupling and encapsulating the complex monitoring and alarm logic according to the state.

[0028] This invention employs an active event detection mechanism. Through a timed scheduler, based on the logical comparison between real-time data and planned information, it actively generates events such as received telemetry, no data after timeout, and arrival at the planned out-of-circle time, thereby enabling monitoring of situations where "no event occurs".

[0029] This invention designs a state machine context to uniformly maintain the real-time status data of satellites in memory, providing a complete data view for accurate alarms.

[0030] This invention sets up alarm triggering rules based on state transition, which precisely binds the triggering of alarms such as "late entry into the circle", "early exit from the circle", and "communication interruption recovery" to specific state transition paths.

[0031] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0032] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0033] Figure 1 This is a flowchart of the method in Example 1.

[0034] Figure 2 This is a schematic diagram of the satellite plan state transition in Example 1.

[0035] Figure 3 This is a system structure diagram of Example 2. Detailed Implementation

[0036] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0037] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0038] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0039] Terminology Explanation:

[0040] (1) Finite state machine (FSM): A mathematical model that represents a finite number of states and behaviors such as transitions and actions between these states.

[0041] (2) State Pattern: An object-oriented design pattern that allows an object to change its behavior when its internal state changes.

[0042] (3) Open-Closed Principle: Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

[0043] (4) Entry into Visibility Pass: This refers to the point in time when the satellite enters the coverage area of ​​the ground control station's antenna beam and begins to have the ability to establish a communication link with the ground station. It is also known as the "start of the visible arc".

[0044] (5) Exit from Visibility Pass: This refers to the time when the satellite leaves the coverage area of ​​the ground control station's antenna beam, ending the current communication window. It is also known as the "end of the visible arc".

[0045] (6) Scheduled Visibility Pass: A time window pre-calculated and allocated by the ground telemetry and control system based on satellite orbit forecasts for performing telemetry reception, remote control transmission or data transmission tasks, including a clear planned entry time and planned exit time.

[0046] (7) Telemetry (TM): refers to the engineering parameters and scientific data transmitted from the satellite to the ground station, including but not limited to the satellite platform status (such as power supply voltage, temperature, attitude angle), payload working status and health information, for ground monitoring and fault diagnosis.

[0047] (8) Event-Driven: A software architecture pattern in which the execution flow of the system is triggered by external or internal events (such as data arrival or timer timeout) rather than active polling.

[0048] Example 1

[0049] This embodiment discloses a satellite telemetry monitoring and alarm method based on event-driven state machines. It manages the satellite's planned arc lifecycle and provides intelligent alarms through a software state machine model. The planned arc lifecycle of a satellite is essentially a process with clearly defined states and transition conditions, which aligns perfectly with the theoretical model of a finite state machine (FSM). Therefore, by systematically introducing the event-driven state machine model into the field of satellite telemetry monitoring, the entire monitoring and alarm logic is reconstructed through states, events, and actions, fundamentally solving the structural defects of traditional solutions.

[0050] like Figure 1 As shown, the satellite telemetry monitoring and alarm method based on event-driven state machines includes the following steps:

[0051] The lifecycle of a satellite program segment is modeled as an event-driven finite state machine containing four states and three types of events;

[0052] Obtain the planned times and corresponding latest telemetry data for the satellites and plans that need to be monitored;

[0053] Based on the planned time of the satellites to be monitored and the preset logical relationship between the latest telemetry data and the current time, the current event is generated;

[0054] The generated current event is routed to a state processor that corresponds to the current state of the satellite to be monitored. The state processor, based on the preset business logic for responding to different events and combined with the current state of the satellite, executes the corresponding alarm operation and completes the state transition of the satellite to the next state.

[0055] The core technology of this embodiment lies in constructing an event-driven finite state machine (Event-DrivenFSM) model, which abstracts the lifecycle of a satellite planning arc into four states and three types of events, and executes business logic through a state processor pattern.

[0056] The implementation steps of this embodiment will be explained in detail below.

[0057] (a) Definition of the core model.

[0058] (1) The state enumeration (SatelliteState) defines the four states that the satellite may be in during the planned arc. The four states specifically include:

[0059] ① Waiting to join the circle (WAIT_ENTER): The satellite has not yet joined the circle and is waiting to receive telemetry data.

[0060] ②In CIRCLE: The satellite has entered the CIRCLE and is receiving telemetry data normally.

[0061] ③Telemetry Interrupted: The satellite is within the orbit, but telemetry data reception times out.

[0062] ④ Exited: The satellite program arc has ended, and cleanup will be carried out.

[0063] (2) The event enumeration (SatelliteEvent) defines three types of events that trigger state transitions. These three types of events specifically include:

[0064] ① Telemetry received (TELEMETRY_RECEIVED): Triggered by an external telemetry data source, indicating that new data has been received.

[0065] ② No data timeout (NO_DATA_TIMEOUT): Triggered by a system-internal periodic check, indicating a communication interruption.

[0066] ③ Arrival at planned exit time (PLAN_EXIT_TIME_REACHED): Triggered by internal system time comparison.

[0067] Enumeration is a general data type. In this embodiment, the state enumeration (SatelliteState) is a custom collection of satellite state data, and the event enumeration (SatelliteEvent) is a custom collection of satellite event data.

[0068] (3) The SatelliteContext maintains a context object for each plan of each satellite to store data during state machine runtime. The state machine context is a core component of the state machine design pattern, responsible for encapsulating data and logic related to state management, serving as the environment for state machine runtime. Its core fields include:

[0069] satelliteId (satellite identifier);

[0070] planId (plan identifier);

[0071] state (current state);

[0072] lastTelemetry (latest telemetry time);

[0073] interruptStart (interrupt start time).

[0074] This embodiment creates, stores, and retrieves SatelliteContext objects for each satellite program in memory (such as ConcurrentHashMap). ConcurrentHashMap is a thread-safe hash table implementation in Java, which achieves high-concurrency read and write operations through segmented locks and CAS (Compare-and-Swap) (CAS) mechanisms.

[0075] (ii) Proactive data acquisition and event generation judgment.

[0076] This embodiment uses a scheduled task (e.g., using Spring's @Scheduled annotation, executed every 2 seconds) to proactively perform the following operations:

[0077] ① Retrieve currently active satellite programs from a database / cache (such as MySQL / Redis).

[0078] ② Update the latest telemetry times of each satellite from the cached message queue (such as Kafka) and store them in the activeMap.

[0079] ③ Based on the latest telemetry data and the logical relationship between the planned time and the current time, actively detect and generate corresponding events (SatelliteEvent) for each context.

[0080] MySQL is an open-source relational database management system that uses the Structured Query Language (SQL) to manage data. Redis is an open-source in-memory data structure storage system, commonly used as a database, cache, or message broker.

[0081] The @Scheduled annotation in Spring is an annotation provided by the Spring framework (an open-source Java enterprise application framework) for automatically executing methods at specified times or periodically.

[0082] The event generation steps specifically include:

[0083] The TELEMETRY_RECEIVED event is generated when the latest telemetry time (lastTelemetry) obtained from the message queue is not empty and is determined to be valid new data.

[0084] The NO_DATA_TIMEOUT event is generated when the satellite is in the IN_CIRCLE state and (current time - last telemetry time) > a preset first threshold, where the preset first threshold is configurable.

[0085] The PLAN_EXIT_TIME_REACHED event is generated when the current time is later than the planned exit time.

[0086] (iii) The state processor executes alarm judgment and state transition processing logic.

[0087] In this embodiment, four independent state processors are pre-set, each corresponding to a state of a finite state machine. Each state processor encapsulates the business logic to be executed in response to different events under the corresponding state. The business logic includes alarm judgment and state transition.

[0088] By setting up four independent state processors to handle the current events of the satellite plan in different current states, the complex monitoring and alarm logic can be decoupled according to state.

[0089] The four independent state processors mentioned above form a state processor set. Each state processor includes an interface that implements SatelliteStateHandler, and each processor encapsulates all the business logic (including alarm judgment, calculation and state transition) that should be executed in response to different events in a specific state.

[0090] SatelliteStateHandler is the abstract interface for state processors implemented in this embodiment. It defines a set of standard state processing methods. Specific state processors complete a unified state processing flow by implementing this interface.

[0091] It can be understood that when using the state processor to execute alarm judgment and state transition processing logic, it is first necessary to obtain the current state of the satellite to be monitored from the state machine context;

[0092] By using a predefined mapping relationship between the current satellite state and the state processor, the generated current event is routed to the matching state processor.

[0093] An example is illustrated below:

[0094] The satellites and plans that need to be monitored are referred to as Satellite Plan A. After the aforementioned logical judgment, the current event for Satellite Plan A is "timeout no data". After retrieving the context object corresponding to Satellite Plan A, it is confirmed that the current status of Satellite Plan A is within the circle.

[0095] Subsequently, based on a predefined mapping relationship between the current state of the satellite and the state processor, state processor B is determined to handle the current state of "within the circle". State processor B is responsible for handling the alarm judgment of the current event "timeout no data" of satellite plan A and the state transition at the next moment.

[0096] like Figure 2 The diagram illustrates the satellite's planned state transitions in this embodiment. The four states—waiting to enter the circle, within the circle, telemetry interrupted, and out of the circle—are represented by boxes. Lines and arrows between the boxes indicate the state transitions between these four states.

[0097] The two boxes, "Waiting to Enter the Circle" and "Inside the Circle," are connected by a line segment. The arrow points inside the circle, indicating that the next state for "Waiting to Enter the Circle" is "Inside the Circle." The "Late Entry" label on the line segment indicates that "Late Entry" may occur when transitioning from "Waiting to Enter the Circle" to "Inside the Circle."

[0098] Connect the two boxes, "Inside the Circle" and "Telemetry Interruption," with a line segment. Use double-headed arrows to point to "Inside the Circle" and "Telemetry Interruption" respectively, indicating that the two states can be switched between each other. The "Data Interruption" label on the line segment indicates that "Data Interruption" or "Data Interruption Stopped" occurs when transitioning from "Inside the Circle" to "Telemetry Interruption" and vice versa.

[0099] Connect the two boxes, "inside the circle" and "outside the circle," with a line segment. The arrow points to "outside the circle," indicating that the final state transition result for "inside the circle" is "outside the circle." The "reaching the planned end time" label on the line segment indicates that when the planned end time is reached, the state transition occurs from "inside the circle" to "outside the circle."

[0100] Specifically, the state processor, based on preset business logic for responding to different events and combined with the current satellite state, executes corresponding alarm operations and completes the state transition for the next satellite state, including:

[0101] (1) When the current state is waiting to enter the circle and the current event is receiving telemetry, calculate the difference between the current time and the planned entry time as the delay amount. If the delay amount is greater than the preset second threshold, generate a late entry alarm and change the satellite's next state to within the circle.

[0102] (2) When the current state is in the circle and the current event is timeout with no data, record the current time as the interrupt start time, mark the start of the interrupt, and transfer the next state of the satellite to telemetry interrupt.

[0103] (3) When the current state is in the circle and the current event is the arrival of the planned exit time, calculate the difference between the planned exit time and the latest telemetry time as the lead time. If the lead time is greater than the preset third threshold, generate an early exit alarm and transfer the satellite's next state to exit.

[0104] (4) When the current state is telemetry interruption and the current event is telemetry received, calculate the difference between the current time and the interruption start time as the total interruption duration, generate a communication interruption recovery alarm, clear the interruption start time, and move the satellite's next state to within the circle.

[0105] (5) When the current state is telemetry interruption and the current event is the arrival of the planned exit time, generate a specific alarm and change the next state of the satellite to exit the circle.

[0106] As shown in Table 1, this embodiment provides a complete rule table for the context state transition of each satellite, providing a more intuitive display.

[0107] Table 1 Satellite State Transition Table

[0108]

[0109] The AlarmService in Table 1 above is called by various state handlers. It is responsible for structuring alarm information, saving it to a database (such as MySQL), and sending it to a message queue (such as Kafka) for other systems to consume.

[0110] (iv) Overall process description.

[0111] This embodiment provides a state machine scheduling engine (SatelliteStateMachineScheduler), which routes execution rights to the corresponding state processors through a mapping relationship based on the current state of the context and the received events.

[0112] The state machine scheduling engine periodically initiates the following process according to the scheduled tasks:

[0113] First, retrieve all satellite programs that need to be monitored and their latest telemetry data from the database (DB) and cache;

[0114] This then enters a loop to process each satellite plan:

[0115] Get or create its state machine context (SatelliteContext) and generate events based on real-time data; if the event is not empty, route the event and the current satellite state to the corresponding state handler (StateHandler) to execute business logic, alarm judgment and state transition according to the current state of the context;

[0116] The corresponding StateHandler will call its respective encapsulated processing method to handle the situation;

[0117] If the event is empty, continue looping to the next satellite plan;

[0118] After all satellite plans have been cycled through, the system enters a congestion waiting state, awaiting the start of the next cycle.

[0119] This process enables automated and status-based monitoring of the entire satellite constellation's planned lifecycle.

[0120] Overall, this embodiment achieves the following through:

[0121] (1) The monitoring process of the satellite planning arc is abstracted into an event-driven finite state machine (FSM) defined by state enumeration (SatelliteState) and event enumeration (SatelliteEvent);

[0122] (2) The State Handler Pattern is adopted to define an independent processor for each state, thereby decoupling and encapsulating the complex monitoring and alarm logic according to the state;

[0123] It solves the core problems of code logic coupling, poor system scalability, and chaotic state management caused by the use of procedural conditional judgment logic in traditional satellite telemetry and monitoring systems.

[0124] This embodiment uses:

[0125] (3) Proactive event detection mechanism: Through the timer scheduler, based on the logical comparison between real-time data and planned information, NO_DATA_TIMEOUT and PLAN_EXIT_TIME_REACHED events are actively generated, realizing the monitoring of the "no event occurred" situation;

[0126] (4) SatelliteContext design: used to maintain real-time satellite status data in memory and provide a complete data view for accurate alarms;

[0127] (5) Alarm triggering rules based on state transition: The triggering of alarms such as "late entry into the circle", "early exit from the circle", and "communication interruption recovery" is precisely bound to a specific state transition path;

[0128] It solves the problem of inaccurate alarms (false alarms and missed alarms) caused by scattered and unclear alarm triggering conditions, as well as the problem of high cost and high risk of modification when adding new monitoring requirements, thereby improving the maintainability and debuggability of the system and making the alarm generation path clearly visible.

[0129] In summary, the technical solution provided in this embodiment has the following technical advantages:

[0130] (1) Architectural advantages: It overcomes the coupling problem of traditional if-else logic and realizes a clear modular architecture through the state machine model, making the code easy to understand, maintain and test.

[0131] (2) Excellent scalability: When new monitoring dimensions need to be added (such as adding a “weak signal strength” state), only new states, events and processors need to be added without touching any existing code, which greatly reduces the complexity and risk of expansion.

[0132] (3) Alarm accuracy: Since the meaning and transition conditions of each state are clear, the conditions for generating alarms also become clear and accurate, fundamentally reducing the possibility of false alarms and missed alarms.

[0133] (4) Maintainability and debuggability: The system's operating logic is manifested as a series of state transitions, which facilitates logging and problem tracking. Developers can easily locate all the processing logic for a certain type of alarm, significantly improving operational efficiency.

[0134] Example 2

[0135] This embodiment discloses a satellite telemetry monitoring and alarm system based on an event-driven state machine.

[0136] A satellite telemetry monitoring and alarm system based on event-driven state machines includes:

[0137] The satellite planning arc modeling module is configured to model the lifecycle of a satellite planning arc as an event-driven finite state machine containing four states and three types of events.

[0138] The data acquisition module is configured to acquire the satellites to be monitored, the planned times, and the corresponding latest telemetry data.

[0139] The event generation module is configured to generate the current event based on the preset logical relationship between the satellites being monitored, the planned time of the plan, the latest telemetry data, and the current time.

[0140] The state processor execution module is configured to route the generated current event to a state processor corresponding to the current state of the satellite to be monitored. The state processor, based on the preset business logic for responding to different events and combined with the current state of the satellite, executes the corresponding alarm operation and completes the state transition of the satellite to the next state.

[0141] Furthermore, the data acquisition module is used to proactively perform the following operations via a scheduled task:

[0142] ① Retrieve currently active satellite plans from a database / cache (such as MySQL / Redis);

[0143] ② Update the latest telemetry times of each satellite from the cached message queue (such as Kafka) and store them in the activeMap.

[0144] The event generation module is used to actively detect and generate corresponding events (SatelliteEvent) for each context based on the latest telemetry data, the logical relationship between the planned time and the current time.

[0145] More specifically, this embodiment also includes the following modules:

[0146] (1) The state machine context management module (ConcurrentHashMap) is configured to create, store and retrieve SatelliteContext objects for each satellite program in memory.

[0147] (2) The state processor collection module (SatelliteStateHandler) contains multiple state processors that implement the SatelliteStateHandler interface (such as WaitEnterState, InCircleState, etc.). Each processor encapsulates all the business logic that should be executed in response to different events in a specific state (including alarm judgment, calculation and state transition).

[0148] (3) The state machine scheduling engine module (SatelliteStateMachineScheduler) is used to route execution rights to the corresponding state processors through a mapping relationship based on the current state of the context and the received events.

[0149] (4) Alarm Service module, which is called by various status processors, is responsible for structuring alarm information and saving it to the database (such as MySQL), and sending it to the message queue (such as Kafka) for other systems to consume.

[0150] (5) Alarm service push module, used to push alarm operations.

[0151] like Figure 3 As shown in this embodiment:

[0152] The state machine scheduling engine module retrieves currently active satellite plans from databases / caches (such as MySQL / Redis) and the latest telemetry data for each satellite from message queues (such as Kafka);

[0153] The state machine scheduling engine module generates events based on preset logic and sends the events to the state processor collection module;

[0154] Subsequently, the state machine scheduling engine module routes the event to the corresponding state processor based on the current state provided by the state machine context management module;

[0155] The corresponding state processor calls the alarm service module to perform alarm operations and state transitions;

[0156] Finally, alarm operations are pushed through the alarm service push module and stored in the database.

[0157] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.

[0158] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A satellite telemetry monitoring and alarm method based on event-driven state machines, characterized in that, Includes the following steps: The lifecycle of a satellite program segment is modeled as an event-driven finite state machine containing four states and three types of events; The satellite planning arc is a time window pre-calculated and allocated by the ground telemetry and control system based on satellite orbit prediction for performing telemetry reception, remote control transmission, or data transmission tasks, including the planned entry time and the planned exit time. The four states include waiting to enter the circle, inside the circle, telemetry interrupted, and outside the circle; The three types of events include receiving telemetry, timeout with no data, and reaching the planned out-of-circle time. The event-driven finite state machine also includes a state machine context, which is a context object maintained for each plan of each satellite. The specific fields of the context object include satellite identifier, plan identifier, current state, latest telemetry time and interruption start time. Obtain the planned times and corresponding latest telemetry data for the satellites and plans that need to be monitored; Based on the required satellite monitoring schedule, the planned time, the latest telemetry data, and the preset logical relationship between the current time, the current event is generated, specifically including: A telemetry received event is generated when the latest telemetry time is not empty and is determined to be valid new data. When the satellite is within the orbit and the difference between the current time and the latest telemetry time is greater than a preset first threshold, a timeout no data event is generated. When the current time is later than the planned exit time, an event indicating that the planned exit time has been reached is generated. The generated current event is routed to a state processor that corresponds to the current state of the satellite to be monitored. The state processor, based on the preset business logic for responding to different events and combined with the current state of the satellite, executes the corresponding alarm operation and completes the state transition of the satellite to the next state.

2. The satellite telemetry monitoring and alarm method based on event-driven state machine as described in claim 1, characterized in that, The four states are specifically defined as follows: Waiting to join the circle: The satellite has not yet joined the circle and is waiting to receive telemetry data; Within the circle: The satellite has entered the circle and is receiving telemetry data normally; Telemetry interruption: The satellite is within the orbit, but telemetry data reception timed out; Out of the loop: The satellite program's phase has ended; The specific triggering methods and meanings of the three types of events are as follows: Telemetry received: Triggered by an external telemetry data source, indicating that new data has been received; No data after timeout: Triggered by an internal timer check, indicating a communication interruption; Arrival time of planned exit: triggered by comparison with internal planned time.

3. The satellite telemetry monitoring and alarm method based on event-driven state machine as described in claim 1, characterized in that, Also includes: Four independent state processors are pre-defined, and each state processor corresponds to a state of a finite state machine. Each state processor encapsulates the business logic to be executed in response to different events under the corresponding state. The business logic includes alarm judgment and state transition.

4. The satellite telemetry monitoring and alarm method based on event-driven state machine as described in claim 3, characterized in that: Obtain the current state of the satellites to be monitored from the state machine context; By using a predefined mapping relationship between the current satellite state and the state processor, the generated current event is routed to the matching state processor.

5. The satellite telemetry monitoring and alarm method based on event-driven state machine as described in claim 1, characterized in that, The state processor, based on preset business logic for responding to different events and combined with the current satellite state, executes corresponding alarm operations and completes the state transition for the next satellite state, specifically including: When the current state is waiting to join the circle and the current event is receiving telemetry, the difference between the current time and the planned entry time is calculated as the delay. If the delay is greater than the preset second threshold, a late entry alarm is generated, and the satellite's next state is changed to within the circle. When the current state is "in the circle" and the current event is "timeout with no data", record the current time as the interruption start time, mark the start of the interruption, and transition the satellite to the next state as "telemetry interruption". When the current state is "in the circle" and the current event is "reaching the planned exit time", the difference between the planned exit time and the latest telemetry time is calculated as the lead time. If the lead time is greater than the preset third threshold, an early exit alarm is generated, and the satellite's next state is changed to "out of the circle". When the current state is telemetry interruption and the current event is telemetry received, calculate the difference between the current time and the interruption start time as the total interruption duration, generate a communication interruption recovery alarm, clear the interruption start time, and change the satellite's next state to within the circle; When the current state is telemetry interrupted and the current event is the arrival of the planned out-of-circle time, a corresponding alarm is generated, and the next state of the satellite is changed to out-of-circle.

6. The satellite telemetry monitoring and alarm method based on event-driven state machine as described in claim 1, characterized in that, The system actively generates current events through a timer scheduler, enabling monitoring of situations where no events occur.

7. A satellite telemetry monitoring and alarm system based on an event-driven state machine, characterized in that, include: The satellite planning arc modeling module is configured to model the lifecycle of a satellite planning arc as an event-driven finite state machine containing four states and three types of events. The satellite planning arc is a time window pre-calculated and allocated by the ground telemetry and control system based on satellite orbit prediction for performing telemetry reception, remote control transmission, or data transmission tasks, including the planned entry time and the planned exit time. The four states include waiting to enter the circle, inside the circle, telemetry interrupted, and outside the circle; The three types of events include receiving telemetry, timeout with no data, and reaching the planned out-of-circle time. The event-driven finite state machine also includes a state machine context, which is a context object maintained for each plan of each satellite. The specific fields of the context object include satellite identifier, plan identifier, current state, latest telemetry time and interruption start time. The data acquisition module is configured to acquire the satellites to be monitored, the planned times, and the corresponding latest telemetry data. The event generation module is configured to generate the current event based on the required monitored satellites, the scheduled time, and the preset logical relationship between the latest telemetry data and the current time. Specifically, this includes: A telemetry received event is generated when the latest telemetry time is not empty and is determined to be valid new data. When the satellite is within the orbit and the difference between the current time and the latest telemetry time is greater than a preset first threshold, a timeout no data event is generated. When the current time is later than the planned exit time, an event indicating that the planned exit time has been reached is generated. The state processor execution module is configured to route the generated current event to a state processor corresponding to the current state of the satellite to be monitored. The state processor, based on the preset business logic for responding to different events and combined with the current state of the satellite, executes the corresponding alarm operation and completes the state transition of the satellite to the next state.

Images